Un tour d'horizon de ce qu'est le DevOps et quelques pistes pour le mettre en œuvre. Présentation faite chez Eutelsat le 28-juin-2018

1. DevOps @ Eutelsat – 28-juin
DEVOPS
UN TOUR D’HORIZON

2. LE SPEAKER
Ludovic Piot
@lpiot

3. Agenda
UNE TENTATIVE DE DÉFINITION
▪ Pourquoi un tel engouement ?
▪ Disclaimer
▪ Une proposition de définition
LES ORIGINES
▪ le mur de la confusion
▪ le mouvement agile : exemple à suivre
▪ le mur de la confusion
OPS, THE FINAL FRONTIER
▪ la software factory : terrain de réconciliation
KNOWING THE PATH VS. WALKING THE PATH
▪ DevOps is... / is not…
▪ TRS
▪ Tools
▪ Pistes de mise en œuvre

4. DEVOPS
Une tentative de définition

5. DEVOPS – pourquoi un tel engouement ?
Source:StateofDevOpsreport2016-2017
(Puppet+DevopsResearch&Assessment)

6. DEVOPS – pourquoi un tel engouement ?
Source:StateofDevOpsreport2016
(Puppet+DevopsResearch&Assessment)

7. DEVOPS – disclaimer
“It’s not about the destination,
it’s about the journey” – Gene Kim
DevOps n’est pas une méthodologie.
Il s’agit de créer une culture dans laquelle
Dev et Ops collaborent étroitement et en confiance.

8. DEVOPS – une proposition de définition
L’approche DEVOPS a un objectif unique :
▪ aligner l'ensemble des acteurs et des compétences
du système d’information…
▪ … sur la seule qualité du produit fourni à
l'utilisateur final
Pour cela, la démarche DEVOPS passe par…
▪ l'engagement de l'ensemble des acteurs sur la
chaîne de production de valeur,
▪ dans une collaboration libre et sans contrainte
▪ et le souci d’une amélioration continue
▪ par le partage d'informations et de responsabilité
▪ et des outils et méthodes communes
▪ en vue d'automatiser les actions
▪ et ainsi d’étendre au maximum l’autonomie des
différents acteurs en dehors de leur périmètre
propre
La démarche DEVOPS
L’approche DEVOPS
the Beal-Hedemark
golden square
Coût Temps
Qualité Satisfaction
Culture
Automation
Lean
Measure
Sharing

9. DEVOPS
les origines

10. DEVOPS – le mur de la confusion
Depuis toujours, DEV et OPS s’opposent à cause
d’objectifs antagonistes…
Les DEV recherchent :
▪ la rapidité de mise à disposition des nouvelles
fonctionnalités aux utilisateurs finaux
▪ culture du produit
Les OPS recherchent :
▪ la stabilité, la robustesse
▪ la maîtrise, la performance
▪ la sécurité
▪ l’industrialisation
▪ l’efficience économique
▪ culture du service
Mais il y a confusion : ces objectifs sont des
objectifs intermédiaires et non exclusifs !

11. “We don’t need an accurate document, we
need a shared understanding” – Jeff Patton

12. AGILE – au départ, des difficultés similaires…
PRATIQUES
▪ des équipes en silo
▪ des échanges sous forme « contractuelle »
client/fournisseur
▪ un « effet tunnel » systémique
▪ des hypothèses de travail amont qui contraignent
la réalisation
CONSTATS
▪ un projet mal maîtrisé (coûts, délais)
▪ des écarts de conformité du livrable avec le besoin
▪ l’apparition tardive des soucis rend les correctifs
très coûteux et douloureux
▪ à chaque étape, la pression du planning conduit à
accepter les approximations des étapes amont
▪ l’OPS, en bout de cycle, doit se faire le garant du
livrable le plus « dénaturé »

13. AGILE – le pragmatisme et le business…
PRATIQUES
▪ des cycles courts et itératifs
▪ des équipes resserrées incluant fonctionnels et
techniques
▪ « Do, learn, adapt ! »
▪ « less documentation is more communication »
▪ la construction commune et quotidienne des
fonctionnalités du produit
▪ des mises en production plus fréquentes
CONSTATS
▪ un projet mieux maîtrisé (coûts, délais)
▪ des ajustements plus rapides et plus fréquents
pour rester pertinent
▪ l’introduction de la notion de « fail fast »
▪ une responsabilité partagée entre fonctionnels et
techniques
▪ … mais l’OPS n’est toujours pas systématiquement
inclus dans la démarche

