Ancu durante un disastru, ci hè sempre u tempu per una tazza di tè
DRP (pianu di ricuperazione di disastru) hè una cosa chì idealmente ùn serà mai necessariu. Ma se di colpu i castori chì migranu durante a staghjoni di l'accoppiamentu gnaw through the backbone fibre optical or a junior admin drops the basis productive, definitamente vulete esse sicuru d'avè un pianu pre-fattu per ciò chì fà cù tutta sta disgrazia.
Mentre i clienti in u panicu cumincianu à cutà i telefoni di supportu tecnicu, u junior cerca di cianuru, avete sapientemente apre u bustu rossu è cumincianu à mette tuttu in ordine.
In questu post vogliu sparte cunsiglii nantu à cumu scrive un DRP è ciò chì deve cuntene. Fighjemu ancu e cose seguenti:
- Amparemu à pensà cum'è un cattivu.
- Fighjemu i benefici di una tazza di tè durante l'apocalisse.
- Pensemu à una struttura DRP cunvene
- Videmu cumu pruvà
Per quale cumpagnie puderia esse utile?
Hè assai difficiuli di disegnà a linea quandu u dipartimentu di l'IT cumencia à avè bisognu di tali cose. Diciaraghju chì avete bisognu di DRP se:
- Firmà un servitore, una applicazione o perde una basa di dati porta à perdite significative per l'affari in generale.
- Avete un dipartimentu IT cumpletu. In u sensu di un dipartimentu in a forma di una unità cumpleta di a cumpagnia, cù u so propiu budgetu, è micca solu uni pochi di impiegati stanchi chì ponenu una reta, pulizziari virus è ricaricate stampanti.
- Avete un budgetu realistu per almenu una redundanza parziale in casu d'urgenza.
Quandu u dipartimentu di l'IT hà dumandatu durante mesi per almenu un paru di HDD in un vechju servitore per backups, hè improbabile di pudè urganizà un muvimentu cumpletu di un serviziu fallutu per riservà a capacità. Ancu s'è quì a documentazione ùn serà micca superflua.
A documentazione hè impurtante
Cumincià cù a documentazione. Diciamu chì u vostru serviziu funziona nantu à un script Perl chì hè statu scrittu trè generazioni fà da l'amministratori, ma nimu ùn sapi cumu funziona. U debitu tecnicu accumulatu è a mancanza di documentazione inevitabbilmente ti spararanu micca solu in u ghjinochju, ma ancu in altri membri, hè più una questione di tempu.
Una volta avete una bona descrizzione di i cumpunenti di u serviziu, cercate statistiche d'accidenti. Seranu quasi certamenti cumplitamenti tipici. Per esempiu, u vostru discu diventa pienu da u tempu à u tempu, chì face chì u node falla finu à ch'ellu hè pulitu manualmente. O u serviziu di u cliente diventa indisponibile per u fattu chì qualchissia s'hè scurdatu di rinnuvà u certificatu, è Let's Encrypt ùn hà micca pussutu o ùn vulia micca cunfigurà.
Pensieri cum'è un sabotatore
A parte più difficiuli hè di predichendu quelli accidenti chì ùn sò mai accaduti prima, ma chì puderanu falla u vostru serviziu cumpletamente. Quì i mo culleghi è eiu di solitu ghjucà i villani. Pigliate assai caffè è qualcosa di gustoso è chjudevi in una sala di riunioni. Solu assicuratevi chì in e stesse negoziazioni chjude in quelli ingegneri chì anu sviluppatu u serviziu di destinazione o travaglianu regularmente cun ellu. Allora, o nantu à u tavulinu o nantu à carta, cuminciate à disegnà tutti l'orrori pussibuli chì puderanu accade à u vostru serviziu. Ùn hè micca necessariu di andà in dettagliu finu à una donna di pulizia specifica è tirà i cavi; hè abbastanza per cunsiderà u scenariu di "Violazione di l'integrità di a reta lucale".
Di genere, a maiò parte di e situazioni d'urgenza tipica sò in i seguenti tipi:
- fallimentu di a rete
- fallimentu di i servizii OS
- fallimentu di l'applicazione
- fallimentu di ferru
- fallimentu di virtualizazione
Basta à passà per ogni tipu è vede ciò chì s'applica à u vostru serviziu. Per esempiu, u daemon Nginx pò falà è micca risurrezzione - questu significa fallimenti da parte di u SO. Una situazione rara chì provoca a vostra applicazione web per fallu hè un fallimentu di u software. Mentre travaglia in questa tappa, hè impurtante di travaglià u diagnosticu di u prublema. Cumu distingue una interfaccia congelata nantu à a virtualizazione da un cis drive cadutu è un accidentu di rete, per esempiu. Questu hè impurtante per truvà rapidamente i rispunsevuli è cumincianu à tirà a cuda finu à chì l'accidentu hè risoltu.
Dopu chì i prublemi tipici sò scritti, versemu più caffè è cuminciamu à cunsiderà i scenarii più strani, quandu certi paràmetri cumincianu à andà assai oltre a norma. Per esempiu:
- Chì succede se u tempu nantu à u node attivu si move un minutu in quantu à l'altri in u cluster?
- E se u tempu avanzava, è se da 10 anni?
- Chì succede se un node di cluster perde di colpu a so reta durante a sincronizazione?
- Chì succede se dui nodi ùn sparte micca a dirigenza per via di l'isolamentu tempurale di l'altri in a reta?
In questu stadiu, l'approcciu inversu hè assai utile. Pigliate u membru più stubbornu di a squadra cù una imaginazione malata è dà u compitu di urganizà un sabotage in u più brevi tempu pussibule chì abbatterà u serviziu. Se hè difficiule di diagnosticà, ancu megliu. Ùn crederete micca ciò chì l'idee strane è fresche venenu ingegneri se li dà un'idea per rompe qualcosa. È se li prumetti un banc di prova per questu, hè assolutamente bè.
Chì ghjè stu DRP di u vostru?!
Cusì avete definitu u vostru mudellu di minaccia. Anu ancu pigliatu in cunsiderà i residenti lucali chì taglianu cavi di fibra ottica in cerca di rame, è un radar militare chì abbanduneghja una linea di relay radio strettamente u venneri à 16:46. Avà avemu bisognu di capisce ciò chì fà cù tuttu questu.
U vostru compitu hè di scrive quelli busti assai rossi chì saranu aperti in una emergenza. Immediatamente s'aspittava chì quandu (micca s'ellu!) tuttu vene à a fine, solu l'internu più inexperienced sarà vicinu, chì e mani si tremaranu violentemente da l'orrore di ciò chì succede. Vede cumu i segni di emergenza sò implementati in l'uffizii medichi. Per esempiu, chì fà in casu di scossa anafilattica. U staffu medicale cunnosce tutti i protokolli da u core, ma quandu una persona vicinu principia à mori, assai spessu tutti s'appoghjanu impotente à tuttu in vista. Per fà questu, ci sò struzzioni chjaru nantu à u muru cù articuli cum'è "apre u pacchettu di tali è tali" è "amministrate tante unità di a droga per via intravenosa".
Hè difficiuli di pensà in una emergenza! Ci deve esse struzzioni simplici per l'analisi di a spina.
Un bon DRP hè custituitu da parechji blocchi simplici:
- À quale avvisà u principiu di un accidente. Questu hè impurtante per parallelizà u prucessu di eliminazione quantu pussibule.
- Cumu diagnosticà currettamente - eseguite una traccia, fighjate in u nome di serviziu di status di systemctl è cusì.
- Quantu tempu pudete passà in ogni tappa? Se ùn avete micca u tempu di riparà manualmente in u tempu SLA, a macchina virtuale hè uccisa è rinviata da a copia di salvezza di ieri.
- Cumu assicurà chì l'accidentu hè finitu.
Ricurdativi chì DRP principia quandu u serviziu hà fiascatu cumplettamente è finisce quandu u serviziu hè restauratu, ancu cù efficienza ridutta. Semplicemente perde una riservazione ùn deve micca attivà DRP. Pudete ancu scrive una tazza di tè in u DRP. Seriu. Sicondu statistiche, parechji accidenti passanu da dispiacevule à catastròficu per via di u fattu chì u persunale in un panicu rush per riparà qualcosa, uccidendu simultaneamente l'unicu nodu vivu cù dati o infine finisce u cluster. In regula, 5 minuti cù una tazza di tè vi darà un pocu di tempu per calmà è analizà ciò chì succede.
Ùn cunfundite micca DRP è passaportu di u sistema! Ùn overload it cù dati inutili. Basta fà pussibule di utilizà rapidamente è cunvenemente iperligami per andà à a sezione desiderata di a documentazione è leghje in un formatu allargatu nantu à e sezzioni necessarii di l'architettura di serviziu. È in u DRP stessu ci sò solu struzzioni diretti nantu à induve è cumu cunnette cù cumandamenti specifichi per copia-incolla.
Cumu pruvà currettamente
Assicuratevi chì ogni impiigatu rispunsevuli hè capaci di cumpiendu tutti l'articuli. À u mumentu più cruciale, pò esse chì l'ingegnere ùn hà micca diritti per accede à u sistema necessariu, ùn ci hè micca password per u contu necessariu, o ùn hà micca idea di ciò chì "Connectate à a cunsola di gestione di u serviziu per mezu di un proxy à l'ughjettu. sede centrale" significa. Ogni puntu deve esse assai simplice.
Incorrecte - "Vai à a virtualizazione è riavvia u node mortu"
Right - "Connettate via l'interfaccia web à virt.example.com, in a sezione di nodi, reboot u node chì causa l'errore".
Evita l'ambiguità. Ricurdativi di l'internu spavintatu.
Assicuratevi di pruvà DRP. Questu ùn hè micca solu un pianu di spettaculu - hè qualcosa chì vi permetterà à voi è à i vostri clienti di esce rapidamente da una situazione critica. Hè megliu fà questu parechje volte:
- Un espertu è parechji trainees travaglianu nantu à un bancu di prova chì simula un veru serviziu quantu pussibule. L'espertu rompe u serviziu in diverse manere è permette à i trainees di ristabilisce secondu u DRP. Tutti i prublemi, ambiguità di documentazione è errori sò registrati. Dopu chì i trainees sò furmatu, u DRP hè allargatu è simplificatu in spazii pocu chjaru.
- Pruvate nantu à un serviziu veru. In fatti, ùn pudete mai creà una copia perfetta di un veru serviziu. Per quessa, un coppiu di volte à l'annu hè necessariu di disattivà in rutina alcuni di i servitori, sever i cunnessione è causanu altri disastri da a lista di minacce per valutà a prucedura di ricuperazione. Un fallimentu pianificatu per 10 minuti in u mità di a notte hè megliu cà un fallimentu bruscu per parechje ore durante a carica di punta cù a perdita di dati.
- Risoluzione di prublemi vera. Iè, questu hè ancu parte di a prova. Se un accidentu accade chì ùn era micca nantu à a lista di minacce, hè necessariu di cumplementà è finalizà u DRP basatu nantu à i risultati di a so investigazione.
Punti chjave
- Se a merda pò accade, ùn succede micca solu, ma farà cusì in u scenariu più catastròficu pussibule.
- Assicuratevi di avè risorse per u trasferimentu di carica di emergenza.
- Assicuratevi di avè backups, sò creati automaticamente è verificati regularmente per a coherenza.
- Pensate à i scenarii tipici di minaccia.
- Dà à l'ingegneri l'uppurtunità di vene cù opzioni non standard per furnisce u serviziu.
- DRP deve esse una struzzione simplice è contundente. Tutti i diagnostichi cumplessi sò realizati solu dopu chì u serviziu di i clienti hè statu restauratu. Ancu s'è a capacità di riserva.
- Fornite numeri di telefunu chjave è cuntatti in u DRP.
- Pruvate a cunniscenza di l'impiegati di u DRP regularmente.
- Organizà accidenti pianificati in i siti di produzzione. I stands ùn ponu micca rimpiazzà tuttu.
Source: www.habr.com