Même en cas de catastrophe, il est toujours temps de prendre une tasse de thé
DRP (plan de reprise après sinistre) est une chose qui, idéalement, ne sera jamais nécessaire. Mais si soudainement des castors migrant pendant la saison des amours rongent la fibre optique de la colonne vertébrale ou si un administrateur junior perd la base productive, vous voulez certainement être sûr que vous aurez un plan prédéfini pour savoir quoi faire de toute cette honte.
Pendant que les clients paniqués commencent à couper les téléphones du support technique, que la 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 de rédiger un DRP et ce qu'il doit contenir. Nous examinerons également les éléments suivants :
- Apprenons à penser comme un méchant.
- Examinons les bienfaits d'une tasse de thé pendant l'apocalypse.
- Réfléchissons à une structure DRP pratique
- Voyons comment le tester
Pour quelles entreprises cela pourrait-il être utile ?
Il est très difficile de tracer une limite lorsque le service informatique commence à avoir besoin de telles choses. Je dirais que vous avez absolument besoin du DRP si :
- L'arrêt d'un serveur, d'une application ou la perte d'une base de données entraînera des pertes importantes pour 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 installent un réseau, nettoient les virus et rechargent les imprimantes.
- Vous disposez d’un budget réaliste pour un licenciement au moins partiel en cas d’urgence.
Lorsque le service informatique réclame depuis des mois au moins quelques disques durs sur un ancien serveur pour des sauvegardes, il est peu probable que vous puissiez organiser un déplacement à part entière d'un service défaillant pour réserver de la capacité. Bien qu'ici la documentation ne soit pas superflue.
La documentation est importante
Commencez par la documentation. Supposons que votre service s'exécute sur un script Perl écrit il y a trois générations par des administrateurs, mais que personne ne sait comment il fonctionne. La dette technique accumulée et le manque de documentation vous tireront inévitablement une balle non seulement dans le genou, mais aussi dans d'autres membres, ce n'est plus qu'une question de temps.
Une fois que vous avez une bonne description des composants du service, recherchez les statistiques d’accidents. Ils seront presque certainement tout à fait typiques. Par exemple, votre disque se remplit de temps en temps, ce qui entraîne l'échec du nœud jusqu'à ce qu'il soit nettoyé manuellement. Ou bien le service client devient indisponible en raison du fait que quelqu'un a encore oublié de renouveler le certificat et que Let's Encrypt n'a pas pu ou n'a pas voulu configurer.
Des pensées de saboteur
Le plus difficile est de prévoir les accidents qui ne se sont jamais produits auparavant, mais qui pourraient potentiellement faire planter complètement votre service. Ici, mes collègues et moi jouons habituellement les méchants. Prenez beaucoup de café et quelque chose de savoureux et enfermez-vous dans une salle de réunion. Assurez-vous simplement que, dans les mêmes négociations, vous engagez les ingénieurs qui ont eux-mêmes développé le service cible ou qui travaillent régulièrement avec lui. Ensuite, soit au tableau, soit sur papier, vous commencez à dessiner toutes les horreurs possibles qui pourraient arriver à votre service. Il n'est pas nécessaire d'entrer dans les détails jusqu'à une femme de ménage spécifique et de retirer les câbles, il suffit d'envisager le scénario de « Violation de l'intégrité du réseau local ».
En règle générale, les situations d’urgence les plus typiques appartiennent aux types suivants :
- Panne de réseau
- Échec des services du système d'exploitation
- Échec de l'application
- Panne de fer
- Échec de la virtualisation
Parcourez simplement chaque type et voyez ce qui s’applique à votre service. Par exemple, le démon Nginx peut tomber et ne pas se relever, ce qui signifie des échecs du système d'exploitation. Une situation rare entraînant l’échec de votre application Web est une panne logicielle. Tout en franchissant cette étape, il est important d’établir le diagnostic du problème. Comment distinguer une interface gelée lors de la virtualisation d'un disque cis tombé et d'un accident réseau, par exemple. Il est important de retrouver rapidement les responsables et de commencer à leur tirer la queue jusqu'à ce que l'accident soit résolu.
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 de loin la norme. Par exemple:
- Que se passe-t-il si l'heure sur le nœud actif recule d'une minute par rapport aux autres nœuds du cluster ?
- Et si le temps avançait, et si d’ici 10 ans ?
- Que se passe-t-il si un nœud de cluster perd soudainement son réseau lors de la synchronisation ?
- Que se passera-t-il si deux nœuds ne partagent pas le leadership en raison d’un isolement temporaire l’un de l’autre sur le réseau ?
À ce stade, l’approche inverse est très utile. Vous prenez le membre le plus têtu de l'équipe avec une imagination malade et lui confiez la tâche d'organiser dans les plus brefs délais un sabotage qui fera tomber le service. Si c’est difficile à diagnostiquer, c’est encore mieux. Vous ne croirez pas les idées étranges et cool que proposent les ingénieurs si vous leur donnez l'idée de casser quelque chose. Et si vous leur promettez un banc d’essai pour cela, ce n’est absolument pas grave.
C'est quoi ton DRP ?!
Vous avez donc défini votre modèle de menace. Ils ont également pris en compte les riverains qui coupaient les câbles de fibre optique à la recherche de cuivre, et un radar militaire qui largue une ligne de relais radio uniquement le vendredi à 16h46. Nous devons maintenant comprendre quoi faire avec tout cela.
Votre tâche est d'écrire ces enveloppes très rouges qui seront ouvertes en cas d'urgence. Attendez-vous immédiatement à ce que lorsque (pas si !) tout se termine, seul le stagiaire le plus inexpérimenté se trouvera à proximité, dont les mains trembleront violemment à cause de l'horreur de ce qui se passe. Découvrez comment les panneaux d'urgence sont mis 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 lorsqu'une personne à proximité commence à mourir, très souvent tout le monde s'accroche, impuissant, à tout ce qu'il voit. Pour ce faire, il y a des instructions claires sur le mur avec des éléments tels que « ouvrir l’emballage de tel ou tel » et « administrer autant d’unités du médicament par voie intraveineuse ».
Difficile de réfléchir 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 plusieurs blocs simples :
- Qui avertir du début d’un accident. Ceci est important afin de paralléliser autant que possible le processus d’élimination.
- Comment diagnostiquer correctement - effectuez une trace, recherchez le nom du service d'état systemctl, etc.
- Combien de temps pouvez-vous consacrer à chaque étape ? Si vous n'avez pas le temps de le réparer manuellement dans le délai SLA, la machine virtuelle est supprimée et restaurée à partir de la sauvegarde d'hier.
- Comment s'assurer que l'accident est terminé.
N'oubliez pas que le DRP commence lorsque le service est complètement défaillant et se termine lorsque le service est restauré, même avec une efficacité réduite. La simple perte d’une réservation ne devrait pas déclencher le DRP. Vous pouvez également inscrire une tasse de thé dans le DRP. Sérieusement. Selon les statistiques, de nombreux accidents passent de désagréables à catastrophiques 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 finalement détruisant le cluster. En règle générale, 5 minutes avec 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 de données inutiles. Permettez simplement d'utiliser rapidement et facilement des hyperliens pour accéder à la section souhaitée 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, il n'y a que des instructions directes sur où et comment se connecter avec des commandes spécifiques pour copier-coller.
Comment tester correctement
Assurez-vous que tout employé responsable est en mesure de terminer tous les éléments. 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 quoi « Connectez-vous à la console de gestion des services via un proxy au niveau du compte. siège social » signifie. Chaque point doit être extrêmement simple.
Mauvais - "Allez à la virtualisation et redémarrez le nœud mort"
Correctement - "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 pour le spectacle, c'est quelque chose qui vous permettra, à vous et à vos clients, de sortir rapidement d'une situation critique. Il est préférable 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 interrompt la prestation de différentes manières et permet aux stagiaires de la rétablir selon le DRP. Tous les problèmes, ambiguïtés dans la documentation et erreurs sont enregistrés. Une fois les stagiaires formés, le DRP est étendu et simplifié dans les domaines peu clairs.
- Test sur un service réel. En fait, vous ne pourrez jamais créer une copie parfaite d’un service réel. Par conséquent, plusieurs fois par an, il est nécessaire d'éteindre systématiquement certains serveurs, de couper les connexions et de provoquer d'autres sinistres parmi la liste des menaces afin d'évaluer l'ordre de récupération. Mieux vaut une panne planifiée de 10 minutes au milieu de la nuit qu’une panne soudaine de plusieurs heures en pleine charge avec perte de données.
- Un vrai dépannage. Oui, cela fait également partie des tests. Si survient un accident qui ne figurait pas sur la liste des menaces, il est nécessaire de compléter et de finaliser le DRP sur la base des résultats de son enquête.
Points clés
- Si quelque chose peut arriver, non seulement cela arrivera, mais cela se produira dans le scénario le plus catastrophique possible.
- Assurez-vous de disposer de ressources pour le transfert de charge d’urgence.
- Assurez-vous d'avoir des sauvegardes, elles sont automatiquement créées et régulièrement vérifiées pour leur cohérence.
- Réfléchissez à des scénarios de menace typiques.
- Donnez aux ingénieurs la possibilité de proposer des options non standard pour fournir le service.
- Le DRP doit être une instruction simple et directe. Tous les diagnostics complexes sont effectués uniquement après le rétablissement du service clients. Même si à capacité de réserve.
- Fournissez les numéros de téléphone et les contacts clés dans le DRP.
- Testez régulièrement la compréhension des employés du DRP.
- Organiser les accidents planifiés sur les sites de production. Les stands ne peuvent pas tout remplacer.
Source: habr.com