Jour de match

Le 13 décembre dernier, l’équipe travaillant sur une application mobile à grand déploiement s’est réunie dans nos bureaux de Montréal pour gérer une terrible catastrophe (fictive, heureusement). Voici le scénario :

Dans 5 heures, notre client s’apprête à lancer sa plus grande campagne marketing de la décennie, rien de moins! Comble du malheur, les services d’AWS sont hors d’usage dans tout le Canada. Après avoir réalisé une EFVP d’urgence (on respecte toujours la loi 25 ), la décision est prise de migrer toute l’infrastructure vers les États-Unis.

Bien que cette mise en scène ait peu de sens, l’exercice, lui, est extrêmement pertinent. En effet, ce type de simulation est de plus en plus courant dans l’industrie. Dans le reste de cet article, nous aborderons les différents bénéfices et partagerons quelques trucs et conseils pour en tirer pleinement profit!

Bien choisir ça catastrophe

Chaque système est unique, et le scénario choisi doit être adapté à ses particularités. Un scénario trop difficile risque d’être démotivant, tandis qu’un scénario trop simple apportera peu de valeur ajoutée. Outre le niveau de maturité technologique du projet, un critère essentiel dans le choix de la catastrophe est la composition de l’équipe. En effet, si les créateurs du système ne font plus partie de l’équipe, il est souvent nécessaire d’ajuster la difficulté du scénario à la baisse.

Il est important de garder à l’esprit que l’objectif principal est de mettre en lumière les zones d’ombre du projet.

Prendre des notes

De nombreuses entreprises disposent de politiques de reprise après sinistre qui n’ont jamais été testées. Le jour de match représente une opportunité idéale pour les mettre à l’épreuve. Pendant toute la durée de l’exercice, il est essentiel de noter les irritants et les correctifs nécessaires. L’objectif de l’exercice n’est pas de résoudre tous les problèmes immédiatement, mais plutôt de les identifier, de les documenter et de les corriger par la suite.

Enfin, la prise de notes n’a de valeur que si elle mène à des actions concrètes. Il est donc crucial de planifier un post-mortem dans les jours suivants afin d’analyser, à tête reposée, les résultats de la simulation. Idéalement, des actions tangibles liées au projet et aux politiques afférentes devraient être intégrées dans le prochain sprint.

Balancer vitesse et apprentissage

Même si le scénario comporte une contrainte temporelle, il est important de tout de même accorder du temps à l’apprentissage. En effet, pour plusieurs membres de l’équipe, ce type d’exercice constitue une occasion unique de découvrir comment certaines composantes du système fonctionnent ou même de se familiariser avec des concepts moins courants dans le quotidien d’un développeur. Par exemple, lors de notre dernier exercice, un membre de l’équipe a eu l’opportunité de comprendre le processus complet de configuration des enregistrements DNS.

Un peu de modération peut s’avérer pertinente dans le cas où quelqu’un, trop compétitif, prioriserait uniquement la rapidité d’exécution. À l’inverse, ajouter une certaine pression peut être bénéfique si l’équipe ne prend pas l’exercice suffisamment au sérieux. L’un des objectifs principaux reste de tester la résilience de l’équipe en cas de situation difficile.

Conclusion

Pour un coût relativement faible, les exercices de reprise après sinistre sont un outil extrêmement précieux pour toute organisation qui valorise l’excellence opérationnelle. Ils permettent de tester la résilience de l’équipe en situation de stress, de découvrir et corriger les zones d’ombre dans le projet ainsi que dans les politiques internes, et de préserver le savoir qui, autrement, s’éroderait avec le temps. Pour ces raisons, nous avons décidé de les inclure comme option dans le plan de maintenance que nous offrons à nos clients.

Et pour ceux que cela intéresse, l’équipe a réussi à recréer l’environnement en 3 heures et 41 minutes, ce qui (sauf en cas d’une autre catastrophe cette année ) nous maintient conformes à notre SLO de 99,95 %. Ce résultat est rendu possible grâce à l’utilisation de technologies modernes telles qu’ECS/Fargate et CloudFormation, ainsi qu’à une stratégie de sauvegarde rigoureuse pour la base de données.

L’exercice n’en était pas moins très pertinent ! Nous avons identifié des fonctions Lambda mal documentées, une file SQS obsolète, ainsi que de nombreuses autres opportunités d’amélioration, qui seront mises en œuvre au cours des prochaines semaines.