Aj počas katastrofy sa vždy nájde čas na šálku čaju
DRP (plán obnovy po katastrofe) je vec, ktorá v ideálnom prípade nebude nikdy potrebná. No ak sa náhle bobry migrujúce v období párenia prehryzú chrbticovým optickým vláknom alebo junior admin zahodí produktívnu základňu, určite si chcete byť istí, že budete mať vopred pripravený plán, čo so všetkou tou hanbou urobiť.
Kým zákazníci v panike začnú odrezávať telefóny technickej podpory, junior hľadá kyanid, vy rozumne otvoríte červenú obálku a začnete všetko dávať do poriadku.
V tomto príspevku sa chcem podeliť o odporúčania, ako vypísať DRP a čo by mala obsahovať. Pozrieme sa aj na nasledujúce veci:
- Naučme sa myslieť ako darebák.
- Pozrime sa na výhody šálky čaju počas apokalypsy.
- Zamyslime sa nad pohodlnou štruktúrou DRP
- Pozrime sa, ako to otestovať
Pre ktoré spoločnosti to môže byť užitočné?
Je veľmi ťažké určiť hranicu, kedy IT oddelenie začne takéto veci potrebovať. Povedal by som, že DRP určite potrebujete, ak:
- Zastavenie servera, aplikácie alebo strata nejakej databázy povedie k značným stratám pre podnik ako celok.
- Máte plnohodnotné IT oddelenie. V zmysle oddelenia v podobe plnohodnotnej jednotky firmy, s vlastným rozpočtom, a nie len pár unavenými zamestnancami, ktorí kladú sieť, čistia vírusy a dopĺňajú tlačiarne.
- Máte reálny rozpočet na aspoň čiastočné prepustenie v prípade núdze.
Keď IT oddelenie už mesiace prosí aspoň o pár HDD na starý server na zálohovanie, je nepravdepodobné, že budete schopní zorganizovať plnohodnotný presun zlyhanej služby do rezervy kapacity. Aj keď tu dokumentácia nebude zbytočná.
Dôležitá je dokumentácia
Začnite s dokumentáciou. Povedzme, že vaša služba beží na skripte Perl, ktorý pred tromi generáciami napísali správcovia, ale nikto nevie, ako to funguje. Nahromadený technický dlh a chýbajúca dokumentácia vás nevyhnutne strelia nielen do kolien, ale aj do iných končatín, je to skôr otázka času.
Keď budete mať dobrý popis komponentov služby, vyhľadajte štatistiky nehôd. Takmer určite budú úplne typické. Napríklad, váš disk sa z času na čas zaplní, čo spôsobí zlyhanie uzla, kým nie je ručne vyčistený. Alebo sa klientska služba stane nedostupnou kvôli tomu, že niekto opäť zabudol obnoviť certifikát a Let's Encrypt nedokázal alebo nechcel nakonfigurovať.
Myšlienky ako sabotér
Najťažšia časť je predpovedať tie nehody, ktoré sa nikdy predtým nestali, ale ktoré by potenciálne mohli úplne zničiť vašu službu. Tu sa s kolegami väčšinou hráme na darebákov. Vezmite si veľa kávy a niečo chutné a zamknite sa v zasadačke. Len sa uistite, že v rovnakých rokovaniach uzamknete tých inžinierov, ktorí sami vyvinuli cieľovú službu alebo s ňou pravidelne pracujú. Potom, buď na tabuľu alebo na papier, začnete kresliť všetky možné hrôzy, ktoré by sa mohli stať vašej službe. Nie je potrebné zachádzať do detailov ku konkrétnej upratovačke a vyťahovať káble, stačí zvážiť scenár „Narušenie integrity lokálnej siete“.
Typicky najtypickejšie núdzové situácie spadajú do nasledujúcich typov:
- Zlyhanie siete
- Zlyhanie služieb OS
- Zlyhanie aplikácie
- Porucha železa
- Zlyhanie virtualizácie
Stačí prejsť každý typ a zistiť, čo sa týka vašej služby. Napríklad démon Nginx môže padnúť a nestúpať - to znamená zlyhania na strane OS. Zriedkavou situáciou, ktorá spôsobí zlyhanie vašej webovej aplikácie, je zlyhanie softvéru. Počas tejto fázy je dôležité určiť diagnózu problému. Ako rozlíšiť zamrznuté rozhranie na virtualizácii od spadnutého cis disku a napríklad zlyhania siete. Je dôležité rýchlo nájsť zodpovedných a začať ich ťahať za chvost, kým sa nehoda nevyrieši.
Po spísaní typických problémov si nalejeme ďalšiu kávu a začneme zvažovať tie najzvláštnejšie scenáre, keď niektoré parametre začnú ísť ďaleko za normu. Napríklad:
- Čo sa stane, ak sa čas na aktívnom uzle posunie o minútu späť v porovnaní s ostatnými v klastri?
- Čo ak sa čas posunie dopredu, čo ak o 10 rokov?
- Čo sa stane, ak uzol klastra počas synchronizácie náhle stratí svoju sieť?
- Čo sa stane, ak dva uzly nebudú zdieľať vedenie z dôvodu dočasnej vzájomnej izolácie v sieti?
V tejto fáze je veľmi nápomocný opačný prístup. Zoberiete najtvrdohlavejšieho člena tímu s chorou predstavivosťou a dáte mu za úlohu v čo najkratšom čase zorganizovať sabotáž, ktorá stiahne službu. Ak je ťažké diagnostikovať, ešte lepšie. Neuveríte, s akými zvláštnymi a skvelými nápadmi prídu inžinieri, ak im dáte nápad, ako niečo rozbiť. A ak im na to sľúbite testovaciu lavicu, je to úplne v poriadku.
Čo je toto tvoje DRP?!
Takže ste definovali svoj model hrozby. Vzali do úvahy aj miestnych obyvateľov, ktorí pri hľadaní medi prerezávali káble z optických vlákien, a vojenský radar, ktorý presne v piatok o 16:46 zhadzuje rádioreléové vedenie. Teraz musíme pochopiť, čo s tým všetkým robiť.
Vašou úlohou je napísať tie veľmi červené obálky, ktoré sa otvoria v prípade núdze. Okamžite očakávajte, že keď (nie ak!) všetko skončí, nablízku bude len ten najneskúsený stážista, ktorému sa budú od hrôzy z toho, čo sa deje, prudko triasť ruky. Pozrite sa, ako sa núdzové značky implementujú v lekárskych ordináciách. Napríklad, čo robiť v prípade anafylaktického šoku. Zdravotnícky personál pozná všetky protokoly naspamäť, ale keď človek nablízku začne umierať, veľmi často sa všetci bezmocne chytajú za všetko, čo je na očiach. Na tento účel sú na stene jasné pokyny s položkami ako „otvorte balenie toho a toho“ a „podajte si intravenózne toľko jednotiek lieku“.
V núdzi je ťažké myslieť! Mali by existovať jednoduché pokyny na analýzu miechy.
Dobrý DRP pozostáva z niekoľkých jednoduchých blokov:
- Komu oznámiť začiatok nehody. Je to dôležité, aby sa proces eliminácie čo najviac paralelizoval.
- Ako správne diagnostikovať - vykonajte sledovanie, pozrite sa do systemctl status servicename atď.
- Koľko času môžete stráviť na každej fáze? Ak to nestihnete opraviť ručne v rámci času SLA, virtuálny počítač sa zastaví a vráti sa späť zo včerajšej zálohy.
- Ako zabezpečiť, aby sa nehoda skončila.
Pamätajte, že DRP začína, keď služba úplne zlyhá, a končí, keď je služba obnovená, a to aj so zníženou efektivitou. Jednoduchá strata rezervácie by nemala spustiť DRP. Do DRP si môžete zapísať aj šálku čaju. vážne. Podľa štatistík sa mnohé nehody menia z nepríjemných na katastrofické v dôsledku skutočnosti, že personál sa v panike ponáhľa niečo opraviť, súčasne zabije jediný živý uzol s údajmi alebo nakoniec dokončí klaster. Spravidla vám 5 minút so šálkou čaju poskytne čas na upokojenie a analýzu toho, čo sa deje.
Nezamieňajte DRP a systémový pas! Nepreťažujte ho zbytočnými údajmi. Umožnite rýchlo a pohodlne pomocou hypertextových odkazov prejsť na požadovanú časť dokumentácie a prečítať si v rozšírenom formáte potrebné časti architektúry služby. A v samotnom DRP sú iba priame pokyny, kde a ako sa pripojiť s konkrétnymi príkazmi na kopírovanie a vkladanie.
Ako správne testovať
Uistite sa, že každý zodpovedný zamestnanec je schopný vyplniť všetky položky. V najkritickejšom momente sa môže ukázať, že technik nemá práva na prístup k požadovanému systému, neexistujú heslá k požadovanému účtu alebo netuší, čo „Pripojte sa ku konzole správy služieb cez proxy na ústredie“ znamená. Každý bod by mal byť veľmi jednoduchý.
zle - „Prejdite na virtualizáciu a reštartujte mŕtvy uzol“
správne - „Pripojte sa cez webové rozhranie k virt.example.com, v sekcii uzly reštartujte uzol, ktorý spôsobuje chybu.“
Vyhnite sa nejednoznačnosti. Spomeňte si na vystrašeného stážistu.
DRP určite otestujte. Toto nie je len plán na predstavenie – je to niečo, čo vám a vašim klientom umožní rýchlo sa dostať z kritickej situácie. Najlepšie je to urobiť niekoľkokrát:
- Jeden odborník a niekoľko stážistov pracuje na skúšobnej stolici, ktorá v maximálnej možnej miere simuluje skutočnú službu. Odborník preruší službu rôznymi spôsobmi a umožní stážistom obnoviť ju podľa DRP. Všetky problémy, nejasnosti v dokumentácii a chyby sú zaznamenané. Po zaškolení účastníkov sa DRP v nejasných oblastiach rozširuje a zjednodušuje.
- Testovanie na reálnej službe. V skutočnosti nikdy nemôžete vytvoriť dokonalú kópiu skutočnej služby. Preto je potrebné niekoľkokrát do roka rutinne vypínať niektoré servery, prerušovať spojenia a spôsobovať ďalšie katastrofy zo zoznamu hrozieb, aby bolo možné posúdiť príkaz na obnovu. Plánovaný výpadok na 10 minút uprostred noci je lepší ako niekoľkohodinový náhly výpadok pri špičkovej záťaži so stratou dát.
- Skutočné riešenie problémov. Áno, aj toto je súčasťou testovania. Ak dôjde k nehode, ktorá nebola na zozname ohrození, je potrebné doplniť a dopracovať DRP na základe výsledkov jej šetrenia.
Kľúčové body
- Ak sa môže stať hovno, nielenže sa to stane, ale stane sa to v tom najkatastrofickejšom možnom scenári.
- Uistite sa, že máte prostriedky na núdzový prenos záťaže.
- Uistite sa, že máte zálohy, vytvárajú sa automaticky a pravidelne kontrolujú ich konzistenciu.
- Zamyslite sa nad typickými scenármi hrozieb.
- Dajte inžinierom príležitosť prísť s neštandardnými možnosťami dodania služby.
- DRP by mala byť jednoduchá a strohá inštrukcia. Všetka komplexná diagnostika sa vykonáva až po obnovení služieb klientov. Aj keď na rezervnú kapacitu.
- Uveďte kľúčové telefónne čísla a kontakty v DRP.
- Pravidelne testujte, či zamestnanci rozumejú DRP.
- Zabezpečte plánované havárie na výrobných miestach. Stojany nemôžu nahradiť všetko.
Zdroj: hab.com