Selv under en katastrofe er der altid tid til en kop te.
DRP (katastrofegenopretningsplan) er en ting, der ideelt set aldrig vil være nødvendig. Men hvis bævere, der migrerer i løbet af parringssæsonen, pludselig gnaver gennem den optiske fiber, eller hvis en junioradministrator taber en produktiv base, vil du helt sikkert være sikker på, at du har en på forhånd lavet plan for, hvad du skal gøre med al denne skændsel.
Mens paniske kunder begynder at ringe til teknisk support, en junior leder efter cyanid, åbner du klogt den røde kuvert og begynder at bringe alt i orden.
I dette indlæg vil jeg dele anbefalinger til, hvordan man skriver en DRP, og hvad den skal indeholde. Vi vil også se på følgende:
- Lær at tænke som en skurk.
- Lad os analysere fordelene ved en kop te under apokalypsen.
- Tænk over en praktisk DRP-struktur
- Lad os se, hvordan man tester det
Hvilke virksomheder kan drage fordel af dette?
Det er meget svært at trække en grænse, når IT-afdelingen begynder at få brug for disse ting. Jeg vil sige, at du med garanti har brug for DRP, hvis:
- At stoppe en server, en applikation eller miste en database vil føre til betydelige tab for virksomheden som helhed.
- Du har en fuldgyldig IT-afdeling. Jeg mener, en afdeling som en fuldgyldig enhed i virksomheden, med sit eget budget, og ikke kun et par trætte medarbejdere, der lægger et netværk, renser virus og genopfylder printere.
- Du har et realistisk budget for i hvert fald delvis afskedigelse i tilfælde af en nødsituation.
Når IT-afdelingen har tigget om mindst et par HDD'er til en gammel server til backup i månedsvis, er det usandsynligt, at du vil kunne organisere en fuldgyldig flytning af den faldne tjeneste for at spare kapacitet. Selvom dokumentationen heller ikke her vil være overflødig.
Dokumentation er vigtig
Start med dokumentation. Lad os sige, at din tjeneste kører på et Perl-script, der blev skrevet for tre generationer af administratorer siden, og ingen ved, hvordan det fungerer. Den akkumulerede tekniske gæld og manglen på dokumentation vil uundgåeligt skyde dig ikke kun i knæet, men også i andre lemmer, det er snarere et spørgsmål om tid.
Når du har en god beskrivelse af servicekomponenterne ved hånden, skal du hæve nedbrudsstatistikken. Næsten helt sikkert vil de være helt typiske. For eksempel har du en disk fuld fra tid til anden, hvilket får noden til at fejle, indtil den manuelt renses. Eller klienttjenesten bliver utilgængelig på grund af det faktum, at nogen igen har glemt at forny certifikatet, og Let's Encrypt ikke kunne konfigureres eller ikke ville.
Tanker som en sabotør
Den sværeste del er at forudsige de ulykker, der aldrig er sket før, men som potentielt kan ødelægge din service fuldstændigt. Her plejer vi at spille skurke med kollegaer. Tag en masse kaffe og noget velsmagende og lås dig inde i mødelokalet. Bare sørg for, at du i samme møde låste de ingeniører, som selv rejste måltjenesten eller arbejder med den regelmæssigt. Så begynder du, enten på tavlen eller på papiret, at tegne alle de mulige rædsler, der kan ske med din tjeneste. Det er ikke nødvendigt at detaljere ned til en specifik rengøringsdame og trække kabler ud, det er nok at overveje scenariet "Krænkelse af det lokale netværks integritet".
Normalt passer de fleste typiske nødsituationer ind i følgende typer:
- Netværksfejl
- OS servicefejl
- Applikationsfejl
- jernsvigt
- Virtualiseringsfejl
Bare gå gennem hver visning og se, hvad der gælder for din tjeneste. For eksempel kan Nginx-dæmonen falde og ikke rejse sig - dette er en fejl fra OS'ets side. En sjælden situation, der driver din webapplikation til en ikke-fungerende tilstand, er en softwarefejl. Under udviklingen af denne fase er det vigtigt at udarbejde diagnosen af problemet. Hvordan man skelner en hængende grænseflade på virtualisering fra en falden cisco og et netværksnedbrud, for eksempel. Dette er vigtigt for hurtigt at finde de ansvarlige og begynde at trække i halen, indtil uheldet er rettet.
Efter at de typiske problemer er skrevet ned, hælder vi mere kaffe op og begynder at overveje de mærkeligste scenarier, når nogle parametre begynder at gå ud over normen. For eksempel:
- Hvad sker der, hvis tiden på den aktive node bevæger sig et minut tilbage i forhold til andre i klyngen?
- Og hvis tiden går fremad, og hvis med 10 år?
- Hvad sker der, hvis en klyngenode pludselig mister netværket under synkronisering?
- Og hvad sker der, hvis to noder ikke deler ledelse på grund af midlertidig isolation af hinanden over netværket?
På dette stadium hjælper den omvendte tilgang meget. Tag det mest stædige medlem af holdet med en syg fantasi og giv ham til opgave at arrangere en afledning på kortest mulig tid, hvilket vil lægge tjenesten ned. Hvis det er svært at diagnosticere, endnu bedre. Du vil ikke tro på de mærkelige og seje ideer, som ingeniører kommer med, når de får ideen til at bryde noget. Og hvis du lover dem en prøvestand for dette, er det meget godt.
Hvad er din DRP?!
Så du har defineret trusselsmodellen. De tog også hensyn til lokale beboere, der klippede fiberoptiske kabler i jagten på kobber, og en militærradar, der dropper en radiorelæledning strengt om fredagen kl. 16:46. Nu skal vi finde ud af, hvad vi skal gøre med det hele.
Din opgave er at skrive de samme røde kuverter, som vil blive åbnet i en nødsituation. Forvent med det samme, at når (ikke hvis!) alt er skruet sammen, vil kun den mest uerfarne praktikant være i nærheden, hvis hænder ryster voldsomt af rædselen over, hvad der sker. Se, hvordan nødskilte implementeres på lægekontorer. For eksempel hvad skal man gøre med anafylaktisk shock. Det medicinske personale kan alle protokollerne udenad, men når en person i nærheden begynder at dø, griber alle meget ofte hjælpeløst efter alting. For at gøre dette hænger en klar instruktion på væggen med genstande som "åbn pakken med sådan og sådan" og "injicer så mange enheder af lægemidlet intravenøst."
Det er svært at tænke i en nødsituation! Der bør være enkle instruktioner til spinal parsing.
En god DRP består af et par simple blokke:
- Hvem skal underrettes om begyndelsen af ulykken. Dette er vigtigt for at parallelisere elimineringsprocessen så meget som muligt.
- Sådan diagnosticeres korrekt - vi sporer, ser i systemctl status servicename og så videre.
- Hvor meget tid kan der bruges på hver etape. Hvis du ikke har tid til at ordne det med dine hænder i SLA-tiden, bliver den virtuelle maskine dræbt og rullet fra gårsdagens backup.
- Sådan sikrer du dig, at styrtet er forbi.
Husk, at DRP starter, når tjenesten er fuldstændig svigtet og fuldføres ved gendannelse, selv med reduceret effektivitet. Blot at miste en reservation burde ikke aktivere DRP. Du kan også ordinere en kop te i DRP. Helt seriøst. Ifølge statistikker går mange ulykker fra ubehagelige til katastrofale på grund af det faktum, at personalet i panik skynder sig at ordne noget, samtidig dræber den eneste levende node med data eller til sidst afslutter klyngen. Som regel vil 5 minutter til en kop te give dig lidt tid til at falde til ro og analysere, hvad der sker.
Forveksle ikke DRP og systempas! Overbelast den ikke med unødvendige data. Giv blot muligheden for hurtigt og bekvemt at gå til den nødvendige sektion af dokumentationen via hyperlinks og læse i et udvidet format om de nødvendige sektioner af tjenestearkitekturen. Og i selve DRP er der kun direkte instruktioner om, hvor og hvordan man forbinder med specifikke kommandoer til copy-paste.
Sådan tester du korrekt
Sørg for, at enhver ansvarlig medarbejder er i stand til at fuldføre alle punkter. På det mest afgørende tidspunkt kan det vise sig, at ingeniøren ikke har adgangsrettigheder til det påkrævede system, at der ikke er adgangskoder til den påkrævede konto, eller at han ikke har nogen idé om, hvad "Opret forbindelse til servicestyringskonsollen via en proxy på hovedkontor” betyder. Hvert element skal være så enkelt som muligt.
forkert - "Gå til virtualisering og genstart den døde node"
korrekt - "Opret forbindelse via webgrænsefladen til virt.example.com, i nodesektionen, genindlæs noden, der forårsager fejlen."
Undgå tvetydighed. Husk den skræmte praktikant.
Sørg for at teste DRP. Dette er ikke kun en plan for show - det er noget, der vil give dig og dine kunder mulighed for hurtigt at komme ud af en kritisk situation. Det er bedst at gøre dette flere gange:
- En ekspert og flere praktikanter arbejder på en testbænk, der så vidt muligt efterligner en rigtig service. Eksperten bryder servicen på forskellige måder og sætter kursisterne i stand til at genoprette den i henhold til DRP. Alle problemer, uklarheder i dokumentationen og fejl registreres. Efter træning af praktikanterne suppleres og forenkles DRP på obskure steder.
- Test på en rigtig service. Faktisk kan du aldrig skabe en perfekt kopi af en rigtig tjeneste. Derfor er det et par gange om året nødvendigt at slukke en del af serverne på et planlagt grundlag, afbryde forbindelser og arrangere andre ulykker fra listen over trusler for at evaluere genopretningsordren. Det er bedre at have en 10-minutters planlagt afbrydelse midt om natten end en pludselig fejl i flere timer ved spidsbelastning med tab af data.
- Virkelig eliminering af ulykken. Ja, det er også en del af testen. Hvis der sker en ulykke, som ikke var på listen over trusler, er det nødvendigt at supplere og færdiggøre DRP baseret på resultaterne af dens undersøgelse.
Centrale punkter
- Hvis lort kan ske, vil det ikke bare ske, men det vil gøre det i det mest katastrofale scenarie.
- Sørg for, at du har ressourcerne til failover.
- Sørg for, at du har sikkerhedskopier, de oprettes automatisk og kontrolleres regelmæssigt for konsistens.
- Overvej typiske trusselsscenarier.
- Giv ingeniører mulighed for at komme med ikke-standardiserede muligheder for at levere tjenesten.
- DRP bør være enkle og dumme instruktioner. Al kompleks diagnostik først efter kunderne har genoprettet service. Også selvom den er på standby.
- Liste nøgletelefonnumre og kontakter i DRP.
- Test jævnligt medarbejderne for DRP-forståelse.
- Arranger planlagte ulykker på produktet. Standere kan ikke erstatte alt.
Kilde: www.habr.com