🥇Pripravujeme DRP — nezabudnite zohľadniť meteority

Aj počas katastrofy je vždy čas na šálku čaju

DRP (plán obnovy po katastrofe) je niečo, čo v ideálnom prípade nikdy nebude potrebné. Ale ak náhodou migrujúce bobry počas svadobného obdobia prehryznú hlavnú optickú sieť alebo junior administrátor zhodí produktívnu databázu, určite chcete mať istotu, že máte vopred vypracovaný plán, čo s tým všetkým robiť.

Kým klienti v panike začnú obťažovať technickú podporu, junior hľadá kyanoz, vy s múdrym výrazom otvárate červenú obálku a začínate všetko uvádzať do poriadku.

V tomto príspevku sa chcem podeliť o odporúčania, ako písať DRP a čo by mal obsahovať. A taktiež sa pozrieme na nasledovné veci:

Naučíme sa myslieť ako zloduch.
Preberieme si osoh šálky čaju počas apokalypsy.
Premyslíme si pohodlnú štruktúru DRP
Pozrieme sa, ako ho testovať

Pre aké firmy to môže byť užitočné

Veľmi ťažko sa vyznačuje hranica, keď IT oddelenie začína potrebovať takéto veci. Povedal by som, že DRP určite potrebujete, ak:

Zastavenie servera, aplikácie alebo strata nejakej databázy povedie k významným stratám v rámci celého podnikania.
Máte plnohodnotné IT oddelenie. Myslím tým oddelenie ako plnohodnotná jednotka spoločnosti, so svojím rozpočtom, a nie len niekoľko unavených zamestnancov, ktorí kladú sieť, čistí vírusy a dopĺňajú tonery.
Máte reálny rozpočet aspoň na čiastočné rezervovanie v prípade havárie.

Keď IT oddelenie mesiacmi žobrá o aspoň pár HDD do starého servera na zálohy, ťažko dosiahnete plnohodnotný presun zlyhávajúcej služby na záložné zdroje. Hoci aj tu nebude dokumentácia na škodu.

Dokumentácia je dôležitá

Začnite s dokumentáciou. Predpokladajme, že vaša služba funguje na základe skriptu v Perli, ktorý bol napísaný pred tromi generáciami administrátorov, a nikto nevie, ako funguje. Nahromadený technický dlh a absencia dokumentácie vám nevyhnutne strelnú nielen koleno, ale aj iné končatiny, to je skôr otázka času.

Akon ste získali dobrý popis komponentov služby, začnite sledovať štatistiku porúch. Takmer s určitosťou budú úplne typické. Napríklad, ak sa vám občas preplní disk, čo vedie k zlyhaniu uzla, kým ho ručne nevyčistíte. Alebo sa služba pre klientov stane nedostupnou, pretože niekto opäť zabudol obnoviť certifikát a nedokázal alebo nechcel nastaviť Let's Encrypt.

Myslite ako diverzant

Najťažšia časť spočíva v predpovedaní tých porúch, ktoré sa ešte nikdy nestali, ale potenciálne môžu úplne zničiť vašu službu. Tu sa zvyčajne s kolegami hráme na záporákov. Zoberte si veľa kávy a niečo chutné a zamknite sa v rokovacej miestnosti. Iba sa uistite, že v tej istej rokovacej miestnosti ste zamkli tých inžinierov, ktorí sami vybudovali cieľovú službu alebo s ňou pravidelne pracujú. Potom na tabuli alebo na papieri začnite kresliť všetky možné hrôzy, ktoré sa s vašou službou môžu stať. Nielenže je potrebné podrobne specifikovať až po konkrétnu upratovačku a vytiahne káble, stačí zvážiť scenár „Porušenia integrity miestnej siete“.

Zvyčajne, väčšina typických poruchových situácií spadá do nasledujúcich kategórií:

Zlyhanie siete
Zlyhanie služieb operačného systému
Zlyhanie aplikácie
Zlyhanie hardvéru
Zlyhanie virtualizácie