14. DEVOPS
Ops, the final frontier

15. ▪ Les méthodes agiles accélèrent et fiabilisent les
livraisons des DEV.
▪ Les OPS et le déploiement sont perçus comme
l’ultime frein à accélérer le Time-to-Market
(TTM).
▪ La nécessité de faire sauter ce dernier goulot d’
étranglement devient flagrante.
SOFTWARE FACTORY – le time-to-market s’impose…

16. L’usine logicielle,
utilisée par les DEV,
nécessite le
savoir-faire des OPS :
▪ forts besoins en
optimisation
d’infrastructure
▪ forts besoins en
automatisation
« système »
SOFTWARE FACTORY – terrain de réconciliation ❤
Usine de Build
Build
Vérifier la
qualité
du code
Compiler
Récupérer les
dépendances
Déployer
Documenter
Exécuter les tests
Packager
Référentiel
binaires
Référentiel
de tâches
et anomalies Plateforme
de tests
Documentation
& Indicateurs
BuildGestionnaire
de sources
Build
local
Notifications
Serveur
d’intégration
continue

17. Les besoins en environnements de test explosent :
▪ organisation des équipes par domaine fonctionnel
(feature teams)
▪ automatisation des tests (fonctionnels,
performances, robustesse, conformité graphique,
multi-canal)
SOFTWARE FACTORY – infrastructure everywhere!

18. Le déploiement continu en Production de chaque
nouvelle fonctionnalité dès qu’elle est livrée
démultiplie les besoins dans le savoir-faire des OPS :
▪ pression de la vélocité
▪ architecture technique complexe (micro-services)
▪ modèles de déploiement complexes (blue/green,
canary testing)
▪ évolution perpétuelle de l’infrastructure technique
▪ environnements éphémères
▪ bacs à sable à la demande pour les équipes des
systèmes connectés
CONTINUOUS DELIVERY – warp speed factor 8!
“How long would it take your organization to deploy a
change that involves just one single line of code?”
- Poppendiek
L’OPS devient
un acteur indispensable
à la réussite
du projet de développement

19. DEVOPS – blue/green deployment

20. DEVOPS
is… / is not…

21. DEVOPS – is not…
5- “to be a devops, use the tool xxx…”
▪ DevOps n’est pas prioritairement une affaire d’outil.
▪ L’usage d’un outil fréquemment utilisé dans les
organisations DevOps n’est ni nécessaire, ni encore moins
suffisant pour faire du DevOps.
1- “One tool to rule them all”
▪ Le partage d’outils doit répondre à un besoin de
coopération et d’autonomie.
▪ Et non pas à un besoin d’industrialisation ou de respect des
standards.
2- “No-OPS”
▪ L’automatisation est un vecteur d’autonomisation des
acteurs et d’amélioration des opérations.
▪ Pas un moyen de se décharger de sa responsabilité.
3- “Every DEV has the root password”
▪ DevOps est un mouvement favorisant la coopération, pas le
remplacement des OPS par les DEV.
▪ Dans ce sens, certains DEV peuvent avoir besoin de root.
▪ Par nature, DevOps doit minimiser ce besoin.
4- “Every sysadmin should write code / every
DEV should rack servers”
▪ La coopération étroite ne veut pas dire la polyvalence de
tous.
▪ C’est, au contraire, reconnaître les forces et faiblesses de
chacun et en tirer le meilleur, collectivement.

22. DEVOPS – is…
7- “Fail fast”
L’erreur est une richesse d’expérience. Il faut l’accepter
comme une composante du mode opératoire, et expérimenter
au plus faible coût (et PDCA).
8- “Most valuable product”
Toute réalisation doit être itérative, pour accélérer l’arrivée
de la feedback loop. On doit chercher le plus petit élément de
réalisation qui apporte le maximum de valeur.
9- “In God we trust. Everything else, we test”
Toute réalisation n’est achevée que lorsque le test
garantissant la conformité de son fonctionnement est
associé.
10- “Less doc is more communication”
La documentation n’existe pas per se. Elle rendue inutile par
le partage des outils et méthodes, du même espace de travail
et les rituels de partage de connaissance (stand-up meeting,
peer-programming, demo)
11- “Everything fails all the time!” - Werner Vogels
Pannes et erreurs humaines sont inévitables. Par design, on
doit les circonscrire et mettre en place les contre-mesures
qui rendent ces pannes indolores.
1- “User-centric product”
La qualité et la pertinence du produit fourni à l’utilisateur final est la
seule chose qui importe.
2- “You build it, you run it!” - Werner Vogels
le DEV est (co-)responsable de ce qui arrive en Prod
(y-compris dans les astreintes).
3- “OPS as enablers, not gatekeepers”
- Lindsay Holmwood
Dans les domaines dont il est garant, l’OPS doit être
facilitateur par son savoir-faire et non-pas censeur.
4- “Measure everything” - Etsy
L’obsession de la mesure et de la traçabilité. Ce qui ne se
mesure pas n’est qu’affaire d’opinion.
5- “Plan, do, check, act (PDCA)”
La démarche d’amélioration continue, basée sur
l’expérimentation perpétuelle et la mesure du résultat qui en
ressort.
6- « Souriez, vous êtes filmés »
Par défaut, la modération n’existe pas. Elle n’intervient qu’à
postériori d’une douleur rencontrée. Pas d’over-engineering.

