I během katastrofy je vždy čas na šálek čaje
DRP (plán obnovy po havárii) je věc, která v ideálním případě nebude nikdy potřeba. Pokud ale náhle bobři migrující v období páření prohryznou páteřní optické vlákno nebo junior admin zahodí produktivní základnu, určitě si chcete být jisti, že budete mít předem připravený plán, co s celou tou ostudou dělat.
Zatímco zákazníci v panice začnou odřezávat telefony technické podpory, junior hledá kyanid, vy moudře otevřete červenou obálku a začnete vše 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. Podíváme se také na následující věci:
- Naučme se myslet jako padouch.
- Podívejme se na výhody šálku čaje během apokalypsy.
- Pojďme se zamyslet nad vhodnou strukturou DRP
- Pojďme se podívat, jak to otestovat
Pro které společnosti by to mohlo být užitečné?
Je velmi těžké stanovit hranici, kdy IT oddělení takové věci začne potřebovat. Řekl bych, že DRP rozhodně potřebujete, pokud:
- Zastavení serveru, aplikace nebo ztráta některé databáze povede k významným ztrátám pro podnik jako celek.
- Máte plnohodnotné IT oddělení. Ve smyslu oddělení v podobě plnohodnotné jednotky firmy, s vlastním rozpočtem a ne jen pár unavenými zaměstnanci pokládajícími síť, čištěním virů a doplňováním tiskáren.
- Máte realistický rozpočet na alespoň částečné propouštění v případě nouze.
Když IT oddělení už měsíce prosí o alespoň pár HDD na starý server pro zálohování, je nepravděpodobné, že budete schopni zorganizovat plnohodnotný přesun neúspěšné služby do rezervy kapacity. I když zde dokumentace nebude zbytečná.
Důležitá je dokumentace
Začněte dokumentací. Řekněme, že vaše služba běží na skriptu Perl, který byl napsán před třemi generacemi administrátory, ale nikdo neví, jak to funguje. Nahromaděný technický dluh a nedostatek dokumentace vás nevyhnutelně střelí nejen do kolen, ale i do jiných končetin, je to spíše otázka času.
Jakmile budete mít dobrý popis součástí služby, vyhledejte si statistiky nehod. Téměř jistě budou zcela typické. Například se čas od času zaplní váš disk, což způsobí selhání uzlu, dokud nebude ručně vyčištěn. Nebo se klientská služba stane nedostupnou kvůli tomu, že někdo opět zapomněl obnovit certifikát a Let's Encrypt se nemohl nebo nechtěl konfigurovat.
Myšlenky jako sabotér
Nejobtížnější je předvídat nehody, které se nikdy předtím nestaly, ale které by mohly potenciálně zcela zruinovat vaši službu. Tady s kolegy většinou hrajeme padouchy. Vezměte si hodně kávy a něco chutného a zamkněte se v zasedací místnosti. Jen se ujistěte, že ve stejných jednáních zablokujete ty inženýry, kteří sami vyvinuli cílovou službu nebo s ní pravidelně pracují. Poté buď na tabuli nebo na papír začnete kreslit všechny možné hrůzy, které by se vaší službě mohly stát. Není nutné zabíhat do detailů až ke konkrétní uklízečce a vytahování kabelů, stačí zvážit scénář „Narušení integrity místní sítě“.
Typicky nejtypičtější nouzové situace spadají do následujících typů:
- Chyba sítě
- Selhání služeb OS
- Selhání aplikace
- Selhání železa
- Selhání virtualizace
Stačí si projít každý typ a zjistit, co platí pro vaši službu. Například démon Nginx může spadnout a nezvednout se - to znamená selhání na straně OS. Vzácnou situací, která způsobí selhání vaší webové aplikace, je selhání softwaru. Během této fáze je důležité vypracovat diagnózu problému. Jak rozeznat zamrzlé rozhraní na virtualizaci od spadlého cis disku a například výpadku sítě. To je důležité, abyste rychle našli zodpovědné osoby a začali je tahat za ocas, dokud se nehoda nevyřeší.
Po sepsání typických problémů si nalijeme další kávu a začneme zvažovat ty nejpodivnější scénáře, kdy některé parametry začnou jít daleko za normu. Například:
- Co se stane, když se čas na aktivním uzlu posune o minutu zpět vzhledem k ostatním v clusteru?
- Co když se čas posune dopředu, co když o 10 let?
- Co se stane, když uzel clusteru během synchronizace náhle ztratí svou síť?
- Co se stane, když dva uzly nebudou sdílet vedení kvůli dočasné vzájemné izolaci v síti?
V této fázi je velmi užitečný opačný přístup. Vezmete nejzarputilejšího člena týmu s chorobnou představivostí a dáte mu za úkol v co nejkratším čase zorganizovat sabotáž, která srazí službu. Pokud je obtížné diagnostikovat, ještě lépe. Nebudete věřit, s jakými podivnými a skvělými nápady inženýři přicházejí, pokud jim dáte nápad, jak něco rozbít. A pokud jim za to slíbíte zkušební stolici, je to naprosto v pořádku.
Co je to za vaše DRP?!
Takže jste definovali svůj model ohrožení. Vzali také v úvahu místní obyvatele, kteří při hledání mědi přeřezávají kabely z optických vláken, a vojenský radar, který přesně v pátek v 16:46 shazuje radioreléové vedení. Nyní musíme pochopit, co s tím vším dělat.
Vaším úkolem je napsat ty velmi červené obálky, které se otevřou v případě nouze. Okamžitě počítejte s tím, že až (ne když!) vše skončí, bude nablízku jen ten nejnezkušenější praktikant, kterému se budou hrůzou z toho, co se děje, prudce třást ruce. Podívejte se, jak jsou nouzové značky implementovány 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 nazpaměť, ale když člověk poblíž začne umírat, velmi často se všichni bezmocně chytají všeho, co je na dohled. K tomu jsou na stěně jasné pokyny s položkami jako „otevřít balení toho a takového“ a „aplikujte nitrožilně tolik jednotek léku“.
V nouzi je těžké přemýšlet! Měly by existovat jednoduché pokyny pro analýzu míchy.
Dobrý DRP se skládá z několika jednoduchých bloků:
- Komu oznámit začátek nehody. To je důležité pro co největší paralelizaci procesu eliminace.
- Jak správně diagnostikovat - proveďte trasování, podívejte se do systemctl status servicename a tak dále.
- Kolik času můžete strávit na každé fázi? Pokud to nestihnete opravit ručně během doby SLA, virtuální počítač bude zabit a vrácen ze včerejší zálohy.
- Jak zajistit, aby nehoda skončila.
Pamatujte, že DRP začíná, když služba úplně selže, a končí, když je služba obnovena, a to i se sníženou účinností. Pouhá ztráta rezervace by neměla vyvolat DRP. Do DRP si můžete zapsat i šálek čaje. Vážně. Podle statistik se mnoho nehod změní z nepříjemných na katastrofické kvůli tomu, že zaměstnanci v panice spěchají něco opravit, současně zabijí jediný živý uzel s daty nebo nakonec klastr dokončí. Zpravidla 5 minut s šálkem čaje vám poskytne čas na uklidnění a analýzu toho, co se děje.
Nezaměňujte DRP a systémový pas! Nepřetěžujte jej zbytečnými daty. Stačí umožnit rychle a pohodlně pomocí hypertextových odkazů přejít na požadovanou část dokumentace a přečíst si v rozšířeném formátu potřebné části architektury služeb. A v samotném DRP jsou pouze přímé pokyny, kde a jak se spojit s konkrétními příkazy pro kopírování a vkládání.
Jak správně testovat
Ujistěte se, že každý odpovědný zaměstnanec je schopen dokončit všechny položky. V nejklíčovějším okamžiku se může ukázat, že technik nemá práva pro přístup k požadovanému systému, neexistují hesla k požadovanému účtu nebo netuší, co „Připojte se ke konzole pro správu služeb přes proxy na ústředí“ znamená. Každý bod by měl být extrémně jednoduchý.
Špatně — „Přejděte na virtualizaci a restartujte mrtvý uzel“
Správně - „Připojte se přes webové rozhraní k virt.example.com, v sekci uzlů restartujte uzel, který chybu způsobuje.“
Vyhněte se dvojznačnosti. Vzpomeňte si na vyděšeného stážistu.
DRP určitě otestujte. Toto není jen plán na představení – je to něco, co vám a vašim klientům umožní rychle se dostat z kritické situace. Nejlepší je to udělat několikrát:
- Jeden odborník a několik stážistů pracuje na zkušební stolici, která co nejvíce simuluje skutečnou službu. Odborník službu různě narušuje a umožňuje školencům ji obnovit podle DRP. Všechny problémy, nejasnosti v dokumentaci a chyby jsou zaznamenávány. Po proškolení účastníků se DRP v nejasných oblastech rozšiřuje a zjednodušuje.
- Testování na skutečné službě. Ve skutečnosti nikdy nemůžete vytvořit dokonalou kopii skutečné služby. Proto je nutné několikrát do roka rutinně vypínat některý ze serverů, přerušovat spojení a způsobit další katastrofy ze seznamu hrozeb, aby bylo možné vyhodnotit pořadí obnovy. Plánovaná porucha na 10 minut uprostřed noci je lepší než náhlá porucha na několik hodin při špičkové zátěži se ztrátou dat.
- Skutečné řešení problémů. Ano, i to je součástí testování. Pokud dojde k nehodě, která nebyla na seznamu hrozeb, je nutné DRP doplnit a dopracovat na základě výsledků jejího šetření.
Klíčové body
- Pokud se může stát hovno, tak se to nejen stane, ale stane se tak v tom nejkatastrofičtějším možném scénáři.
- Ujistěte se, že máte prostředky pro nouzový přenos zátěže.
- Ujistěte se, že máte zálohy, jsou automaticky vytvářeny a pravidelně kontrolovány na konzistenci.
- Promyslete si typické scénáře hrozeb.
- Dejte technikům příležitost přijít s nestandardními možnostmi poskytování služby.
- DRP by měla být jednoduchá a neomalená instrukce. Veškerá komplexní diagnostika se provádí až po obnovení služeb klientů. I když na rezervní kapacitu.
- Uveďte klíčová telefonní čísla a kontakty v DRP.
- Pravidelně testujte, jak zaměstnanci rozumějí DRP.
- Zajistěte plánované havárie na výrobních místech. Stojany nemohou nahradit vše.
Zdroj: www.habr.com