@crochefolle
Directeur Excellence Opérationnelle @ OUI.sncf
Christophe ROCHEFOLLE
@BenjaminGakic
Chaos Engineer & SRE @ OUI.sncf
Benjamin GAKIC
Noël 2013
Wii U et 3DS sous le
sapin…
Juin 2017
Incident général…
Novembre
2008
30h
d’indisponibilité
Pour la première fois, les indisponibilités
arrivent en tête des sujets d’inquiétude
des responsables informatiques,
devançant ainsi la sécurité.
Sondage réalisé sur un échantillon de 400 entreprises en Grande-Bretagne,
Allemagne, France, Suède et Pays-Bas par Quocirca pour Splunk
Source: Master of Machines III - Réduire l’impact des incidents IT Quocirca
Et pourtant on teste à tous les étages !!
Sécurité, charge,
métier
Interface graphique,
bout en bout,
fonctionnels
Intégrations, API
Unitaires
« Comment tester dans un
environnement comme celui d’Amazon ?
Devez-vous construire un autre Amazon
pour les tests quelque part, qui aurait le
même nombre de machines, le même
nombre de centres de calcul, de clients
et les mêmes tables et fichiers ? »
Werner Vogels, CTO Amazon
Et ça se complexifie …
 DevOps,
 Cloud, scalabilité
 BigData, Smartdata,
 IA,
 Ordinateur quantique
CHAOS ENGINEERING
« Discipline de l'expérimentation sur un système distribué afin de
renforcer la confiance dans la capacité du système à résister à des
conditions turbulentes en production. »
http://principlesofchaos.org/
initiée par
La Question :
A quel point votre système
est-il proche du précipice
et peut sombrer
dans le chaos ?
Expérimenter en
production ?!?
Expérimenter
pour éprouver nos systèmes
Expérimenter
pour apprendre
Expérimenter
en production
sur un système stable et performant
Designer
l’expérimentation
1. Question
2. Périmètre
3. Mesure
4. Communiquer
5. Injecter
6. Analyser
Expérimenter
en continue
Automatiser l’expérience
pour qu’elle se réalise en continue
afin de suivre l’évolution du système
Chaos Engineering (rappel)
https://medium.com/russmiles/chaos-engineering-for-the-business-17b723f26361
Et concrètement ?
POC
Squad inter-équipe dev & ops
Développement en mode expérimental,
à base de mini-hackatons
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Mode de fonctionnement adopté!
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Communauté
Résilience et Tests Techniques
Objectifs :
• Proposer des outils de test de résilience
• Aider à la mise en place des outils et patterns
• Apporter un changement culturel
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Grâce à la communauté
nous disposons d’un bestiaire
à l’image de la Simian army
de Netflix
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Days of Chaos
Chapter One
Vendredi 13 Janvier 2017
Initiation au test en production,
La panne va-t-elle avoir un impact notable?
Pilotage et validation pour les devs Entrainement pour les ops
Chaos Monkey
Bridé
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Chaos Monkey en production,
La finalité
Mon appli en prod
Chaos Monkey
Libéré! Délivré!
LES DEV OPS
Même pas peur
Objectif :
Aucun impact financier
Même pas mal!
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Premier Chaos Monkey en production…
…et la production marche toujours
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Days of Chaos
Chapter 2
Vendredi 07/07/2017
Objectif : faire du chaos engineering sur toutes
les applications critiques
Mars 2016
Mai 2017
Aujourd’hui
Janvier 2016
Octobre 2016
Février 2017
Janvier 2017
Juillet 2017
Game Day
Days of Chaos
Chapter One
Vendredi 13 Janvier 2017
DaysofChaos
Vous allez subir des vagues de pannes en provenance des tréfonds de l’exploitation.
Votre mission est de repousser ces vagues et de
détecter, diagnostiquer et résoudre
les pannes le plus vite possible.
L’avenir de notre production dépend de vous…
Détection :
+100
Diagnostic :
+150
Résolution :
+200
Bonus 1ère proposition:
+100
Indice :
-50
Nombrederounds: 8
Récompenses:
3
Résolution Dev
Incident Ops
Détection Dev Diagnostic Dev
Remise en état...
Validation Ops
Gestion d’une panne Question bonus Vidéo explicative1 2 3
Sans ops rien n’est
possible!
Impliquer
Convaincre
43 pannes
8 short listées
113 joueurs
18 équipes 2 commentateurs
2 aides de camp
8 ops
Objectif accompli !
Détection : 87%
Diagnostic : 73%
Résolution : 45%
Supervision et alerting
Tests techniques
Partage des connaissances
Arbres d’analyse
8 -> 6 pannes
4h -> 3h30 de jeu
80% Intérêt du jeu
70% Qualité de l’organisation
74% Prise de conscience
• Disponibilité
• Préparation des pannes
• Trop peu pour gérer autant de joueurs
• Quelques ratés organisationnels
• Ambiance
• Nouveauté
• Intérêt
• Jeu bien calibré pour une première
Communication et marketing
Cohésion intra et inter-équipes
Gamification
Points forts
Days of Chaos
Chapter 1
Days of Chaos
Chapter 2
CHAPTER 3Vendredi 13/01/2017
Vendredi
07/07/2017
VENDREDI 13/07/2018
En production
La vraie vie, avec des vrais utilisateurs et
potentiellement de la perte de VA.
Communication
Mettre en place du Chaos n’est pas la meilleure
façon de rencontrer vos nouveaux collègues,
mais c’est la plus rapide.
Nora Jones (@nora_js)
Gamification
Rendre l’apprentissage plus amusant
en s’appuyant sur la prédisposition
humaine au jeu
Expérimentation
Les principaux points à retenir
Validation de ce qui est important sur
votre infrastructure. Votre résilience
n’est pas celle des autres.
Le Chaos Engineering dans le monde
https://days-of-chaos.slack.com
Paris Chaos Engineering Meetup
http://meetu.ps/c/3BMlX/xNjMx/f https://chaosengineering.slack.com
http://days-of-chaos.com/
https://medium.com/paris-
chaos-engineering-
community

