Selfs tydens 'n ramp is daar altyd tyd vir 'n koppie tee.
DRP (rampherstelplan) is 'n ding wat ideaal gesproke nooit nodig sal wees nie. Maar as die bevers wat gedurende die paarseisoen migreer skielik deur die hoof optiese vesel knaag of die junior admin die produktiewe basis laat val, wil jy beslis seker wees dat jy 'n voorafgemaakte plan sal hê van wat om met al hierdie skande te doen.
Terwyl paniekbevange kliënte tegniese ondersteuning begin bel, 'n junior op soek is na sianied, maak jy wyslik die rooi koevert oop en begin alles in orde stel.
In hierdie pos wil ek aanbevelings deel oor hoe om 'n DRP te skryf en wat dit moet bevat. Ons sal ook na die volgende kyk:
- Leer om soos 'n skurk te dink.
- Kom ons ontleed die voordele van 'n koppie tee tydens die apokalips.
- Dink aan 'n gerieflike DRP-struktuur
- Kom ons kyk hoe om dit te toets
Watter maatskappye kan hierby baat?
Dit is baie moeilik om 'n streep te trek wanneer die IT-afdeling hierdie dinge begin nodig kry. Ek sou sê dat jy gewaarborg is om DRP te benodig as:
- Om 'n bediener, 'n toepassing of die verlies van 'n databasis te stop, sal lei tot aansienlike verliese vir die besigheid as geheel.
- Jy het 'n volwaardige IT-afdeling. Ek bedoel, 'n departement as 'n volwaardige eenheid van die maatskappy, met sy eie begroting, en nie net 'n paar moeë werknemers wat 'n netwerk lê, virusse skoonmaak en drukkers hervul nie.
- Jy het 'n realistiese begroting vir ten minste gedeeltelike ontslag in die geval van 'n noodgeval.
Wanneer die IT-afdeling al maande lank smeek vir ten minste 'n paar HDD's vir 'n ou bediener vir rugsteun, is dit onwaarskynlik dat jy 'n volwaardige verskuiwing van die gevalle diens sal kan reël om kapasiteit te spaar. Alhoewel die dokumentasie ook nie hier oorbodig sal wees nie.
Dokumentasie is belangrik
Begin met dokumentasie. Kom ons sê jou diens loop op 'n Perl-skrip wat drie generasies van administrateurs gelede geskryf is, en niemand weet hoe dit werk nie. Die opgehoopte tegniese skuld en die gebrek aan dokumentasie sal jou noodwendig nie net in die knie skiet nie, maar ook in ander ledemate, dit is eerder 'n kwessie van tyd.
Sodra jy 'n goeie beskrywing van die dienskomponente byderhand het, verhoog die ongelukstatistieke. Byna seker sal hulle heeltemal tipies wees. Byvoorbeeld, jy het van tyd tot tyd 'n skyf vol, wat veroorsaak dat die nodus misluk totdat dit met die hand skoongemaak word. Of die kliëntediens raak onbeskikbaar as gevolg van die feit dat iemand weer vergeet het om die sertifikaat te hernu, maar hy kon of wou nie Let's Encrypt opstel nie.
Gedagtes soos 'n saboteur
Die moeilikste deel is om daardie ongelukke te voorspel wat nog nooit vantevore gebeur het nie, maar wat moontlik jou diens heeltemal kan verwoes. Hier speel ons gewoonlik skurke saam met kollegas. Neem baie koffie en iets lekkers en sluit jouself in die vergaderkamer toe. Maak net seker dat jy in dieselfde vergadering daardie ingenieurs toegesluit het wat self die teikendiens verhoog het of gereeld daarmee saamwerk. Dan, hetsy op die bord of op papier, begin jy al die moontlike gruwels teken wat met jou diens kan gebeur. Dit is nie nodig om na 'n spesifieke skoonmaakdame te verduidelik en kabels uit te trek nie, dit is genoeg om die scenario "Skending van die integriteit van die plaaslike netwerk" te oorweeg.
Gewoonlik pas die meeste tipiese noodgevalle in die volgende tipes:
- Netwerk mislukking
- OS diens mislukking
- Toepassingsmislukking
- ysterversaking
- Virtualisering mislukking
Gaan net deur elke aansig en kyk wat van toepassing is op jou diens. Byvoorbeeld, die Nginx-demoon kan val en nie styg nie - dit is 'n mislukking aan die kant van die bedryfstelsel. 'n Seldsame situasie wat jou webtoepassing in 'n nie-werkende toestand laat dryf, is 'n sagtewarefout. Tydens die ontwikkeling van hierdie stadium is dit belangrik om die diagnose van die probleem uit te werk. Hoe om 'n gehang koppelvlak op virtualisering te onderskei van 'n gevalle cisco en 'n netwerkongeluk, byvoorbeeld. Dit is belangrik om vinnig diegene wat verantwoordelik is te vind en hul stert te begin trek totdat die ongeluk reggestel is.
Nadat die tipiese probleme neergeskryf is, skink ons meer koffie en begin ons die vreemdste scenario's oorweeg, wanneer sommige parameters verder as die norm begin gaan. Byvoorbeeld:
- Wat gebeur as die tyd op die aktiewe nodus 'n minuut terug beweeg relatief tot ander in die groep?
- En as die tyd vorentoe beweeg, en as met 10 jaar?
- Wat gebeur as 'n groepknoop skielik netwerk verloor tydens sinchronisasie?
- En wat gebeur as twee nodusse nie leierskap deel nie as gevolg van tydelike isolasie van mekaar oor die netwerk?
Op hierdie stadium help die omgekeerde benadering baie. Neem die hardnekkigste lid van die span met 'n siek verbeelding en gee hom die taak om 'n afleiding in die kortste moontlike tyd te reël, wat die diens sal laat sak. As dit moeilik is om te diagnoseer, selfs beter. Jy sal nie die vreemde en cool idees glo waarmee ingenieurs vorendag kom wanneer hulle die idee kry om iets te breek nie. En as jy hulle 'n toetsstand hiervoor belowe, is dit baie goed.
Wat is hierdie DRP van jou?!
So jy het die bedreigingsmodel gedefinieer. Hulle het ook plaaslike inwoners in ag geneem wat optieseveselkabels sny op soek na koper, en 'n militêre radar wat 'n radio-afloslyn streng op Vrydae om 16:46 laat val. Nou moet ons uitvind wat om met dit alles te doen.
Jou taak is om dieselfde rooi koeverte te skryf wat in 'n noodgeval oopgemaak sal word. Verwag dadelik dat wanneer (nie as!) Alles opgemors is, net die mees onervare leerling naby sal wees wie se hande hewig sal bewe van die afgryse van wat gebeur. Kyk hoe noodtekens in mediese kantore geïmplementeer word. Byvoorbeeld, wat om te doen met anafilaktiese skok. Die mediese personeel ken al die protokolle uit die kop, maar wanneer 'n persoon naby begin sterf, gryp almal baie dikwels hulpeloos na alles. Om dit te doen, hang 'n duidelike instruksie teen die muur met items soos "maak die pakkie van so en so oop" en "spuit soveel eenhede van die dwelm binneaars in."
Dit is moeilik om in 'n noodgeval te dink! Daar moet eenvoudige instruksies vir spinale ontleding wees.
'n Goeie DRP bestaan uit 'n paar eenvoudige blokke:
- Wie om in kennis te stel oor die begin van die ongeluk. Dit is belangrik om die eliminasieproses so veel as moontlik te paralleliseer.
- Hoe om korrek te diagnoseer - ons spoor, kyk in systemctl status diensnaam en so aan.
- Hoeveel tyd kan aan elke verhoog bestee word. As jy nie tyd het om dit met jou hande reg te maak tydens die SLA-tyd nie, word die virtuele masjien doodgemaak en gerol vanaf gister se rugsteun.
- Hoe om seker te maak dat die ongeluk verby is.
Onthou dat DRP begin wanneer die diens heeltemal misluk het en voltooi word deur herstel, selfs met verminderde doeltreffendheid. Om bloot 'n bespreking te verloor behoort nie DRP te aktiveer nie. Jy kan ook 'n koppie tee in DRP voorskryf. Ernstig. Volgens statistieke gaan baie ongelukke van onaangenaam tot katastrofies as gevolg van die feit dat die personeel in paniek jaag om iets reg te maak, terselfdertyd die enigste lewendige nodus met data doodmaak of die groep uiteindelik afrond. As 'n reël sal 5 minute vir 'n koppie tee jou 'n bietjie tyd gee om te kalmeer en te ontleed wat gebeur.
Moenie DRP en stelselpaspoort verwar nie! Moenie dit oorlaai met onnodige data nie. Gee net die geleentheid om vinnig en gerieflik na die vereiste afdeling van die dokumentasie te gaan via hiperskakels en in 'n uitgebreide formaat te lees oor die nodige afdelings van die diensargitektuur. En in die DRP self is daar net direkte instruksies oor waar en hoe om met spesifieke opdragte vir copy-paste te koppel.
Hoe om korrek te toets
Maak seker dat enige verantwoordelike werknemer in staat is om alle items te voltooi. Op die mees deurslaggewende oomblik kan dit blyk dat die ingenieur nie toegangsregte tot die vereiste stelsel het nie, daar is geen wagwoorde vir die vereiste rekening nie, of hy het geen idee wat "Koppel aan die diensbestuurkonsole deur 'n instaanbediener by die hoofkantoor” beteken. Elke item moet so eenvoudig as moontlik wees.
verkeerd - "Gaan na virtualisasie en herlaai die dooie node"
korrek - "Koppel via die webkoppelvlak aan virt.example.com, in die nodusafdeling, herlaai die nodus wat die fout veroorsaak."
Vermy dubbelsinnigheid. Onthou die bang intern.
Maak seker dat u DRP toets. Dit is nie net 'n plan vir vertoning nie - dit is iets wat jou en jou kliënte sal toelaat om vinnig uit 'n kritieke situasie te kom. Dit is die beste om dit verskeie kere te doen:
- Een deskundige en verskeie interns werk op 'n toetsbank wat 'n ware diens soveel as moontlik naboots. Die deskundige breek die diens op verskeie maniere en stel die leerlinge in staat om dit volgens die DRP te herstel. Alle probleme, onduidelikhede in die dokumentasie en foute word aangeteken. Nadat die leerlinge opgelei is, word DRP op obskure plekke aangevul en vereenvoudig.
- Toets op 'n regte diens. Trouens, jy kan nooit 'n perfekte kopie van 'n regte diens skep nie. Daarom is dit 'n paar keer per jaar nodig om 'n deel van die bedieners op 'n beplande basis af te skakel, verbindings te verbreek en ander ongelukke uit die lys van bedreigings te reël om die herstelbevel te evalueer. Dit is beter om 'n 10-minute beplande onderbreking in die middel van die nag te hê as 'n skielike mislukking vir 'n paar uur tydens pieklading met dataverlies.
- Werklike uitskakeling van die ongeluk. Ja, dit is ook deel van die toetsing. Indien 'n ongeluk plaasvind wat nie in die lys van dreigemente was nie, is dit nodig om die DRP aan te vul en te finaliseer op grond van die resultate van sy ondersoek.
Belangrike punte
- As snert kan gebeur, sal dit nie net gebeur nie, maar dit sal dit in die mees katastrofiese scenario doen.
- Maak seker jy het die hulpbronne vir failover.
- Maak seker dat jy rugsteun het, dit word outomaties geskep en gereeld nagegaan vir konsekwentheid.
- Oorweeg tipiese bedreigingscenario's.
- Gee ingenieurs die geleentheid om met nie-standaard opsies vorendag te kom om die diens te lewer.
- DRP moet eenvoudige en dom instruksies wees. Alle komplekse diagnostiek slegs nadat kliënte diens herstel het. Al is dit op bystand.
- Lys sleutelfoonnommers en kontakte in DRP.
- Toets werknemers gereeld vir DRP-begrip.
- Reël beplande ongelukke op die produk. Staanplekke kan nie alles vervang nie.
Bron: will.com