Ek by in ramp is der altyd tiid foar in bakje tee
DRP (plan foar rampherstel) is in ding dat ideaal nea nedich sil wêze. Mar as bevers dy't yn it pearseizoen migrearje ynienen troch de optyske glêstried knaagje of in junior admin de produktive basis sakket, wolle jo perfoarst der wis fan wêze dat jo in foarôf makke plan hawwe foar wat te dwaan mei al dizze skande.
Wylst klanten yn panyk begjinne te snijen technyske stipe telefoans, de junior siket cyanide, jo ferstannich iepenje de reade envelop en begjinne te setten alles yn oarder.
Yn dizze post wol ik oanbefellings diele oer hoe't jo in DRP skriuwe en wat it moat befetsje. Wy sille ek de folgjende dingen besjen:
- Lit ús leare te tinken as in skurk.
- Litte wy sjen nei de foardielen fan in kopke tee tidens de apokalyps.
- Litte wy tinke oer in handige DRP-struktuer
- Litte wy sjen hoe't jo it testen
Foar hokker bedriuwen kin dit nuttich wêze?
It is heul lestich om de line te tekenjen as de IT-ôfdieling sokke dingen begjint te ferlet te hawwen. Ik soe sizze dat jo DRP perfoarst nedich binne as:
- It stopjen fan in server, applikaasje of it ferliezen fan wat database sil liede ta signifikante ferliezen foar it bedriuw as gehiel.
- Jo hawwe in folsleine IT-ôfdieling. Yn 'e betsjutting fan in ôfdieling yn' e foarm fan in folweardige ienheid fan it bedriuw, mei in eigen budzjet, en net allinich in pear wurge meiwurkers dy't in netwurk lizze, firussen skjinmeitsje en printers opnij folje.
- Jo hawwe in realistysk budzjet foar op syn minst in part ûntslach yn gefal fan in need.
As de IT-ôfdieling al moannen smeekt om op syn minst in pear HDD's yn in âlde server foar backups, binne jo net wierskynlik in folsleine beweging fan in mislearre tsjinst te organisearjen om kapasiteit te reservearjen. Hoewol hjir de dokumintaasje sil net oerstallich wêze.
Dokumintaasje is wichtich
Begjin mei dokumintaasje. Litte wy sizze dat jo tsjinst rint op in Perl-skript dat trije generaasjes lyn skreaun is troch admins, mar gjinien wit hoe't it wurket. Akkumulearre technyske skuld en gebrek oan dokumintaasje sil ûnûntkomber sjitte jo net allinnich yn 'e knibbel, mar ek yn oare ledematen, it is mear in kwestje fan tiid.
As jo ienris in goede beskriuwing hawwe fan 'e tsjinstkomponinten, sykje jo ûngelokstatistiken op. Se sille hast wis wêze folslein typysk. Jo skiif wurdt bygelyks sa no en dan fol, wêrtroch't it knooppunt mislearret oant it mei de hân wurdt skjinmakke. Of de klanttsjinst wurdt net beskikber fanwege it feit dat immen wer fergeat it sertifikaat te fernijen, en Let's Encrypt koe of net konfigurearje.
Gedachten as in saboteur
It dreechste diel is yn it foarsizzen fan dy ûngemakken dy't noch noait earder bard binne, mar dy't jo tsjinst potensjeel kinne crashe. Hjir spylje myn kollega's en ik meastentiids smjunten. Nim in protte kofje en wat lekkers en slute jo op yn in gearkomsteromte. Soargje derfoar dat jo yn deselde gearkomste dy yngenieurs opslute dy't sels de doeltsjinst ûntwikkele hawwe of der geregeld mei wurkje. Dan, op it boerd of op papier, begjinne jo alle mooglike horrors te tekenjen dy't mei jo tsjinst barre kinne. It is net nedich om yn detail nei in spesifike skjinmakster te gean en kabels út te lûken; it is genôch om it senario te beskôgjen fan "Siening fan 'e yntegriteit fan it lokale netwurk."
Typysk falle de meast typyske needsituaasjes yn 'e folgjende soarten:
- Netwurk mislearring
- OS tsjinsten flater
- Applikaasje mislearring
- Izerfalen
- Virtualisaasje mislearring
Gean gewoan troch elk type en sjoch wat jildt foar jo tsjinst. Bygelyks, de Nginx-daemon kin falle en net opstean - dit betsjut mislearrings fan 'e kant fan it OS. In seldsume situaasje wêrtroch jo webapplikaasje mislearret, is in softwarefout. Wylst jo troch dizze faze wurkje, is it wichtich om de diagnoaze fan it probleem út te wurkjen. Hoe te ûnderskieden in beferzen ynterface op virtualization fan in fallen cis drive en in netwurk flater, bygelyks. Dit is wichtich om fluch de ferantwurdliken te finen en har sturt te begjinnen oant it ûngelok is oplost.
Nei't typyske problemen opskreaun binne, jouwe wy mear kofje en begjinne de frjemdste senario's te beskôgjen, as guon parameters fier bûten de noarm begjinne te gean. Bygelyks:
- Wat bart der as de tiid op it aktive knooppunt in minút werom beweecht relatyf oan oaren yn it kluster?
- Wat as de tiid foarút giet, wat as mei 10 jier?
- Wat bart der as in klusterknooppunt syn netwurk ynienen ferliest by syngronisaasje?
- Wat sil barre as twa knooppunten gjin liederskip diele fanwegen tydlike isolaasje fan elkoar op it netwurk?
Op dit stadium is de omkearde oanpak tige nuttich. Jo nimme it meast koppige lid fan 'e ploech mei in sike ferbylding en jou him de taak om yn' e koartst mooglike tiid in sabotaazje te organisearjen dy't de tsjinst delkomt. As it dreech is om te diagnostearjen, noch better. Jo sille net leauwe hokker frjemde en koele ideeën yngenieurs komme mei as jo har in idee jouwe om wat te brekken. En as jo har hjirfoar in testbank taseine, is dat hielendal goed.
Wat is dizze DRP fan dy?!
Dat jo hawwe jo bedrigingsmodel definieare. Se hawwe ek rekken hâlden mei pleatslike bewenners dy't snijden glêstried kabels op syk nei koper, en in militêre radar dy't sakket in radio estafette line strikt op freed om 16:46. No moatte wy begripe wat te dwaan mei dit alles.
Jo taak is om dy heul reade enveloppen te skriuwen dy't sille wurde iepene yn in need. Ferwachtsje fuortdaliks dat as (net as!) alles oan in ein komt, allinich de meast sûnder ûnderfining stazjêre yn 'e buert sil wêze, waans hannen fûleindich skodzje fan' e skrik fan wat der bart. Sjoch hoe't needtekens wurde ymplementearre yn medyske kantoaren. Bygelyks, wat te dwaan yn gefal fan anafylaktyske skok. It medysk personiel kin alle protokollen út it hert, mar as in persoan yn 'e buert begjint te stjerren, grypt hiel faak elkenien helpleas oan alles wat yn sicht is. Om dit te dwaan, binne d'r dúdlike ynstruksjes op 'e muorre mei items lykas "iepenje it pakket fan sa en sa" en "administraasje safolle ienheden fan it medisyn intraveneus."
It is lestich om te tinken yn in need! D'r moatte ienfâldige ynstruksjes wêze foar it parsearjen fan it spinalkord.
In goede DRP bestiet út ferskate ienfâldige blokken:
- Wa te melden oer it begjin fan in ûngelok. Dit is wichtich om it eliminaasjeproses safolle mooglik te parallelisearjen.
- Hoe kinne jo korrekt diagnoaze - fiere in spoar, sjoch yn systemctl status servicename ensafuorthinne.
- Hoefolle tiid kinne jo besteegje oan elke poadium? As jo gjin tiid hawwe om it mei de hân te reparearjen binnen de SLA-tiid, wurdt de firtuele masine fermoarde en weromrôle fan 'e backup fan juster.
- Hoe kinne jo derfoar soargje dat it ûngelok foarby is.
Unthâld dat DRP begjint as de tsjinst is folslein mislearre en einiget as de tsjinst wurdt restaurearre, sels mei redusearre effisjinsje. Simply ferlieze in reservaat moat net trigger DRP. Jo kinne ek in kopke tee yn 'e DRP skriuwe. Serieus. Neffens statistiken draaie in protte ûngemakken fan ûnnoflik nei katastrophale troch it feit dat meiwurkers yn panyk haasten om wat te reparearjen, tagelyk de ienige libbene knooppunt mei gegevens te fermoardzjen of it kluster úteinlik ôfmeitsje. As regel sille 5 minuten mei in kopke tee jo wat tiid jaan om te kalmearjen en te analysearjen wat der bart.
Ferwarje DRP en systeempaspoart net! Overload it net mei ûnnedige gegevens. Meitsje it gewoan mooglik om fluch en maklik hyperkeppelings te brûken om nei de winske seksje fan 'e dokumintaasje te gean en yn in útwreide opmaak te lêzen oer de nedige seksjes fan' e tsjinstarsjitektuer. En yn 'e DRP sels binne d'r allinich direkte ynstruksjes oer wêr't en hoe't jo kinne ferbine mei spesifike kommando's foar kopiearje-plakke.
Hoe te testen korrekt
Soargje derfoar dat elke ferantwurdlike meiwurker alle items kin foltôgje. Op it meast krúsjale momint kin it blike dat de yngenieur gjin rjochten hat om tagong te krijen ta it fereaske systeem, d'r binne gjin wachtwurden foar it fereaske akkount, of hy hat gjin idee wat "Ferbine mei de tsjinstbehearkonsole fia in proxy by de haadkantoar” betsjut. Elk punt moat ekstreem ienfâldich wêze.
Wrong - "Gean nei virtualisaasje en herstart de deade knooppunt"
Korrekt - "Ferbine fia de webynterface nei virt.example.com, yn 'e knooppunten seksje, herstart de knooppunt dy't de flater feroarsaket."
Foarkom dûbelsinnigens. Unthâld de bang stazjêre.
Wês wis dat jo DRP testje. Dit is net allinich in plan foar show - it is iets wêrmei jo en jo kliïnten fluch út in krityske situaasje kinne komme. It is it bêste om dit ferskate kearen te dwaan:
- Ien saakkundige en ferskate trainees wurkje oan in testbank dy't in echte tsjinst safolle mooglik simulearret. De saakkundige brekt de tsjinst op ferskate manieren en stelt de stagiairs yn steat om it neffens de DRP werom te bringen. Alle problemen, dûbelsinnigens yn dokumintaasje en flaters wurde opnommen. Nei't trainees binne oplaat, wurdt de DRP útwreide en ferienfâldige yn ûndúdlike gebieten.
- Testen op in echte tsjinst. Yn feite kinne jo noait in perfekte kopy meitsje fan in echte tsjinst. Dêrom is it in pear kear yn 't jier nedich om guon fan' e tsjinners regelmjittich út te skeakeljen, ferbiningen te brekken en oare rampen te feroarsaakjen fan 'e list mei bedrigingen om de herstelproseduere te beoardieljen. In plande mislearring foar 10 minuten yn 'e midden fan' e nacht is better as in hommelse mislearring foar ferskate oeren tidens pykladen mei gegevensferlies.
- Echte troubleshooting. Ja, dit is ek diel fan testen. As in ûngelok bart dat net op 'e list fan bedrigingen wie, is it needsaaklik om de DRP oan te foljen en te finalisearjen op basis fan' e resultaten fan har ûndersyk.
Key punten
- As stront kin barre, sil it net allinich barre, mar it sil dat dwaan yn it meast katastrofale senario mooglik.
- Soargje derfoar dat jo middels hawwe foar oerdracht fan needlast.
- Soargje derfoar dat jo backups hawwe, se wurde automatysk oanmakke en regelmjittich kontrolearre op konsistinsje.
- Tink troch typyske bedrigingssenario's.
- Jou yngenieurs de kâns om te kommen mei net-standert opsjes foar it leverjen fan de tsjinst.
- DRP moat in ienfâldige en stompe ynstruksje wêze. Alle komplekse diagnoaze wurde allinich útfierd nei't de tsjinst fan 'e kliïnten is restaurearre. Sels as by reservekapasiteit.
- Jou wichtige telefoannûmers en kontakten yn 'e DRP.
- Test it begryp fan meiwurkers fan 'e DRP regelmjittich.
- Arrangearje plande ûngemakken op produksjeplakken. Stands kinne net ferfange alles.
Boarne: www.habr.com