Paris Chaos Engineering Meetup #5

  • 1.
    @crochefolle Directeur Excellence Opérationnelle@ OUI.sncf Christophe ROCHEFOLLE @BenjaminGakic Chaos Engineer & SRE @ OUI.sncf Benjamin GAKIC
  • 3.
    Noël 2013 Wii Uet 3DS sous le sapin… Juin 2017 Incident général… Novembre 2008 30h d’indisponibilité
  • 4.
    Pour la premièrefois, les indisponibilités arrivent en tête des sujets d’inquiétude des responsables informatiques, devançant ainsi la sécurité. Sondage réalisé sur un échantillon de 400 entreprises en Grande-Bretagne, Allemagne, France, Suède et Pays-Bas par Quocirca pour Splunk Source: Master of Machines III - Réduire l’impact des incidents IT Quocirca
  • 5.
    Et pourtant onteste à tous les étages !! Sécurité, charge, métier Interface graphique, bout en bout, fonctionnels Intégrations, API Unitaires
  • 6.
    « Comment testerdans un environnement comme celui d’Amazon ? Devez-vous construire un autre Amazon pour les tests quelque part, qui aurait le même nombre de machines, le même nombre de centres de calcul, de clients et les mêmes tables et fichiers ? » Werner Vogels, CTO Amazon
  • 7.
    Et ça secomplexifie …  DevOps,  Cloud, scalabilité  BigData, Smartdata,  IA,  Ordinateur quantique
  • 8.
    CHAOS ENGINEERING « Disciplinede l'expérimentation sur un système distribué afin de renforcer la confiance dans la capacité du système à résister à des conditions turbulentes en production. » http://principlesofchaos.org/ initiée par
  • 9.
    La Question : Aquel point votre système est-il proche du précipice et peut sombrer dans le chaos ?
  • 10.
  • 11.
    Expérimenter pour éprouver nossystèmes Expérimenter pour apprendre
  • 12.
    Expérimenter en production sur unsystème stable et performant
  • 13.
    Designer l’expérimentation 1. Question 2. Périmètre 3.Mesure 4. Communiquer 5. Injecter 6. Analyser
  • 14.
    Expérimenter en continue Automatiser l’expérience pourqu’elle se réalise en continue afin de suivre l’évolution du système
  • 15.
  • 16.
    POC Squad inter-équipe dev& ops Développement en mode expérimental, à base de mini-hackatons Mars 2016 Mai 2017 Aujourd’hui Janvier 2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017
  • 17.
    Mode de fonctionnementadopté! Mars 2016 Mai 2017 Aujourd’hui Janvier 2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017
  • 18.
    Communauté Résilience et TestsTechniques Objectifs : • Proposer des outils de test de résilience • Aider à la mise en place des outils et patterns • Apporter un changement culturel Mars 2016 Mai 2017 Aujourd’hui Janvier 2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017
  • 19.
    Grâce à lacommunauté nous disposons d’un bestiaire à l’image de la Simian army de Netflix Mars 2016 Mai 2017 Aujourd’hui Janvier 2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017
  • 20.
    Mars 2016 Mai 2017 Aujourd’hui Janvier2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017 Days of Chaos Chapter One Vendredi 13 Janvier 2017
  • 21.
    Initiation au testen production, La panne va-t-elle avoir un impact notable? Pilotage et validation pour les devs Entrainement pour les ops Chaos Monkey Bridé Mars 2016 Mai 2017 Aujourd’hui Janvier 2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017
  • 22.
    Chaos Monkey enproduction, La finalité Mon appli en prod Chaos Monkey Libéré! Délivré! LES DEV OPS Même pas peur Objectif : Aucun impact financier Même pas mal! Mars 2016 Mai 2017 Aujourd’hui Janvier 2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017
  • 23.
    Premier Chaos Monkeyen production… …et la production marche toujours Mars 2016 Mai 2017 Aujourd’hui Janvier 2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017
  • 24.
    Mars 2016 Mai 2017 Aujourd’hui Janvier2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017 Days of Chaos Chapter 2 Vendredi 07/07/2017
  • 25.
    Objectif : fairedu chaos engineering sur toutes les applications critiques Mars 2016 Mai 2017 Aujourd’hui Janvier 2016 Octobre 2016 Février 2017 Janvier 2017 Juillet 2017
  • 26.
  • 27.
    Days of Chaos ChapterOne Vendredi 13 Janvier 2017
  • 28.
    DaysofChaos Vous allez subirdes vagues de pannes en provenance des tréfonds de l’exploitation. Votre mission est de repousser ces vagues et de détecter, diagnostiquer et résoudre les pannes le plus vite possible. L’avenir de notre production dépend de vous… Détection : +100 Diagnostic : +150 Résolution : +200 Bonus 1ère proposition: +100 Indice : -50 Nombrederounds: 8 Récompenses: 3
  • 29.
    Résolution Dev Incident Ops DétectionDev Diagnostic Dev Remise en état... Validation Ops Gestion d’une panne Question bonus Vidéo explicative1 2 3
  • 30.
    Sans ops rienn’est possible! Impliquer Convaincre
  • 32.
  • 35.
    113 joueurs 18 équipes2 commentateurs 2 aides de camp 8 ops
  • 36.
    Objectif accompli ! Détection: 87% Diagnostic : 73% Résolution : 45%
  • 37.
    Supervision et alerting Teststechniques Partage des connaissances Arbres d’analyse 8 -> 6 pannes 4h -> 3h30 de jeu 80% Intérêt du jeu 70% Qualité de l’organisation 74% Prise de conscience • Disponibilité • Préparation des pannes • Trop peu pour gérer autant de joueurs • Quelques ratés organisationnels • Ambiance • Nouveauté • Intérêt • Jeu bien calibré pour une première
  • 38.
    Communication et marketing Cohésionintra et inter-équipes Gamification Points forts
  • 39.
    Days of Chaos Chapter1 Days of Chaos Chapter 2 CHAPTER 3Vendredi 13/01/2017 Vendredi 07/07/2017 VENDREDI 13/07/2018
  • 41.
    En production La vraievie, avec des vrais utilisateurs et potentiellement de la perte de VA. Communication Mettre en place du Chaos n’est pas la meilleure façon de rencontrer vos nouveaux collègues, mais c’est la plus rapide. Nora Jones (@nora_js) Gamification Rendre l’apprentissage plus amusant en s’appuyant sur la prédisposition humaine au jeu Expérimentation Les principaux points à retenir Validation de ce qui est important sur votre infrastructure. Votre résilience n’est pas celle des autres.
  • 42.
    Le Chaos Engineeringdans le monde
  • 43.
    https://days-of-chaos.slack.com Paris Chaos EngineeringMeetup http://meetu.ps/c/3BMlX/xNjMx/f https://chaosengineering.slack.com http://days-of-chaos.com/ https://medium.com/paris- chaos-engineering- community

