Även under en katastrof finns det alltid tid för en kopp te
DRP (katastrofåterställningsplan) är en sak som helst aldrig kommer att behövas. Men om bävrar som plötsligt migrerar under parningssäsongen gnager genom den optiska fibern i ryggraden eller om en junioradministratör tappar den produktiva basen, vill du definitivt vara säker på att du kommer att ha en färdig plan för vad du ska göra med all denna skam.
Medan kunder i panik börjar stänga av tekniska supporttelefoner, junioren letar efter cyanid, öppnar man klokt det röda kuvertet och börjar ställa allt i ordning.
I det här inlägget vill jag dela med mig av rekommendationer om hur man skriver en DRP och vad den ska innehålla. Vi kommer också att titta på följande saker:
- Låt oss lära oss att tänka som en skurk.
- Låt oss titta på fördelarna med en kopp te under apokalypsen.
- Låt oss fundera över en bekväm DRP-struktur
- Låt oss se hur man testar det
Vilka företag kan detta vara användbart för?
Det är väldigt svårt att dra gränsen när IT-avdelningen börjar behöva sådant. Jag skulle säga att du definitivt behöver DRP om:
- Att stoppa en server, applikation eller förlora någon databas kommer att leda till betydande förluster för verksamheten som helhet.
- Du har en fullfjädrad IT-avdelning. I bemärkelsen en avdelning i form av en fullfjädrad enhet inom företaget, med egen budget, och inte bara några trötta anställda som lägger nätverk, städar virus och fyller på skrivare.
- Du har en realistisk budget för åtminstone partiell uppsägning i händelse av en nödsituation.
När IT-avdelningen i månader har bett om åtminstone ett par hårddiskar till en gammal server för säkerhetskopiering, är det osannolikt att du kommer att kunna organisera en fullvärdig flytt av en misslyckad tjänst för att reservera kapacitet. Även här kommer dokumentationen inte att vara överflödig.
Dokumentation är viktigt
Börja med dokumentation. Låt oss säga att din tjänst körs på ett Perl-skript som skrevs för tre generationer sedan av administratörer, men ingen vet hur det fungerar. Den ackumulerade tekniska skulden och bristen på dokumentation kommer oundvikligen att skjuta dig inte bara i knäet utan även i andra lemmar, det är mer en tidsfråga.
När du har en bra beskrivning av servicekomponenterna, slå upp olycksstatistik. De kommer nästan säkert att vara helt typiska. Till exempel blir din disk full då och då, vilket gör att noden misslyckas tills den rensas upp manuellt. Eller så blir klienttjänsten otillgänglig på grund av att någon igen har glömt att förnya certifikatet och Let's Encrypt inte kunde eller ville konfigurera.
Tankar som en sabotör
Den svåraste delen är att förutsäga de olyckor som aldrig har hänt tidigare, men som potentiellt kan krascha din tjänst helt. Här brukar vi leka skurkar med kollegor. Ta en massa kaffe och något gott och lås in dig i mötesrummet. Se bara till att du i samma förhandlingar låser in de ingenjörer som själva utvecklat måltjänsten eller regelbundet arbetar med den. Sedan, antingen på tavlan eller på papper, börjar du rita alla möjliga hemskheter som kan hända din tjänst. Det är inte nödvändigt att gå in i detalj ner till en specifik städerska och dra ut kablar; det räcker med att överväga scenariot med "Brott mot det lokala nätverkets integritet."
Vanligtvis faller de flesta typiska nödsituationer in i följande typer:
- Nätverksfel
- OS-tjänster misslyckades
- Applikationsfel
- Järnsvikt
- Virtualiseringsfel
Gå bara igenom varje vy och se vad som gäller för din tjänst. Till exempel kan Nginx-demonen falla och inte stiga - detta är ett misslyckande från operativsystemets sida. En sällsynt situation som gör att din webbapplikation misslyckas är ett programvarufel. Under utvecklingen av detta stadium är det viktigt att utarbeta diagnosen av problemet. Hur man skiljer ett fruset gränssnitt på virtualisering från en fallen cis-enhet och ett nätverksfel, till exempel. Detta är viktigt för att snabbt hitta de ansvariga och börja dra i svansen tills olyckan är åtgärdad.
Efter att typiska problem har skrivits ner häller vi upp mer kaffe och börjar överväga de konstigaste scenarierna, när vissa parametrar börjar gå långt utöver normen. Till exempel:
- Vad händer om tiden på den aktiva noden flyttas tillbaka en minut i förhållande till andra i klustret?
- Tänk om tiden går framåt, tänk om med 10 år?
- Vad händer om en klusternod plötsligt tappar sitt nätverk under synkronisering?
- Vad händer om två noder inte delar ledarskap på grund av tillfällig isolering av varandra i nätverket?
I detta skede är det omvända tillvägagångssättet till stor hjälp. Du tar den mest envisa medlemmen i teamet med en sjuk fantasi och ger honom i uppdrag att organisera ett sabotage på kortast möjliga tid som kommer att få ner tjänsten. Om det är svårt att diagnostisera, ännu bättre. Du kommer inte att tro vilka konstiga och coola idéer ingenjörer kommer på om du ger dem en idé om att bryta något. Och om du lovar dem en testbänk för detta är det helt okej.
Vad är din DRP?!
Så du har definierat din hotmodell. De tog också hänsyn till lokala invånare som kapade fiberoptiska kablar i jakt på koppar, och en militärradar som släpper en radioreläledning strikt på fredagar klockan 16:46. Nu måste vi förstå vad vi ska göra med allt detta.
Din uppgift är att skriva de där mycket röda kuverten som kommer att öppnas i en nödsituation. Förvänta dig omedelbart att när (inte om!) allt tar slut, kommer bara den mest oerfarna praktikanten att vara i närheten, vars händer kommer att skaka våldsamt av fasan över vad som händer. Se hur nödskyltar implementeras på läkarmottagningar. Till exempel vad man ska göra vid anafylaktisk chock. Sjukvårdspersonalen kan alla protokoll utantill, men när en person i närheten börjar dö, griper alla väldigt ofta hjälplöst tag i allt i sikte. För att göra detta finns det tydliga instruktioner på väggen med saker som "öppna förpackningen med sådant och sådant" och "administrera så många enheter av läkemedlet intravenöst."
Det är svårt att tänka i en nödsituation! Det bör finnas enkla instruktioner för ryggmärgsanalys.
En bra DRP består av flera enkla block:
- Vem ska meddelas om början av en olycka. Detta är viktigt för att parallellisera elimineringsprocessen så mycket som möjligt.
- Hur man diagnostiserar korrekt - utför en spårning, titta i systemctl status servicename och så vidare.
- Hur mycket tid kan du lägga på varje etapp? Om du inte har tid att fixa det manuellt inom SLA-tiden, dödas den virtuella maskinen och rullas tillbaka från gårdagens säkerhetskopia.
- Hur man ser till att olyckan är över.
Kom ihåg att DRP börjar när tjänsten har misslyckats helt och slutar när tjänsten återställs, även med minskad effektivitet. Att bara förlora en reservation bör inte utlösa DRP. Du kan också skriva en kopp te i DRP. Allvarligt. Enligt statistik förvandlas många olyckor från obehagliga till katastrofala på grund av det faktum att personalen i panik rusar för att fixa något, samtidigt dödar den enda levande noden med data eller slutligen avslutar klustret. Som regel kommer 5 minuter med en kopp te att ge dig lite tid att lugna ner dig och analysera vad som händer.
Blanda inte ihop DRP och systempass! Överbelasta den inte med onödiga data. Gör det bara möjligt att snabbt och bekvämt använda hyperlänkar för att gå till önskad del av dokumentationen och läsa i utökat format om de nödvändiga delarna av tjänstens arkitektur. Och i själva DRP finns det bara direkta instruktioner om var och hur man ansluter med specifika kommandon för copy-paste.
Hur man testar rätt
Se till att alla ansvariga medarbetare kan slutföra alla objekt. I det mest avgörande ögonblicket kan det visa sig att ingenjören inte har rättigheter att komma åt det system som krävs, att det inte finns några lösenord för det nödvändiga kontot eller att han inte har någon aning om vad "Anslut till servicehanteringskonsolen via en proxy på huvudkontor” betyder. Varje punkt bör vara extremt enkel.
fel — "Gå till virtualisering och starta om den döda noden"
korrekt - "Anslut via webbgränssnittet till virt.example.com, i nodavsnittet, starta om noden som orsakar felet."
Undvik oklarheter. Kom ihåg den rädda praktikanten.
Var noga med att testa DRP. Det här är inte bara en plan för show - det är något som gör att du och dina kunder snabbt kan ta sig ur en kritisk situation. Det är bäst att göra detta flera gånger:
- En expert och flera praktikanter arbetar på en testbänk som simulerar en riktig tjänst så mycket som möjligt. Experten bryter tjänsten på olika sätt och gör det möjligt för praktikanterna att återställa den enligt DRP. Alla problem, oklarheter i dokumentationen och fel registreras. Efter att praktikanter utbildats utökas och förenklas DRP på oklara områden.
- Testar på en riktig tjänst. Faktum är att du aldrig kan skapa en perfekt kopia av en riktig tjänst. Därför är det ett par gånger om året nödvändigt att rutinmässigt stänga av några av servrarna, bryta anslutningar och orsaka andra katastrofer från listan över hot för att kunna bedöma återställningsordern. Ett planerat fel i 10 minuter mitt i natten är bättre än ett plötsligt fel i flera timmar vid toppbelastning med dataförlust.
- Verklig felsökning. Ja, detta är också en del av testningen. Om en olycka inträffar som inte fanns på listan över hot, är det nödvändigt att komplettera och slutföra DRP baserat på resultaten av dess utredning.
Nyckelord
- Om skit kan hända kommer det inte bara att hända, utan det kommer att göra det i det mest katastrofala scenariot som möjligt.
- Se till att du har resurser för nödlastöverföring.
- Se till att du har säkerhetskopior, de skapas automatiskt och kontrolleras regelbundet för konsistens.
- Tänk igenom typiska hotscenarier.
- Ge ingenjörer möjlighet att komma med icke-standardiserade alternativ för att leverera tjänsten.
- DRP ska vara en enkel och trubbig instruktion. All komplex diagnostik utförs först efter att kundens tjänst har återställts. Även om vid reservkapacitet.
- Ange viktiga telefonnummer och kontakter i DRP.
- Testa medarbetarnas förståelse för DRP regelbundet.
- Ordna planerade olyckor på produktionsplatser. Stativ kan inte ersätta allt.
Källa: will.com