DRP virbereeden - vergiesst net de Meteorit ze berücksichtegen

DRP virbereeden - vergiesst net de Meteorit ze berücksichtegen
Och bei enger Katastroph gëtt et ëmmer Zäit fir eng Taass Téi

DRP (Katastrophen Erhuelungsplang) ass eng Saach déi am Idealfall ni gebraucht gëtt. Awer wann op eemol Beaver, déi während der Paarungszäit migréieren, duerch d'Backbone optesch Faser gnagen oder e Junior Admin d'produktiv Basis fällt, wëllt Dir definitiv sécher sinn datt Dir e virausgemaache Plang hutt fir wat Dir mat all dëser Schimmt maache musst.

Wärend d'Clienten a Panik ufänken technesch Ënnerstëtzungstelefonen ofzeschneiden, sicht de Junior no Cyanid, Dir maach de roude Enveloppe verstänneg op a fänkt un alles an Uerdnung ze setzen.

An dësem Post wëll ech Empfehlungen deelen wéi een en DRP schreift a wat et soll enthalen. Mir wäerten och déi folgend Saache kucken:

  1. Loosst eis léieren wéi e Béis ze denken.
  2. Loosst eis d'Virdeeler vun enger Taass Téi während der Apokalypse kucken.
  3. Loosst eis iwwer eng praktesch DRP Struktur denken
  4. Loosst eis kucken wéi et ze testen

Fir wéi eng Firmen kéint dëst nëtzlech sinn?

Et ass ganz schwéier d'Linn ze zéien wann d'IT Departement ufänkt sou Saachen ze brauchen. Ech géif soen datt Dir definitiv DRP braucht wann:

  • E Server, Applikatioun ze stoppen oder eng Datebank ze verléieren féiert zu bedeitende Verloschter fir d'Geschäft als Ganzt.
  • Dir hutt eng vollwäerteg IT Departement. Am Sënn vun engem Departement a Form vun enger vollwäerteger Eenheet vun der Firma, mat engem eegene Budget, an net nëmmen e puer midd Mataarbechter, déi e Netz leeën, Viren botzen an Drécker opfëllen.
  • Dir hutt e realistesche Budget fir op d'mannst deelweis Redundanz am Noutfall.

Wann d'IT Departement fir Méint fir op d'mannst e puer vun HDDs an en ale Server fir Backupsatellit gefrot huet, Dir sidd onwahrscheinlech eng vollwäerteg Beweegung vun engem gescheitert Service ze reservéieren Kapazitéit organiséieren kënnen. Och wann hei d'Dokumentatioun net iwwerflësseg ass.

Dokumentatioun ass wichteg

Start mat Dokumentatioun. Loosst eis soen datt Äre Service op engem Perl Skript leeft deen virun dräi Generatiounen vun Administrateuren geschriwwe gouf, awer kee weess wéi et funktionnéiert. Déi accumuléiert technesch Schold an de Mangel u Dokumentatioun wäerten Iech zwangsleefeg net nëmmen am Knéi schéissen, awer och an anere Gliedmaart, et ass méi eng Fro vun der Zäit.

Wann Dir eng gutt Beschreiwung vun de Servicekomponenten hutt, kuckt Accidentstatistiken op. Si wäerte bal sécher ganz typesch sinn. Zum Beispill gëtt Är Disk vun Zäit zu Zäit voll, wat verursaacht datt den Node fällt bis se manuell gebotzt gëtt. Oder de Client Service gëtt net erreechbar wéinst der Tatsaach datt een erëm vergiess huet den Zertifika ze erneieren, a Let's Encrypt konnt net konfiguréieren oder net wëlle konfiguréieren.

Gedanken wéi e Saboteur

Dee schwieregsten Deel ass fir déi Accidenter virauszesoen déi nach ni geschitt sinn, awer déi potenziell Äre Service komplett ofbriechen. Hei spillen ech an meng Kollegen normalerweis Béiser. Huelt Iech vill Kaffi an eppes leckeres a gespaart Iech an engem Versammlungsraum. Gitt einfach sécher datt Dir an deene selwechte Verhandlungen déi Ingenieuren gespaart hutt, déi selwer den Zilservice entwéckelt hunn oder regelméisseg mat him schaffen. Dann, entweder um Bord oder op Pabeier, fänkt Dir all méiglech Schrecken ze zéien, déi mat Ärem Service geschéie kënnen. Et ass net néideg am Detail op eng spezifesch Botzfra ze goen an d'Kabelen erauszezéien; et ass genuch fir de Szenario vun "Verletzung vun der Integritéit vum lokalen Netzwierk ze berücksichtegen."

Typesch falen déi meescht typesch Noutsituatiounen an déi folgend Aarte:

  • Netzfehler
  • OS Servicer Feeler
  • Applikatioun Echec
  • Eisen Echec
  • Virtualiséierungsfehler