Jednoducho prejdete každým druhom a pozriete sa, čo je aplikovateľné na vašu službu. Napríklad, môže zlyhať a nezotaviť sa démon Nginx - to sa týka zlyhaní zo strany OS. Rádovo zriedkavejšia situácia, ktorá znehodnocuje vaše webové aplikácie - zlyhanie softvéru. Počas spracovania tohto kroku je dôležité sa zaoberať diagnostikou problému. Ako rozdeliť zamrznuté rozhranie na virtualizácii od zlyhajúcej Cisco a poruchy na sieti, napríklad. Je to dôležité na rýchle nájdenie zodpovedných a začatie ich ťahania za chvost, kým sa porucha neodstráni.

Po zaznamenaní typických problémov si nalievame ďalšiu kávu a začíname zvažovať tie najčudnejšie scenáre, keď nejaké parametre začnú výrazne presahovať normu. Napríklad:

Čo sa stane, ak sa čas na aktívnom uzle posunie o minútu späť voči ostatným v klastri?
A ak sa čas posunie dopredu, a čo ak o 10 rokov?
Čo sa stane, ak počas synchronizácie uzol klastra náhle stratí sieť?
A čo sa stane, ak si dve uzly nepredajú vodcovstvo kvôli dočasnej izolácii navzájom v sieti?

Na tomto fóre veľmi pomáha prístup odzadu. Vezmite najzapálennejšieho člena tímu s bohatou fantáziou a dajte mu úlohu zostaviť sabotáž v čo najkratšom čase, ktorá zruší službu. Ak bude ťažké ju diagnostikovať — tým lepšie. neuveríte, aké divné a skvelé nápady ponúkajú inžinieri, ak im dáte myšlienku niečo rozbiť. A ak im s tým sľúbite testovaciu platformu — to je úplne skvelé.

Čo to je ten váš DRP?!

Takže ste určili model hrozieb. Zohľadnili ste aj miestnych obyvateľov, ktorí rezali optické káble v snahe získať meď, a vojenský radar, ktorý zabezpečuje rádiovú linku presne v piatok o 16:46. Teraz treba pochopiť, čo s tým všetkým robiť.

Vašou úlohou je napísať tie červené obálky, ktoré sa otváranú v núdzovej situácii. Hneď počítajte s tým, že keď (nie ak!) sa všetko podarí, vedľa bude len ten najnepodstatnejší stážista, ktorého ruky budú triasť od hrôzy z prebiehajúceho dejania. Pozrite sa, ako sú realizované núdzové tabuľky v lekárskych kabínach. Napríklad, čo robiť pri anafylaktickom šoku. Lekársky personál naozaj pozná všetky protokoly, ale keď vedľa niekto začína umierať, veľmi často bezradne chytajú všetko, čo je po ruke. Na tento účel visí na stene jasný návod, ktorý obsahuje body ako „otvoriť balenie toho-toho“ a „podávať intravenózne toľko jednotiek lieku“.

V núdzovej situácii je ťažké myslieť! Musia byť jednoduché inštrukcie na spracovanie mocou miechy.

Dobrý DRP sa skladá z niekoľkých jednoduchých blokov:

Koho informovať o začiatku havárie. To je dôležité na maximalizovanie paralelizácie procesu odstraňovania.
Ako správne diagnostikovať — vykonávame trasovanie, pozrite sa na systemctl status servicename a podobne.
Koľko času je potrebné venovať každému kroku. Ak sa vám nepodarí opraviť rukami v čase SLA — virtuálna mašina sa zlikviduje a obnoví sa z včerajšej zálohy.
Ako sa uistíte, že havária je ukončená.

