Čak i tijekom katastrofe uvijek se nađe vremena za šalicu čaja.
DRP (plan oporavka od katastrofe) je stvar koja u idealnom slučaju nikada neće biti potrebna. Ali ako iznenada dabrovi koji migriraju tijekom sezone parenja izgrizu glavno optičko vlakno ili ako mlađi administrator odustane od proizvodne baze, svakako želite biti sigurni da ćete imati unaprijed napravljen plan što učiniti sa svom ovom sramotom.
Dok kupci u panici počinju prekidati telefone tehničke podrške, junior traži cijanid, vi mudro otvarate crvenu kovertu i počinjete sve slagati.
U ovom postu želim podijeliti preporuke o tome kako napisati DRP i što bi trebao sadržavati. Također ćemo razmotriti sljedeće stvari:
- Nauči razmišljati kao zlikovac.
- Analizirajmo dobrobiti šalice čaja tijekom apokalipse.
- Razmislimo o prikladnoj DRP strukturi
- Pogledajmo kako to testirati
Za koje bi tvrtke ovo moglo biti korisno?
Vrlo je teško podvući crtu kada IT odjel počinje trebati takve stvari. Rekao bih da vam DRP svakako treba ako:
- Zaustavljanje poslužitelja, aplikacije ili gubitak neke baze podataka dovest će do značajnih gubitaka za poslovanje u cjelini.
- Imate kompletan IT odjel. U smislu odjela u obliku punopravne jedinice tvrtke, sa svojim proračunom, a ne samo nekoliko umornih zaposlenika koji postavljaju mrežu, čiste viruse i pune pisače.
- Imate realan proračun za barem djelomičnu otpremninu u slučaju nužde.
Kad IT odjel mjesecima moli za barem nekoliko HDD-ova u stari poslužitelj za sigurnosne kopije, malo je vjerojatno da ćete moći organizirati potpuno premještanje neuspjelog servisa u rezervni kapacitet. Iako ovdje dokumentacija neće biti suvišna.
Dokumentacija je važna
Počnite s dokumentacijom. Recimo da vaša usluga radi na Perl skripti koju su prije tri generacije napisali administratori, ali nitko ne zna kako radi. Nagomilani tehnički dug i nedostatak dokumentacije neminovno će vas pogoditi ne samo u koljeno, već iu druge udove, više je pitanje vremena.
Nakon što imate dobar opis komponenti usluge, potražite statistiku nesreća. Gotovo je sigurno da će biti potpuno tipični. Na primjer, vaš se disk s vremena na vrijeme napuni, što uzrokuje kvar sve dok se ručno ne očisti. Ili klijentska usluga postaje nedostupna zbog činjenice da je netko opet zaboravio obnoviti certifikat, a Let's Encrypt nije mogao ili nije želio konfigurirati.
Misli kao saboter
Najteži dio je predvidjeti one nesreće koje se nikada prije nisu dogodile, ali koje potencijalno mogu u potpunosti srušiti vašu uslugu. Ovdje moji kolege i ja obično glumimo negativce. Uzmite puno kave i nešto ukusno i zaključajte se u sobu za sastanke. Samo pazite da u istim pregovorima uključite one inženjere koji su sami razvili ciljnu uslugu ili redovito rade s njom. Zatim, ili na ploču ili na papir, počnete crtati sve moguće strahote koje bi se mogle dogoditi vašoj službi. Nije potrebno ići u detalje do konkretne čistačice i izvlačenja kablova, dovoljno je razmotriti scenarij “Narušavanje integriteta lokalne mreže”.
Tipično, većina tipičnih hitnih situacija spada u sljedeće vrste:
- Kvar mreže
- Kvar usluga OS-a
- Neuspjeh aplikacije
- Kvar željeza
- Neuspjeh virtualizacije
Samo prođite kroz svaku vrstu i pogledajte što se odnosi na vašu uslugu. Na primjer, Nginx demon može pasti i ne ustati - to znači kvarove na dijelu OS-a. Rijetka situacija koja uzrokuje kvar vaše web aplikacije je kvar softvera. Dok prolazite kroz ovu fazu, važno je razraditi dijagnozu problema. Kako razlikovati zamrznuto sučelje na virtualizaciji od palog cis diska i mrežne nezgode, na primjer. Ovo je važno kako bi se brzo pronašli odgovorni i počeli ih vući za rep dok se nesreća ne riješi.
Nakon što su tipični problemi zapisani, ulijemo još kave i počnemo razmatrati najčudnije scenarije, kada neki parametri počnu ići daleko iznad norme. Na primjer:
- Što se događa ako se vrijeme na aktivnom čvoru pomakne minutu unatrag u odnosu na druge u klasteru?
- A ako vrijeme pomakne naprijed, i ako za 10 godina?
- Što se događa ako čvor klastera iznenada izgubi svoju mrežu tijekom sinkronizacije?
- Što će se dogoditi ako dva čvora ne dijele vodstvo zbog privremene međusobne izolacije na mreži?
U ovoj fazi puno pomaže obrnuti pristup. Uzimate najtvrdokornijeg člana tima s bolesnom maštom i dajete mu zadatak da u što kraćem vremenu organizira sabotažu koja će srušiti uslugu. Ako je teško dijagnosticirati, još bolje. Nećete vjerovati na kakve čudne i cool ideje inženjeri dolaze ako im date ideju da nešto razbiju. A ako im obećate testni stalak za ovo, to je vrlo dobro.
Kakav je ovo tvoj DRP?!
Dakle, definirali ste model prijetnje. Uzeli su u obzir i lokalno stanovništvo koje reže optičke kabele u potrazi za bakrom, te vojni radar koji ispušta radiorelejnu liniju striktno petkom u 16:46. Sada moramo smisliti što ćemo sa svime time.
Vaš zadatak je da napišete baš one crvene koverte koje će se otvoriti u hitnim slučajevima. Odmah očekujte da će, kad (ne ako!) svemu dođe kraj, u blizini biti samo najneiskusniji pripravnik kojem će se ruke grčevito tresti od užasa onoga što se događa. Pogledajte kako se znakovi za hitne slučajeve implementiraju u medicinske ordinacije. Na primjer, što učiniti u slučaju anafilaktičkog šoka. Medicinsko osoblje zna sve protokole napamet, ali kada osoba u blizini počne umirati, vrlo često se svi bespomoćno hvataju za sve što im predstoji. Da biste to učinili, na zidu postoje jasne upute sa stavkama poput "otvorite pakiranje tog i tog" i "dajte toliko jedinica lijeka intravenski."
Teško je razmišljati u hitnim slučajevima! Trebale bi postojati jednostavne upute za analizu kralježnice.
Dobar DRP sastoji se od nekoliko jednostavnih blokova:
- Koga obavijestiti o početku nesreće. Ovo je važno kako bi se proces eliminacije što više paralelizirao.
- Kako ispravno dijagnosticirati - pratimo, gledamo u systemctl status servicename i tako dalje.
- Koliko vremena možete provesti u svakoj fazi? Ako nemate vremena to ručno popraviti unutar SLA vremena, virtualni stroj se ugasi i vraća s jučerašnje sigurnosne kopije.
- Kako biti siguran da je pad završen.
Imajte na umu da DRP počinje kada usluga potpuno otkaže i završava kada se usluga obnovi, čak i uz smanjenu učinkovitost. Jednostavan gubitak rezervacije ne bi trebao pokrenuti DRP. Također možete upisati šalicu čaja u DRP. Ozbiljno. Prema statistici, mnoge nesreće prerastu iz neugodnih u katastrofalne zbog činjenice da osoblje u panici žuri nešto popraviti, istovremeno ubijajući jedini živi čvor s podacima ili konačno dokrajčujući klaster. U pravilu, 5 minuta uz šalicu čaja dat će vam malo vremena da se smirite i analizirate što se događa.
Ne brkajte DRP i putovnicu sustava! Ne opterećujte ga nepotrebnim podacima. Samo omogućite brzo i praktično korištenje hiperveza za odlazak na željeni odjeljak dokumentacije i čitanje u proširenom formatu o potrebnim dijelovima arhitekture usluge. A u samom DRP-u postoje samo izravne upute o tome gdje i kako se povezati s određenim naredbama za kopiranje i lijepljenje.
Kako ispravno testirati
Provjerite može li bilo koji odgovorni zaposlenik ispuniti sve stavke. U najvažnijem trenutku može se ispostaviti da inženjer nema prava pristupa traženom sustavu, nema lozinki za traženi račun ili nema pojma što je “Poveži se na konzolu za upravljanje uslugom putem proxyja na glavni ured” znači. Svaka točka bi trebala biti krajnje jednostavna.
pogrešno - "Idite na virtualizaciju i ponovno pokrenite mrtvi čvor"
ispravno - "Povežite se putem web sučelja na virt.example.com, u odjeljku čvorova ponovno pokrenite čvor koji uzrokuje pogrešku."
Izbjegavajte dvosmislenost. Sjetite se prestrašenog pripravnika.
Obavezno testirajte DRP. Ovo nije samo plan za predstavu - to je nešto što će Vama i Vašim klijentima omogućiti da brzo izađete iz kritične situacije. Najbolje je to učiniti nekoliko puta:
- Jedan stručnjak i nekoliko pripravnika rade na ispitnom stolu koji u najvećoj mogućoj mjeri simulira stvarnu uslugu. Stručnjak kvari uslugu na različite načine i omogućuje polaznicima da je vrate u rad prema DRP-u. Svi problemi, dokumentacijske nejasnoće i pogreške se evidentiraju. Nakon što su polaznici obučeni, DRP se proširuje i pojednostavljuje u nejasnim područjima.
- Testiranje na stvarnom servisu. Zapravo, nikada ne možete stvoriti savršenu kopiju stvarne usluge. Stoga je nekoliko puta godišnje potrebno rutinski isključiti neke od poslužitelja, prekinuti veze i izazvati druge katastrofe s popisa prijetnji kako bi se procijenio redoslijed oporavka. Planirani kvar od 10 minuta usred noći bolji je od iznenadnog kvara od nekoliko sati tijekom vršnog opterećenja s gubitkom podataka.
- Pravo otklanjanje nesreće. Da, ovo je također dio testiranja. Ukoliko se dogodi nesreća koja nije bila na listi prijetnji, potrebno je dopuniti i finalizirati DRP temeljem rezultata njezine istrage.
Ključne točke
- Ako se sranje može dogoditi, ne samo da će se dogoditi, nego će se to dogoditi u najkatastrofalnijem mogućem scenariju.
- Provjerite imate li resurse za nadogradnju.
- Provjerite imate li sigurnosne kopije, one se automatski stvaraju i redovito provjeravaju dosljednost.
- Razmislite o tipičnim scenarijima prijetnji.
- Dajte inženjerima priliku da osmisle nestandardne opcije za isporuku usluge.
- DRP bi trebala biti jednostavna i jasna uputa. Sve složene dijagnostike provode se tek nakon ponovnog uspostavljanja usluge klijenta. Čak i ako je u rezervnom kapacitetu.
- Navedite ključne telefonske brojeve i kontakte u DRP-u.
- Redovito testirajte razumijevanje DRP-a od strane zaposlenika.
- Uredite planirane nesreće na proizvodnim mjestima. Stalci ne mogu zamijeniti sve.
Izvor: www.habr.com