Gitt einfach duerch all Typ a kuckt wat fir Äre Service gëllt. Zum Beispill kann den Nginx-Daemon falen an net eropgoen - dat heescht Feeler vum OS. Eng selten Situatioun, déi Är Webapplikatioun ausfällt, ass e Softwarefehler. Wärend dëser Etapp schafft, ass et wichteg d'Diagnos vum Problem erauszefannen. Wéi z'ënnerscheeden eng gefruer Interface op Virtualiséierung vun engem gefall cis fueren an engem Netz Accident, zum Beispill. Dëst ass wichteg fir déi Verantwortlech séier ze fannen an de Schwanz ze zéien bis den Accident geléist ass.

Nodeems typesch Probleemer opgeschriwwe sinn, gi mir méi Kaffi a fänken un déi komeschste Szenarie ze berücksichtegen, wann e puer Parameteren ufänken wäit iwwer d'Norm ze goen. Zum Beispill:

  • Wat geschitt wann d'Zäit um aktive Node eng Minutt relativ zu aneren am Stärekoup zréckbeweegt?
  • Wat wann d'Zäit no vir geet, wat wann ëm 10 Joer?
  • Wat geschitt wann e Cluster Node op eemol säi Netzwierk während der Synchroniséierung verléiert?
  • Wat geschitt wann zwee Wirbelen net Leedung deelen wéinst temporärer Isolatioun vuneneen am Netz?

Op dëser Etapp ass déi ëmgedréint Approche ganz hëllefräich. Dir hëlt den haartnäckege Member vun der Équipe mat krank Fantasie a gitt him d'Aufgab, a kuerzer Zäit e Sabotage ze organiséieren, deen de Service erofgeet. Wann et schwéier ass ze diagnostizéieren, nach besser. Dir wäert net gleewen wat komesch a cool Iddien Ingenieuren kommen, wann Dir hinnen eng Iddi gitt eppes ze briechen. A wann Dir hinnen eng Testbank dofir versprécht, ass dat absolut gutt.

Wat ass dësen DRP vun Iech?!

Also hutt Dir Äre Bedrohungsmodell definéiert. Si hunn och d'lokal Awunner berücksichtegt, déi Glasfaserkabelen op der Sich no Kupfer ofgeschnidden hunn, an e Militärradar, deen eng Radiorelaislinn strikt Freideg um 16:46 fällt. Elo musse mir verstoen wat mat all deem ze maachen.

Är Aufgab ass déi ganz rout Enveloppen ze schreiwen déi an engem Noutfall opgemaach ginn. Erwaart direkt, datt wann (net wann!) alles op en Enn kënnt, nëmmen den onerfuerenste Stagiaire an der Géigend wäert sinn, deem seng Hänn gewalteg rëselen aus dem Schrecken vun deem wat geschitt. Kuckt wéi Noutschëlder a medizinesche Büroen ëmgesat ginn. Zum Beispill, wat ze maachen am Fall vun anaphylaktesche Schock. D'medezinesch Personal kennt all d'Protokoller aus Häerz, awer wann eng Persoun an der Géigend ufänkt ze stierwen, hält ganz dacks jiddereen hëlleflos un alles an der Siicht. Fir dëst ze maachen, ginn et kloer Instruktiounen op der Mauer mat Elementer wéi "de Package vun esou an esou opmaachen" an "sou vill Eenheeten vum Medikament intravenös verwalten."

Et ass schwéier an engem Noutfall ze denken! Et sollt einfach Instruktioune fir d'Spinalkordparsing sinn.

E gudden DRP besteet aus e puer einfache Blocks:

  1. Wien iwwer den Ufank vun engem Accident matdeelen. Dëst ass wichteg fir den Eliminatiounsprozess sou vill wéi méiglech ze parallelliséieren.
  2. Wéi richteg ze diagnostizéieren - maacht eng Spuer, kuckt am Systemctl Status Servicename an sou weider.
  3. Wéi vill Zäit kënnt Dir op all Etapp verbréngen? Wann Dir keng Zäit hutt fir et manuell bannent der SLA Zäit ze fixéieren, gëtt d'virtuell Maschinn ëmbruecht an aus dem Backup vu gëschter zréckgezunn.
  4. Wéi sécherzestellen, datt den Accident eriwwer ass.

