Még egy katasztrófa idején is mindig jut idő egy csésze teára
DRP (katasztrófa utáni helyreállítási terv) egy olyan dolog, amelyre ideális esetben soha nem lesz szükség. De ha a párzási időszakban vándorló hódok hirtelen átrágják a gerinc optikai szálát, vagy egy fiatal admin megszakítja a termelőbázist, akkor mindenképp biztosra kell mennie, hogy lesz egy előre elkészített terve, mit kezdjen ezzel a sok szégyennel.
Miközben a pánikba esett ügyfelek elkezdik levágni a technikai támogatási telefonokat, a junior ciánt keres, Ön bölcsen kinyitja a piros borítékot, és elkezd mindent rendbe tenni.
Ebben a bejegyzésben javaslatokat szeretnék megosztani a DRP megírására és annak tartalmára. A következő dolgokat is megvizsgáljuk:
- Tanuljunk meg gonoszként gondolkodni.
- Nézzük egy csésze tea előnyeit az apokalipszis idején.
- Gondoljunk egy kényelmes DRP-struktúrára
- Lássuk, hogyan teszteljük
Mely cégeknek lehet ez hasznos?
Nagyon nehéz meghúzni a határt, amikor az informatikai részlegnek szüksége van ilyesmire. Azt mondanám, hogy feltétlenül szüksége van DRP-re, ha:
- Egy szerver, alkalmazás leállítása vagy egyes adatbázisok elvesztése jelentős veszteségekhez vezet a vállalkozás egésze számára.
- Teljes értékű informatikai részleggel rendelkezik. Értelemszerűen egy részleg a cég teljes értékű egysége formájában, saját költségvetéssel, és nem csak néhány fáradt, hálózatot rakó, vírustisztítás és nyomtatók utántöltő alkalmazott.
- Reális költségvetése van legalább részleges elbocsátásra vészhelyzet esetén.
Amikor az informatikai részleg hónapok óta könyörög legalább néhány HDD-ért egy régi szerverre biztonsági mentések céljából, nem valószínű, hogy sikerül megszervezni egy meghibásodott szolgáltatás teljes körű áthelyezését a kapacitás lefoglalására. Bár itt a dokumentáció nem lesz felesleges.
Fontos a dokumentálás
Kezdje a dokumentációval. Tegyük fel, hogy a szolgáltatásod egy Perl-szkripten fut, amelyet három generációval ezelőtt írtak a rendszergazdák, de senki sem tudja, hogyan működik. A felgyülemlett műszaki adósság és a dokumentáció hiánya óhatatlanul nem csak térdbe, hanem más végtagba is lövi, ez inkább idő kérdése.
Miután megfelelő leírást kapott a szolgáltatás összetevőiről, nézze meg a baleseti statisztikákat. Szinte biztosan teljesen tipikusak lesznek. Például a lemez időről időre megtelik, ami a csomópont meghibásodását okozza, amíg manuálisan meg nem tisztítják. Vagy az ügyfélszolgáltatás elérhetetlenné válik, mert valaki megint elfelejtette megújítani a tanúsítványt, és a Let's Encrypt nem tudta vagy nem akarta konfigurálni.
Gondolatok, mint egy szabotőr
A legnehezebb az olyan balesetek előrejelzése, amelyek még soha nem történtek, de amelyek potenciálisan teljesen összeomolhatják a szolgáltatást. Itt a kollégáimmal általában gazembereket játszunk. Igyon sok kávét és valami finomat, és zárja be magát egy tárgyalóterembe. Csak győződjön meg arról, hogy ugyanazokon a tárgyalásokon zárja be azokat a mérnököket, akik maguk fejlesztették ki a célszolgáltatást, vagy rendszeresen dolgoznak vele. Ezután akár a táblára, akár a papírra elkezdi lerajzolni az összes lehetséges borzalmat, ami a szolgálatával történhet. Nem szükséges részletezni egy konkrét takarítónőt és a kábelek kihúzását, elég, ha figyelembe vesszük a „Helyi hálózat integritásának megsértése” forgatókönyvet.
A legtöbb tipikus vészhelyzet a következő típusokba sorolható:
- Hálózati hiba
- Az operációs rendszer szolgáltatásainak meghibásodása
- Alkalmazáshiba
- Vashiba
- Virtualizációs hiba
Csak nézze meg az egyes típusokat, és nézze meg, mi vonatkozik az Ön szolgáltatására. Például az Nginx démon leeshet, de nem emelkedhet - ez az operációs rendszer hibáit jelenti. A webalkalmazás meghibásodását okozó ritka helyzet a szoftverhiba. Ezen a szakaszon való munka során fontos kidolgozni a probléma diagnózisát. Hogyan lehet megkülönböztetni például a befagyott interfészt a virtualizáción a leesett cis-meghajtótól és a hálózati meghibásodástól. Ez fontos ahhoz, hogy gyorsan megtalálják a felelősöket, és elkezdjék húzni a farkukat, amíg a baleset meg nem oldódik.
Miután feljegyeztük a tipikus problémákat, töltünk még egy kávét, és elkezdjük mérlegelni a legfurcsább forgatókönyveket, amikor egyes paraméterek kezdenek messze túllépni a normán. Például:
- Mi történik, ha az aktív csomóponton lévő idő egy perccel visszalép a fürt többi részéhez képest?
- Mi van, ha az idő előrehalad, mi van, ha 10 évvel?
- Mi történik, ha egy fürtcsomópont hirtelen elveszíti a hálózatát a szinkronizálás során?
- Mi történik, ha két csomópont nem osztozik a vezetésen, mivel átmenetileg elszigetelődnek egymástól a hálózaton?
Ebben a szakaszban a fordított megközelítés nagyon hasznos. Fogod a csapat legmakacsabb tagját beteges fantáziával, és megbízod vele, hogy a lehető legrövidebb időn belül szervezzen egy szabotázst, amely lerombolja a szolgáltatást. Ha nehéz diagnosztizálni, még jobb. Nem fogod elhinni, milyen furcsa és menő ötleteket találnak a mérnökök, ha ötletet adsz nekik, hogy eltörjenek valamit. És ha megígérsz nekik egy próbapadot erre, az teljesen rendben van.
Mi ez a tiéd DRP?!
Tehát meghatározta a fenyegetési modelljét. Figyelembe vették a helyi lakosokat is, akik optikai kábeleket vágnak réz után, és egy katonai radart, amely szigorúan péntekenként 16:46-kor ejti le a rádiórelé vezetéket. Most meg kell értenünk, mit tegyünk mindezzel.
Az Ön feladata, hogy megírja azokat a nagyon piros borítékokat, amelyeket vészhelyzetben kinyitnak. Azonnal számíts rá, hogy amikor (nem ha!) mindennek vége szakad, csak a legtapasztalatlanabb gyakornok lesz a közelben, akinek hevesen remeg a keze a történések rémületétől. Nézze meg, hogyan alkalmazzák a vészhelyzeti jelzéseket az orvosi rendelőkben. Például mit kell tenni anafilaxiás sokk esetén. Az egészségügyi személyzet fejből ismeri az összes protokollt, de amikor egy közelben lévő ember elkezd meghalni, nagyon gyakran mindenki tehetetlenül kapaszkodik mindenbe, ami a látókörébe kerül. Ehhez egyértelmű utasítások vannak a falon, olyan tételekkel, mint „nyisd ki az ilyen és ehhez hasonlók csomagját” és „adjon be annyi egységnyi gyógyszert intravénásan”.
Vészhelyzetben nehéz gondolkodni! Egyszerű utasításoknak kell lenniük a gerincvelő elemzéséhez.
Egy jó DRP több egyszerű blokkból áll:
- Kit kell értesíteni a baleset kezdetéről. Ez azért fontos, hogy az eliminációs folyamat a lehető legnagyobb mértékben párhuzamos legyen.
- Hogyan kell helyesen diagnosztizálni - végezzen nyomkövetést, nézze meg a systemctl állapot szolgáltatásnevét és így tovább.
- Mennyi időt tölthet az egyes színpadokon? Ha nincs ideje manuálisan kijavítani az SLA-időn belül, a virtuális gép megsemmisül, és visszakerül a tegnapi biztonsági másolatból.
- Hogyan győződjön meg arról, hogy a baleset véget ért.
Ne feledje, hogy a DRP akkor kezdődik, amikor a szolgáltatás teljesen meghiúsul, és akkor ér véget, amikor a szolgáltatás visszaáll, még akkor is, ha a hatékonyság csökkent. A foglalás puszta elvesztése nem válthatja ki a DRP-t. Egy csésze teát is írhat a DRP-be. Komolyan. A statisztikák szerint sok baleset válik kellemetlenből katasztrofálissá, mert a munkatársak pánikszerűen rohannak megjavítani valamit, és ezzel egyidejűleg megölik az egyetlen élő, adatokkal rendelkező csomópontot, vagy végül befejezik a klasztert. Általában 5 perc egy csésze teával ad egy kis időt, hogy megnyugodjon és elemezze a történéseket.
Ne keverje össze a DRP-t és a rendszerútlevelet! Ne terhelje túl szükségtelen adatokkal. Csak tegye lehetővé, hogy a hiperhivatkozások segítségével gyorsan és kényelmesen eljusson a dokumentáció kívánt részéhez, és kibővített formában olvassa el a szolgáltatásarchitektúra szükséges szakaszait. És magában a DRP-ben csak közvetlen utasítások vannak arra vonatkozóan, hogy hol és hogyan kell kapcsolódni a másolás-beillesztés speciális parancsaival.
Hogyan kell helyesen tesztelni
Győződjön meg arról, hogy minden felelős alkalmazott képes az összes tételt kitölteni. A legdöntőbb pillanatban kiderülhet, hogy a mérnöknek nincs jogosultsága a kívánt rendszerhez való hozzáféréshez, nincsenek jelszavak a szükséges fiókhoz, vagy fogalma sincs, mi „Csatlakozzon a szolgáltatáskezelő konzolhoz proxyn keresztül a székhelye” azt jelenti. Minden pontnak rendkívül egyszerűnek kell lennie.
rossz — „Lépjen a virtualizációba, és indítsa újra a halott csomópontot”
helyesen - "Csatlakozzon a webes felületen keresztül a virt.example.com webhelyhez, a csomópontok részben indítsa újra a hibát okozó csomópontot."
Kerülje a kétértelműséget. Emlékezz a rémült gyakornokra.
Mindenképpen tesztelje a DRP-t. Ez nem csak egy bemutató terv – ez olyasvalami, amely lehetővé teszi Önnek és ügyfelei számára, hogy gyorsan kilábaljanak a kritikus helyzetből. A legjobb, ha ezt többször megteszi:
- Egy szakértő és több gyakornok dolgozik egy próbapadon, amely a lehető legjobban szimulálja a valódi szolgáltatást. A szakértő különféle módokon megszakítja a szolgáltatást, és lehetővé teszi a gyakornokoknak, hogy a DRP szerint helyreállítsák. Minden probléma, a dokumentáció kétértelműsége és hibája rögzítésre kerül. A gyakornokok képzése után a DRP kibővül és egyszerűsödik a tisztázatlan területeken.
- Tesztelés valódi szolgáltatáson. Valójában soha nem lehet valódi szolgáltatás tökéletes másolatát létrehozni. Ezért évente néhány alkalommal rutinszerűen ki kell kapcsolni néhány szervert, le kell szakítani a kapcsolatokat és egyéb katasztrófákat kell előidézni a fenyegetések listájáról a helyreállítási eljárás értékeléséhez. Az éjszaka közepén 10 percre tervezett meghibásodás jobb, mint egy többórás hirtelen meghibásodás csúcsterheléskor, adatvesztéssel.
- Valódi hibaelhárítás. Igen, ez is a tesztelés része. Ha olyan baleset történik, amely nem szerepelt a fenyegetések listáján, a DRP kiegészítése és véglegesítése szükséges a vizsgálat eredményei alapján.
Főbb pontok
- Ha megtörténhet a szar, az nemcsak megtörténik, de a lehető legkatasztrófálisabb forgatókönyv esetén is megtörténik.
- Győződjön meg arról, hogy rendelkezik erőforrásokkal a vészhelyzeti terhelésátvitelhez.
- Győződjön meg róla, hogy van biztonsági másolata, ezek automatikusan létrejönnek, és rendszeresen ellenőrzik a konzisztenciát.
- Gondolja végig a tipikus fenyegetési forgatókönyveket.
- Adja meg a mérnököknek a lehetőséget, hogy nem szabványos lehetőségeket találjanak ki a szolgáltatás nyújtására.
- A DRP-nek egyszerű és tompa utasításnak kell lennie. Minden komplex diagnosztikát csak az ügyfelek szolgáltatásának helyreállítása után végeznek el. Még ha tartalékkapacitáson is.
- Adja meg a kulcsfontosságú telefonszámokat és kapcsolatokat a DRP-ben.
- Rendszeresen ellenőrizze, hogy az alkalmazottak megértették a DRP-t.
- A termelési helyszíneken tervezett balesetek megszervezése. Az állványok nem helyettesíthetnek mindent.
Forrás: will.com