23. DEVOPS
knowing the path vs. walking the path

24. 6- Augmentez le feedback des Ops
7- Mesurez votre succès à travers des KPIs
… synthétiques
8- Adaptez vos processus business à votre
vélocité de développement
9- Participez à la communauté
1- Commencez petit
… et faites de ce succès un hérault
2- Concentrez-vous sur la culture
… et pas sur les outils
3- Investissez sur les outils qui créent de la
visibilité en temps réel
… et l’intégration poussée dans l’usage de ces
outils
4- Déployez des technologies
d’automatisation
… et ouvrez-en l’usage aux populations du projet
5- Augmentez votre vitesse de déploiement
… et faites-en un KPI du projet
DEVOPS – 9 bonnes pratiques à mettre en œuvre…

25. TRS – le Taux de Rendement Synthétique
Ponctualité des Mises
en Production
▪ P1 - Respect des dates
de MEP
▪ P2 - Cadence des MEP
par rapport aux
sprints
▪ P3 - Profondeur des
décalages de date de
livraison
Taux de
Charge
TRG
Taux de
Disponibilité
Taux de
Performance
Taux de
Qualité
TRS
Disponibilité de la
plateforme à chaque
étape
▪ D1 - Rapidité de mise
à dispo. des
environnements
▪ D2 - Dispo. des
environnements
Exigences non
fonctionnelles
▪ Q1 - Qualité du code
▪ Q2 - Préparation de la
MEP
Expérience utilisateur
▪ Q3 - performance
applicative ressentie
par l’utilisateur
▪ Q4 - Incidents suite à
MEP
Taux de
Disponibilité
Taux de
Performance
Taux de
Qualité
Utilisation efficiente
des ressources
▪ C1 - Taux d’utilisation
des ressources /
plateformes

26. LE TAUX DE RENDEMENT SYNTHÉTIQUE
▪ La mesure aide à fédérer et à faire adhérer
▪ Un moyen pratique d’établir un dialogue
▪ Le TRS permet d’aller vite à l’essentiel.
▪ Cultiver un état d’esprit collaboratif.
▪ L’essayer c’est l’adopter !
TRS – quels enseignements ?

27. 6- Augmentez le feedback des Ops
7- Mesurez votre succès à travers des KPIs
… synthétiques
8- Adaptez vos processus business à votre
vélocité de développement
9- Participez à la communauté
1- Commencez petit
… et faites de ce succès un hérault
2- Concentrez-vous sur la culture
… et pas sur les outils
3- Investissez sur les outils qui créent de la
visibilité en temps réel
… et l’intégration poussée dans l’usage de ces
outils
4- Déployez des technologies
d’automatisation
… et ouvrez-en l’usage aux populations du projet
5- Augmentez votre vitesse de déploiement
… et faites-en un KPI du projet
DEVOPS – 9 bonnes pratiques à mettre en œuvre…

28. Les nouvelles formes de collaboration – Build / ship / run
DEV OPS
Ephemeral
Envs

29. Tools – Periodic table of DevOps tools

30. Tools – Continuous Delivery maturity matrix

31. Roadmap partagée et adaptative
Utiliser un outil de project mgmt unique (Jira) :
▪ workflow peu contraignant
▪ workflow facile à faire évoluer
Documentation en maintenance collaborative
▪ Rendre la documentation accessible à tous.
▪ Centraliser la doc dans un unique référentiel (Confluence).
▪ Permettre une maintenance collaborative avec validation
croisée (pull requests)
▪ Documentation comme vecteur de maîtrise vs. vecteur de
références
Specs as tests
Décrire les fonctionnalités qui, une fois compilées,
servent :
▪ de tests unitaires (Cucumber)
▪ ou de tests d’acceptance (FitNesse)
Souriez, vous êtes filmés
Mettre en place une métrologie accessible à tous sur l’
évolution des docs et des specs :
▪ vélocité d’évolution
▪ qualité des revues
▪ nombre d’allers-retours
Plan – Quelques pistes de mise en œuvre
DEV OPS

