Tudi med katastrofo se vedno najde čas za skodelico čaja
DRP (načrt za obnovitev po nesreči) je stvar, ki v idealnem primeru ne bo nikoli potrebna. A če nenadoma bobri, ki se selijo med sezono parjenja, pregriznejo hrbtenično optično vlakno ali če mlajši skrbnik opusti produktivno bazo, vsekakor želite biti prepričani, da boste imeli vnaprej pripravljen načrt, kaj storiti z vso to sramoto.
Medtem ko kupci v paniki začnejo prekinjati telefone tehnične podpore, junior išče cianid, vi modro odprete rdečo kuverto in začnete vse urejati.
V tej objavi želim deliti priporočila o tem, kako napisati DRP in kaj naj vsebuje. Ogledali si bomo tudi naslednje stvari:
- Naučimo se razmišljati kot zlobnež.
- Poglejmo si prednosti skodelice čaja med apokalipso.
- Razmislimo o priročni strukturi DRP
- Poglejmo, kako ga preizkusiti
Za katera podjetja bi to lahko bilo koristno?
Zelo težko je potegniti črto, ko oddelek IT začne potrebujeti te stvari. Rekel bi, da DRP zagotovo potrebujete, če:
- Zaustavitev strežnika, aplikacije ali izguba baze podatkov bo povzročila znatne izgube za podjetje kot celoto.
- Imate popoln IT oddelek. V smislu oddelka v obliki polnopravne enote podjetja, z lastnim proračunom, in ne le nekaj utrujenih zaposlenih, ki postavljajo omrežje, čistijo viruse in polnijo tiskalnike.
- Imate realen proračun za vsaj delno odpuščanje v nujnih primerih.
Ko IT oddelek že mesece prosjači za vsaj nekaj trdih diskov v stari strežnik za varnostne kopije, je malo verjetno, da boste lahko organizirali popolno selitev neuspele storitve v rezervno zmogljivost. Čeprav tukaj dokumentacija ne bo odveč.
Dokumentacija je pomembna
Začnite z dokumentacijo. Recimo, da vaša storitev deluje na skriptu Perl, ki so ga pred tremi generacijami napisali skrbniki, vendar nihče ne ve, kako deluje. Nakopičen tehnični dolg in pomanjkanje dokumentacije vas bo neizogibno izstrelil ne le v koleno, ampak tudi v druge okončine, to je bolj vprašanje časa.
Ko imate dober opis komponent storitve, poiščite statistiko nesreč. Skoraj zagotovo bodo povsem tipske. Vaš disk se na primer občasno napolni, kar povzroči, da vozlišče ne uspe, dokler ni ročno očiščeno. Ali pa odjemalska storitev postane nedosegljiva zaradi dejstva, da je nekdo spet pozabil obnoviti potrdilo in Let's Encrypt ni mogel ali želel konfigurirati.
Razmišlja kot saboter
Najtežje je napovedati tiste nesreče, ki se še nikoli niso zgodile, a bi lahko popolnoma uničile vašo storitev. Tukaj običajno igramo negativce s kolegi. Vzemite veliko kave in nekaj okusnega ter se zaprite v sejno sobo. Prepričajte se le, da ste na istem sestanku zaklenili tiste inženirje, ki so sami postavili ciljno storitev ali z njo redno delajo. Nato bodisi na tablo bodisi na papir začneš risati vse možne grozote, ki se lahko zgodijo tvoji službi. Ni potrebno, da se podrobno posvetite določeni čistilki in izvlečete kable, dovolj je, da razmislite o scenariju "Kršitev celovitosti lokalnega omrežja".
Običajno večina tipičnih izrednih situacij spada v naslednje vrste:
- Okvara omrežja
- Napaka storitve OS
- Napaka aplikacije
- Okvara železa
- Napaka pri virtualizaciji
Samo preglejte vsak pogled in poglejte, kaj velja za vašo storitev. Na primer, demon Nginx lahko pade in se ne dvigne - to je napaka OS. Redka situacija, ki požene vašo spletno aplikacijo v nedelujoče stanje, je okvara programske opreme. Med razvojem te stopnje je pomembno določiti diagnozo problema. Kako ločiti obešen vmesnik na virtualizaciji od padlega cisca in sesutja omrežja npr. To je pomembno, da hitro najdemo odgovorne in jih začnemo vleči za rep, dokler se nesreča ne odpravi.
Ko tipične težave zapišemo, natočimo še kavo in začnemo razmišljati o najbolj nenavadnih scenarijih, ko začnejo nekateri parametri daleč presegati normo. Na primer:
- Kaj se zgodi, če se čas na aktivnem vozlišču premakne za minuto nazaj glede na druge v gruči?
- In če se čas premakne naprej, in če za 10 let?
- Kaj se zgodi, če vozlišče gruče med sinhronizacijo nenadoma izgubi omrežje?
- In kaj se zgodi, če si dve vozlišči ne delita vodstva zaradi začasne medsebojne izolacije v omrežju?
Na tej stopnji je obratni pristop zelo koristen. Vzameš najbolj trmastega člana ekipe z bolno domišljijo in mu daš nalogo, da v najkrajšem možnem času organizira sabotažo, ki bo sesula službo. Če je težko diagnosticirati, še bolje. Ne boste verjeli, do kakšnih nenavadnih in kul idej pridejo inženirji, če jim date idejo, da bi nekaj zlomili. In če jim obljubite preskusno napravo za to, je to povsem v redu.
Kaj je ta tvoj DRP?!
Torej ste definirali model grožnje. Upoštevali so tudi lokalne prebivalce, ki režejo optične kable v iskanju bakra, in vojaški radar, ki striktno ob petkih ob 16 spusti radiorelejno linijo. Zdaj moramo ugotoviti, kaj narediti z vsem tem.
Vaša naloga je, da napišete enake rdeče ovojnice, ki se bodo odprle v nujnih primerih. Takoj pričakujte, da bo, ko bo (ne če!) vse zajebano, v bližini le najbolj neizkušen pripravnik, ki se mu bodo roke močno tresle od groze dogajanja. Oglejte si, kako se znaki za nujne primere izvajajo v zdravstvenih ordinacijah. Na primer, kaj storiti z anafilaktičnim šokom. Zdravstveno osebje pozna vse protokole na pamet, ko pa človek v bližini začne umirati, pogosto vsi nemočno grabijo za vse. Če želite to narediti, na steni visi jasno navodilo s stavki, kot sta "odprite embalažo tega in tega" in "injicirajte toliko enot zdravila intravenozno."
Težko je razmišljati v sili! Obstajati morajo preprosta navodila za razčlenjevanje hrbtenjače.
Dober DRP je sestavljen iz več preprostih blokov:
- Koga obvestiti o začetku nesreče. To je pomembno, da čim bolj vzporedimo proces izločanja.
- Kako pravilno diagnosticirati - izsledimo, pogledamo v systemctl status servicename in tako naprej.
- Koliko časa lahko porabite za vsako stopnjo? Če nimate časa, da bi ga ročno popravili v času SLA, se virtualni stroj uniči in vrne nazaj iz včerajšnje varnostne kopije.
- Kako zagotoviti, da je nesreče konec.
Ne pozabite, da se DRP začne, ko storitev popolnoma odpove, in konča, ko je storitev ponovno vzpostavljena, tudi z zmanjšano učinkovitostjo. Preprosta izguba rezervacije ne bi smela sprožiti DRP. V DRP lahko vpišete tudi skodelico čaja. resno Po statističnih podatkih se številne nesreče spremenijo iz neprijetnih v katastrofalne zaradi dejstva, da osebje v paniki hiti, da bi nekaj popravilo, hkrati pa ubije edino živo vozlišče s podatki ali končno uniči gručo. Praviloma vam bo 5 minut s skodelico čaja dalo nekaj časa, da se umirite in analizirate, kaj se dogaja.
Ne zamenjujte DRP in sistemskega potnega lista! Ne obremenjujte ga z nepotrebnimi podatki. Omogočite le hitro in priročno uporabo hiperpovezav za dostop do želenega odseka dokumentacije in branje v razširjeni obliki o potrebnih odsekih storitvene arhitekture. In v samem DRP so samo neposredna navodila, kje in kako se povezati s posebnimi ukazi za kopiranje in lepljenje.
Kako pravilno testirati
Prepričajte se, da lahko kateri koli odgovorni zaposleni izpolni vse postavke. V najbolj ključnem trenutku se lahko izkaže, da inženir nima pravic za dostop do zahtevanega sistema, ni gesel za zahtevani račun ali pa nima pojma, kaj je »Povežite se s konzolo za upravljanje storitev prek proxyja na glavna pisarna“ pomeni. Vsaka točka mora biti izjemno preprosta.
Napačna - »Pojdite na virtualizacijo in znova zaženite mrtvo vozlišče«
Pravilno - »Prek spletnega vmesnika se povežite z virt.example.com, v razdelku z vozlišči znova zaženite vozlišče, ki povzroča napako.«
Izogibajte se dvoumnosti. Spomnite se prestrašenega pripravnika.
Bodite prepričani, da preizkusite DRP. To ni samo načrt za predstavo - je nekaj, kar bo vam in vašim strankam omogočilo, da se hitro rešite iz kritične situacije. Najbolje je, da to storite večkrat:
- En strokovnjak in več pripravnikov dela na testni napravi, ki v največji možni meri simulira resnično storitev. Strokovnjak na različne načine prekine storitev in tečajnikom omogoči, da jo obnovijo po DRP. Vse težave, dokumentacijske nejasnosti in napake se evidentirajo. Po usposabljanju pripravnikov se DRP razširi in poenostavi na nejasnih področjih.
- Testiranje na realnem servisu. Pravzaprav nikoli ne morete ustvariti popolne kopije prave storitve. Zato je treba nekajkrat na leto načrtovano izklopiti del strežnikov, prekiniti povezave in urediti druge nesreče s seznama groženj, da se oceni vrstni red obnovitve. Bolje je imeti 10-minutni načrtovani izpad sredi noči kot nenaden večurni izpad pri največji obremenitvi z izgubo podatkov.
- Pravo odpravljanje težav. Da, tudi to je del testiranja. Če pride do nesreče, ki ni bila na seznamu nevarnosti, je potrebno DRP dopolniti in dodelati na podlagi rezultatov njene preiskave.
Ključne točke
- Če se sranje lahko zgodi, se ne bo samo zgodilo, ampak se bo to zgodilo po najbolj katastrofalnem možnem scenariju.
- Prepričajte se, da imate sredstva za nujni prenos bremena.
- Prepričajte se, da imate varnostne kopije, ki se samodejno ustvarijo in redno preverjajo glede skladnosti.
- Razmislite o tipičnih scenarijih groženj.
- Dajte inženirjem priložnost, da pripravijo nestandardne možnosti za zagotavljanje storitve.
- DRP bi moral biti preprosta in odkrita navodila. Vsa kompleksna diagnostika se izvede šele po obnovitvi storitve strank. Tudi če je na rezervnih zmogljivostih.
- V DRP navedite ključne telefonske številke in kontakte.
- Redno testirajte razumevanje DRP pri zaposlenih.
- Uredite načrtovane nesreče na proizvodnih mestih. Stojala ne morejo nadomestiti vsega.
Vir: www.habr.com