🥇DRP előkészítése — ne felejtse el figyelembe venni a meteoritokat

Még katasztrófa idején is mindig van idő egy csésze teára.

DRP (disaster recovery plan) - ez egy dolog, amely ideális esetben soha nem lesz szükséges. De ha a házassági időszakban a hódok átvágják a fő optikai kábelt, vagy a junior admin leejti a produktív adatbázist, akkor biztosan szeretné, ha lenne egy előre elkészített terve arra, hogy mit kell kezdeni mindezzel a káosszal.

Míg a kliensek pánikba esve csörgetik a technikai támogatás telefonját, a junior a ciánokat keresi, te bölcs arckifejezéssel felbontod a piros borítékot, és elkezdesz mindent rendbe tenni.

Ebben a bejegyzésben szeretném megosztani a tanácsaimat arról, hogyan kell írni a DRP-t, és mit kell tartalmaznia. Emellett az alábbi dolgokat is megvizsgáljuk:

Tanuljunk meg úgy gondolkodni, mint a gazemberek.
Megvizsgáljuk, milyen haszna van egy csésze teának a világvégén.
Átgondoljuk a DRP kényelmes struktúráját.
Meghatározzuk, hogyan kell tesztelni.

Milyen cégek számára lehet ez hasznos.

Nagyon nehéz meghúzni a határt, amikor az IT részleg hasonló dolgokra kezd szükséget érezni. Azt mondanám, hogy a DRP garantáltan szükséges, ha:

A szerver, alkalmazás leállása vagy egy adatbázis elvesztése jelentős üzleti veszteségeket okoz.
Van egy teljes IT-osztályod. Úgy értem, egy olyan osztály, amely egy teljes céget képvisel, saját költségvetéssel, nem pedig csak néhány fáradt alkalmazott, akik hálózatot állítanak be, vírusokat törölnek és nyomtatókat töltenek be.
Van valós költségvetésed, legalább részleges mentésre sürgősségi helyzet esetén.

Amikor az IT-osztály hónapokig könyörög legalább néhány HDD-ért egy régi szerverbe a biztonsági mentésekhez, valószínűleg nem fogod tudni szervezni a leesett szolgáltatás teljes migrálását a tartalék kapacitásokra. Bár itt is a dokumentáció nem árt.

A dokumentáció fontos.

Kezdj a dokumentációval. Tegyük fel, hogy a szolgáltatásod egy Perl alapú skriptre épül, amit három admin generáción keresztül írtak, és senki sem tudja, hogyan működik. A felhalmozott technikai adósság és a dokumentáció hiánya elkerülhetetlenül nemcsak a térdedet, hanem más végtagjaidat is el fogja találni, ez inkább idő kérdése.

Miután jó leírást készített a szolgáltatás összetevőiről, vegye át a hibastatisztikákat. Szinte biztos, hogy teljesen tipikusak lesznek. Például időnként megtelik a lemez, ami a csomópont leállásához vezet a kézi tisztításáig. Vagy a kliensszolgáltatás elérhetetlenné válik, mert valaki megint elfelejtette meghosszabbítani a tanúsítványt, és a Let’s Encrypt beállításával nem tudott vagy nem akart foglalkozni.

Gondolkodj, mint egy diverzáns

A legnehezebb rész a korábban soha nem tapasztalt hibák előrejelzése, amelyek potenciálisan teljesen letartóztathatják a szolgáltatását. Itt általában a kollégáimmal gonosztevőket játszunk. Készítsen sok kávét és valami finomat, és zárja be magát a tárgyalóba. Csak győződjön meg róla, hogy abban a tárgyalóban zárta be azokat a mérnököket, akik maguk állították be a célzott szolgáltatást vagy rendszeresen dolgoznak vele. Ezután vagy a táblán, vagy papíron elkezd rajzolni minden lehetséges szörnyűséget, ami történhet a szolgáltatásával. Nem szükséges részletezni egészen a konkrét takarítónőig és a kábelek kihúzásáig, elegendő megvizsgálni a „Helyi hálózat integritásának megsértése” forgatókönyvet.

Általában a legtöbb tipikus vészhelyzet a következő típusokba sorolható:

Hálózati hiba
Operációs rendszer szolgáltatásainak hibája
Alkalmazás hibája
Hardver hiba
Virtualizációs hiba