Pamätajte, že DRP začína, keď služba úplne zlyhá a končí obnovením funkčnosti, aj so zníženou efektívnosťou. Iba strata rezervácie by nemala aktivovať DRP. Môžete si do DRP zapísať aj šálku čaju. Seriózne. Podľa štatistiky sa mnohé nehody z nepríjemných stávajú katastrofálnymi, pretože personál v panike začína opravovať niečo a pritom zabíja jedinú žijúcu nód s dátami alebo definitívne zhadzuje klaster. Zvyčajne 5 minút na šálku čaju vám poskytne trochu času sa upokojiť a analyzovať situáciu.

Nemiešajte DRP a pas systému! Nepreplňujte ho zbytočnými údajmi. Jednoducho poskytnite možnosť rýchlo a pohodlne prejsť cez hypertextové odkazy do potrebnej časti dokumentácie a prečítať si v rozšírenom formáte o potrebných oblastiach architektúry služby. A v samotnom DRP by mali byť len priame pokyny, kam a ako sa pripojiť so špecifickými príkazmi na kopírovanie a vkladanie.

Ako správne testovať

Uistite sa, že ktorýkoľvek zodpovedný zamestnanec je schopný vykonať všetky body. V najdôležitejšom momente môže nastať situácia, že inžinier nemá prístup do potrebného systému, chýbajú heslá k potrebným účtom alebo nemá tušenie, čo znamená 'Pripojte sa k administratívnej konzole služby cez proxy v centrále'. Každý bod by mal byť maximálne jednoduchý.

Nesprávne — 'Choďte na virtualizáciu a reštartujte mŕtvu nód'
Správne — 'Pripojte sa cez webové rozhranie k virt.example.com, v sekcii nód vykonajte reštart nód, ktorá vyvoláva chybu.'

Nedovoľte nejednoznačnosti. Pamätajte na vystrašeného stážistu.

Nezabúdajte testovať DRP. Nie je to len plán pre formálnosť – to, čo vám a vašim zákazníkom umožní rýchlo sa dostať z kritickej situácie. Optimálne je to zopakovať niekoľkokrát:

Jeden expert a niekoľko stážistov pracujú na testovacom prostredí, ktoré maximálne imituje reálnu službu. Expert rozbíja službu rôznymi spôsobmi a dáva stážistom príležitosť obnoviť ju podľa DRP. Všetky problémy, nejasnosti v dokumentácii a chyby sa zaznamenávajú. Po školení stážistov sa DRP dopĺňa a zjednodušuje na nejasných miestach.
Testovanie na skutočnom servise. V skutočnosti nikdy nemožno vytvoriť dokonalú kópiu skutočného servisu. Preto je potrebné niekoľkokrát ročne plánovane vypnúť časť serverov, prerušiť pripojenia a usporiadať iné havárie z hrozbového zoznamu, aby sa vyhodnotil poriadok obnovenia. Lepšia je plánovaná havária na 10 minút uprostred noci, než náhly výpadok na niekoľko hodín v čase špičky s potenciálnou stratou dát.
Skutočné odstránenie havárie. Áno, to je tiež súčasť testovania. Ak nastane havária, ktorá nebola v hrozbovom zozname, je potrebné doplniť a upraviť DRP na základe výsledkov jej vyšetrovania.

Kľúčové body

Ak sa niečo zlé môže stať, stane sa to nielenže, ale aj to spraví maximálne katastrofickým scenárom.
Uistite sa, že máte zdroje na havarijné prehodnotenie zaťaženia.
Uistite sa, že máte zálohy, ktoré sa automaticky vytvárajú a pravidelne kontrolujú na konzistenciu.
Premyslite si typické scenáre hrozieb.
Dajte inžinierom možnosť vymyslieť netypické varianty, ako zložiť servis.
DRP by mal byť jednoduchým a jasným návodom. Všetka zložitá diagnostika až po obnovení servisu pre klientov. Nech aj na záložných kapacitách.
Uveďte kľúčové telefóny a kontakty v DRP.
Pravidelne testujte zamestnancov na pochopenie DRP.
Usporadúvajte plánované havárie na produkcii. Stendy nemôžu nahradiť všetko.