Denkt drun datt DRP ufänkt wann de Service komplett gescheitert ass an endet wann de Service restauréiert ass, och mat reduzéierter Effizienz. Einfach eng Reservatioun verléieren soll net DRP ausléisen. Dir kënnt och eng Taass Téi an den DRP schreiwen. Eescht. Laut Statistiken, ginn vill Accidenter vun désagréabel ze katastrophal wéinst der Tatsaach, datt d'Personal an enger Panik Rush eppes ze fixéieren, gläichzäiteg déi eenzeg lieweg Node mat Daten ëmbréngen oder endlech de Cluster ofgeschloss. An der Regel, 5 Minutte mat enger Taass Téi ginn Iech Zäit fir ze berouegen an ze analyséieren wat geschitt.

Duercherneen net DRP a System Pass! Iwwerlaascht et net mat onnéidege Donnéeën. Just maachen et méiglech séier a bequem Hyperlinks ze benotzen fir op déi gewënscht Sektioun vun der Dokumentatioun ze goen an an engem erweiderten Format iwwer déi néideg Sektioune vun der Servicearchitektur ze liesen. An am DRP selwer ginn et nëmmen direkt Instruktiounen iwwer wou a wéi Dir mat spezifesche Befehle fir Copy-Paste verbënnt.

Wéi richteg ze testen

Vergewëssert Iech datt all verantwortlech Mataarbechter fäeg ass all Elementer ofzeschléissen. Am entscheedendsten Moment kann et erausstellen datt den Ingenieur keng Rechter huet fir den erfuerderleche System ze kréien, et gi keng Passwierder fir den erfuerderleche Kont, oder hien huet keng Ahnung wat "Connect to the service management console through a proxy at the Sëtz“ heescht. All Punkt soll extrem einfach sinn.

Falsch - "Gitt an d'Virtualiséierung a restart den Doudegen Node"
Keng Äntwert - "Verbindt iwwer d'Webinterface op virt.example.com, an der Nodes Sektioun, restart den Node deen de Feeler verursaacht."

Vermeiden Ambiguititéit. Erënneren der Angscht Intern.

Gitt sécher DRP ze testen. Dëst ass net nëmmen e Plang fir ze weisen - et ass eppes wat Iech an Är Clienten erlaabt séier aus enger kritescher Situatioun erauszekommen. Et ass am beschten dëst e puer Mol ze maachen:

  • Een Expert a verschidde Stagiairen schaffen op enger Testbänk déi e richtege Service sou vill wéi méiglech simuléiert. Den Expert brécht de Service op verschidde Manéieren an erméiglecht de Stagiairen en no DRP ze restauréieren. All Problemer, Dokumentatioun Ambguitéiten a Feeler ginn opgeholl. Nodeems d'Stagiairen trainéiert sinn, gëtt den DRP an onkloere Beräicher erweidert a vereinfacht.
  • Testen op engem richtege Service. Tatsächlech kënnt Dir ni eng perfekt Kopie vun engem richtege Service erstellen. Dofir ass et e puer Mol am Joer néideg fir e puer vun de Serveren regelméisseg auszeschalten, Verbindungen ze trennen an aner Katastrophen aus der Lëscht vun de Geforen ze verursaachen fir d'Erhuelungsuerdnung ze bewäerten. E geplangten Ausfall fir 10 Minutten an der Mëtt vun der Nuecht ass besser wéi e plötzlechen Ausfall fir e puer Stonnen wärend der Spëtzbelaaschtung mat Dateverloscht.
  • Real troubleshooting. Jo, dëst ass och Deel vum Test. Wann en Accident geschitt deen net op der Lëscht vun de Bedrohungen war, ass et néideg den DRP ze ergänzen an ze finaliséieren op Basis vun de Resultater vu senger Enquête.

Schlëssel Punkten

  1. Wann Schäiss ka geschéien, wäert et net nëmmen geschéien, mee et wäert dat am meeschte katastrophal Szenario maachen.
  2. Vergewëssert Iech datt Dir Ressourcen fir Noutlaaschttransfer hutt.
  3. Vergewëssert Iech datt Dir Backups hutt, se ginn automatesch erstallt a regelméisseg iwwerpréift fir Konsistenz.
  4. Denkt duerch typesch Bedrohungsszenarien.
  5. Gitt Ingenieuren d'Méiglechkeet mat net-Standardoptiounen ze kommen fir de Service ze liwweren.
  6. DRP soll eng einfach a stompeg Instruktioun sinn. All komplex Diagnostik gëtt nëmmen duerchgefouert nodeems de Service vum Client restauréiert gouf. Och wann op Reservekapazitéit.
  7. Gitt Schlëssel Telefonsnummeren a Kontakter am DRP.
  8. Test d'Verständnis vun de Mataarbechter vun der DRP regelméisseg.
  9. Arrangéiert geplangten Accidenter op Produktiounsplazen. Stänn kënnen net alles ersetzen.

DRP virbereeden - vergiesst net de Meteorit ze berücksichtegen

DRP virbereeden - vergiesst net de Meteorit ze berücksichtegen

Source: will.com

Setzt e Commentaire