Fins i tot durant un desastre sempre hi ha temps per a una tassa de te
DRP (pla de recuperació de desastres) és una cosa que idealment mai serà necessària. Però si de sobte els castors que migren durant la temporada d'aparellament roseguen la fibra òptica de la columna vertebral o un administrador júnior deixa caure la base productiva, definitivament voldrà estar segur que tindreu un pla predefinit sobre què fer amb tota aquesta desgràcia.
Mentre els clients en pànic comencen a tallar els telèfons d'assistència tècnica, el jove busca cianur, obriu el sobre vermell amb prudència i comenceu a posar-ho tot en ordre.
En aquesta publicació vull compartir recomanacions sobre com escriure un DRP i què ha de contenir. També mirarem les coses següents:
- Aprenem a pensar com un dolent.
- Vegem els beneficis d'una tassa de te durant l'apocalipsi.
- Pensem en una estructura de DRP convenient
- Vegem com provar-ho
Per a quines empreses pot ser útil?
És molt difícil marcar la línia quan el departament d'informàtica comença a necessitar aquestes coses. Jo diria que definitivament necessiteu DRP si:
- Aturar un servidor, una aplicació o la pèrdua d'alguna base de dades comportarà pèrdues importants per al conjunt del negoci.
- Tens un departament informàtic complet. En el sentit d'un departament en forma d'una unitat de l'empresa en tota regla, amb el seu propi pressupost, i no només uns quants empleats cansats establint una xarxa, netejant virus i omplint impressores.
- Teniu un pressupost realista per almenys una acomiadament parcial en cas d'emergència.
Quan el departament informàtic ha estat demanant almenys un parell de discs durs durant mesos per posar-los en un servidor antic per fer còpies de seguretat, és poc probable que pugueu organitzar un moviment complet del servei fallit per reservar capacitat. Encara que aquí la documentació no serà superflua.
La documentació és important
Comenceu amb la documentació. Suposem que el vostre servei s'executa amb un script Perl escrit fa tres generacions pels administradors, però ningú sap com funciona. El deute tècnic acumulat i la falta de documentació us dispararan inevitablement no només al genoll, sinó també a altres extremitats, és més una qüestió de temps.
Un cop tingueu una bona descripció dels components del servei, consulteu les estadístiques d'accidents. Gairebé segur que seran completament típics. Per exemple, el vostre disc s'omple de tant en tant, cosa que fa que el node falli fins que es neteja manualment. O el servei al client no està disponible a causa del fet que algú va tornar a oblidar de renovar el certificat i Let's Encrypt no va poder o no va voler configurar-lo.
Pensaments com un saboteador
La part més difícil és predir aquells accidents que no s'han produït mai abans, però que podrien bloquejar completament el vostre servei. Aquí els meus companys i jo normalment juguem a vilans. Preneu molt cafè i alguna cosa saborós i tanqueu-vos en una sala de reunions. Només assegureu-vos que en les mateixes negociacions bloquegeu els enginyers que ells mateixos van desenvolupar el servei objectiu o que hi treballen regularment. Aleshores, ja sigui a la pissarra o al paper, comenceu a dibuixar tots els possibles horrors que puguin passar al vostre servei. No cal entrar en detall fins a una dona de neteja específica i treure cables; n'hi ha prou amb considerar l'escenari de "Violació de la integritat de la xarxa local".
Normalment, la majoria de situacions d'emergència típiques es divideixen en els següents tipus:
- Error a la xarxa
- Falla dels serveis del sistema operatiu
- Error de l'aplicació
- Falla de ferro
- Falla de virtualització
Només heu de revisar cada tipus i veure què s'aplica al vostre servei. Per exemple, el dimoni Nginx pot caure i no pujar; això significa errors per part del sistema operatiu. Una situació poc freqüent que fa que la vostra aplicació web falli és una fallada del programari. Durant aquesta etapa, és important elaborar el diagnòstic del problema. Com distingir una interfície congelada a la virtualització d'una unitat cis caiguda i un accident de xarxa, per exemple. Això és important per trobar ràpidament els responsables i començar a estirar la cua fins que es resolgui l'accident.
Després d'anotar els problemes típics, aboquem més cafè i comencem a considerar els escenaris més estranys, quan alguns paràmetres comencen a anar molt més enllà de la norma. Per exemple:
- Què passa si el temps al node actiu es mou un minut enrere en relació amb els altres del clúster?
- Què passa si el temps avança, i si 10 anys?
- Què passa si un node de clúster perd sobtadament la seva xarxa durant la sincronització?
- Què passarà si dos nodes no comparteixen el lideratge a causa de l'aïllament temporal entre ells a la xarxa?
En aquesta etapa, l'enfocament invers és molt útil. Agafes el membre més tossut de l'equip amb una imaginació malaltissa i li encarregues d'organitzar un sabotatge en el menor temps possible que farà caure el servei. Si és difícil de diagnosticar, encara millor. No us creureu quines idees estranyes i genials surten als enginyers si els doneu una idea per trencar alguna cosa. I si els promets un banc de proves per a això, està absolutament bé.
Què és aquest teu DRP?!
Així que heu definit el vostre model d'amenaça. També van tenir en compte els residents locals que tallen cables de fibra òptica a la recerca de coure, i un radar militar que deixa caure una línia de relé de ràdio estrictament els divendres a les 16:46. Ara hem d'entendre què fer amb tot això.
La teva tasca és escriure aquells sobres molt vermells que s'obriran en cas d'emergència. Espereu immediatament que quan (no si!) tot s'acabi, només hi haurà a prop el intern més inexpert, les mans del qual tremolaran violentament per l'horror del que està passant. Vegeu com s'implementen els senyals d'emergència als consultoris mèdics. Per exemple, què fer en cas de xoc anafilàctic. El personal mèdic coneix tots els protocols de memòria, però quan una persona propera comença a morir, molt sovint tothom s'aferra impotent a tot el que està a la vista. Per fer-ho, hi ha instruccions clares a la paret amb elements com "obrir el paquet de tal i tal" i "administrar tantes unitats del fàrmac per via intravenosa".
És difícil pensar en una emergència! Hi hauria d'haver instruccions senzilles per analitzar la medul·la espinal.
Un bon DRP consta de diversos blocs senzills:
- A qui notificar l'inici d'un accident. Això és important per tal de paral·lelitzar el procés d'eliminació tant com sigui possible.
- Com fer un diagnòstic correctament: realitzeu un rastre, busqueu l'estat systemctl nom del servei i així successivament.
- Quant de temps pots dedicar a cada escenari? Si no teniu temps d'arreglar-ho manualment dins del temps de SLA, la màquina virtual s'elimina i es desactiva des de la còpia de seguretat d'ahir.
- Com assegurar-se que l'accident ha acabat.
Recordeu que el DRP comença quan el servei ha fallat completament i acaba quan es restableix el servei, fins i tot amb una eficiència reduïda. Simplement perdre una reserva no hauria de desencadenar DRP. També podeu escriure una tassa de te al DRP. De debò. Segons les estadístiques, molts accidents passen de desagradables a catastròfics a causa del fet que el personal s'afanya a arreglar alguna cosa, matant simultàniament l'únic node viu amb dades o finalment acabant el clúster. Per regla general, 5 minuts amb una tassa de te us donaran temps per calmar-vos i analitzar què està passant.
No confongueu DRP i passaport del sistema! No el sobrecarregueu amb dades innecessàries. Només feu possible utilitzar hipervincles de manera ràpida i còmoda per anar a la secció desitjada de la documentació i llegir en un format ampliat les seccions necessàries de l'arquitectura del servei. I al mateix DRP només hi ha instruccions directes sobre on i com connectar-se amb ordres específiques per copiar i enganxar.
Com provar correctament
Assegureu-vos que qualsevol empleat responsable pugui completar tots els elements. En el moment més crucial, pot resultar que l'enginyer no té drets per accedir al sistema requerit, no hi ha contrasenyes per al compte requerit o no té ni idea de què "Connecteu-vos a la consola de gestió del servei mitjançant un proxy al seu central” vol dir. Cada punt ha de ser extremadament senzill.
Incorrecte - "Vés a la virtualització i reinicia el node mort"
Correctament - "Connecteu-vos mitjançant la interfície web a virt.example.com, a la secció de nodes, reinicieu el node que està causant l'error".
Evita l'ambigüitat. Recordeu el intern espantat.
Assegureu-vos de provar DRP. Aquest no és només un pla per a l'espectacle, és una cosa que us permetrà a vosaltres i als vostres clients sortir ràpidament d'una situació crítica. El millor és fer-ho diverses vegades:
- Un expert i diversos aprenents treballen en un banc de proves que simula al màxim un servei real. L'expert trenca el servei de diverses maneres i permet als estudiants restablir-lo segons el DRP. Es registren tots els problemes, ambigüitats de la documentació i errors. Després de la formació dels estudiants, el DRP s'amplia i simplifica en àrees poc clares.
- Prova en un servei real. De fet, mai podeu crear una còpia perfecta d'un servei real. Per tant, un parell de cops a l'any cal apagar de manera rutinària alguns dels servidors, tallar connexions i provocar altres desastres de la llista d'amenaces per avaluar l'ordre de recuperació. Una fallada planificada durant 10 minuts al mig de la nit és millor que una fallada sobtada durant diverses hores durant la càrrega màxima amb pèrdua de dades.
- Resolució de problemes reals. Sí, això també forma part de les proves. Si es produeix un accident que no figurava a la llista d'amenaces, cal complementar i finalitzar el DRP a partir dels resultats de la seva investigació.
Punts clau
- Si pot passar una merda, no només passarà, sinó que ho farà en l'escenari més catastròfic possible.
- Assegureu-vos que disposeu de recursos per a la transferència de càrrega d'emergència.
- Assegureu-vos de tenir còpies de seguretat, es creen automàticament i es comprova regularment la coherència.
- Penseu en escenaris d'amenaça típics.
- Oferiu als enginyers l'oportunitat de trobar opcions no estàndard per oferir el servei.
- DRP hauria de ser una instrucció senzilla i contundent. Tots els diagnòstics complexos només es realitzen després que s'hagi restaurat el servei dels clients. Encara que a capacitat de reserva.
- Proporcioneu números de telèfon i contactes clau al DRP.
- Comproveu la comprensió dels empleats del DRP periòdicament.
- Organitzar accidents planificats als llocs de producció. Els estands no poden substituir-ho tot.
Font: www.habr.com