Notes de l'éditeur

  • #3 De l’importance de tester nos backups et nos scénarios de reprises : Rm * Heureusement, la conceptrice principale venait d’accoucher et avec une synchro à la maison …
  • #5 Les organisations européennes connaissent en moyenne 3 incidents IT par mois. 2/3 (65%) des organisations européennes rapportent qu’un incident IT a déjà eu des conséquences sur leur réputation, engendrant des répercutions financières (115 k€).
  • #14 Définir qu’elle est l’hypothèse que l’on veut expérimenter : souhaite-t-on tester la résilience d’un composant, d’une application, d’une organisation ? Définir le périmètre de l’expérience : est-ce tout ou partie de la production ? est-ce uniquement l’environnement technique seul ou inclure également les interventions humaines (surveillance, exploitation, support), Identifier précisément les métriques qui permettront de valider l’expérience et éventuellement de l’arrêter instantanément en cas d’impact critique, Prévenir l’organisation de l’existence de l’expérimentation – pour éviter l’escalade en cas d’incident critique Réaliser l’expérience Analyser les résultats, mettre en place les éventuels plans d’action nécessaires Elargir le scope pour la prochaine expérience. Automatiser l’expérience pour qu’elle se réalise en continue afin de suivre l’évolution du système.
  • #29 On veut de la séduction? Préparons notre jeu comme un jeu vidéo avec une vrai jaquette!
  • #31 Ops ont les droits et connaissent un rayon sur les pannes! Subir ma vie d’exploitant Transformer la relation avec les devs Sortir de la routine
  • #32 Rappel objectif : Sdf Devops (faire une sorte de mini subit ma vie) Marquer les esprits Pannes Système! Celles que vivent les ops. Ceci aura été l’hameçonnage pour les ops. Faites subir aux devs ce que vous vivez!
  • #33 Rappel objectif : Sdf Devops (faire une sorte de mini subit ma vie) Marquer les esprits Pannes Système! Celles que vivent les ops. Ceci aura été l’hameçonnage pour les ops. Faites subir aux devs ce que vous vivez!
  • #34 Besoin d’implication forte de la partie ops. Présentation comme un jeu mais aussi comme une opportunité de faire un « vie ma vie d’exploitant ». Permettre de sensibiliser les équipes au travail fait et aux pannes les plus fréquentes ou au besoin de bien communiquer et développer les applications. 2 ateliers de création des pannes : 20 exploitants mobilisés en 2 sessions d’une heure. 40 pannes proposées. 15 short listées pour leur pertinence. 8 sélectionnées par facilité de mise en oeuvre et possibilité de résolution par les équipes de dev (il faut rester pragmatique). Désignation d’une équipe de choc pour gérer le scripting et la réalisation des pannes
  • #35 Phase de com’ – Opération séduction Des affiches de teasing créant une rupture avec toutes les autres opérations de com’ réalisées jusqu’à présent. Le thème principal : le jeu de guerre en reprenant comme support culturel « Ender’s Game (la strategie Ender) » de Scott Orson card. Des affiches posées avec très peu d’information, juste un « engagez-vous ». Un ajout à un moment donné d’une adresse vers un site interne réalisé pour l’événement avec sa propre charte graphique et son formulaire d’engagement. Une com’ réglementaire par mail venant compléter le tout et enfonçant le clou.
  • #36 Phase de jeu – Le jour J Début à 9h 4 + 8 + 5 personnes dédiées au déroulement. Deux commentateurs maitres de cérémonie (un à Paris, un à Nantes), une aide ops, une chargée de classement et de décompte de points, 8 ops à 150%, 2 com’ interne, 3 services généraux. Une conf Skype avec deux commentateurs donnant des informations sur le déroulement et les avancées du jeu Une room hipchat pour les communications officielles et les réponses Une conf Skype dediée ops 7 pannes déroulées dont une a râté. Une dernière annulée suite à un incident sur la preprod. Fin à 12h30 Remise des prix à 14h. Plus de 200 spectateurs
  • #38 War room côté ops pour éviter une conf dédiée parallèle + effet je suis dédié à l’événement. Possibilité pour les ops de participer à la conf gobale Prévoir plus d’ops pour faciliter le traitement des demandes des équipes. Descendre de 4h à 3h d’événement. Pousser peu plus loin les répétitions et les préparations des pannes. Planifier la fin des inscriptions plus tôt. Laisser un délais de un mois entre la fin des inscriptions et l’événement.
  • #39 Un sujet difficile, peu motivant rendu plus accessible par la gamification