Vállalati failover megoldások értékelése

A számlázás működik, a rendeléskezelés működik, a raktár is halad - egészen addig, amíg egy központi szerver, internetkapcsolat vagy alkalmazás kiesik. Ekkor derül ki, hogy ki tud még dolgozni, melyik adat érhető el, és mely folyamatok állnak le teljesen. A vállalati failover megoldások értékelése ezért nem elsősorban infrastruktúra-vásárlási feladat. Annak vizsgálata, hogy egy technikai hiba milyen gyorsan válik üzleti problémává.

Egy 20-500 fős vállalatnál a leállás ritkán látványos az első percben. Először valaki nem tud címkét nyomtatni. A webshopból érkező rendelés nem kerül át az ügyviteli rendszerbe. A termelési tervhez szükséges adat csak egy megosztott mappában van, amely éppen nem elérhető. Néhány óra múlva már telefonok, e-mailek és kézzel vezetett listák helyettesítik a rendszereket. Ez nemcsak bevételkiesés: hibákat, késéseket, túlórát és bizonytalan vezetői döntéseket okoz.

Mit kell valójában értékelni?

A failover olyan tartalék működési mechanizmus, amely egy meghibásodott komponens helyett másik erőforrást állít munkába. Lehet másodlagos szerver, alternatív internetkapcsolat, tartalék hálózati eszköz, adatbázis-replika vagy felhőben futó környezet. A technikai definíció azonban csak a kiindulópont.

A vezetői kérdés inkább ez: ha ez a rendszer nem érhető el, pontosan mi nem történhet meg a vállalatban? Nem minden rendszer érdemel azonos szintű védelmet. Egy belső archívum néhány órás kiesése lehet kezelhető. A rendelésfeldolgozás, a raktári készletinformáció, a gyártási vezérlés vagy a számlázási kapcsolat kiesése viszont hamar közvetlen üzleti kockázattá válhat.

A jó értékelés tehát nem azzal kezdődik, hogy kell-e két szerver. Előbb fel kell rajzolni, hogyan halad át egy rendelés, munkalap vagy szállítási igény a rendszereken és az embereken. Gyakran itt látszik meg, hogy a legnagyobb függőség nem is az alkalmazás, hanem egyetlen integráció, egy közös fájlmegosztás vagy egy munkatárs által ismert kézi kerülőút.

A vállalati failover megoldások értékelésének első lépése: üzleti hatás

Érdemes néhány konkrét üzleti forgatókönyvvel dolgozni, nem általános kérdésekkel. Mi történik például, ha a vállalati internet négy órára kiesik egy hétfő reggelen? Tud a raktár komissiózni? Megérkeznek a webshoprendelések? Elérik az értékesítők az ügyféladatokat? Tud-e a pénzügy számlát kiállítani vagy banki adatot ellenőrizni?

Ugyanilyen fontos az alkalmazáshiba vizsgálata. Ha az ERP elérhető, de a webshop és az ERP közötti kapcsolat áll le, a csapat észreveszi ezt azonnal? A rendelések sorba állnak, elvesznek, vagy a kollégák kézzel kezdik újra rögzíteni őket? A kézi rögzítés rövid távon segítségnek tűnhet, de később duplikációhoz, hibás készlethez és egyeztetési munkához vezethet.

A hatás felmérésénél négy nézőpontot célszerű külön kezelni:

• bevétel és ügyfélkiszolgálás: elmarad-e rendelés, szállítás vagy számlázás;
• működés: leáll-e a raktár, termelés, beszerzés vagy ügyfélszolgálat;
• adat és megfelelőség: sérülhet-e adat, elveszhet-e tranzakció, sérülhet-e naplózási kötelezettség;
• emberi terhelés: ki kezeli a hibát, ki tud kerülőfolyamatot alkalmazni, és meddig tartható fenn ez a helyzet.

Ezek alapján már különbséget lehet tenni kellemetlen és elfogadhatatlan kiesés között. Ez a különbség határozza meg, hogy egy rendszerhez elegendő-e a dokumentált helyreállítás, vagy automatikus átállásra van szükség.

RTO és RPO: két érték, amelyet üzleti nyelvre kell fordítani

A failover-tervezésben gyakran szerepel két rövidítés. Az RTO, vagyis helyreállítási időcél azt mondja meg, mennyi idő alatt kell újra használhatóvá válnia egy szolgáltatásnak. Az RPO, vagyis helyreállítási pontcél azt jelöli, mennyi adatvesztés fogadható el.

A számok önmagukban keveset érnek. Az, hogy egy rendszer RTO-ja négy óra, csak akkor értelmezhető, ha a vállalat tudja, mi történik ez alatt a négy óra alatt. Ha reggel nyolc és dél között ez a raktári kiszállítás leállását jelenti, a cél túl laza lehet. Ha egy ritkán használt riportkörnyezetet érint, akár indokolt is lehet.

Az RPO-nál ugyanez a helyzet. Egy órányi adatvesztés elfogadható lehet bizonyos dokumentumtáraknál, de nem egy olyan rendelési vagy gyártási rendszerben, ahol percenként új tranzakciók keletkeznek. Ilyenkor nem elég az éjszakai mentés. Replikációra, gyakoribb mentésre vagy olyan alkalmazási logikára lehet szükség, amely biztosítja a tranzakciók visszaállíthatóságát.

