Čak i u vrijeme katastrofe uvijek je vrijeme za šalicu čaja
DRP (plan oporavka od katastrofe) - to je nešto što, idealno, nikad neće biti potrebno. No, ako se slučajno dogodi da migrirajući ježevi prerežu glavnu optičku mrežu ili junior administrativni radnik izbriše proizvodnu bazu, zasigurno želite biti sigurni da imate unaprijed pripremljen plan za to što učiniti s tom situacijom.
Dok klijenti u panici počinju zvati tehničku podršku, junior traži cijanide, vi mudro otvarate crvenu omotnicu i počinjete sve dovoditi u red.
U ovom postu želim podijeliti preporuke o tome kako pisati DRP i što bi on trebao sadržavati. Također ćemo razmotriti sljedeće stvari:
- Naučit ćemo razmišljati kao zločinac.
- Razmotrit ćemo prednosti šalice čaja tijekom apokalipse.
- Razviti ćemo prikladnu strukturu DRP-a
- Pogledati ćemo kako ga testirati
Za koje tvrtke to može biti korisno
Veoma je teško povući granicu kada IT odjel počne imati potrebu za sličnim stvarima. Rekao bih da vam DRP sigurno treba ako:
- Zaustavljanje poslužitelja, aplikacije ili gubitak neke baze podataka rezultira značajnim gubicima za poslovanje u cjelini.
- Imate kompletan IT odjel. Mislim, odjel kao punopravna jedinica unutar tvrtke, sa svojim budžetom, a ne samo nekoliko iscrpljenih zaposlenika koji postavljaju mrežu, čiste viruse i puni god.
- Imate stvarni budžet barem za djelomično rezerviranje u slučaju izvanredne situacije.
Kada IT odjel mjesecima moli za barem par HDD-a u starom poslužitelju za backup, teško ćete organizirati potpuni prijenos pao usluga na rezervne kapacitete. Ipak, i ovdje će dokumentacija biti korisna.
Dokumentacija je važna
Započnite s dokumentacijom. Pretpostavimo da vaš servis radi na skripti u Perlu, koja je napisana prije tri generacije administratora, a nitko ne zna kako ona funkcionira. Nakupljeni tehnički dug i nedostatak dokumentacije neizbježno će vam nanijeti štetu ne samo na koljenu, nego i na drugim udovima, to je više pitanje vremena.
Nakon što imate dobro opisane komponente usluge, pregledajte statistiku o kvarovima. Gotovo sigurno će biti potpuno tipični. Na primjer, povremeno se vaš disk prepunjava, što dovodi do otkaza nodu dok se ručno ne očisti. Ili usluga za korisnike postaje nedostupna zato što je netko opet zaboravio produžiti certifikat, a Let’s Encrypt nije mogao ili nije htio postaviti.
Razmišljajte kao diverzant
Najteži dio je predviđanje onih kvarova koji se još nikada nisu dogodili, a koji bi potencijalno mogli potpuno srušiti vašu uslugu. Ovde obično igramo zlikovce s kolegama. Uzimajte puno kafe i nešto ukusno te se zatvorite u sobu za sastanke. Samo se pobrinite da u istoj sobi zatvorite one inženjere koji su postavili ciljan servis ili redovito s njim rade. Zatim, bilo na ploči ili na papiru, počnite crtati sve moguće horore koji se mogu dogoditi s vašom uslugom. Nije potrebno detaljno opisivati do konkretne čistačice koja izvlači kablove, dovoljno je razmatrati scenarij „Poremećaja integriteta lokalne mreže“.
Obično, većina tipičnih kvarova ulazi u sljedeće vrste:
- Kvar mreže
- Kvar usluga operativnog sistema
- Kvar aplikacije
- Kvar hardvera
- Kvar virtualizacije
Jednostavno idete kroz svaku vrstu i gledate što se primjenjuje na vašu uslugu. Na primjer, može pasti i ne podići se demon Nginx — to je kvar s operativnim sistemom. Rijetka situacija koja dovodi vašu web aplikaciju u neoperativno stanje — kvar softvera. Tijekom ovog koraka važno je razviti dijagnostiku problema. Kako razlikovati zamrznuti interfejs na virtualizaciji od pao CISCO-a i kvar na mreži, na primjer. To je važno da biste brže pronašli odgovorne i počeli ih vući za rep, dok kvar ne bude uklonjen.
Nakon što su tipični problemi zabilježeni, natočite još kafe i počnite razmatrati najčudnije scenarije kada neki parametri počnu drastično izlaziti van norme. Na primjer:
- Što će se dogoditi ako se vrijeme na aktivnoj nodi pomakne jednu minutu unazad u odnosu na druge u klasteru?
- A ako se vrijeme pomakne unaprijed, a ako za 10 godina?
- Što će se dogoditi ako tijekom sinkronizacije nod klastera iznenada izgubi mrežu?
- Što će se dogoditi ako se dvije nodove ne uspiju dogovoriti o vođstvu zbog privremene izolacije jedni od drugih putem mreže?
U ovoj fazi vrlo pomaže povratni pristup. Uzmite najupornijeg člana tima s bolesnom maštom i dajte mu zadatak da u najkraćem mogućem roku organizira diverziju koja će srušiti servis. Ako je teško dijagnosticirati — još bolje. Nećete vjerovati kakve čudne i sjajne ideje inženjeri iznose kada im date do znanja da nešto treba srušiti. A ako im obećate testno okruženje za to — bit će savršeno.
Što je taj vaš DRP?!
Dakle, odredili ste model prijetnje. Uzimajući u obzir i lokalne stanovnike koji režu optičke kabele tražeći metal, i vojni radar koji ruši radiorelejnu liniju strogo petkom u 16:46. Sada trebate shvatiti što učiniti s tim.
Vaš zadatak je napisati one crvene omotnice koje će se otvoriti u hitnoj situaciji. Odmah planirajte da kada (ne ako!) sve krene po zlu, u blizini će biti samo najneiskusniji stažist, čije će ruke trzati od užasa. Pogledajte kako su implementirane hitne oznake u medicinskim kabinetima. Na primjer, što učiniti u slučaju anafilaktičkog šoka. Medicinsko osoblje napamet zna sve protokole, ali kada netko počne umirati, često se bespomoćno hvataju za sve što im je pri ruci. Za to na zidu visi jasna instrukcija s točkama poput "otvoriti pakiranje onoga" i "unijeti intravenozno toliko jedinica pripravka."
U hitnoj situaciji teško je razmišljati! Moraju biti jednostavne upute za parsiranje osnovnim instinktom.
Dobar DRP sastoji se od nekoliko jednostavnih blokova:
- Koga obavijestiti o početku nesreće. To je važno da bi se proces otklanjanja problema mogao maksimalno paralelizirati.
- Kako ispravno dijagnosticirati — provodimo traceroute, gledamo u systemctl status servicename i tako dalje.
- Koliko vremena može biti potrošeno na svaki korak. Ako ne uspijete popraviti ručno unutar SLA vremena — virtualna mašina se uništava i vraća iz jučerašnje sigurnosne kopije.
- Kako se uvjeriti da je nesreća završena.
Zapamtite, da DRP započinje kada usluga potpuno otkaže i završava obnavljanjem funkcionalnosti, čak i uz smanjenu učinkovitost. Sam gubitak rezerviranja ne bi trebao aktivirati DRP. A možete čak uključiti i šalicu čaja u DRP. Ozbiljno. Prema statistikama, mnoge nesreće iz neugodnih postaju katastrofalne zbog toga što osoblje u panici pokušava nešto popraviti, pritom uništavajući jedinu živu nodu s podacima ili konačno uništavajući klaster. Obično, 5 minuta za šalicu čaja dati će vam malo vremena da se smirite i analizirate što se događa.
Nemojte brkati DRP i sustavni pasport! Ne preopterećujte ga suvišnim podacima. Samo omogućite brzo i jednostavno preusmjeravanje putem hiperveza u potrebne dijelove dokumentacije i čitajte o potrebnim dijelovima arhitekture usluge u proširenom formatu. A u samom DRP-u samo izravne upute kamo i kako se povezati s konkretnim komandama za kopiranje.
Kako pravilno testirati
Osigurajte da svaki odgovorni zaposlenik može izvršiti sve točke. U najbitnijem trenutku može se pokazati da inženjer nema prava pristupa potrebnom sustavu, nedostaju mu lozinke za pravi račun ili nema pojma što znači 'Povežite se s konzolom upravljanja uslugom putem proxyja u glavnom uredu'. Svaka točka trebala bi biti krajnje jednostavna.
Netočno — 'Idite na virtualizaciju i rebootajte mrtvu nodu'
Točno — 'Povežite se putem web sučelja na virt.example.com, u odjeljku nodi izvršite ponovno pokretanje nodi koja izaziva grešku'.
Izbjegavajte dvosmislenosti. Zapamtite na uplašenog pripravnika.
Obavezno testirajte DRP. To nije samo plan za odraditi – to je ono što će vam i vašim klijentima omogućiti brz izlaz iz kritične situacije. Optimalno je napraviti to nekoliko puta:
- Jedan stručnjak i nekoliko pripravnika rade na testnom postavu koji maksimalno imitira stvarnu uslugu. Stručnjak uništava uslugu na razne načine i daje mogućnost pripravnicima da je obnove prema DRP-u. Sve probleme, nejasnoće u dokumentaciji i greške bilježe se. Nakon obuke pripravnika, DRP se dopunjuje i pojednostavljuje na nejasnim mjestima.
- Testiranje na stvarnoj usluzi. Zapravo, nikada se ne može stvoriti savršena kopija stvarne usluge. Stoga, par puta godišnje, potrebno je planirati isključivanje dijela poslužitelja, prekinuti veze i organizirati druge nesreće s popisa prijetnji kako bi se ocijenila učinkovitost oporavka. Bolje je planirana nesreća od 10 minuta usred noći nego iznenadni kvar koji traje nekoliko sati u vršnom opterećenju s gubitkom podataka.
- Stvarno otklanjanje nesreće. Da, to je također dio testiranja. Ako se dogodi nesreća koja nije bila na popisu prijetnji, potrebno je nadopuniti i doraditi DRP na temelju rezultata njezine istrage.
Ključne točke
- Ako se nesreća može dogoditi, ona neće samo nastati, već će se dogoditi na što katastrofalniji način.
- Provjerite imate li resurse za hitno preusmjeravanje opterećenja.
- Provjerite imate li sigurnosne kopije, da se one automatski kreiraju i redovito testiraju na dosljednost.
- Razmislite o tipičnim scenarijima prijetnji.
- Omogućite inženjerima da smišljaju netipične načine kako srušiti uslugu.
- DRP bi trebao biti jednostavna i jasna uputa. Sva složena dijagnostika samo nakon što se klijentima obnovi usluga. Čak i na rezervnim kapacitetima.
- Navedite ključne telefone i kontakte u DRP-u.
- Redovito testirajte zaposlenike o razumijevanju DRP-a.
- Organizirajte planirane nesreće na produkciji. Stendi ne mogu zamijeniti sve.
Izvor: habr.com
