Même pendant une catastrophe, il y a toujours du temps pour une tasse de thé
DRP (plan de reprise après sinistre) - une chose qui, idéalement, n'a jamais besoin. Mais si soudainement les castors qui migrent pendant la saison des amours rongent la fibre optique de l'épine dorsale ou si l'administrateur junior laisse tomber la base productive, vous voulez certainement être sûr que vous aurez un plan prédéfini de ce qu'il faut faire avec tout ce désordre.
Alors que les clients paniqués commencent à couper leurs téléphones de support technique, le junior cherche du cyanure, vous ouvrez sagement l'enveloppe rouge et commencez à tout mettre en ordre.
Dans cet article, je souhaite partager des recommandations sur la façon d'écrire un DRP et ce qu'il doit contenir. Nous examinerons également les éléments suivants:
- Apprenons à penser comme un méchant.
- Regardons les bienfaits d'une tasse de thé pendant l'apocalypse.
- Nous réfléchirons à une structure DRP pratique
- Voyons comment le tester.
Pour quelles entreprises cela peut être utile
Il est très difficile de tracer la ligne lorsque le service informatique commence à avoir besoin de ces choses. Je dirais que vous êtes assuré d'avoir besoin de DRP si:
- L'arrêt du serveur, de l'application ou la perte d'une base entraînera des pertes importantes de l'entreprise dans son ensemble.
- Vous disposez d'un service informatique à part entière. Dans le sens d'un département sous la forme d'une unité à part entière de l'entreprise, avec son propre budget, et pas seulement quelques employés fatigués qui posent un réseau, nettoient les virus et font le plein d'imprimantes.
- Vous disposez d'un budget réaliste pour une redondance au moins partielle en cas d'urgence.
Lorsque le service informatique demande pendant des mois au moins quelques disques durs pour un ancien serveur pour les sauvegardes, il est peu probable que vous puissiez organiser un transfert complet d'un service tombé en panne pour réserver de la capacité. Bien que la documentation ici ne soit pas superflue.
La documentation est importante
Commencez par la documentation. Disons que votre service est basé sur un script Perl qui a été écrit il y a trois générations d'administrateurs, et personne ne sait comment cela fonctionne. La dette technique accumulée et le manque de documentation vous tireront inévitablement non seulement dans le genou, mais aussi dans d'autres membres, c'est plutôt une question de temps.
Une fois que vous avez une bonne description des composants du service, augmentez les statistiques de plantage. Ils seront presque certainement tout à fait typiques. Par exemple, vous avez un disque plein de temps en temps, ce qui entraîne une défaillance du nœud avant qu'il ne soit nettoyé manuellement. Ou le service client devient indisponible en raison du fait que quelqu'un a de nouveau oublié de renouveler le certificat, et Let's Encrypt n'a pas pu ou n'a pas voulu le configurer.
Des pensées comme un saboteur
Le plus difficile est de prévoir des accidents qui ne se sont jamais produits auparavant, mais qui pourraient potentiellement tuer complètement votre service. Ici, nous jouons généralement les méchants avec nos collègues. Prenez beaucoup de café et quelque chose de savoureux et enfermez-vous dans une salle de réunion. Assurez-vous simplement que dans la même salle de réunion vous avez enfermé les ingénieurs qui ont eux-mêmes élevé le service cible ou qui travaillent régulièrement avec. Ensuite, que ce soit au tableau ou sur papier, vous commencez à dessiner toutes les horreurs possibles qui peuvent arriver à votre service. Il n'est pas nécessaire de détailler jusqu'à un nettoyeur spécifique et de retirer les câbles, il suffit d'envisager le scénario «Violation de l'intégrité du réseau local».
Habituellement, la plupart des situations d'urgence typiques appartiennent aux types suivants:
- Panne de réseau
- Échec des services du système d'exploitation
- Échec de l'application
- Échec du fer
- Échec de la virtualisation
Parcourez simplement chaque vue et voyez ce qui s'applique à votre service. Par exemple, le démon Nginx peut planter et ne pas se lever - il s'agit d'un échec de la part du système d'exploitation. Une situation rare qui conduit votre application Web dans un état de non-fonctionnement est une défaillance logicielle. Au cours de cette étape, il est important d'élaborer le diagnostic du problème. Comment distinguer une interface bloquée sur la virtualisation d'un tsiska tombé en panne et d'un crash réseau, par exemple. Il est important de trouver rapidement les responsables et de commencer à tirer sur leur queue jusqu'à ce que l'accident soit réglé.
Une fois les problèmes typiques notés, nous versons plus de café et commençons à envisager les scénarios les plus étranges lorsque certains paramètres commencent à dépasser la norme. Par exemple:
- Que se passe-t-il si l'heure du nœud actif recule d'une minute par rapport aux autres dans le cluster?
- Et si le temps avance, et si de 10 ans?
- Que se passe-t-il si un nœud de cluster perd soudainement son réseau pendant la synchronisation?
- Et que se passera-t-il si deux nœuds ne partagent pas le leadership en raison de l'isolement temporaire l'un de l'autre sur le réseau?
L'approche inverse aide beaucoup à ce stade. Vous prenez le membre de l'équipe le plus têtu avec une imagination malade et lui donnez la tâche d'organiser un sabotage le plus tôt possible, ce qui mettra le service hors service. S'il est difficile de le diagnostiquer, c'est encore mieux. Vous ne croirez pas les idées étranges et cool que les ingénieurs proposent si vous leur donnez une idée de casser quelque chose. Et déjà si vous leur promettez un banc d’essai pour cela, c’est très bien.
Quel est votre DRP?!
Vous avez donc défini le modèle de menace. Ils ont également pris en compte les habitants qui coupaient les câbles en fibre optique à la recherche de cuivre, et le radar militaire, qui lâche la ligne de relais radio strictement le vendredi à 16h46. Nous devons maintenant comprendre quoi faire de tout cela.
Votre tâche est d'écrire les enveloppes très rouges qui seront ouvertes en cas d'urgence. Attendez-vous immédiatement à ce que quand (pas si!) Tout va bien, seul le stagiaire le moins expérimenté sera à proximité, dont les mains trembleront violemment de l'horreur de ce qui se passe. Découvrez comment les étiquettes d'urgence sont mises en œuvre dans les cabinets médicaux. Par exemple, que faire en cas de choc anaphylactique. Le personnel médical connaît tous les protocoles par cœur, mais quand une personne à côté de lui commence à mourir, très souvent, tout le monde s'accroche impuissant à tout. Pour ce faire, il y a une instruction claire sur le mur avec des éléments comme «ouvrir l'emballage de ceci» et «injecter autant d'unités du médicament par voie intraveineuse».
Il est difficile de penser en cas d'urgence! Il devrait y avoir des instructions simples pour l'analyse de la moelle épinière.
Un bon DRP se compose de quelques blocs simples:
- . , .
- — , systemctl status servicename .
- . SLA — .
- , .
N'oubliez pas que DRP démarre lorsque le service a complètement échoué et finit par se reconstruire, même avec une efficacité réduite. La simple perte d'une réservation ne devrait pas activer DRP. Vous pouvez également ajouter une tasse de thé à DRP. Sérieusement. Selon les statistiques, de nombreux accidents désagréables deviennent catastrophiques en raison du fait que le personnel paniqué se précipite pour réparer quelque chose, tuant simultanément le seul nœud vivant avec des données ou finissant finalement le cluster. En règle générale, 5 minutes pour une tasse de thé vous donneront le temps de vous calmer et d'analyser ce qui se passe.
Ne confondez pas DRP et passeport système! Ne le surchargez pas avec des données inutiles. Il suffit de rendre possible l'utilisation rapide et pratique des hyperliens pour accéder à la section requise de la documentation et lire dans un format étendu les sections nécessaires de l'architecture de service. Et dans le DRP lui-même, seules les instructions directes où et comment se connecter avec des commandes spécifiques pour le copier-coller.
Comment tester correctement
Assurez-vous que toute personne responsable est en mesure de compléter tous les points. Au moment le plus crucial, il peut s'avérer que l'ingénieur n'a pas les droits d'accès au système requis, qu'il n'y a pas de mot de passe pour le compte requis, ou qu'il n'a aucune idée de ce que cela signifie «Connectez-vous à la console de gestion des services via un proxy au siège social». Chaque point doit être extrêmement simple.
Mauvais - "Accédez à la virtualisation et redémarrez le nœud mort"
Correct - "Connectez-vous via l'interface Web à virt.example.com, dans la section nœuds, redémarrez le nœud à l'origine de l'erreur."
Évitez toute ambiguïté. Souvenez-vous du stagiaire effrayé.
Assurez-vous de tester DRP. Ce n'est pas seulement un plan à cocher - c'est un plan qui vous permettra, à vous et à vos clients, de vous sortir rapidement d'une situation critique. Il est optimal de le faire plusieurs fois:
- Un expert et plusieurs stagiaires travaillent sur un banc de test qui simule au maximum un service réel. L'expert rompt le service de différentes manières et donne aux stagiaires la possibilité de le restaurer selon le DRP. Tous les problèmes, ambiguïtés dans la documentation et erreurs sont enregistrés. Après la formation des stagiaires, le DRP est complété et simplifié dans des endroits obscurs.
- . . , , , . 10 , .
- . , . , , DRP .
- , , .
- , .
- , , .
- .
- .
- DRP . , . .
- DRP.
- DRP.
- . .
