Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Paris Chaos Engineering Meetup #1

697 views

Published on

La présentation présentée lors du premier Meetup français sur le Chaos Engineering le 24 novembre 2017

Published in: Technology
  • Be the first to comment

Paris Chaos Engineering Meetup #1

  1. 1. Sponsorisé par 24 novembre 2017
  2. 2. Le Chaos Engineering dans le monde
  3. 3. www.slido.com #8283
  4. 4. Programme 16h : Introduction du Meetup 16h05  Place au Chaos Engineering, une discipline émergente Christophe Rochefolle, Directeur Excellence Opérationnelle – OUI.sncf 16h20  Chaos Monkey, concept et implémentation chez OUI.sncf Benjamin Gakic, Expert Sûreté de Fonctionnement & facilitateur – OUI.sncf 16h35  Days Of Chaos, un Chaos Gameday chez OUI.sncf Benjamin Gakic, Expert Sûreté de Fonctionnement & facilitateur - OUI.sncf 16h50  ChaosToolkit, une API ouverte pour le Chaos Engineering Sylvain Hellegouarch / sylvain@chaosiq.io Suivi de 20 à 30 minutes d’échanges puis 17h30 : After-work pour continuer la discussion ©chaosiq 2017
  5. 5. Place au Chaos Engineering, une discipline émergente Christophe Rochefolle Directeur Excellence Opérationnelle – OUI.sncf
  6. 6. Si ce n’est pas cassé, ne le répare pas. Bert Lance, Nation’s Business, 1977 Si ce n’est pas encore cassé, essaye plus fort. Philosophie Chaos Engineering, 2015
  7. 7. Pourquoi une nouvelle discipline ? Désordre SIMPLE COMPLIQUÉ CHAOS COMPLEXE Procédure Meilleures pratiques Observer – Catégoriser – Répondre Expert Bonnes pratiques Observer – Analyser – Répondre Agilité, Devops & Management 3.0 Pratiques émergentes Sonder – Observer – Répondre Produit Sprint Nouvelles Pratiques Agir – Observer – Répondre Chaos Engineering Causes Effets ? Systémique Cause Effet Indus Cause Effet
  8. 8. 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
  9. 9. La Question : A quel point votre système est-il proche du précipice et peut sombrer dans le chaos ?
  10. 10. La réponse usuelle :
  11. 11. Est-ce suffisant ?
  12. 12. Expérimenter en production ?!?
  13. 13. Expérimenter pour éprouver nos systèmes Expérimenter pour apprendre
  14. 14. Expérimenter en production sur un système stable et performant
  15. 15. Designer l’expérimentation 1. Question 2. Périmètre 3. Mesure 4. Communiquer 5. Injecter 6. Analyser
  16. 16. Expérimenter en continue Automatiser l’expérience pour qu’elle se réalise en continue afin de suivre l’évolution du système
  17. 17. Belle théorie…?
  18. 18. Notre histoire commence fin 2015 …
  19. 19. Chaos Monkey, Du concept à l’implémentation Benjamin Gakic Expert Sûreté de Fonctionnement & facilitateur - OUI.sncf
  20. 20. Auto-scaling: Dimensionner son architecture aux justes besoins du moment, c’est-à-dire de pouvoir dynamiquement augmenter ou réduire le nombre d’instances nécessaires au bon fonctionnement du SI sans pénaliser les performances. Scale up : le système peine, il faut créer plus d’instances pour absorber la charge. Scale down : le système est en sous charge, il ne sert à rien de disposer de trop d’instances, on les retire pour adapter la charge. Scale initial : C’est le nombre d’instances optimal devant être disponible à tout moment. On peut tester l’implémentation avec un tir de charge
  21. 21. La vrai question n’est pas de savoir si ça va tomber mais quand ça va tomber Werner Vogels: “Everything fails all the time” Si vous savez que ça va tomber, forcément vous en tenez compte CTO @Amazon
  22. 22. Je n’ai pas d’auto scaling, je ne suis pas chez AWS, puis-je faire du chaos monkey?
  23. 23. Conserver les mêmes concepts autour du Chaos Engineering Redéfinir et adapter le Chaos Monkey à son infrastructure : • Valider la résilience des applications sur le même symptôme • Vérifier la présence d’effets inattendus
  24. 24. L’implémentation technique?...
  25. 25. Le plus important n’est pas l’implémentation en elle-même mais la manière dont on implémente
  26. 26. POC Squad inter-équipe dev & ops Développement en mode expérimental, à base de mini-hackatons Mars 2016 Mai 2017 Fin 2017 Janvier 2016 Octobre 2016 Février 2017
  27. 27. 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 Fin 2017 Janvier 2016 Octobre 2016 Février 2017
  28. 28. Grâce à la communauté nous disposons d’un bestiaire à l’image de la Simian army de Netflix Mars 2016 Mai 2017 Fin 2017 Janvier 2016 Octobre 2016 Février 2017
  29. 29. 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 Fin 2017 Janvier 2016 Octobre 2016 Février 2017
  30. 30. 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 Fin 2017 Janvier 2016 Octobre 2016 Février 2017
  31. 31. Premier Chaos Monkey en production… …et la production marche toujours Mars 2016 Mai 2017 Fin 2017 Janvier 2016 Octobre 2016 Février 2017
  32. 32. Nous prévoyons 5 applications exécutant régulièrement un chaos monkey en production Mars 2016 Mai 2017 Fin 2017 Janvier 2016 Octobre 2016 Février 2017
  33. 33. #1 : Le Chaos Monkey n’est pas un outil de test
  34. 34. #2 : Le Chaos Monkey ce n’est pas casser la prod juste pour s’amuser
  35. 35. #3 : Le Chaos Monkey n’est pas un phénomène de mode, il s’inscrit dans une démarche
  36. 36. Comme toute démarche, une action unique ne suffit pas
  37. 37. Benjamin Gakic Expert Sûreté de Fonctionnement & facilitateur - OUI.sncf Days of Chaos Chapter One Vendredi 13 Janvier 2017
  38. 38. 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
  39. 39. 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
  40. 40. Sans ops rien n’est possible! Impliquer Convaincre
  41. 41. 43 pannes 8 short listées
  42. 42. 113 joueurs 18 équipes 2 commentateurs 2 aides de camp 8 ops
  43. 43. Objectif accompli ! Détection : 87% Diagnostic : 73% Résolution : 45%
  44. 44. 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
  45. 45. Communication et marketing Cohésion intra et inter-équipes Gamification Points forts
  46. 46. Fin du premier chapitre
  47. 47. A vous d’organiser vos Days of Chaos! Partagez vos expériences sur http://days-of-chaos.com
  48. 48. C’était le début de notre histoire… … pour commencer la vôtre, et si vous utilisiez un framework pour bootstrapper ?
  49. 49. chaostoolkit Une API ouverte pour le Chaos Engineering © chaosiq 2017 - Sylvain Hellegouarch / sylvain@chaosiq.io
  50. 50. D’où partons-nous ?
  51. 51. Enfin, plutôt ça...
  52. 52. Ce à quoi nous aspirons
  53. 53. Au début on a un plan
  54. 54. Tout va bien
  55. 55. Mais après un certain temps
  56. 56. Nous ne maîtrisons pas tout.
  57. 57. Demandez à OVH
  58. 58. Ou AWS
  59. 59. Ou GitHub
  60. 60. Ou Monzo
  61. 61. Responsabilités ?
  62. 62. Que faire ?
  63. 63. Continuellement challenger le système et nos acquis
  64. 64. Puis analyser et répondre
  65. 65. Chaos Engineering with the chaostoolkit
  66. 66. Une API ouverte pour la chaos engineering
  67. 67. C’est votre expérience
  68. 68. Et votre expertise
  69. 69. Le chaostoolkit n’est pas prescriptif
  70. 70. Le chaostoolkit s’adapte à vos environnements et process
  71. 71. chaostookit en quelques mots • Open-Source (Apache v2) • Extensible (déjà Kubernetes, Gremlin, Prometheus, Kubesec…) • Plateforme agnostique • Python 3 • Workshop à Munich lundi 20/11 basé sur le chaostoolkit
  72. 72. Piloté par sa communauté
  73. 73. Une interface accessible de pilotage et d’apprentissage d’initiatives chaos engineering
  74. 74. chaostoolkit - Collecter l’information Probes => pour interroger et collecter de l’information durant l’expérience "probes": { "close": { "title": "Fetch the CPU usage for our service", "layer": "application", "type": "python", "module": "chaosprometheus.probes", "func": "query", "arguments": { "query": "process_cpu_seconds_total{job='websvc'}", "when": "2 minutes ago" } } }
  75. 75. chaostoolkit - Agir sur le système Actions => conditions de stress du système "action": { "title": "Let's max out the CPU of a node", "layer": "application", "type": "python", "module": "chaosgremlin.actions", "func": "attack", "background": true, "secrets": "gremlin", "arguments": { "command": { "type": "cpu" }, "target": { "type": "Random" } } }
  76. 76. Démo !
  77. 77. Merci pour votre attention
  78. 78. JESSE ROBBINS Ex-Amazon « Master of disaster » Fondateur et CEO de OrionLabs Ancien pompier Créateur du concept de « GameDay » Merci aux papas du Chaos Engineering YURY IZRAILEVSKY Directeur Cloud & Infrastructure NETFLIX ARIEL TSEITLIN Directeur des solutions Cloud NETFLIX Créateurs du concept de « Chaos Monkey » « For every dollar spent in failure, learn a dollar’s worth of lesson. » “Our journey to the cloud at Netflix began in August of 2008, when we experienced a major database corruption and for three days could not ship DVDs to our members. That is when we realized that we had to move away from vertically scaled single points of failure, like relational databases in our datacenter, towards highly reliable, horizontally scalable, distributed systems in the cloud.”
  79. 79. Merci à la nouvelle génération
  80. 80. Pour continuer à échanger, rejoignez-nous sur le groupe Paris Chaos Engineering Meetup http://meetu.ps/c/3BMlX/xNjMx/f Merci à pour l’accueil et l’organisation de ce premier Meetup et…
  81. 81. After-work

×