Selv under en katastrofe er der altid tid til en kop te
DRP (disaster recovery plan) er noget, der ideelt set aldrig bør være nødvendigt. Men hvis de migrerende bevere i parringsperioden pludselig bider over hovedfiberkablet, eller en junior-administrator dropper den produktive database, vil du helt sikkert gerne være sikker på, at du har en forudgående plan for, hvad der skal gøres med al denne rod.
Mens kunderne i panik begynder at flå telefonerne til tech support, leder junioren efter cyanid, mens du med et klogt udtryk åbner den røde kuvert og begynder at bringe orden i det hele.
I dette indlæg vil jeg dele anbefalinger til, hvordan man skriver en DRP, og hvad den skal indeholde. Desuden vil vi se på følgende emner:
- Lad os lære at tænke som en skurk.
- Vi vil se på fordelene ved en kop te under apokalypsen.
- Vi vil overveje en praktisk struktur for DRP'en.
- Vi vil se på, hvordan den skal testes.
Hvilke virksomheder kan have gavn af dette.
Det kan være svært at trække grænsen, når IT-afdelingen begynder at have brug for sådanne ting. Jeg vil sige, at du helt sikkert har brug for en DRP, hvis:
- Driftstop af server, applikation eller tab af en database vil medføre betydelige tab for forretningen generelt.
- Du har en fuld IT-afdeling. Jeg mener en afdeling som en fuldgyldig enhed i virksomheden, med sit eget budget, ikke bare et par trætte medarbejdere der trækker kabler, fjerner vira og fylder printere.
- Du har et reelt budget, i det mindste til delvis reservedele i tilfælde af en nødsituation.
Når IT-afdelingen i månedsvis beder om blot et par HDD'er til en gammel server til backup, vil du næppe kunne organisere en fuld migration af den nedlagte service til reservekapacitet. Selvom dokumentation her også vil være nyttig.
Dokumentation er vigtig
Begynd med dokumentationen. Antag at din service kører på en Perl-script, der blev skrevet tre generationer administratorer siden, og hvordan det fungerer, ved ingen. Den akkumulerede tekniske gæld og mangel på dokumentation vil uundgåeligt ramme dig ikke kun i knæet, men også i andre lemmer, det er mere et spørgsmål om tid.
Når du har en god beskrivelse af servicekomponenterne, skal du se på statistikken for nedbrud. De vil næsten helt sikkert være helt typiske. For eksempel, hvis din disk periodevis overfyldes, hvilket medfører, at en node går ned, indtil den manuelt ryddes. Eller kundeservicen bliver utilgængelig, fordi nogen igen har glemt at forny certifikatet, og de kunne ikke eller ville ikke konfigurere Let's Encrypt.
Tanker som en sabotør
Den sværeste del er at forudsige de nedbrud, der endnu ikke har fundet sted, men som potentielt kan bringe din service helt ned. Her spiller vi normalt skurke med mine kolleger. Tag masser af kaffe og noget lækkert og lås jer inde i mødelokalet. Sørg for, at de ingeniører, der faktisk har opsat den pågældende service eller arbejder med den regelmæssigt, også er låst inde i dette mødelokale. Derefter begynder I enten på tavlen eller på papir at tegne alle mulige rædsler, der kan ske med din service. Det er ikke nødvendigt at detaljere ned til den specifikke rengøringsmedarbejder og at trække kabler ud, det er tilstrækkeligt at overveje scenariet "Brud på integriteten af det lokale netværk."
Normalt falder de fleste typiske nødsituationer ind under følgende typer:
- Netværksfejl
- Fejl i operativsystemets tjenester
- Applikationsfejl
- Hardwarefejl
- Virtualiseringsfejl
Du går simpelthen igennem hver type og ser, hvad der gælder for din service. For eksempel kan Nginx-demonen falde og ikke starte igen - det henviser til fejl fra OS. En sjælden situation, der bringer din webapplikation i en ikke-fungerende tilstand - Softwarens fejl. Under arbejdet med dette trin er det vigtigt at arbejde med problemdiagnosen. Hvordan skelner man mellem en fastlåst grænseflade i virtualiseringen og et nedbrudt Cisco-system eller et netværksnedbrud, for eksempel. Det er vigtigt for hurtigt at finde de ansvarlige og begynde at trække dem i halerne, indtil nedbruddet er løst.
Når de typiske problemer er nedskrevet, hælder vi mere kaffe og begynder at overveje de mest mærkelige scenarier, hvor nogle parametre begynder at overstige normen. For eksempel:
- Hvad vil der ske, hvis tiden på den aktive node flyttes et minut tilbage i forhold til de andre i klyngen?
- Og hvad hvis tiden flyttes fremad, hvad hvis den flyttes 10 år frem?
- Hvad vil ske, hvis en klynge-node pludselig mister netværket under synkroniseringen?
- Hvad sker der, hvis to noder ikke kan dele lederskabet på grund af midlertidig isolation fra hinanden i netværket?
På dette tidspunkt er det meget hjælpsomt at tage den mest besatte medlem af teamet med en sygelig fantasi og give ham opgaven at skabe en sabotage, der vil lamme tjenesten. Hvis det er svært at diagnosticere — endnu bedre. Du vil ikke tro, hvilke mærkelige og fede idéer ingeniører kommer med, når de får mulighed for at bryde noget. Og hvis du endda lover dem en testbænk til det formål — er det helt perfekt.
Hvad er denne DRP?!
Så du har identificeret trusselsmodellen. Du har taget højde for de lokale beboere, der skærer fiberkabler i jagten på kobber, og militærradaren, der nedlægger radiolinjen præcis om fredagen kl. 16:46. Nu skal du finde ud af, hvad man skal gøre med alt dette.
Din opgave er at skrive de røde kuverter, der skal åbnes i en nødsituation. Forbered dig på, at når (ikke hvis!) alt går galt, vil der være kun den mest uerfarne praktikant i nærheden, hvis hænder ryster voldsomt af skrækken over, hvad der sker. Kig på, hvordan nødskilt er udført i lægekontorer. For eksempel, hvad man skal gøre ved anafylaktisk chok. Det medicinske personale kender alle protokoller udenad, men når der er en person, der begynder at dø, griber de ofte panisk fat i alt muligt. Derfor hænger der en klar instruktion på væggen med punkter som "åbn emballagen af dette" og "giv intravenøst så mange enheder af dette stof".
I en nødsituation er det svært at tænke! Der skal være enkle instruktioner til at bearbejde med den rygmarv.
En god DRP består af flere enkle blokke:
- Hvem skal informeres om starten af en nødsituation. Dette er vigtigt for at maksimere paralleliseringen af problemløsningsprocessen.
- Hvordan man korrekt diagnosticerer — vi udfører sporing, tjekker systemctl status servicename og så videre.
- Hvor meget tid kan der bruges på hvert trin. Hvis du ikke kan reparere det manuelt inden for SLA-tiden — bliver den virtuelle maskine dræbt og gendannet fra gårsdagens backup.
- Hvordan man sikrer, at nødsituationen er afsluttet.
Husk, at DRP'en starter, når tjenesten helt fejler, og slutter med genopretningen, selv med nedsat effektivitet. Bare tabet af reservation bør ikke aktivere DRP. Du kan også inkludere en kop te i DRP'en. Seriøst. Ifølge statistikker bliver mange uheld fra ubehagelige til katastrofale, fordi personalet i panik kaster sig over noget reparation, hvilket samtidig ødelægger den eneste aktive node med data eller endeligt skader klusteret. Som regel giver 5 minutter til en kop te dig lidt tid til at falde til ro og analysere, hvad der sker.
Forveksl ikke DRP med systemets pas! Overbelast det ikke med unødvendige data. Giv mulighed for hurtigt og nemt at navigere via hyperlinks til de relevante afsnit i dokumentationen og læse om de relevante områder i tjenestens arkitektur i udvidet format. Og i selve DRP'en skal der kun være direkte anvisninger om, hvor og hvordan man forbindes med specifikke kommandoer til kopiering.
Hvordan man tester korrekt
Sørg for, at enhver ansvarlig medarbejder er i stand til at udføre alle punkter. I det mest kritiske øjeblik kan det vise sig, at ingeniøren ikke har adgangsrettigheder til det nødvendige system, at adgangskoder til den relevante konto mangler, eller at han ikke har nogen idé om, hvad "Forbind til kontrolpanelet for tjenesten via proxy i hovedkontoret" betyder. Hvert punkt skal være meget enkelt.
Forkert — "Gå ind i virtualiseringen og genstart den døde node"
Rigtigt — "Forbind via webgrænsefladen til virt.example.com, og under sektionen for noder, genstart noden, som forårsager fejlen."
Undgå tvetydigheder. Husk den skræmte praktikant.
Test altid DRP'en. Dette er ikke bare en plan for at få den afkrydset — det er det, der gør det muligt for dig og dine kunder hurtigt at komme ud af en kritisk situation. Det er optimalt at gøre dette flere gange:
- En ekspert og flere praktikanter arbejder på en teststand, der maksimalt efterligner den rigtige tjeneste. Eksperten skader tjenesten på forskellige måder og giver praktikanterne mulighed for at genoprette den i henhold til DRP'en. Alle problemer, uklarheder i dokumentationen og fejl bliver noteret. Efter træningen af praktikanterne bliver DRP'en suppleret og forenklet i de uklare områder.
- Testning på en reel tjeneste. Det er faktisk aldrig muligt at skabe en perfekt kopi af en rigtig tjeneste. Derfor er det nødvendigt at planlægge at slukke for en del servere et par gange om året, afbryde forbindelser og skabe andre nedbrud fra trusselslisten for at vurdere genoprettelsesordenen. Bedre med en planlagt nedbrud på 10 minutter midt om natten end en pludselig fejl i højbelastningstimerne med datatab.
- Reelt fejlfinding. Ja, det er også en del af testningen. Hvis der opstår et nedbrud, som ikke var på trusselslisten, skal DRP'en suppleres og tilpasses ud fra resultaterne af undersøgelsen af hændelsen.
Nøglepunkter
- Hvis noget kan gå galt, så vil det ikke blot gå galt, men gøre det på den mest katastrofale måde.
- Sørg for, at I har ressourcer til nødlastbalancering.
- Sørg for, at I har backups, som automatisk oprettes og regelmæssigt kontrolleres for konsistens.
- Overvej typiske trusselscenarier.
- Giv ingeniørerne mulighed for at finde på usædvanlige måder at tage tjenesten ned.
- DRP'en skal være en simpel og ligetil instruktion. Al kompleks diagnose kommer først efter, at kundenes tjeneste er genoprettet. Selv hvis det er på reservemuligheder.
- Angiv nøgletelefonnumre og kontakter i DRP'en.
- Test regelmæssigt medarbejderne for deres forståelse af DRP'en.
- Arranger planlagte nedbrud på produktionen. Standby-opsætninger kan ikke erstatte alt.
Kilde: habr.com
