🥇Připravujeme DRP — nezapomeňte zohlednit meteorit

I během katastrofy je vždy čas na šálek čaje

DRP (plán obnovy po katastrofě) je něco, co byste ideálně nikdy neměli potřebovat. Ale pokud náhodou migranti v období páření bobři přetrhnou hlavní optické vlákno nebo junior administrátor omylem smaže produktivní databázi, definitivně chcete mít předem připravený plán, jak s tím vším naložit.

Zatímco zákazníci v panice začínají bombardovat technickou podporu telefonáty, junior hledá kyanidy, vy s moudrým výrazem otevíráte červenou obálku a začínáte všechno dávat do pořádku.

V tomto příspěvku se chci podělit o doporučení, jak napsat DRP a co by měl obsahovat. Také se podíváme na následující věci:

Naučíme se myslet jako padouch.
Probereme výhody šálku čaje během apokalypsy.
Promyslíme pohodlnou strukturu DRP.
Podíváme se, jak jej testovat.

Pro které společnosti to může být užitečné.

Je velmi těžké stanovit hranici, kdy IT oddělení začíná mít potřebu něčeho takového. Řekl bych, že DRP vám zaručeně potřebné, pokud:

Zastavení serveru, aplikace nebo ztráta nějaké databáze povede k výrazným ztrátám v podnikání jako celku.
Máte plnohodnotné IT oddělení. Má na mysli oddělení jako plnohodnotnou jednotku společnosti, s vlastním rozpočtem, a ne jen několik unavených zaměstnanců, kteří spravují síť, odstraňují viry a doplňují tonery do tiskáren.
Máte skutečný rozpočet alespoň na částečné zálohování v případě nouze.

Když IT oddělení měsíce žádá o pár HDD do starého serveru pro zálohy, je nepravděpodobné, že se vám podaří zorganizovat plnohodnotný přesun nefunkční služby na záložní kapacity. I zde však bude dokumentace zbytečně užitečná.

Dokumentace je důležitá

Začněte s dokumentací. Předpokládejme, že váš servis běží na skriptu v Perlu, který byl napsán před třemi generacemi administrátorů, a nikdo neví, jak funguje. Nahromaděný technický dluh a nedostatek dokumentace vám bezpochyby prostřelí nejen koleno, ale i další končetiny, to je spíš otázka času.

Jakmile máte dobrý popis komponent služby, získejte statistiky o výpadcích. Ty budou téměř jistě zcela typové. Například, pokud se vám občas zaplní disk, což vede k selhání uzlu, dokud není ručně vyčištěn. Nebo se stane, že zákaznický servis nebude dostupný, protože někdo zase zapomněl obnovit certifikát a Let’s Encrypt nastavit nedokázal nebo nechtěl.

Myslete jako diverzant

Nejkomplikovanější část spočívá v předpovídání těch výpadků, které ještě nikdy nenastaly, ale potenciálně mohou váš servis zcela ochromit. Zde obvykle hrajeme se spolupracovníky na padouchy. Vezměte si hodně kávy a něco dobrého k jídlu a zamkněte se v zasedačce. Jen se ujistěte, že v této stejné zasedačce máte zamčené inženýry, kteří službu sami nasazovali nebo s ní pravidelně pracují. Pak na tabuli nebo na papíře začněte kreslit všechny možné hrůzy, které se mohou s vaším servisem stát. Není nutné detailně popisovat konkrétní uklízečku a vytahování kabelů, stačí zvážit scénář „Narušení integrity místní sítě“.

Obvykle se většina typických havarijních situací vejde do následujících typů:

Selhání sítě
Selhání služeb OS
Selhání aplikace
Selhání hardwaru
Selhání virtualizace

Jednoduše projdete každý typ a zjistíte, co se vztahuje k vašemu servisu. Například může spadnout a neochotně se zvednout démon Nginx – to spadá pod selhání na straně OS. Méně obvyklá situace, která dostane vaši webovou aplikaci do nefunkčního stavu – selhání SW. Během zpracování této fáze je důležité pracovat na diagnostice problému. Jak rozlišit zablokované uživatelské rozhraní na virtualizaci od zkolabovaného Cisco a havárie v síti, například. Je to důležité pro rychlé nalezení odpovědných osob a zahájení jejich táhnutí za ocas, dokud nebude havárie odstraněna.

Jakmile jsou typické problémy zaznamenány, nalijeme si další kávu a začneme zkoumat nejpodivnější scénáře, kdy některé parametry začnou výrazně překračovat normu. Například:

Co se stane, pokud se čas na aktivním uzlu posune o minutu zpět ve srovnání s ostatními v clusteru?
A co když se čas posune dopředu, a co když o 10 let?
Co se stane, pokud během synchronizace uzel clusteru náhle ztratí síť?
A co se stane, pokud si dvě uzly nebudou moci rozdělit vedení kvůli dočasné izolaci v síti?

V této fázi velmi pomáhá přístup z opačné strany. Vezmete nejzapálenějšího člena týmu s bujnou fantazií a dáte mu úkol v co nejkratším čase naplánovat diverzi, která zastaví službu. Čím obtížněji se to bude diagnostikovat, tím lépe. Neuvěříte, jaké zvláštní a skvělé nápady inženýři navrhují, pokud jim dáte myšlenku něco rozbít. A pokud jim slíbíte testovací stanoviště, bude to ještě lepší.

