Chaos engineering sur Amazon Web Services : faire son propre GameDay.
Le virage Cloud est en train d’être pris à-bras-le-corps par les entreprises françaises. L’attrait des ressources à la demande (à l’heure, à la minute) est réel.. mais le prix à payer est organisationnel et technique.
Les Ops ainsi que les Devs doivent réapprendre de nouvelles manières de déployer et changer leurs préoccupations en termes d’infrastructure.
Ces préoccupations concernant les services AWS que l’on doit maîtriser sont :
- Le niveau de service (SLA).
- Le degré de consommation de ce service.
- La sûreté de fonctionnement du code applicatif déployé.
Et c’est là que le chaos engineering peut aider à monter en maîtrise sur ces préoccupations : en testant le niveau de service, en vérifiant l’impact applicatif et le bon fonctionnement des procédures de secours automatisés.
En tant que consultant Valeuriad, j’ai été amené à travailler sur le déploiement d’un nouveau produit sur Amazon Web Services chez Voyages-Sncf Technologies. Dans une démarche DevOps, nous nous sommes penchés sur une stratégie de test de résilience sur ce produit. Ceci nous a conduit à mettre en place un exercice inédit nommé “Month of Chaos” qui n’est autre qu’un GameDay étendu.
Pourquoi faire du chaos engineering sous forme de GameDay?
- Rassurer et entraîner votre équipe support, vos exploitants.
- Tester les processus de bout en bout de gestion d’incident de prod.
- Tester vos processus d’heures non ouvrées (en spécifiant aux équipes en heures ouvrées de réagir comme en HNO)
- Pratiquer les outils plus techniques pour l’analyse (CloudWatch par exemple) de l’incident et son suivi
- Chercher des axes d’améliorations de son processus d’incident de production, il est toujours plus facile dans un climat d’incident provoqué de prendre le temps d’y réfléchir.
Exemple de terrain de jeu
L’architecture repose sur trois AZ (Avaibility Zone), une VPC, deux couches réseau public/privé, bref une architecture classique AWS.
En termes de services nous avons en vrac : S3, DynamoDB, ElastiCache, IAM, SNS, ECS, EC2, Lambda, RDS, Route53, SES.
La mise en oeuvre du “Month of Chaos” grâce à la Gamification
Si vous avez besoin d’une piqûre de rappel sur la notion de Gamification, jetez-vous sur l’excellent épisode dédié :
La recette qui a bien fonctionné pour nous :
- Des slides qui présentent les principes, les joueurs, les règles du jeu, le terrain de jeu (le périmètre)
- Une réunion en amont pour trouver des pannes
- Répertorier les pannes dans une page wiki cachée, uniquement accessible au game master.
- Une page google formulaire à remplir par le joueur à la fin de chaque panne. Afin de récolter son feedback et mesurer son niveau de confiance.
Les principes, c’est ce dont nous avons parlé plus haut, à détailler pour votre entreprise et vos processus.
Les joueurs sont les personnes qui sont d’astreintes en général, mais c’est ouvert à n’importe qui. Une personne ne se sentant pas à l’aise techniquement dans l’architecture de votre projet est un très bon candidat à ce jeu !
Les règles de jeu que nous avions défini :
- Le jeu dure 1 mois.
- Une panne peut survenir de 9h30 à 17h.
- Les zones impactées peuvent dépasser le compte amazon de production (usine logicielle externe, réseau, proxy)
- Le calendrier d’astreinte doit être prêt et défini pour tous les joueurs
- Une panne n’est considérée détectée que si les personnes en début de chaîne l’ont bien détectée et transmise au reste de la chaîne.
- Si une personne du support de niveau 1 est en difficulté, elle peut appeler un autre joueur (notion de back-up).
- Se mettre en condition de HNO : Utiliser le matériel fourni pour l’astreinte (téléphone 4g en partage + ordinateur portable) et interdiction de contacter une autre personne que le back-up.
Trouver les pannes, voila la phase un peu tricky de la recette! Une panne trop facile à trouver laissera indifférent le joueur tandis qu’une panne trop complexe laissera un goût amer..
Par contre un joueur qui a déjà joué et qui ne jouera plus, peut aider à trouver des pannes avec le Game Master.
Les pannes qui ont bien fonctionné
- Stop d’une ou plusieurs instance(s) EC2 via la console
- Stop de toutes les instances EC2 d’une AZ
- Stop d’un service ECS en mettant le nombre de tâches à tourner à 0
- Delete d’un cluster ECS (/!\ si vous avez de quoi le remonter rapidement)
- Mettre une connexion lente sur votre proxy (assez facile via squid)
- Couper un flux sortant par le proxy (/etc/hosts du proxy, mettre une adresse erronée pour un host donné, un partenaire par exemple)
- Si vous avez une authentification, mettre un espace dans le nom et déclencher une erreur 403. Resté têtu et déclencher tout le processus de support en se trompant systématiquement lors des re-tentatives.
- Suppression d’items DynamoDB
- Couper l’accès à la base RDS via IAM
- Supprimer un fichier sur S3
Quelques chiffres et le retour d’expérience des joueurs
Pour présenter le REX, nous avons utilisé RealtimeBoard, le schéma d’architecture et la chaîne du processus d’incident de prod a été reporté pour identifier sous forme de post-it numériques les points améliorés durant le GameDay et à améliorer ensuite.
Un autre axe de réflexion pendant ce REX avec les joueurs fût de placer des faits marquants du GameDay au sein du diagramme suivant :
Au total, cela a été une vingtaine de pannes jouées, à peu près 2 par joueur durant 1 mois. Toutes les pannes ont été résolues par les joueurs avec des fois l’appel à un ami.
Le niveau de confiance par panne a été relevé dans les formulaires google et redemandé de manière plus générale sous forme de nuage de points aux joueurs durant le REX.
Le niveau de confiance a augmenté. Les joueurs ont bien aimés et en redemande avec — pourquoi pas — des choses plus difficiles.
Et les autres formes de Chaos engineering?
Si vous voulez faire du chaos engineering mais d’une manière plus libre et/ou plus automatisée, vous pouvez vous référer à mon autre article https://medium.com/@lesvoixdelaveille/chaos-engineering-sur-aws-automatiser-ses-pannes-b844557da2a9
Remerciements
Merci aux Days Of Chaos implémentés au sein de Voyages-Sncf Technologies dont nous nous sommes inspirés, mis en place par Benjamin Gakic.
Des liens qui peuvent vous intéresser
Ecrit par Antoine Choimet, Ingénieur DevOps à Valeuriad et Cyrille Caillaud, Scrummaster Voyages-Sncf Technologies
