Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Sponsorisé par
13 novembre 2018
Retour sur
Retour sur la Chaos Conf – 28 septembre 2018
1. Ce qu’on a retenu
2. Taxonomie des pannes
3. Observabilité
4. Influence
1. Ce qu’on a retenu
« Nous ne devons plus gérer uniquement nos pannes, mais également celle des systèmes dont nous
dépendons.
Les tests au niv...
« Vous ne pouvez pas faire des lois pour interdire les
pannes, mais vous pouvez vous concentrer sur une
détection et une r...
« Raconter la bonne histoire à chaque partie prenante pour les
embarquer. »
Christophe Rochefolle,
Directeur Excellence Op...
« Fail fast, fail often»
Vilas Veeraraghavan,
Directeur Engineering, Walmart Labs
« Les catastrophes sont causées par des pannes en cascade. Les postmortem
qui ne se concentrent que sur les “root cause” n...
« Plus vous êtes orientés services, plus le réseau est central dans votre système.
La mauvaise nouvelle : les réseaux sont...
«Le nombre de résultats de recherche Google pour “pourquoi les
systèmes distribués sont si difficiles ?” ne fait que croît...
«Les systèmes distribués ont une liste quasi infinie de scenarios d’échec qui rendent
pratiquement inutiles les environnem...
Démonstration de la plateforme Gremlin
Keynote de clôture
de la journée
2. Taxonomie des pannes
Adrian Cockcroft
@adrianco
AWS VP Cloud Architecture Strategy
La solidité d'une chaîne n'excède pa...
Taxonomie
des pannes
Un langage commun, une
terminologie, et des définitions
aident à limiter les problèmes de
communicati...
Taxonomie
Infrastructure
Software stack
Application
Exploitation
Taxonomie
des pannes
Différentes
couches
d’impacts
Taxonomie
Infrastructure
Taxonomie
des pannes
Pannes
Pannes Matérielles
Disques, alimentations, câbles & fibres, cartes mè...
Taxonomie
Taxonomie
des pannes
Pannes
Software stack
Bombes temporelles
Compteur et temps machines, fuite mémoire
Bombes d...
Taxonomie
Taxonomie
des pannes
Pannes
Software stack
Expiration
Fin de vie de Certificats
Révocation
Fin de License ou com...
Taxonomie
Taxonomie
des pannes
Pannes
Software stack
Bugs Langage
Compilateur, interpréteur
Bugs Runtime
JVM, Docker, Linu...
Application
Taxonomie
Taxonomie
des pannes
Pannes
Bombes temporelles (dans le code)
Compteur et temps machines, fuite mémo...
Taxonomie
Taxonomie
des pannes
La description d’un film Netflix pour un
titre espagnol contenait une cédille —
Ç—encodée <...
Taxonomie
Taxonomie
des pannes
Configuration
Mauvaise configuration ou mauvaise syntaxe
Versioning
Problème de compatibili...
Taxonomie
Taxonomie
des pannes
Pannes en cascades
Bugs de gestion d’erreurs
Surcharge en cascade
Logging excessif, lock co...
Taxonomie
Taxonomie
des pannes
Gestion d’incidents inadéquate
Retard à la declaration d’incident
Dashboards de monitoring ...
Taxonomie
des pannesQu’en pensez-vous ?
3/ Observabilité
Charity Major
@mipsytipsy
CEO at honeycomb
Signe particulier : aime les poney, les arcs-en-ciel,
les gros...
Nous sommes tous d’accord pour dire que le
Chaos engineering est un terme marketing
pour justifier les tests tardifs dans ...
La complexité explose partout mais nos outils
restent conçus pour un monde prévisible
Que ce soit pour le monitoring ou pour les
tests
L’observabilité n’est pas une nouvelle
définition du monitoring
Monitoring != Observabilité
Monitoring VS Observabilité
Monitoring
Action d’observer et de vérifier les
comportements et les outputs d’un système
et de ses composants dans le tem...
Observabilité
Observabilité
Un système est dit observable quand on peut
déduire son état des symptômes et des
informations qu’il émet.
A...
Une question de point de vue
• Le monitoring permet de répondre à une question que l’on connait à
l’avance. Il s’agit de c...
Les commandements de l’observabilité
Les logs ne sont qu’un mécanisme de
transport pour les événements
Observability
Low
Medium
High
Microservice that does one thing
Function with no side effects
Monolith with logging
Monolit...
Et le Chaos Engineering dans tout ça?
Le Chaos Engineering permet de valider votre monitoring et votre
capacité d’observab...
La production reste le seul vrai
environnement
Pour en savoir plus
https://www.d2si.io/ebook-observability/
4. Stratégie d’influence
Comment convaincre votre CODIR
de se lancer dans le Chaos Engineering ?
« On va tout casser en
production, ça va être fun ! »
Méthode dite des « gros sabots»
Méthode du ROI
CA/VA perdu par heure d'interruption 525 000 €
Days Of Chaos
Nb ETP préparation DoC 8
Hypothèse de réductio...
Le rationnel ne suffit pas …
Il faut
commencer par
rendre le sujet
familier.
Etape #1
Face à l’inconnu,
l’homme ne
dispose que de
trois choix :
combattre,
ne rien faire
ou fuir.
Utilisez les
réseaux sociaux
internes comme
externes
Partager des articles, des expériences
Etape #2
Identifier les
acteurs
BOSS ?
CEO
COO
CIO
CTO CFO
CMO
CSO
CBO
CDO
Stratégie d’influence adaptée aux profils
Ennemis Opposants
Ecoutez-les chaque fois qu’ils ont des
raisons qui méritent d’être intégrées, pas
si c’est une oppositio...
Amis
Consacrez-leur l’essentiel de votre
temps, sans oublier que les constructifs
peuvent s’opposer parfois ; vous devez
l...
Faites-les participer, souvent par
l’entremise des constructifs ;
autant que possible évitez de les
braquer, il serait dom...
Etape #3
La bonne
histoire pour
vos acteurs
Une fois les
conditions d’un
échange serein
posées, il est
possible de passer
à l’étape suivante.
Vue très simpliste,
notr...
Jouer sur les émotions
Un incident majeur est si vite arrivé…
Parfois, savoir être opportuniste…
Assurer – ré-assurer - rassurer
Résilience
« Même pas mal »
Il vaut mieux
expérimenter et
apprendre en
journée, que
d’être réveillé de
nuit pour un
incident majeur.
Hypothèse de la Reine
Rouge
Proposé en 1973 par Leigh Van Valen
« L'évolution permanente d'une espèce est
nécessaire pour ...
Même si
l’approche est
nouvelle,
personne n’est
débutant.
#disasterRecovery
#incidentManagementSystem
#GestionCrise
Vous n’êtes pas seuls… https://goo.gl/qshh4K
…même si ce n’est que le début
Evolution de “Chaos Monkey” vs “Chaos
Engineering” depuis Juin 2010 sur Google
Trends
Chaos...
C’est aussi très motivant de contribuer à
explorer un nouveau terrain de jeu…
Défense
Protection
Innovation
Précurseur
Suivre
GAFA
NATU
CHAOS
ENGINEERING
Eviter le mur lors du prochain
incident critiq...
Toujours pas
convaincu ?
Stratégie Engagement
Inspiration 90%
Consultation 55%
Sympathie personnelle 42%
Echange 35%
Se faire bien voir 31%
Persuas...
3% engagement
31% engagement
Merci pour votre participation
Pour continuer à échanger, rejoignez-nous sur
Merci à
pour l’accueil de ce Meetup
https://days-of-chaos.slack.comParis Cha...
11-12 décembre 2018
DevOps - Next Steps
Beffroi de Montrouge
27-28 novembre 2018
Chaos Engineering - si on testait en
prod...
Paris Chaos Engineering Meetup #6
Paris Chaos Engineering Meetup #6
Prochain SlideShare
Chargement dans…5
×