Egyszerűen vegye sorra az egyes típusokat, és nézze meg, mi alkalmazható az Ön szolgáltatására. Például leállhat és nem indulhat újra az Nginx démon - ez az operációs rendszer hibái közé tartozik. Ritka helyzet, ami a webalkalmazását működésképtelenné teszi - a szoftver hibája. Ennek a szakasznak a feldolgozása során fontos, hogy a hiba diagnózisát is kidolgozzuk. Hogyan lehet megkülönböztetni a virtualizáció alatt megfagyott interfészt egy elromlott híd és hálózati hiba esetén, például? Ez fontos ahhoz, hogy gyorsan megtalálja a felelősöket, és elkezdje őket húzni, amíg a hiba el nem hárul.

Miután a tipikus problémákat rögzítettük, töltünk még egy kávét, és elkezdjük megvizsgálni a legfurcsább forgatókönyveket, amikor bizonyos paraméterek jelentősen túllépik a normát. Például:

Mi történik, ha az aktív csomópont időpontja egy perccel visszacsúszik a klaszter többi csomópontjához képest?
Mi történik, ha előre csúszik az idő, és ha tíz évvel?
Mi történik, ha a klaszter csomópontja a szinkronizálás során hirtelen elveszíti a hálózatot?
Mi fog történni, ha két csomópont nem tudja megosztani a vezetést a hálózaton belüli ideiglenes elszigetelés miatt?

Ebben a szakaszban nagyon segít a visszafelé történő megközelítés. Válaszd ki a csapat legelkötelezettebb tagját, aki beteg ötletekkel rendelkezik, és adj neki feladatot, hogy a lehető legrövidebb időn belül szabotázsot hajtson végre, amely tönkreteszi a szolgáltatást. Ha nehéz diagnosztizálni — annál jobb. Nem fogod elhinni, milyen furcsa és klassz ötleteket osztanak meg a mérnökök, ha lehetőségük van arra, hogy valamit tönkretegyenek. Ha pedig tesztkörnyezetet is ígérsz nekik — az még jobb.

Mi ez a DRP?!

Tehát meghatároztad a fenyegetési modellt. Figyelembe vetted a helyi lakosokat is, akik optikai szálakat vágnak a rézért, és a katonai radart, amely szigorúan péntekenként 16:46-kor hajtja végre a rádióhíd vonalát. Most meg kell értened, mit kell tenni mindezzel.

A feladatod az lesz, hogy megírd azokat a piros borítékokat, amelyeket vészhelyzet esetén kell felnyitni. Azonnal számolj azzal, hogy amikor (nem ha!) minden elromlik, csak a legkevésbé tapasztalt gyakornok lesz a közelben, akinek a kezét erősen remegni fog a történtek borzalma miatt. Nézd meg, hogyan valósítják meg a vészhelyzeti táblákat az orvosi rendelőkben. Például, mit kell tenni anafilaxiás sokk esetén. Az egészségügyi személyzet fejből tudja az összes protokollt, de amikor egy ember éppen meghal, gyakran teljesen tehetetlenül kapkodnak mindent. Erre a falon egy világos utasítás található, amely pontokat tartalmaz, mint például „nyisd ki a pakka ezt” és „jusson be annyi egység a gyógyszerből intravénásan”.

Vészhelyzetben nehéz gondolkodni! Egyszerű utasításokra van szükség a gerincvelővel történő feldolgozáshoz.

Jó DRP néhány egyszerű blokkból áll:

Kit kell értesíteni a vészhelyzet kezdetéről. Ez fontos ahhoz, hogy a folyamatot a lehető legjobban párhuzamosítsuk.
Hogyan diagnosztizáljunk helyesen — végrehajtjuk a nyomvonal-ellenőrzést, megnézzük a systemctl status szolgáltatásnév és így tovább.
Mennyi időt lehet eltölteni minden szakaszra. Ha nem tudod a SLA időn belül kézzel megjavítani — a virtuális gépet megölni és az előző napi biztonsági mentésből újból telepíteni kell.
Hogyan lehet biztosítani, hogy a vészhelyzet véget ért.

Ne felejtsük el, hogy a DRP (Disaster Recovery Plan) akkor kezdődik, amikor a szolgáltatás teljesen leáll, és azzal ér véget, hogy helyreáll a működése, még ha csökkentett hatékonysággal is. Csak az, ha veszítünk a tartalékból, nem aktiválhatja a DRP-t. Ezenkívül a DRP-ben belefoghatsz egy csésze tea elkészítésébe is. Komolyan. Statisztikák szerint nagyon sok baleset, amely kellemetlen, kataklizmikus méreteket ölt, amiatt történik, hogy a személyzet pánikba esik, és valamit megpróbál javítani, miközben véletlenül tönkreteszi az egyetlen élő adatcsomópontot, vagy végleg kipusztítja a klasztert. Általában 5 perc a teás csésze készítésére ad némi időt a megnyugvásra és a történtek elemzésére.

