Hondamendi batean ere beti dago te kopa bat hartzeko denbora
DRP (hondamendia berreskuratzeko plana) ezin hobeto inoiz beharrezkoa izango ez den gauza bat da. Baina bat-batean estaltze-garaian migratzen diren kastoreek bizkarrezurra zuntz optikotik hazten badute edo administratzaile txiki batek oinarri produktiboa erortzen badu, ziur egon nahi duzu aldez aurretik egindako plan bat izango duzula lotsagarri honekin guztiarekin zer egin.
Izututa dauden bezeroak laguntza teknikoko telefonoak mozten hasten diren bitartean, gaztea zianuroaren bila dabil, zuhurtziaz irekitzen duzu gutun-azal gorria eta dena ordenatzen hasten zara.
Post honetan DRP bat nola idatzi eta zer eduki behar duen buruzko gomendioak partekatu nahi ditut. Gauza hauek ere aztertuko ditugu:
- Ikas dezagun gaizto bat bezala pentsatzen.
- Ikus ditzagun apokalipsiaren garaian te kikara baten onurak.
- Pentsa dezagun DRP egitura eroso bat
- Ikus dezagun nola probatu
Zein enpresentzat izan daiteke erabilgarria?
Oso zaila da marra marraztea IT sailak horrelako gauzak behar izaten hasten direnean. DRP behar duzula esango nuke, baldin eta:
- Zerbitzari bat, aplikazio bat gelditzeak edo datu-baseren bat galtzeak galera handiak ekarriko ditu negozio osoarentzako.
- IT sail osoa duzu. Enpresa osoko unitate baten formako sail baten zentzuan, bere aurrekontuarekin, eta ez soilik langile nekatu batzuk sare bat ezarriz, birusak garbituz eta inprimagailuak betez.
- Larrialdi kasuetan gutxienez erredundantzia partzialerako aurrekontu errealista duzu.
Informatika sailak hilabeteetan gutxienez HDD pare bat eskatzen dituenean zerbitzari zahar batean babeskopiak egiteko, nekez antolatu ahal izango duzu huts egin duen zerbitzuaren erabateko mugimendurik edukiera erreserbatzeko. Hemen dokumentazioa soberan egongo ez den arren.
Dokumentazioa garrantzitsua da
Hasi dokumentaziotik. Demagun zure zerbitzua administratzaileek duela hiru belaunaldi idatzitako Perl script batean exekutatzen dela, baina inork ez daki nola funtzionatzen duen. Pilatutako zor teknikoak eta dokumentazio faltak ezinbestean tiro egingo zaituzte belaunean ez ezik, beste gorputz-adarretan ere, denbora kontua baino gehiago da.
Zerbitzuaren osagaien deskribapen ona duzunean, bilatu istripuen estatistikak. Ia ziur guztiz tipikoak izango dira. Adibidez, zure diskoa noizean behin bete egiten da, eta horrek nodoa huts egiten du eskuz garbitu arte. Edo bezero-zerbitzua ez dago erabilgarri, norbaitek berriro ziurtagiria berritzea ahaztu duelako eta Let's Encrypt-ek ezin izan duelako edo konfiguratu nahi ez duelako.
Saboteatzaile baten moduko pentsamenduak
Zailena inoiz gertatu ez diren baina zure zerbitzua guztiz huts egin dezaketen istripu horiek aurreikustea da. Hemen nire lankideek eta biok gaiztoak jokatzen ditugu normalean. Hartu kafe asko eta zerbait zaporetsua eta itxi zaitez bilera-gela batean. Ziurtatu negoziazio berdinetan beraiek xede-zerbitzua garatu duten edo harekin aldian-aldian lan egiten duten ingeniari horiek blokeatzen dituzula. Orduan, arbelean edo paperean, zure zerbitzuari gerta litezkeen izugarrikeria posible guztiak marrazten hasten zara. Ez da beharrezkoa garbiketa-andre zehatz bati eta kableak ateratzeari buruzko xehetasunetan sakondu; nahikoa da "Tokiko sarearen osotasunaren urraketa" eszenatokia kontuan hartzea.
Normalean, larrialdi-egoera ohikoenak honako mota hauetan daude:
- Sarearen porrota
- OS zerbitzuen hutsegitea
- Aplikazioaren hutsegitea
- Burdinaren porrota
- Birtualizazioaren hutsegitea
Joan mota bakoitza eta ikusi zer aplikatzen zaion zure zerbitzuari. Esate baterako, Nginx deabrua erori eta ez igo daiteke - horrek OSaren hutsegiteak esan nahi du. Zure web aplikazioa huts egiten duen egoera arraroa softwarearen hutsegite bat da. Etapa honetan zehar lan egiten duzun bitartean, garrantzitsua da arazoaren diagnostikoa lantzea. Nola bereizi birtualizazioan izoztutako interfaze bat eroritako cis disko batetik eta sareko istripu batetik, adibidez. Garrantzitsua da arduradunak azkar aurkitzeko eta buztanari tiraka hastea istripua konpondu arte.
Arazo tipikoak idatzi ondoren, kafe gehiago isurtzen dugu eta eszenatoki bitxienak aztertzen hasten gara, parametro batzuk arautik urrunago joaten hasten direnean. Adibidez:
- Zer gertatzen da nodo aktiboko denborak klusterreko besteekiko minutu bat atzera egiten badu?
- Zer gertatzen da denborak aurrera egiten badu, zer gertatzen da 10 urtera?
- Zer gertatzen da kluster-nodo batek bat-batean sarea galtzen badu sinkronizazioan?
- Zer gertatuko da bi nodok lidergoa partekatzen ez badute sarean elkarren artean aldi baterako isolatuta dagoelako?
Fase honetan, alderantzizko ikuspegia oso lagungarria da. Irudimen gaiztoarekin taldeko kiderik egoskorrena hartzen duzu eta zerbitzua jaitsiko duen ahalik eta denbora laburrenean sabotaje bat antolatzeko zeregina ematen diozu. Diagnostikoa zaila bada, are hobeto. Ez duzu sinetsiko ingeniariek zer ideia bitxi eta politak sortzen duten zerbait hausteko ideia bat ematen badiezu. Eta horretarako proba-banku bat agintzen badiezu, guztiz ondo dago.
Zein da zure DRP hau?!
Beraz, zure mehatxu eredua definitu duzu. Gainera, kobrearen bila zuntz optikoko kableak mozten dituzten bertako bizilagunak eta ostiraletan 16:46etan irratsaio linea bat zorrozki erortzen duen radar militar bat ere hartu dituzte kontuan. Orain ulertu behar dugu zer egin honekin guztiarekin.
Zure zeregina larrialdi batean irekiko diren gutun-azal oso gorri horiek idaztea da. Berehala espero da (ez bada!) dena amaitzen denean, esperientziarik gabeko bekadun bakarra egongo dela gertu, zeinen eskuak bortizki dardara emango diotela gertatzen ari denaren izuagatik. Ikusi nola ezartzen diren larrialdi seinaleak mediku bulegoetan. Esaterako, zer egin shock anafilaktiko baten kasuan. Mediku-langileek protokolo guztiak ezagutzen dituzte, baina gertuko pertsona bat hiltzen hasten denean, sarritan denak ezinean ari dira begiz jota dagoen guztiari. Horretarako, horman argibide argiak daude, besteak beste, "ireki holako eta halakoen paketea" eta "hainbeste unitate administratu sendagaiaren barnean".
Zaila da larrialdi batean pentsatzea! Bizkarrezur-muina analizatzeko argibide errazak izan behar dira.
DRP on batek hainbat bloke erraz ditu:
- Nori jakinarazi istripu baten hasieraz. Hau garrantzitsua da ezabatze-prozesua ahalik eta gehien paralelizatzeko.
- Nola diagnostikatu behar bezala - egin arrasto bat, begiratu systemctl status servicename eta abar.
- Zenbat denbora eman dezakezu etapa bakoitzean? SLA denboran eskuz konpontzeko denborarik ez baduzu, makina birtuala hil egiten da eta atzoko babeskopiatik atzera egiten da.
- Nola ziurtatu istripua amaitu dela.
Gogoratu DRP zerbitzuak guztiz huts egin duenean hasten dela eta zerbitzua berrezartzen denean amaitzen dela, nahiz eta eraginkortasun murriztua izan. Erreserba bat galtzeak ez luke DRP eragin behar. DRPan te kopa bat ere idatz dezakezu. Serio. Estatistiken arabera, istripu asko desatsegina izatetik hondamendi izatera pasatzen dira, langileak izuan zerbait konpontzera presaka dabiltzalako, aldi berean datuekin bizi den nodo bakarra hiltzen dutelako edo azkenean klusterra amaitzen dutelako. Oro har, 5 minutu te kopa batekin denbora pixka bat emango dizu lasaitzeko eta gertatzen ari dena aztertzeko.
Ez nahastu DRP eta sistema pasaportea! Ez kargatu behar ez diren datuekin. Egin ahal izateko hiperestekak azkar eta eroso erabiltzea dokumentazioaren nahi den atalera joateko eta zerbitzu-arkitekturaren beharrezko atalei buruzko formatu zabalduan irakurtzeko. Eta DRPn bertan kopiatu-itsatsirako komando espezifikoekin non eta nola konektatu jakiteko argibide zuzenak baino ez daude.
Nola probatu behar bezala
Ziurtatu edozein langile arduratsu elementu guztiak bete ditzakeela. Momenturik erabakigarrienean, gerta liteke ingeniariak behar den sistemara sartzeko eskubiderik ez duela, behar den konturako pasahitzik ez dagoela edo ez duela ideiarik zer "Konektatu zerbitzuaren kudeaketa kontsolara proxy baten bidez. egoitza nagusiaβ esan nahi du. Puntu bakoitzak oso sinplea izan behar du.
oker - "Joan birtualizaziora eta berrabiarazi hildako nodoa"
Behar bezala - "Konektatu web interfazearen bidez virt.example.com-era, nodoen atalean, berrabiarazi errorea eragiten duen nodoa."
Saihestu anbiguotasuna. Gogoratu bekadun beldurtua.
Ziurtatu DRP probatzen duzula. Hau ez da ikuskizunerako plan bat soilik, zuk eta zure bezeroek egoera larritik azkar ateratzeko aukera emango dizun zerbait da. Hobe da hau hainbat aldiz egitea:
- Aditu batek eta hainbat ikaslek benetako zerbitzu bat ahalik eta gehien simulatzen duen proba-banku batean lan egiten dute. Adituak hainbat modutan hausten du zerbitzua eta praktiketako ikasleei DRPren arabera berreskuratzeko aukera ematen die. Arazoak, dokumentazioaren anbiguotasun eta akats guztiak erregistratzen dira. Prestatzaileak trebatu ondoren, DRP zabaltzen eta sinplifikatu egiten da argi ez dauden eremuetan.
- Benetako zerbitzu batean probak egitea. Izan ere, ezin duzu inoiz benetako zerbitzu baten kopia perfektua sortu. Hori dela eta, urtean pare bat aldiz beharrezkoa da ohiko zerbitzari batzuk itzaltzea, konexioak moztu eta mehatxuen zerrendatik beste hondamendi batzuk eragitea berreskuratzeko ordena ebaluatzeko. Gauaren erdian 10 minutuz aurreikusitako hutsegite bat hobe da bat-bateko hutsegitea hainbat ordutan datu galerarekin karga gorenetan.
- Benetako arazoak konpontzea. Bai, hau ere proben parte da. Mehatxuen zerrendan ez zegoen istripu bat gertatzen bada, beharrezkoa da DRPa osatu eta amaitu, bere ikerketaren emaitzen arabera.
Gako puntuak
- Kaka gerta badaiteke, ez da bakarrik gertatuko, baizik eta ahalik eta eszenatoki katastrofikoenean egingo du.
- Ziurtatu larrialdiko karga transferitzeko baliabideak dituzula.
- Ziurtatu babeskopiak dituzula, automatikoki sortzen dira eta aldiro koherentzia dela egiaztatzen da.
- Pentsa ezazu mehatxu-egoera tipikoetan.
- Eman ingeniariei zerbitzua emateko aukera estandarrak ez diren aukerak sortzeko.
- DRP argibide sinple eta zorrotza izan behar da. Diagnostiko konplexu guztiak bezeroen zerbitzua berreskuratu ondoren bakarrik egiten dira. Nahiz eta erreserbako edukiera izan.
- Eman telefono-zenbakiak eta kontaktuak DRP-n.
- Probatu langileek DRPren ulermena aldizka.
- Produkzio guneetan aurreikusitako istripuak antolatzea. Harmailek ezin dute dena ordezkatu.
Iturria: www.habr.com