Eĉ dum katastrofo, ĉiam estas tempo por taso da teo.
DRP (katastrofa reakiro) estas afero, kiu ideale neniam estos bezonata. Sed se subite la kastoroj migrantaj dum la pariĝa sezono ronĝas tra la ĉefa optika fibro aŭ la juna administranto faligas la produktivan bazon, vi certe volas esti certa, ke vi havos antaŭfaritan planon pri tio, kion fari kun ĉi tiu tuta malhonoro.
Dum panikitaj klientoj komencas voki teknikan subtenon, junulo serĉas cianidon, vi saĝe malfermas la ruĝan koverton kaj komencas ordigi ĉion.
En ĉi tiu afiŝo, mi volas dividi rekomendojn pri kiel verki DRP kaj kion ĝi devus enhavi. Ni ankaŭ rigardos la jenajn:
- Lernu pensi kiel fiulo.
- Ni analizu la avantaĝojn de taso da teo dum la apokalipso.
- Pensu pri oportuna DRP-strukturo
- Ni vidu kiel testi ĝin
Kiuj kompanioj povus profiti el tio?
Estas tre malfacile desegni linion kiam la IT-fako komencas bezoni ĉi tiujn aferojn. Mi dirus, ke vi certe bezonos DRP se:
- Ĉesigi servilon, aplikaĵon aŭ perdi iun datumbazon kondukos al gravaj perdoj por la komerco entute.
- Vi havas plenrajtan IT-fakon. Mi volas diri, fako kiel plenrajta unuo de la kompanio, kun propra buĝeto, kaj ne nur kelkaj lacaj dungitoj, kiuj metas reton, purigas virusojn kaj replenigas presilojn.
- Vi havas realisman buĝeton por almenaŭ parta redundo en okazo de krizo.
Kiam la IT-sekcio petegas almenaŭ kelkajn HDD-ojn por malnova servilo por sekurkopioj dum monatoj, vi verŝajne ne povos organizi plenan translokadon de la falinta servo por ŝpari kapablojn. Kvankam ankaŭ ĉi tie la dokumentado ne estos superflua.
Dokumentado estas grava
Komencu kun dokumentado. Ni diru, ke via servo funkcias per Perl-skripto, kiu estis skribita antaŭ tri generacioj da administrantoj, kaj neniu scias kiel ĝi funkcias. La akumulita teknika ŝuldo kaj la manko de dokumentado neeviteble pafos vin ne nur en la genuon, sed ankaŭ en aliajn membrojn, ĝi estas prefere demando de tempo.
Post kiam vi havas bonan priskribon de la servaj komponantoj, altigu la kraŝstatistikojn. Preskaŭ certe ili estos tute tipaj. Ekzemple, vi havas diskon plena de tempo al tempo, kio kaŭzas la nodon malsukcesi ĝis ĝi estas permane purigita. Aŭ la klientservo fariĝas neatingebla pro la fakto, ke iu denove forgesis renovigi la atestilon, kaj Let's Encrypt ne povis esti agordita aŭ ne volis.
Pensoj kiel sabotisto
La plej malfacila parto estas antaŭdiri tiujn akcidentojn, kiuj neniam antaŭe okazis, sed kiuj eble povus ruinigi vian servon tute. Ĉi tie ni kutime ludas fiulojn kun kolegoj. Prenu multe da kafo kaj ion bongustan kaj enŝlosu vin en la kunvenĉambro. Nur certigu, ke en la sama kunveno vi ŝlosis tiujn inĝenierojn, kiuj mem altigis la celservon aŭ laboras kun ĝi regule. Tiam, ĉu sur la tabulo ĉu sur papero, vi komencas desegni ĉiujn eblajn teruraĵojn, kiuj povas okazi al via servo. Ne necesas detaligi al specifa purigistino kaj eltiri kablojn, sufiĉas konsideri la scenaron "Malobservo de la integreco de la loka reto".
Kutime, la plej multaj tipaj krizoj taŭgas en la jenajn tipojn:
- Reto fiasko
- Fiasko de la OS-servo
- Fiasko de aplikaĵo
- malfunkcio de fero
- Virtualigo Fiasko
Nur trairu ĉiun vidon kaj vidu kio validas por via servo. Ekzemple, la demono Nginx povas fali kaj ne leviĝi - ĉi tio estas fiasko de la OS. Malofta situacio, kiu kondukas vian TTT-aplikaĵon en nefunkciantan staton, estas programaro fiasko. Dum la disvolviĝo de ĉi tiu etapo, gravas ellabori la diagnozon de la problemo. Kiel distingi pendigitan interfacon pri virtualigo de falinta cisco kaj retkraŝo, ekzemple. Ĉi tio gravas rapide trovi la respondecajn kaj komenci tiri sian voston ĝis la akcidento estas riparita.
Post kiam la tipaj problemoj estas notitaj, ni verŝas pli da kafo kaj komencas pripensi la plej strangajn scenarojn, kiam iuj parametroj komencas iri preter la normo. Ekzemple:
- Kio okazas se la tempo sur la aktiva nodo moviĝas malantaŭen unu minuton relative al aliaj en la areto?
- Kaj se la tempo antaŭeniras, kaj se de 10 jaroj?
- Kio okazas se grapolnodo subite perdas reton dum sinkronigado?
- Kaj kio okazas se du nodoj ne dividas gvidadon pro provizora izolado unu de la alia super la reto?
En ĉi tiu etapo, la inversa aliro multe helpas. Prenu la plej obstinan membron de la teamo kun malsana imago kaj donu al li la taskon aranĝi amuzon en la plej mallonga ebla tempo, kiu malfunkciigos la servon. Se estas malfacile diagnozi, eĉ pli bone. Vi ne kredos la strangajn kaj bonegajn ideojn, kiujn inĝenieroj elpensas, kiam oni donas la ideon rompi ion. Kaj se vi promesas al ili provon por ĉi tio, ĝi estas tre bona.
Kio estas ĉi tiu via DRP?!
Do vi difinis la minacan modelon. Ili ankaŭ enkalkulis lokajn loĝantojn, kiuj tranĉas optikajn kablojn serĉante kupron, kaj armean radaron, kiu faligas radiorelajsolinion strikte vendrede je 16:46. Nun ni devas eltrovi, kion fari kun ĉio.
Via tasko estas skribi la samajn ruĝajn kovertojn, kiuj estos malfermitaj en kriz-okazo. Tuj atendu, ke kiam (ne se!) Ĉio estos fuŝita, nur la plej nesperta staĝanto estos proksime, kies manoj forte skuos pro la teruro de tio, kio okazas. Vidu kiel krizaj signoj estas efektivigitaj en medicinaj oficejoj. Ekzemple, kion fari kun anafilaksa ŝoko. La medicina personaro parkere scias ĉiujn protokolojn, sed kiam homo proksima komencas morti, tre ofte ĉiuj kaptas senhelpe ĉion. Por fari tion, klara instrukcio pendas sur la muro kun aĵoj kiel "malfermi la pakaĵon de tia kaj tia" kaj "injekti tiom da unuoj de la drogo intravejne".
Estas malfacile pensi en kriz-okazo! Devus ekzisti simplaj instrukcioj por mjel-analizado.
Bona DRP konsistas el kelkaj simplaj blokoj:
- Kiun sciigi pri la komenco de la akcidento. Ĉi tio gravas por paraleligi la eliminprocezon kiel eble plej multe.
- Kiel ĝuste diagnozi - ni spuras, rigardas en systemctl statuso servonomo ktp.
- Kiom da tempo povas esti pasigita sur ĉiu stadio. Se vi ne havas tempon ripari ĝin per viaj manoj dum la SLA-tempo, la virtuala maŝino estas senvivigita kaj rulita de la sekurkopio de hieraŭ.
- Kiel certigi, ke la kraŝo finiĝis.
Memoru, ke DRP komenciĝas kiam la servo tute malsukcesis kaj finiĝas per reakiro, eĉ kun reduktita efikeco. Simple perdi rezervadon ne devus aktivigi DRP. Vi ankaŭ povas preskribi tason da teo en DRP. Serioze. Laŭ statistiko, multaj akcidentoj iras de malagrabla al katastrofa pro la fakto, ke la personaro en paniko rapidas por ripari ion, samtempe mortigante la nuran vivan nodon kun datumoj aŭ finfine finante la areton. Kiel regulo, 5 minutoj por taso da teo donos al vi iom da tempo por trankviliĝi kaj analizi kio okazas.
Ne konfuzu DRP kaj sisteman pasporton! Ne troŝarĝu ĝin per nenecesaj datumoj. Nur donu la ŝancon rapide kaj oportune iri al la bezonata sekcio de la dokumentaro per hiperligoj kaj legi en pligrandigita formato pri la necesaj sekcioj de la serva arkitekturo. Kaj en la DRP mem, ekzistas nur rektaj instrukcioj pri kie kaj kiel konekti kun specifaj komandoj por kopii-alglui.
Kiel testi ĝuste
Certigu, ke iu respondeca dungito kapablas plenumi ĉiujn erojn. En la plej decida momento, povas rezulti, ke la inĝeniero ne havas alirrajtojn al la bezonata sistemo, ne ekzistas pasvortoj por la bezonata konto, aŭ li ne havas ideon, kion "Konekti al la servo-administra konzolo per prokurilo ĉe la". ĉefsidejo” signifas. Ĉiu ero devus esti kiel eble plej simpla.
Malĝusta - "Iru al virtualigo kaj rekomencu la mortintan nodon"
Ĝuste - "Konektu per la retinterfaco al virt.example.com, en la noda sekcio, reŝargu la nodon, kiu kaŭzas la eraron."
Evitu ambiguecon. Memoru la timigitan internulo.
Nepre testi DRP. Ĉi tio ne estas nur plano por spektaklo - ĝi estas io, kio permesos al vi kaj al viaj klientoj rapide eliri el kritika situacio. Plej bone estas fari ĉi tion plurfoje:
- Unu spertulo kaj pluraj staĝantoj laboras sur provbenko, kiu laŭeble imitas veran servon. La fakulo rompas la servon diversmaniere kaj ebligas al la praktikantoj restarigi ĝin laŭ la DRP. Ĉiuj problemoj, ambiguecoj en la dokumentado kaj eraroj estas registritaj. Post trejnado de la praktikantoj, DRP estas kompletigita kaj simpligita en malklaraj lokoj.
- Testado sur vera servo. Fakte, vi neniam povas krei perfektan kopion de vera servo. Sekve, kelkfoje jare necesas malŝalti parton de la serviloj laŭplane, rompi konektojn kaj aranĝi aliajn akcidentojn el la listo de minacoj por taksi la reakivan ordon. Pli bone estas havi 10-minutan planitan malfunkcion en la mezo de la nokto ol subita malsukceso dum pluraj horoj ĉe pinta ŝarĝo kun datumperdo.
- Reala elimino de la akcidento. Jes, ĉi tio ankaŭ estas parto de la testado. Se okazas akcidento, kiu ne estis en la listo de minacoj, necesas kompletigi kaj fini la DRP surbaze de la rezultoj de ĝia esploro.
Esencaj punktoj
- Se abomenaĵo povas okazi, ĝi ne simple okazos, sed ĝi faros ĝin en la plej katastrofa scenaro.
- Certigu, ke vi havas la rimedojn por malfunkciigo.
- Certiĝu, ke vi havas sekurkopiojn, ili estas aŭtomate kreitaj kaj regule kontrolitaj por konsistenco.
- Konsideru tipajn minacajn scenarojn.
- Donu al inĝenieroj la ŝancon elpensi ne-normajn eblojn por meti la servon.
- DRP devus esti simplaj kaj stultaj instrukcioj. Ĉiuj kompleksaj diagnozoj nur post kiam klientoj restarigis servon. Eĉ se ĝi estas en standby.
- Listigu ŝlosilajn telefonnumerojn kaj kontaktojn en DRP.
- Regule provu dungitojn pri DRP-kompreno.
- Aranĝu planitajn akcidentojn sur la produkto. Standoj ne povas anstataŭigi ĉion.
fonto: www.habr.com