Ne keverje a DRP-t a rendszer útlevelével! Ne terhelje meg felesleges adatokkal. Csak lehetőséget kell adnia arra, hogy gyorsan és kényelmesen hiperhivatkozásokon át eljuthasson a dokumentáció megfelelő szakaszához, és bővebben olvashasson a szolgáltatás architektúrájának szükséges elemeiről. A DRP-ben pedig csak közvetlen utasításokat adjon arról, hogy hol és hogyan csatlakozhat, konkrét parancsokkal a másoláshoz és beillesztéshez.

Hogyan teszteljük helyesen

Győződjön meg arról, hogy bármely felelős munkatárs képes végrehajtani az összes pontot. A legkritikusabb pillanatban előfordulhat, hogy az engineernek nincsenek jogai a megfelelő rendszerhez történő hozzáféréshez, hiányoznak a jelszavak a szükséges fiókhoz, vagy fogalma sincs, mit jelent a „Csatlakozzon a szolgáltatás vezérlőpultjához a központi irodán keresztül proxy-n keresztül”. Minden pontnak rendkívül egyszerűnek kell lennie.

Helytelen — „Lépjen be a virtualizációba, és indítsa újra a halott csomópontot”
Helyes — „Csatlakozzon a webfelületen a virt.example.com-hoz, a csomópont szakaszban indítsa újra a hibát okozó csomópontot.”

Ne engedje a kétértelműségeket. Ne felejtsék el a megijedt gyakornokot.

Kötelezően tesztelje a DRP-t. Ez nem csak egy ellenőrzőlista — ez az, ami lehetővé teszi önnek és ügyfeleinek, hogy gyorsan kilépjenek a kritikus helyzetből. Optimális esetben ezt többször érdemes elvégezni:

Egy szakértő és néhány gyakornok dolgozik egy tesztalapú rendszeren, amely a lehető legjobban tükrözi a valós szolgáltatást. A szakértő különböző módokon megzavarja a szolgáltatást, és lehetőséget ad a gyakornokoknak, hogy a DRP szerint helyreállítsák. Minden probléma, dokumentációs zavar és hiba feljegyzésre kerül. A gyakornokok képzése után a DRP kiegészítésekre és egyszerűsítésekre kerül a nem világos helyeken.
Valós szolgáltatás tesztelése. Valójában soha nem lehet tökéletes másolatot létrehozni egy valódi szolgáltatásról. Ezért évente pár alkalommal tervezetten le kell állítani a szerverek egy részét, bontani a kapcsolatokat és más, a fenyegetések listáján szereplő zavarokat kell szimulálni a helyreállítási folyamat értékelése érdekében. Jobb egy tervezett zavar 10 percig éjjel, mint egy hirtelen leállás több órán át csúcsidőben adatvesztéssel.
Valós zavar elhárítás. Igen, ez is a tesztelés része. Ha olyan zavar történik, amely nem szerepel az fenyegetések listáján, akkor szükséges a DRP kiegészítése és kidolgozása a kivizsgálás eredményei alapján.

Kulcsfontosságú pontok

Ha valami rossz dolog megtörténhet, az nemcsak meg fog történni, hanem a lehető legkatasztrofálisabb forgatókönyv szerint fog végbemenni.
Győződjön meg arról, hogy rendelkezik erőforrásokkal a zavarok terhelésének áttevődésére.
Győződjön meg arról, hogy van biztonsági másolat, amit automatikusan létrehoz, és rendszeresen ellenőrzi a konzisztenciáját.
Gondoljon át tipikus fenyegetési forgatókönyveket.
Adja lehetőséget a mérnököknek, hogy nem tipikus módon gondolkodjanak a szolgáltatás leállításáról.
A DRP-nek egyszerű és világos utasításnak kell lennie. Minden bonyolult diagnózis csak azután bonyolódik, hogy a kliensek helyreállították a szolgáltatást, még akkor is, ha tartalék kapacitáson.
Adja meg a kulcsfontosságú telefonszámokat és kapcsolatokat a DRP-ben.
Rendszeresen tesztelje az alkalmazottakat a DRP megértéséről.
Rendszeresen szervezzen tervezett zavarokat a termelés során. Az állványok nem helyettesíthetik az összeset.