Préparer un DRP — n'oubliez pas de prendre en compte les météorites

Même en temps de catastrophe, il y a toujours du temps pour une tasse de thé.

DRP (plan de récupération après sinistre) est quelque chose dont on espère idéalement ne jamais avoir besoin. Mais si, par hasard, des castors migrateurs rongent une fibre optique principale ou qu'un junior admin fait tomber une base de données en production, vous voulez être sûr d'avoir un plan d'action préalable pour gérer tout ce désordre.

Pendant que les clients, paniqués, commencent à inonder le support technique d'appels, le junior cherche des cyanures, vous, avec un air sage, ouvrez l'enveloppe rouge et commencez à remédier à la situation.

Dans ce post, je souhaite partager des recommandations sur la manière d'écrire un DRP et ce qu'il devrait contenir. Nous aborderons également les sujets suivants :

1. Apprenons à penser comme un méchant.
2. Analysons l'importance d'une tasse de thé pendant l'apocalypse.
3. Réfléchissons à une structure conviviale pour le DRP.
4. Voyons comment le tester correctement.

Pour quelles entreprises cela peut-il être utile.

Il est très difficile de tracer une ligne lorsque le département IT commence à avoir besoin de ce type de choses. Je dirais que vous avez certainement besoin d'un DRP si :

• L'arrêt d'un serveur, d'une application ou la perte d'une base provoquera des pertes commerciales significatives dans l'ensemble.
• Vous avez un service IT complet. Autrement dit, un département qui fonctionne comme une véritable unité au sein de l'entreprise, avec son propre budget, et non simplement quelques employés fatigués qui s'occupent du réseau, nettoient les virus et remplissent les imprimantes.
• Vous disposez d'un budget réel, ne serait-ce que pour une partie de la sauvegarde en cas d'urgence.

Lorsque le département IT demande pendant des mois quelques disques durs pour un ancien serveur pour des sauvegardes, il est peu probable que vous puissiez organiser un véritable transfert du service en panne vers des capacités de secours. Mais là encore, la documentation ne sera pas de trop.

La documentation est essentielle.

Commencez par la documentation. Supposons que votre service fonctionne sur un script Perl, écrit il y a trois générations d'administrateurs, et qu'aucun ne sait comment il fonctionne. La dette technique accumulée et l'absence de documentation vous blesseront inévitablement, non seulement au genou, mais aussi à d'autres membres, c'est une question de temps.

Une fois que vous avez une bonne description des composants du service, examinez les statistiques des pannes. Il y a de fortes chances qu'elles soient typiques. Par exemple, de temps en temps, un disque peut être saturé, entraînant une défaillance du nœud jusqu'à son nettoyage manuel. Ou le service client devient inaccessible parce que quelqu'un a encore oublié de renouveler le certificat, et ne sait pas ou ne veut pas configurer Let's Encrypt.

Pensez comme un saboteur

La partie la plus difficile réside dans la prévision des pannes qui ne se sont jamais produites, mais qui pourraient potentiellement faire tomber complètement votre service. C'est ici que nous jouons généralement à des méchants avec mes 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 cette même salle, vous avez enfermé les ingénieurs qui ont mis en place le service ciblé ou qui y travaillent régulièrement. Ensuite, soit au tableau, soit sur papier, commencez à dessiner tous les horreurs possibles qui pourraient survenir avec votre service. Il n'est pas nécessaire de détailler jusqu'à la femme de ménage spécifique et à tirer sur les câbles, il suffit d'examiner le scénario "Violation de l'intégrité du réseau local".

En général, la plupart des situations d'urgence typiques se regroupent dans les catégories suivantes :

• Défaillance réseau
• Défaillance des services du système d'exploitation
• Défaillance de l'application
• Défaillance matérielle
• Défaillance de la virtualisation

Il suffit de passer en revue chaque type et de voir ce qui s'applique à votre service. Par exemple, le démon Nginx peut tomber et ne pas se relever — cela relève des défaillances du système d'exploitation. Une situation rare qui met votre application web hors service — c'est une défaillance logicielle. Lors de l'examen de cette étape, il est important de se concentrer sur le diagnostic du problème. Comment distinguer une interface figée en virtualisation d'un switch tombé en panne et d'une défaillance réseau, par exemple. C'est crucial pour trouver rapidement les responsables et commencer à les tirer par la manche, tant que la panne n'est pas résolue.

Une fois que les problèmes typiques sont notés, nous versons encore du café et commençons à envisager les scénarios les plus étranges, lorsque certains paramètres commencent à dépasser considérablement les normes. Par exemple :

• Que se passerait-il si l'heure sur un nœud actif reculait d'une minute par rapport aux autres dans le cluster ?
• Et si l'heure avançait, que se passerait-il si elle avançait de 10 ans ?
• Que se passerait-il si, pendant la synchronisation, le nœud du cluster perdait soudainement le réseau ?
• Que se passe-t-il si deux nœuds ne parviennent pas à se partager le leadership à cause d'une isolation temporaire l'un de l'autre sur le réseau ?

À ce stade, une approche inverse s'avère très utile. Prenez le membre d'équipe le plus obstiné avec une imagination débordante et confiez-lui la tâche urgente de provoquer une diversion qui mettrait le service hors service. Plus il sera difficile de la diagnostiquer, mieux ce sera. Vous ne croirez pas à quels concepts étranges et innovants les ingénieurs peuvent penser lorsqu'on leur donne l'idée de briser quelque chose. Et si vous leur promettez un environnement de test pour cela, c'est encore mieux.

C'est quoi ce DRP ?!

Vous avez donc identifié le modèle de menace. Vous avez pris en compte les habitants locaux qui coupent les câbles en fibre optique à la recherche de cuivre, ainsi qu'un radar militaire qui interrompt la ligne en relais strictement le vendredi à 16h46. Il est maintenant temps de comprendre quoi faire avec tout cela.