A túl szigorú céloknak ára van. Az azonnali átállás, a több helyszínen fenntartott kapacitás és a folyamatos adatszinkron jelentős beruházást és üzemeltetési fegyelmet igényel. Nem cél minden rendszert banki szintű rendelkezésre állásra tervezni. A cél az, hogy a védelem arányban legyen a kiesés valós üzleti következményével.

Nem elég a tartalék szerver, ha a függőségek egy helyen maradnak

Sok szervezetnek van mentése, esetleg másodlagos szervere is, mégis egyetlen hibapont marad a működésben. A másodlagos környezet hiába indul el, ha ugyanazt az internetkapcsolatot használja, ugyanarra a hitelesítési szolgáltatásra támaszkodik, vagy ugyanaz az integrációs szolgáltatás köti össze a rendszereket.

A vizsgálatnak ezért ki kell terjednie a teljes láncra: hálózatra, tápellátásra, DNS-re, identitáskezelésre, adatbázisra, alkalmazásokra, külső szolgáltatókra és az integrációkra is. Egy webshop például lehet elérhető, miközben a fizetési szolgáltató, a készletinformáció vagy a fuvarozói kapcsolat nem működik. Üzleti szempontból ez részleges, de nagyon is valós kiesés.

A manuális folyamatok szintén függőséget jelentenek. Ha egy munkatárs minden délután exportál egy fájlt, majd feltölti egy partner rendszerébe, akkor az illető távolléte és a fájlmegosztás hibája is leállást okozhat. Itt a failover részben technikai kérdés, részben pedig folyamat-újratervezés. Lehet, hogy a helyes válasz nem egy drága magas rendelkezésre állású környezet, hanem a kézi átadás megszüntetése és az integráció ellenőrizhetővé tétele.

Automatikus vagy kézi átállás?

Az automatikus failover gyorsabb, de összetettebb. Akkor hasznos, ha a kiesés percek alatt mérhető üzleti kárt okoz, és a szolgáltatás állapota biztonságosan ellenőrizhető. Például egy ügyfelek által közvetlenül használt online szolgáltatásnál vagy folyamatos termelési adatkapcsolatnál indokolt lehet.

A kézi átállás lassabb, viszont sok esetben egyszerűbb, olcsóbb és jobban kontrollálható. Egy belső üzleti alkalmazásnál, amelynek néhány órás helyreállítása elfogadható, megfelelő dokumentációval és kijelölt felelősökkel ez lehet a racionális döntés. A kulcs az, hogy a folyamat valóban végrehajtható legyen nyomás alatt is, ne csak egy régi technikai leírásban létezzen.

A két modell között hibrid megoldások is vannak. Az internetkapcsolat automatikusan válthat tartalék vonalra, miközben egy kevésbé kritikus üzleti rendszer helyreállítása továbbra is jóváhagyáshoz és kézi indításhoz kötött. Ez gyakran jobban illeszkedik a valós kockázatokhoz, mint az automatikus átállás erőltetése mindenhol.

A teszt az értékelés legfontosabb része

A nem tesztelt failover inkább feltételezés, mint működőképesség. A mentésről is csak akkor derül ki, hogy használható, amikor abból ténylegesen visszaállítanak adatot. Ugyanez igaz az átállási tervekre: a másodlagos környezet elindulhat, de lehet, hogy a felhasználók nem tudnak belépni, egy partneri kapcsolat blokkolja az új IP-címet, vagy a rendszer régebbi adatállapotot mutat.

A tesztnek üzleti forgatókönyvet kell követnie. Nem elég azt igazolni, hogy egy virtuális gép elindult. Ellenőrizni kell, hogy a rendelés létrejön-e, átkerül-e a következő rendszerbe, megjelenik-e a raktárban, elkészül-e a bizonylat, és helyreáll-e a riportolás. A teszt során keletkező eltérések különösen értékesek, mert megmutatják azokat a rejtett függőségeket, amelyeket a rendszerrajzok gyakran nem tartalmaznak.

A tesztelésnek felelőse, jegyzőkönyve és javítási listája legyen. Ha egy kritikus lépés csak egy külső szakértő fejében van meg, vagy a hozzáférés egyetlen munkatárshoz kötődik, akkor nem alakult ki valódi üzletmenet-folytonosság.

Mire utal, ha az átállás túl bonyolult?

Ha egy szolgáltatás helyreállításához sok táblázat, telefonhívás és improvizáció kell, az gyakran nem pusztán infrastruktúraprobléma. Jelezheti, hogy a folyamat túl sok rendszeren halad át, az integrációk nincsenek felügyelve, vagy a felelősségi körök nem világosak. A failover értékelése ezért jó alkalom arra is, hogy a vállalat újra megnézze, miért ezen az úton mozog az információ.

Egy jól megtervezett megoldás nem feltétlenül látványos. Sokszor abban mutatkozik meg, hogy egy hiba esetén a munkatársak tudják, mi történik, mit kell tenniük, és melyik adat tekinthető hitelesnek. Ez a kontroll csökkenti a pánikot, a felesleges kézi munkát és az ügyfelek felé vállalt kockázatot.

A következő kiesés nem jó időpont annak kiderítésére, hogy a tartalék megoldás valóban működik-e. Érdemes akkor végigvenni a kritikus folyamatokat, amikor még van idő megkérdezni: mi áll le, ki érintett, mi pótolható, és mi az, amihez nincs elfogadható kerülőút.