32. Poste de dev. disponible on-demand
Utiliser un outil de déploiement automatisé pour
configurer le poste de DEV (Ansible, Vagrant, Packer) :
▪ code disponible sur un dépôt partagé
▪ code adaptable à des contextes projets
▪ à l’échelle d’une équipe / d’un projet / de l’entreprise
Peer-review
Permettre une validation croisée (pull requests) entre
DEV, mais aussi entre DEV et OPS.
Dépôts de code communautaires
Utiliser des dépôts centralisés :
▪ fonctionnalités de collaboration sociale (Github, Gitlab,
BitBucket)
▪ gouvernance de type community management
▪ réemploi de code comme stratégie d’entreprise.
Lazy-coupled services
Permettre une évolution dissociée de différentes
applications / composants.
Test development kit
cf. rubrique test
Code – Quelques pistes de mise en œuvre
DEV OPS

33. Envs éphémères on-demand
Pouvoir paralléliser les builds et les tests :
▪ envs. on-demand (Infra as Code)
▪ architecture technique iso prod
▪ jeu de données de test as a service
Orchestration as Code
Décrire le workflow de build et de tests par
programmation (Jenkins Job DSL, Gitlab CI)
Performance des tests
Optimiser au maximum le temps de passage
end-to-end des tests.
▪ mise à dispo de l’env. de test
▪ passage des tests (tests automatisés)
▪ restitution consolidée des résultats
Test development kit
Fournir un jeu de tests (jeu de données compris) pour
tout code communautaire :
▪ tests automatisés
▪ jeu de données de test
▪ code de provisionning d’env. de test
▪ code de provisionning de workflow de test
Build / test – Quelques pistes de mise en œuvre
DEV OPS

34. Test like an Ops
Embarquer les tests liés au run :
▪ tests de fail-over / recovery / clustering
▪ tests de restauration de données
▪ tests de rollback
▪ tests de performance (nominal, aux limites, endurance)
▪ tests d’upscaling / outscaling
▪ tests d’accès / de sécurité
▪ tests de débordement
Page d’autodiagnostic
Inclure des tests de base au sein de l’applicatif
▪ test d’accès R/W aux données / aux logs (DB et FS)
▪ test de connexion aux composants techniques / applis
tierces
▪ test de load-balancing
▪ identification des serveurs portant les composants testés
▪ affichage de la configuration embarquée
Smoke tests
Jouer un scénario fonctionnel minimal avant et après
chaque opération en production
Test – Quelques pistes de mise en œuvre
DEV OPS

35. Release on demand
Autonomiser les acteurs du projet sur les opérations
techniques :
▪ configuration partagée et collaborative (CMDB on git)
▪ envs. on-demand (Infra as Code)
▪ déploiements automatisés
In God we trust. Everything else, we test
Tracer et tester l’état de la plateforme avant et après
chaque release/deploiement.
Full stack release management
Versionner et tracer tous les éléments mis en œuvre
dans une release :
▪ application
▪ données
▪ code de déploiement
▪ documentation et specs
▪ tests
▪ infrastructure (immutable infrastructure)
Release / deploy – Quelques pistes de mise en œuvre
DEV OPS

36. Self-service
Autonomiser les acteurs du projet sur les opérations
techniques :
▪ automatiser les tâches les plus courantes
▪ outil d’orchestration (Jenkins)
Ops As a Service… on demand
Packager et fournir les activités des administrateurs sur
un projet comme des services clé-en-main.
In God we trust. Everything else, we test
Inclure le provisionning et la configuration de la
métrologie avec chaque tâche de déploiement.
Partager les retours d’expérience
Rendre les post-mortem publics (fail con’).
Exposer les bonnes pratiques / les succès locaux.
Supervision collaborative
Partager la maintenance et le suivi de la supervision :
▪ outil accessible par tous les acteurs du projet
▪ capacités techniques et applicatives, voire projet
▪ maintenance collaborative avec validation croisée
▪ déploiement et maintenance as code : tests
Operate / monitor – Quelques pistes de mise en œuvre
DEV OPS

37. What’s next?

38. Questions ?