Paris Chaos Engineering Meetup #6

246 vues

Publié le

Support de la présentation du 6ième Meetup français sur le Chaos Engineering

Retour sur la Chaos Conf 2018

Résumé :
Des débuts de Jesse Robbins, Master of Disaster chez Amazon en 2004 à la Chaos Conf à San Francisco en septembre 2018, retour sur la première Chaos Conf à San Francisco le 28 septembre 2018. L'occasion de rencontrer nos homologues, échanger sur nos pratiques mais aussi contribuer à l'accroissement de la connaissance sur le sujet.
L'occasion de revenir notamment sur 2 sujets inspirants:
• La taxonomie des incidents : désigne un langage, une terminologie et des définitions communes permettant d'atténuer les problèmes de communication entre les personnes travaillant sur la résilience (résistance au choc). Merci Adrian Cockroft
• L'observabilité : un ensemble de moyens et pratiques permettant de s'assurer que son système fournit la meilleure qualité de service possible et la mise à disposition d'informations pour investiguer lorsque ce n'est pas le cas (cf. eBook Observabilité). Probablement le mot le plus prononcé lors de la journée après « chaos » ! Merci Charity Majors & Adrian COckroft

Publié dans : Ingénierie
  • Soyez le premier à commenter

Paris Chaos Engineering Meetup #6

  1. 1. Sponsorisé par 13 novembre 2018
  2. 2. Retour sur
  3. 3. Retour sur la Chaos Conf – 28 septembre 2018 1. Ce qu’on a retenu 2. Taxonomie des pannes 3. Observabilité 4. Influence
  4. 4. 1. Ce qu’on a retenu
  5. 5. « Nous ne devons plus gérer uniquement nos pannes, mais également celle des systèmes dont nous dépendons. Les tests au niveau des serveurs et réseaux ne sont plus suffisants. Il est nécessaire d’affiner la granularité pour tester nos applications avec efficacité.» Kolton Andrus, fondateur et CEO de Gremlin Ouverture de la journée par Kolton Andrus, fondateur et CEO de Gremlin Lancement du nouveau produit de Gremlin : ALFI Application Level Fault Injection
  6. 6. « Vous ne pouvez pas faire des lois pour interdire les pannes, mais vous pouvez vous concentrer sur une détection et une réponse rapide.» Adrian Cockroft, Amazon AWS VP Cloud Architecture Strategy 2004 2010 2012 2016 2017 2018 Amazon—Jesse Robbins. Master of disaster Netflix—Greg Orzell. @chaosimia - Première implémentation de Chaos Monkey pour renforcer l’usage de services stateless auto-scaled NetflixOSS libère la Simian Army en Open Source Fondation de Gremlin Inc Sortie du livre Netflix Chaos Engineering Naissance du projet open source Chaos toolkit Les concepts du Chaos Engineering se déploie progressivement dans le monde et première Chaos Conf ! Keynote d’ouverture de la journée Taxonomie des pannes https://github.com/adrianco/slides/blob/master/History_of_Chaos_v05a.pptx
  7. 7. « Raconter la bonne histoire à chaque partie prenante pour les embarquer. » Christophe Rochefolle, Directeur Excellence Opérationnelle, OUI.sncf Stratégie d’influence https://www.slideshare.net/madrockriss/kriss-rochefolle-how-to-convince-your- boss-to-say-yes-to-chaos-engineering-chaos-conf-2018
  8. 8. « Fail fast, fail often» Vilas Veeraraghavan, Directeur Engineering, Walmart Labs
  9. 9. « Les catastrophes sont causées par des pannes en cascade. Les postmortem qui ne se concentrent que sur les “root cause” ne vont couvrir que 12.5 % des problèmes. » Ronnie Chen, Engineering Manager, Twitter « Si vous devez tout faire vous- même, au moment critique, tout peut s’effondrer. Il est essentiel de faire grandir les personnes sans expérience pour augmenter la résilience de l’ensemble. » https://t.co/QMZKq1y7Dy
  10. 10. « Plus vous êtes orientés services, plus le réseau est central dans votre système. La mauvaise nouvelle : les réseaux sont connus pour être chaotique. La bonne nouvelle : les services Mesh vous permettent d’observer le comportement et d’appliquer rapidement des changements. » Mark McBride, CEO & Fondateur, Turbine Labs https://blog.octo.com/vision-docto-sur-le-service-mesh-les-enjeux/
  11. 11. «Le nombre de résultats de recherche Google pour “pourquoi les systèmes distribués sont si difficiles ?” ne fait que croître exponentiellement. De plus en plus d’ingénieurs en construisent… Comment survivre ? » Mikolaj Pawlikowski, Software Engineer, Bloomberg « Un système distribué est un système dans lequel un ordinateur dont vous ne soupçonniez pas l’existence peut rendre inutilisable votre propre ordinateur. » Leslie Lamport, chercheur en informatique américain, spécialiste de l'algorithmique répartie. Prix Turing 2013. Concepteur de LaTeX.
  12. 12. «Les systèmes distribués ont une liste quasi infinie de scenarios d’échec qui rendent pratiquement inutiles les environnements hors production. Déployer du code est un process d’amélioration de la confiance dans votre code.» Charity Majors, engineer/CEO @honeycombio «Sans observabilité, vous n’avez pas de chaos engineering vous avez juste du chaos» Observabilité https://speakerdeck.com/charity
  13. 13. Démonstration de la plateforme Gremlin
  14. 14. Keynote de clôture de la journée
  15. 15. 2. Taxonomie des pannes Adrian Cockcroft @adrianco AWS VP Cloud Architecture Strategy La solidité d'une chaîne n'excède pas celle de son maillon le plus faible. Pourfendeur de nuages - Russell Banks Comment pouvons-nous essayer de penser à tout ce qui pourrait échouer?
  16. 16. Taxonomie des pannes Un langage commun, une terminologie, et des définitions aident à limiter les problèmes de communication pendant les incidents. Adrian Cockroft propose une terminologie pour harmoniser les définitions plutôt que chacun en avoir une.
  17. 17. Taxonomie Infrastructure Software stack Application Exploitation Taxonomie des pannes Différentes couches d’impacts
  18. 18. Taxonomie Infrastructure Taxonomie des pannes Pannes Pannes Matérielles Disques, alimentations, câbles & fibres, cartes mères, firmware Pannes CPU Cache corruption de cache, bugs logiques Pannes Datacenter Alimentation électrique, connectivité, refroidissement, feu, inondations, tempête, tremblement de terre Pannes Internet DNS, ISP, routages
  19. 19. Taxonomie Taxonomie des pannes Pannes Software stack Bombes temporelles Compteur et temps machines, fuite mémoire Bombes datées Y2K, 29/02, fin des temps Unix Fin des temps Unix
  20. 20. Taxonomie Taxonomie des pannes Pannes Software stack Expiration Fin de vie de Certificats Révocation Fin de License ou compte fermé par un fournisseur Vulnérabilité Faille de sécurité
  21. 21. Taxonomie Taxonomie des pannes Pannes Software stack Bugs Langage Compilateur, interpréteur Bugs Runtime JVM, Docker, Linux, Hypervisor Problèmes de protocole Dépendance sur de la latence ou reprise d’erreur déficiente
  22. 22. Application Taxonomie Taxonomie des pannes Pannes Bombes temporelles (dans le code) Compteur et temps machines, fuite mémoire Bombes datées (dans le code) Y2K, 29/02, fin des temps Unix Bombes dans le contenu Pannes liées aux données
  23. 23. Taxonomie Taxonomie des pannes La description d’un film Netflix pour un titre espagnol contenait une cédille — Ç—encodée <ç>, mais il manquait le >. Chaque fois que le titre s’affichait, le code de presentation partait dans une boucle infini qui faisait progressivement tomber le site. Le code correspondant à ce bug existait depuis six ans. Application Pannes
  24. 24. Taxonomie Taxonomie des pannes Configuration Mauvaise configuration ou mauvaise syntaxe Versioning Problème de compatibilité Application Pannes
  25. 25. Taxonomie Taxonomie des pannes Pannes en cascades Bugs de gestion d’erreurs Surcharge en cascade Logging excessif, lock contention, hysteresis Retry Storms Trop de reprises, work amplification, mauvaise stratégie de timeout Application Pannes
  26. 26. Taxonomie Taxonomie des pannes Gestion d’incidents inadéquate Retard à la declaration d’incident Dashboards de monitoring inaccessible Système d’observabilité insuffisant Actions correctives incorrectes Capacity planning insuffisant Exploitation Pannes
  27. 27. Taxonomie des pannesQu’en pensez-vous ?
  28. 28. 3/ Observabilité Charity Major @mipsytipsy CEO at honeycomb Signe particulier : aime les poney, les arcs-en-ciel, les gros mots et la provocation The only good diff is a red diff Sans observabilité il n’y a pas de Chaos Engineering, juste du Chaos. Charity Major
  29. 29. Nous sommes tous d’accord pour dire que le Chaos engineering est un terme marketing pour justifier les tests tardifs dans le cycle de développement.
  30. 30. La complexité explose partout mais nos outils restent conçus pour un monde prévisible
  31. 31. Que ce soit pour le monitoring ou pour les tests
  32. 32. L’observabilité n’est pas une nouvelle définition du monitoring Monitoring != Observabilité Monitoring VS Observabilité
  33. 33. Monitoring Action d’observer et de vérifier les comportements et les outputs d’un système et de ses composants dans le temps. Known-Unknowns
  34. 34. Observabilité
  35. 35. Observabilité Un système est dit observable quand on peut déduire son état des symptômes et des informations qu’il émet. Au final l’observabilité, c’est la capacité du système à exposer des informations que l’on peut exploiter ou pas. Unknown-Unknowns A system is observable If the behavior of the entire system can be determined by only looking at its inputs and outputs
  36. 36. Une question de point de vue • Le monitoring permet de répondre à une question que l’on connait à l’avance. Il s’agit de code écrit pour surveiller du code. • L’observabilité permet de répondre à toute (nouvelle) question. Sans avoir à réécrire de code. Known-Unknowns Unknown-Unknowns
  37. 37. Les commandements de l’observabilité Les logs ne sont qu’un mécanisme de transport pour les événements
  38. 38. Observability Low Medium High Microservice that does one thing Function with no side effects Monolith with logging Monolith with tracing and logging
  39. 39. Et le Chaos Engineering dans tout ça? Le Chaos Engineering permet de valider votre monitoring et votre capacité d’observabilité. Le Chaos Engineering vous « mets le nez dedans ». Même approche sur la complexité :
  40. 40. La production reste le seul vrai environnement
  41. 41. Pour en savoir plus https://www.d2si.io/ebook-observability/
  42. 42. 4. Stratégie d’influence
  43. 43. Comment convaincre votre CODIR de se lancer dans le Chaos Engineering ?
  44. 44. « On va tout casser en production, ça va être fun ! » Méthode dite des « gros sabots»
  45. 45. Méthode du ROI CA/VA perdu par heure d'interruption 525 000 € Days Of Chaos Nb ETP préparation DoC 8 Hypothèse de réduction du nombre d'incident 2% Nb ETP jour DoC 150 Hypothèse de réduction de la durée d'incident 10% Durée DoC (j) 0.5 Impact incidents /an 3 937 500 € Nb jours Préparation (hors ETP permanent) 12 Nouvel impact par an 3 472 875 € Nb DoC / an 3 Economie d'impact 1ère année 464 625 € Budget (jours) / DoC 171 Budget (€) / DoC 85 500 € Gain par an 5% Budget (jours) 513 Budget (€) 256 500 € Chaos Monkey Nb ETP permanent 1 Nb ETP moyen communauté 5 Nb jours / mois communauté 2 Budget (jours) 332 Budget (€) 166 000 € TOTAL Budget (jours) 845 Budget (€) 422 500 €
  46. 46. Le rationnel ne suffit pas …
  47. 47. Il faut commencer par rendre le sujet familier. Etape #1
  48. 48. Face à l’inconnu, l’homme ne dispose que de trois choix : combattre, ne rien faire ou fuir.
  49. 49. Utilisez les réseaux sociaux internes comme externes
  50. 50. Partager des articles, des expériences
  51. 51. Etape #2 Identifier les acteurs
  52. 52. BOSS ? CEO COO CIO CTO CFO CMO CSO CBO CDO
  53. 53. Stratégie d’influence adaptée aux profils
  54. 54. Ennemis Opposants Ecoutez-les chaque fois qu’ils ont des raisons qui méritent d’être intégrées, pas si c’est une opposition de principe. Concentrez-vous sur les opposants qui ont du pouvoir ou de l’influence sur les autres et voyez-les si possible dans des situations informelles
  55. 55. Amis Consacrez-leur l’essentiel de votre temps, sans oublier que les constructifs peuvent s’opposer parfois ; vous devez les soigner en priorité Constructifs et engagés
  56. 56. Faites-les participer, souvent par l’entremise des constructifs ; autant que possible évitez de les braquer, il serait dommage de déstabiliser la dynamique par une maladresse : soignez votre communication Indifférents Passifs et hésitants
  57. 57. Etape #3 La bonne histoire pour vos acteurs
  58. 58. Une fois les conditions d’un échange serein posées, il est possible de passer à l’étape suivante. Vue très simpliste, notre cerveau est bien plus complexe !!!
  59. 59. Jouer sur les émotions
  60. 60. Un incident majeur est si vite arrivé…
  61. 61. Parfois, savoir être opportuniste…
  62. 62. Assurer – ré-assurer - rassurer
  63. 63. Résilience « Même pas mal »
  64. 64. Il vaut mieux expérimenter et apprendre en journée, que d’être réveillé de nuit pour un incident majeur.
  65. 65. Hypothèse de la Reine Rouge Proposé en 1973 par Leigh Van Valen « L'évolution permanente d'une espèce est nécessaire pour maintenir son aptitude suite aux évolutions des espèces avec lesquelles elle coévolue. » Le système économique évolue en permanence, notre rôle en tant qu’entrepreneur est de développer des compétences de survie pour maintenir notre business en vie.
  66. 66. Même si l’approche est nouvelle, personne n’est débutant. #disasterRecovery #incidentManagementSystem #GestionCrise
  67. 67. Vous n’êtes pas seuls… https://goo.gl/qshh4K
  68. 68. …même si ce n’est que le début Evolution de “Chaos Monkey” vs “Chaos Engineering” depuis Juin 2010 sur Google Trends Chaos Engineering au sein du Technology Radar de ThoughtWorks
  69. 69. C’est aussi très motivant de contribuer à explorer un nouveau terrain de jeu…
  70. 70. Défense Protection Innovation Précurseur Suivre GAFA NATU CHAOS ENGINEERING Eviter le mur lors du prochain incident critique Amélioration Alerting/Monitoring Stabilité Résilience Adapter le discours à chacun
  71. 71. Toujours pas convaincu ?
  72. 72. Stratégie Engagement Inspiration 90% Consultation 55% Sympathie personnelle 42% Echange 35% Se faire bien voir 31% Persuasion rationnelle 23% Pression 3% Coalition 3% Légitimer 0% ROI Choisir la bonne stratégie pour engager
  73. 73. 3% engagement 31% engagement
  74. 74. Merci pour votre participation
  75. 75. Pour continuer à échanger, rejoignez-nous sur Merci à pour l’accueil de ce Meetup https://days-of-chaos.slack.comParis Chaos Engineering Meetup http://meetu.ps/c/3BMlX/xNjMx/f https://chaosengineering.slack.com
  76. 76. 11-12 décembre 2018 DevOps - Next Steps Beffroi de Montrouge 27-28 novembre 2018 Chaos Engineering - si on testait en production? Paris – Porte de Versailles 22 novembre 2018 AWS User Group : Soirée Chaos Engineering : Venez relever le défi... et apprendre Lille - Euratechnologies

×