Čak i tokom katastrofe uvek se nađe vremena za šoljicu čaja
DRP (plan oporavka od katastrofe) je stvar koja u idealnom slučaju nikada neće biti potrebna. Ali ako iznenada dabrovi koji migriraju tokom sezone parenja progrizu optičko vlakno oko kičme ili mlađi administrator ispusti produktivnu bazu, definitivno želite biti sigurni da ćete imati unaprijed napravljen plan šta učiniti sa svom ovom sramotom.
Dok kupci u panici počinju da prekidaju telefone tehničke podrške, junior traži cijanid, vi mudro otvarate crvenu kovertu i počinjete da sve dovodite u red.
U ovom postu želim podijeliti preporuke o tome kako napisati DRP i šta treba da sadrži. Također ćemo razmotriti sljedeće stvari:
- Naučimo da razmišljamo kao negativac.
- Pogledajmo prednosti šoljice čaja tokom apokalipse.
- Razmislimo o prikladnoj DRP strukturi
- Hajde da vidimo kako da ga testiramo
Za koje kompanije bi ovo moglo biti korisno?
Vrlo je teško podvući crtu kada IT odjelu počnu trebati takve stvari. Rekao bih da vam DRP svakako treba ako:
- Zaustavljanje servera, aplikacije ili gubitak neke baze podataka će dovesti do značajnih gubitaka za poslovanje u cjelini.
- Imate potpuno IT odjel. U smislu odeljenja u vidu punopravne jedinice kompanije, sa sopstvenim budžetom, a ne samo nekoliko umornih zaposlenih koji postavljaju mrežu, čiste viruse i pune štampače.
- Imate realan budžet za barem djelomično otpuštanje u hitnim slučajevima.
Kada IT odjel mjesecima moli barem nekoliko HDD-a u stari server za sigurnosne kopije, malo je vjerovatno da ćete moći organizirati potpuno premještanje neuspjelog servisa u rezervisanje kapaciteta. Iako ovdje dokumentacija neće biti suvišna.
Dokumentacija je važna
Počnite s dokumentacijom. Recimo da vaš servis radi na Perl skripti koju su prije tri generacije napisali administratori, ali niko ne zna kako funkcionira. Nagomilani tehnički dug i nedostatak dokumentacije neminovno će vam pucati ne samo u koleno, već i u druge udove, više je pitanje vremena.
Kada dobijete dobar opis komponenti usluge, potražite statistiku nezgoda. Oni će gotovo sigurno biti potpuno tipični. Na primjer, vaš disk se s vremena na vrijeme napuni, što uzrokuje neuspjeh čvora dok se ručno ne očisti. Ili klijentska usluga postaje nedostupna zbog činjenice da je neko opet zaboravio obnoviti certifikat, a Let's Encrypt nije mogao ili nije htio konfigurirati.
Misli kao saboter
Najteži dio je u predviđanju onih nesreća koje se nikada prije nisu dogodile, ali koje bi potencijalno mogle u potpunosti srušiti vašu uslugu. Ovdje moje kolege i ja obično igramo negativce. Uzmite puno kafe i nešto ukusno i zaključajte se u salu za sastanke. Samo se pobrinite da u istim pregovorima uključite one inženjere koji su sami razvili ciljnu uslugu ili redovno rade s njom. Zatim, bilo na tabli ili na papiru, počinjete crtati sve moguće strahote koje bi se mogle dogoditi vašoj službi. Nije potrebno ulaziti u detalje do određene čistačice i izvlačenja kablova, dovoljno je razmotriti scenario „Kršenje integriteta lokalne mreže“.
Tipično, najčešće hitne situacije spadaju u sljedeće vrste:
- Greška mreže
- Kvar OS servisa
- Neuspjeh aplikacije
- Kvar gvožđa
- Greška virtuelizacije
Samo prođite kroz svaku vrstu i vidite šta se odnosi na vašu uslugu. Na primjer, Nginx daemon može pasti i ne rasti - to znači kvarove na dijelu OS-a. Rijetka situacija koja uzrokuje kvar vaše web aplikacije je kvar softvera. Dok radite kroz ovu fazu, važno je razraditi dijagnozu problema. Kako razlikovati zamrznuto sučelje na virtuelizaciji od palog cis diska i mrežne nesreće, 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, sipamo još kafe i počinjemo razmatrati najčudnije scenarije, kada neki parametri počnu daleko prelaziti normu. Na primjer:
- Šta se događa ako se vrijeme na aktivnom čvoru pomakne za minutu unazad u odnosu na druge u klasteru?
- Šta ako vrijeme krene naprijed, šta ako za 10 godina?
- Šta se dešava ako čvor klastera iznenada izgubi svoju mrežu tokom sinhronizacije?
- Šta će se dogoditi ako dva čvora ne dijele vodstvo zbog privremene izolacije jedan drugog u mreži?
U ovoj fazi, obrnuti pristup je od velike pomoći. Uzimate najtvrdokornijeg člana ekipe sa bolesnom maštom i dajete mu zadatak da u najkraćem mogućem roku organizuje sabotažu koja će srušiti servis. Ako je teško postaviti dijagnozu, još bolje. Nećete vjerovati na kakve čudne i cool ideje dolaze inženjeri ako im date ideju da nešto razbiju. A ako im obećate probnu klupu za ovo, to je sasvim u redu.
Šta je ovo tvoj DRP?!
Dakle, definisali ste svoj model pretnje. Uzeli su u obzir i lokalne stanovnike koji su presekli optičke kablove u potrazi za bakrom, te vojni radar koji ispušta radio relejnu liniju strogo petkom u 16:46. Sada treba da shvatimo šta da radimo sa svim ovim.
Vaš zadatak je da napišete one vrlo crvene koverte koje će se otvoriti u hitnim slučajevima. Odmah očekujte da će, kada (ne ako!) svemu dođe kraj, u blizini biti samo najneiskusniji pripravnik, čije će se ruke žestoko tresti od užasa onoga što se dešava. Pogledajte kako se postavljaju znakovi za hitne slučajeve u medicinskim ordinacijama. Na primjer, šta učiniti u slučaju anafilaktičkog šoka. Medicinsko osoblje zna sve protokole napamet, ali kada osoba u blizini počne da umire, vrlo često se svi bespomoćno hvataju za sve što se vidi. Da biste to učinili, postoje jasne upute na zidu s stavkama poput „otvori pakovanje tog i takvog“ i „dati toliko jedinica lijeka intravenozno“.
Teško je razmišljati u hitnim slučajevima! Trebalo bi postojati jednostavna uputstva za raščlanjivanje kičmene moždine.
Dobar DRP se sastoji od nekoliko jednostavnih blokova:
- Koga obavijestiti o početku nesreće. Ovo je važno kako bi se što više paralelizirao proces eliminacije.
- Kako ispravno dijagnosticirati - izvršite praćenje, pogledajte status systemctl servicename i tako dalje.
- Koliko vremena možete provesti na svakoj pozornici? Ako nemate vremena da to popravite ručno unutar SLA vremena, virtualna mašina će biti ubijena i vraćena iz jučerašnje sigurnosne kopije.
- Kako osigurati da je nesreća gotova.
Zapamtite da DRP počinje kada je usluga potpuno otkazana i završava se kada se usluga vrati, čak i sa smanjenom efikasnošću. Običan gubitak rezervacije ne bi trebao pokrenuti DRP. Takođe možete upisati šolju čaja u DRP. Ozbiljno. Prema statistikama, mnoge nesreće se iz neugodnih pretvaraju u katastrofalne zbog činjenice da osoblje u panici žuri da nešto popravi, istovremeno ubijajući jedini živi čvor s podacima ili konačno dovršavajući klaster. Po pravilu, 5 minuta uz šoljicu čaja daće vam vremena da se smirite i analizirate šta se dešava.
Nemojte brkati DRP i sistemski pasoš! Nemojte ga preopteretiti nepotrebnim podacima. Samo omogućite brzu i praktičnu upotrebu hiperveza za odlazak na željeni dio dokumentacije i čitanje u proširenom formatu o potrebnim dijelovima arhitekture usluge. A u samom DRP-u postoje samo direktne upute o tome gdje i kako se povezati s određenim komandama za kopiranje-paste.
Kako ispravno testirati
Pobrinite se da svaki odgovorni zaposlenik može završiti sve stavke. U najvažnijem trenutku može se ispostaviti da inženjer nema prava pristupa traženom sistemu, da nema lozinki za traženi nalog ili da nema pojma šta „Poveži se na konzolu za upravljanje uslugama preko proxyja na sjedište” znači. Svaka tačka treba da bude krajnje jednostavna.
Pogrešno - “Idite na virtuelizaciju i ponovo pokrenite mrtvi čvor”
Tačno - “Povežite se putem web sučelja na virt.example.com, u odjeljku čvorovi, ponovo pokrenite čvor koji uzrokuje grešku.”
Izbjegavajte dvosmislenost. Sjetite se uplaš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 se brzo izvučete iz kritične situacije. Najbolje je to učiniti nekoliko puta:
- Jedan stručnjak i nekoliko polaznika rade na ispitnom stolu koji maksimalno simulira pravu uslugu. Stručnjak razbija uslugu na različite načine i omogućava polaznicima da je restauriraju prema DRP-u. Svi problemi, nejasnoće u dokumentaciji i greške se evidentiraju. Nakon što polaznici prođu obuku, DRP se proširuje i pojednostavljuje u nejasnim oblastima.
- Testiranje na pravom servisu. U stvari, nikada ne možete stvoriti savršenu kopiju prave usluge. Stoga je potrebno nekoliko puta godišnje rutinski isključiti neki od servera, prekinuti veze i izazvati druge katastrofe sa liste prijetnji kako bi se procijenio redosled oporavka. Planirani kvar u trajanju od 10 minuta usred noći bolji je od iznenadnog kvara u trajanju od nekoliko sati tokom vršnog opterećenja sa gubitkom podataka.
- Pravo rješavanje problema. Da, ovo je također dio testiranja. Ukoliko dođe do nezgode koja nije bila na listi prijetnji, potrebno je dopuniti i finalizirati DRP na osnovu rezultata njegove istrage.
Ključne točke
- Ako se sranje može dogoditi, ne samo da će se dogoditi, već će se to dogoditi u najkatastrofalnijem mogućem scenariju.
- Provjerite imate li resurse za hitni prijenos opterećenja.
- Pobrinite se da imate sigurnosne kopije, one se automatski kreiraju i redovno provjeravaju dosljednost.
- Razmislite o tipičnim scenarijima prijetnji.
- Dajte inženjerima priliku da smisle nestandardne opcije za isporuku usluge.
- DRP bi trebao biti jednostavna i tupa instrukcija. Sva složena dijagnostika se vrši tek nakon što je usluga klijenta obnovljena. Čak iu rezervnom kapacitetu.
- Navedite ključne telefonske brojeve i kontakte u DRP-u.
- Redovno testirajte razumijevanje DRP-a od strane zaposlenih.
- Organizovati planirane nezgode na proizvodnim lokacijama. Stalci ne mogu sve zamijeniti.
izvor: www.habr.com