Co je to váš DRP?!

Takže jste určili model hrozeb. Zohlednili jste i místní obyvatele, kteří pílí optické kabely v honbě za mědí, a vojenský radar, který shazuje radioreléovou linku přesně v pátek v 16:46. Teď musíte pochopit, co s tím vším dělat.

Vaším úkolem je napsat ty červené obálky, které se otevřou v případě nouze. Počítejte s tím, že až (ne pokud!) se všechno pokazí, bude poblíž jen nejméně zkušený stážista, kterému se budou ruce trhat hrůzou. Podívejte se, jak jsou realizovány nouzové tabulky v lékařských ordinacích. Například, co dělat v případě anafylaktického šoku. Zdravotnický personál zná všechny protokoly zpaměti, ale když někdo vedle umírá, často se bezradně chytají všeho, co mají po ruce. Na stěně proto visí jasný pokyn s body jako „otevřít balení toho a toho“ a „vstříknout intravenózně tolik a tolik jednotek léku“.

V nouzové situaci se těžko přemýšlí! Musí existovat jednoduché instrukce pro zpracování mozkovou substantivou.

Dobrý DRP se skládá z několika jednoduchých bloků:

Koho upozornit na začátek havárie. To je důležité pro co největší paralelizaci procesu odstranění.
Jak správně diagnostikovat — provádíme trasování, díváme se na systemctl status servicename a tak dále.
Kolik času lze strávit na každé fázi. Pokud se vám nedaří opravit ručně v rámci SLA — virtuální stroj je zlikvidován a obnovuje se z včerejší zálohy.
Jak se ujistit, že je havárie ukončena.

Pamatujte, že DRP začíná, když služba úplně selže, a končí obnovením funkčnosti, i když se sníženou efektivitou. Pouhá ztráta rezervace by neměla aktivovat DRP. Můžete do DRP zahrnout i šálek čaje. Opravdu. Podle statistik se mnohé havárie mění z nepříjemných na katastrofické, protože personál v panice začíná něco opravovat, přičemž ničí poslední živou nodu s daty nebo definitivně ničí cluster. Obvykle pět minut na šálek čaje vám dá čas na uklidnění a analýzu situace.

Nesmíte zaměňovat DRP a systémový pas! Nepřeplňujte jej zbytečnými údaji. Stačí umožnit rychlé a pohodlné přechody na příslušné části dokumentace prostřednictvím hypertextových odkazů a číst o důležitých částech architektury služby v rozšířeném formátu. V samotném DRP by měly být pouze přímé pokyny, kam a jak se připojit s konkrétními příkazy na kopírování.

Jak správně testovat

Ujistěte se, že každý odpovědný zaměstnanec je schopen splnit všechny body. V nejkritičtějším okamžiku může být, že inženýr nemá přístupová práva do potřebného systému, chybějí mu hesla k potřebným účtům, nebo nemá ponětí, co znamená „Připojte se na konzoli řízení služby přes proxy v centrále“. Každý bod musí být naprosto jednoduchý.

Špatně — „Přejděte na virtualizaci a restartujte mrtvou nodu“
Správně — „Připojte se přes webové rozhraní na virt.example.com, v části nody proveďte restart nodu, která hlásí chybu“.

Nedovolte dvojznačnosti. Pamatujte na vystrašeného stážistu.

Povinně testujte DRP. Není to jen plán pro forma — to, co vám a vašim klientům umožní rychle se dostat z kritické situace. Optimálně to udělejte několikrát:

Jeden expert a několik stážistů pracují na testovacím standu, který co nejvíce imituje skutečnou službu. Expert narušuje službu různými způsoby a dává stážistům možnost ji obnovit podle DRP. Všechny problémy, nejasnosti v dokumentaci a chyby jsou zaznamenány. Po školení stážistů je DRP doplněno a zjednodušeno na nejasných místech.
Testování na reálném serveru. Ve skutečnosti nikdy nelze vytvořit dokonalou kopii skutečné služby. Proto je třeba několikrát ročně plánovaně vypnout část serverů, přerušit připojení a provádět další havárie ze seznamu hrozeb, aby se posoudil proces obnovení. Lepší plánovaná havárie na 10 minut uprostřed noci, než náhlé selhání na několik hodin během špičky s ztrátou dat.
Skutečné odstranění havárie. Ano, to je také součást testování. Pokud dojde k havárii, která se nenacházela v seznamu hrozeb, je třeba dodatečně doplnit a upravit DRP na základě výsledků jejího vyšetřování.

Klíčové body

Pokud se může stát problém, nejenže se stane, ale stane se to tím nejkatastrofálnějším scénářem.
Ujistěte se, že máte zdroje pro havarijní přetížení.
Ujistěte se, že máte zálohy, které se automaticky vytvářejí a pravidelně kontrolují na konzistenci.
Promyslete typické scénáře hrozeb.
Dejte možnost inženýrům vymyslet netypické varianty, které mohou službu ohrozit.
DRP by měl být jednoduchým a jasným pokynem. Veškerá složitá diagnostika až poté, co se služba obnovila pro klienty. Klidně i na záložních kapacitách.
Uveďte klíčová telefonní čísla a kontakty v DRP.
Pravidelně testujte zaměstnance na pochopení DRP.
Uskutečňujte plánované havárie na produkci. Stánky nemohou nahradit všechno.