1.
Sponsorisé par
13 novembre 2018

2.
Retour sur

3.
Retour sur la Chaos Conf – 28 septembre 2018
1. Ce qu’on a retenu
2. Taxonomie des pannes
3. Observabilité
4. Influence

4.
1. Ce qu’on a retenu

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.
« 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.
« 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.
« Fail fast, fail often»
Vilas Veeraraghavan,
Directeur Engineering, Walmart Labs

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.
« 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.
«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.
«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.
Démonstration de la plateforme Gremlin

14.
Keynote de clôture
de la journée

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.
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.
Taxonomie
Infrastructure
Software stack
Application
Exploitation
Taxonomie
des pannes
Différentes
couches
d’impacts

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.
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.
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.
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.
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.
Taxonomie
Taxonomie
des pannes
La description d’un film Netflix pour un
titre espagnol contenait une cédille —
Ç—encodée <&#231;>, 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.
Taxonomie
Taxonomie
des pannes
Configuration
Mauvaise configuration ou mauvaise syntaxe
Versioning
Problème de compatibilité
Application
Pannes

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.
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.
Taxonomie
des pannesQu’en pensez-vous ?

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.
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.
La complexité explose partout mais nos outils
restent conçus pour un monde prévisible

31.
Que ce soit pour le monitoring ou pour les
tests

32.
L’observabilité n’est pas une nouvelle
définition du monitoring
Monitoring != Observabilité
Monitoring VS Observabilité

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.
Observabilité

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.
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.
Les commandements de l’observabilité
Les logs ne sont qu’un mécanisme de
transport pour les événements

38.
Observability
Low
Medium
High
Microservice that does one thing
Function with no side effects
Monolith with logging
Monolith with tracing and logging

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.
La production reste le seul vrai
environnement

41.
Pour en savoir plus
https://www.d2si.io/ebook-observability/

42.
4. Stratégie d’influence

43.
Comment convaincre votre CODIR
de se lancer dans le Chaos Engineering ?

44.
« On va tout casser en
production, ça va être fun ! »
Méthode dite des « gros sabots»

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.
Le rationnel ne suffit pas …

47.
Il faut
commencer par
rendre le sujet
familier.
Etape #1

48.
Face à l’inconnu,
l’homme ne
dispose que de
trois choix :
combattre,
ne rien faire
ou fuir.

49.
Utilisez les
réseaux sociaux
internes comme
externes

50.
Partager des articles, des expériences

51.
Etape #2
Identifier les
acteurs

52.
BOSS ?
CEO
COO
CIO
CTO CFO
CMO
CSO
CBO
CDO

53.
Stratégie d’influence adaptée aux profils

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.
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.
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.
Etape #3
La bonne
histoire pour
vos acteurs

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.
Jouer sur les émotions

60.
Un incident majeur est si vite arrivé…

61.
Parfois, savoir être opportuniste…

62.
Assurer – ré-assurer - rassurer

63.
Résilience
« Même pas mal »

64.
Il vaut mieux
expérimenter et
apprendre en
journée, que
d’être réveillé de
nuit pour un
incident majeur.

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.
Même si
l’approche est
nouvelle,
personne n’est
débutant.
#disasterRecovery
#incidentManagementSystem
#GestionCrise

67.
Vous n’êtes pas seuls… https://goo.gl/qshh4K

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.
C’est aussi très motivant de contribuer à
explorer un nouveau terrain de jeu…

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.
Toujours pas
convaincu ?

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.
3% engagement
31% engagement

74.
Merci pour votre participation

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.
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