Votre tâche est d'écrire ces fameuses enveloppes rouges qui seront ouvertes en situation d'urgence. Prévoyez dès le départ que lorsque (pas si !) tout s'effondrera, le seul à être présent sera le stagiaire le moins expérimenté, qui tremblera de peur face à la situation. Regardez comment sont mises en œuvre les instructions d'urgence dans les cabinets médicaux. Par exemple, que faire en cas de choc anaphylactique. Le personnel médical connaît sur le bout des doigts tous les protocoles, mais lorsqu'une personne commence à mourir à proximité, il arrive souvent que chacun se précipite pour attraper n'importe quoi. C'est pourquoi il y a sur le mur des instructions claires sous forme de points tels que « ouvrir l'emballage de tel produit » et « administrer par voie intraveineuse autant d'unités du médicament ».

En situation d'urgence, il est difficile de réfléchir ! Il doit y avoir des instructions simples à comprendre instinctivement.

Un bon DRP se compose de plusieurs blocs simples :

1. Qui alerter en cas d'urgence. C'est important pour paralléliser au maximum le processus d'élimination.
2. Comment diagnostiquer correctement - nous effectuons le tracé, vérifions avec systemctl status nomduservice, et ainsi de suite.
3. Combien de temps peut-on consacrer à chaque étape. Si vous ne parvenez pas à réparer manuellement dans le temps imparti par le SLA, la machine virtuelle est détruite et restaurée à partir de la sauvegarde d'hier.
4. Comment s'assurer que l'urgence est terminée.

N'oubliez pas que le DRP commence lorsque le service a complètement échoué et se termine lorsqu'il est restauré, même avec une efficacité réduite. Une simple perte de réservation ne devrait pas déclencher le DRP. Et vous pouvez même inscrire dans le DRP une tasse de thé. Sérieusement. Selon les statistiques, de nombreux incidents désagréables deviennent catastrophiques parce que le personnel, dans la panique, s'empresse de réparer quelque chose, risquant ainsi de tuer la seule nœud active contenant des données ou d'achever le cluster. En général, prendre 5 minutes pour une tasse de thé vous donnera un peu de temps pour vous calmer et analyser la situation.

Ne confondez pas le DRP et le passeport système ! Ne le surchargez pas de données inutiles. Permettez simplement un accès rapide et facile via des hyperliens vers la section pertinente de la documentation pour lire en détail sur les parties nécessaires de l'architecture du service. Dans le DRP, seules des instructions claires devraient indiquer où et comment se connecter, avec des commandes spécifiques à copier-coller.

Comment bien tester

Assurez-vous que tout employé responsable est capable de réaliser toutes les étapes. Au moment le plus critique, il se peut que l'ingénieur n'ait pas les droits d'accès au système nécessaire, qu'il n'ait pas les mots de passe requis ou qu'il n'ait aucune idée de ce que signifie « Connectez-vous à la console de gestion du service via un proxy au siège social ». Chaque étape doit être d'une simplicité absolue.

Incorrect — « Allez sur la virtualisation et redémarrez le nœud mort »
C'est vrai — « Connectez-vous via l'interface web à virt.example.com, dans la section des nœuds, redémarrez le nœud qui provoque l'erreur ».

Évitez les ambiguïtés. N'oubliez pas le stagiaire effrayé.

Testez absolument le DRP. Ce n'est pas simplement un plan pour faire beau — c'est ce qui permettra à vous et à vos clients de sortir rapidement d'une situation critique. Il est optimal de le faire plusieurs fois :

• Un expert et plusieurs stagiaires travaillent sur un banc d'essai qui imite au mieux le service réel. L'expert brise le service de différentes manières et permet aux stagiaires de le restaurer conformément au DRP. Tous les problèmes, ambiguïtés dans la documentation et erreurs sont notés. Après la formation des stagiaires, le DRP est complété et simplifié aux endroits peu clairs.
• Tests sur un véritable service. En réalité, il est impossible de créer une copie parfaite d'un service réel. C'est pourquoi, une ou deux fois par an, il est nécessaire de couper planifiquement une partie des serveurs, de rompre les connexions et de provoquer d'autres types d'incidents figurant sur la liste des menaces, afin d'évaluer l'ordre de récupération. Une panne planifiée de 10 minutes au milieu de la nuit est préférable à un arrêt inattendu de plusieurs heures en période de forte charge avec perte de données.
• Gestion réelle des incidents. Oui, c'est aussi une partie des tests. Si un incident survient, qui ne figure pas sur la liste des menaces, il est nécessaire de compléter et d'affiner le DRP (Plan de Reprise d'Activité) sur la base des résultats de son enquête.

Points clés

1. Si quelque chose peut mal tourner, cela ne manquera pas d'arriver, et ce, selon le scénario le plus catastrophique.
2. Assurez-vous d'avoir les ressources nécessaires pour le basculement d'urgence.
3. Assurez-vous d'avoir des sauvegardes, qu'elles soient créées automatiquement et vérifiées régulièrement pour leur cohérence.
4. Réfléchissez aux scénarios typiques de menaces.
5. Permettez aux ingénieurs de trouver des variantes atypiques pour arrêter le service.
6. Le DRP doit être une instruction simple et directe. Toute la diagnostique complexe ne doit intervenir qu'après la restauration du service pour les clients. Même si c'est sur des capacités de secours.
7. Indiquez les numéros de téléphone et contacts clés dans le DRP.
8. Testez régulièrement les employés sur leur compréhension du DRP.
9. Organisez des pannes planifiées en production. Les environnements de test ne peuvent pas tout remplacer.

Source : habr.com