1. 1

2. 2
⇒ Présentation
⇒ Introduction
⇒ L’origine du mal
⇒ DevOps YABW
⇒ Les N effets Kisscool du DevOps
⇒ Le “Treeptik”Gagnant du DevOps
⇒ Le continuous Everything
⇒ Oubliez les légendes urbaines
⇒ Le plan d’actions vers le DevOps
Programme

3. 3
Présentation
⇒ Expert des architectures Java …. canal historique.
⇒ Partenaire Docker (Formation et Conseil).
⇒ Organisateur DevOps D-Day à Marseille.
⇒ Organisateur des Meetup Docker Marseille et de DevOps
Provence

4. 4
⇒ 95 % des projets des entreprises ont une composante IT.
⇒ Aujourd’hui toutes les entreprises sont des entreprises IT.
⇒ Il n’y a plus de banque, plus de libraire …. que des sociétés IT.
Introduction

5. 5
⇒ Aujourd’hui ce ne sont plus les grosses entreprises qui mangent les plus petites,
⇒ Ce sont les plus rapides qui mangent les plus lentes.
Introduction

6. 6
La révolution du digital est bel et bien là et elle change certains paradigmes :
Introduction
Avant Maintenant
L’IT met en oeuvre le business L’IT pilote le business
L’IT est un centre de coût L’IT génère la valeur
Il faut acheter les services IT au plus bas Il faut recruter les meilleurs talents IT

7. 7
Il en découle donc qu’aujourd’hui :
⇒ Il faut faire des logiciels,
⇒ … et il faut les faire rapidement.
Malheureusement ce n’est pas si simple que ça. Une étude menée par l’université d’Oxford en
2012 montre que :
● 17 % des grands projets vont si mal qu’ils menacent l'existence même de la société.
● Les grands projets dépassent de 45 % le budget initial ...
● Tout en offrant 56% de valeur en moins !
Introduction

8. 8
L’origine du mal
La meilleure ruse du Diable est de faire croire qu’il n’existe pas
⇒ Les organisations des équipes en silos
⇒ Des objectifs et des missions différentes
⇒ Un vocabulaire différent

9. 9
Les organisations en silos
⇒ Une organisation naturelle
⇒ Accentuée par l'autonomisation des équipes
⇒ Qui a rendu le travail de certain opaque
L’origine du mal

10. 10
Les organisations en silos
⇒ Et si on ajoute le management transversal pour casser les silos ?
Résultat :
● Tout le monde travaille avec tout le monde
● Tout le monde reporte à tout le monde
● Inefficacité et paralysie
L’origine du mal

11. 11
Des objectifs et des missions différentes
⇒ Création VS Exploitation
⇒ Rapidité VS Stabilité
⇒ Scrum VS ITIL
L’origine du mal

12. 12
Un vocabulaire différent
L’origine du mal

13. 13
DEVOPS YABW
Yet Another Buzzword
Devops se définit comme un mouvement visant à aligner le système d'information sur les
besoins de l'entreprise. Ce que l'on pourrait résumer en : travailler ensemble pour produire de la
valeur pour l'entreprise
(Définition : WIKIPEDIA)

14. 14
DevOps c’est donc :
⇒ Un changement de culture
⇒ Qui encourage la collaboration (au-delà des Dev et des Ops)
⇒ Dans le but de produire plus rapidement avec une meilleure qualité
DevOps n’est vraiment pas :
⇒ Un rôle ou un poste
⇒ Des outils, des scripts (pas seulement) …
⇒ Des certifications
⇒ Seulement pour les Dev ou pour les Ops
DEVOPS YABW

15. 15
Les “N” effets Kisscool
Mais pourquoi donc tout le monde veut faire du DevOps
⇒ Le Time To Market
⇒ La qualité
⇒ L’innovation

16. 16
Améliorer le Time To Market
⇒ 4 livraisons par An ou 4 livraisons par Jour ?
⇒ Comment mesurer le TTM ?
Les N effets Kisscool

17. 17
Améliorer le Time To Market. Pourquoi ?
⇒ Profiter d’un avantage concurrentiel
⇒ Bénéficier d’un meilleur prix de vente en début de cycle de vie
⇒ Cycle de vie plus long sur le marché
Les N effets Kisscool

18. 18
Améliorer le Time To Market. Pourquoi ?
Mais aussi ...
⇒ Fidéliser les clients en proposant régulièrement des nouveautés
⇒ Améliorer la gestion des ressources internes
⇒ Dates de lancement plus prévisibles
Les N effets Kisscool

19. 19
Améliorer la Qualité
⇒ Qualité globale de l’application
⇒ Réduction de la dette technique
⇒ Améliorer la satisfaction des utilisateurs
Les N effets Kisscool

20. 20
Améliorer l’innovation
⇒ Donner de la valeur à l’entreprise
⇒ Anticiper les nouveaux marchés / usages
⇒ Conquérir de nouveau marché
⇒ Réduire les coûts, réduire les risques ….
Les N effets Kisscool

21. 21
Le “Treeptik” gagnant du DevOps
Attention jeu de mots complètement délirant !
⇒ Les personnes
⇒ La culture
⇒ Les outils

22. 22
Les Personnes
⇒ L’IT, ce sont des hommes et des femmes avant tout !
⇒ Rendre les équipes fières de leur travail
⇒ Attention aux barrières que mettent les mots (Dev / Ops …)
Le “Treeptik” gagnant du DevOps

23. 23
Les Personnes
⇒ Communiquer
⇒ Donner du sens
⇒ Expliquer les risques
Le “Treeptik” gagnant du DevOps

24. 24
La culture
D’après Wikipédia, la culture organisationnelle d’une entreprise c’est l’ensemble des éléments
particuliers qui définissent les bases du comportement de l’organisation.
C’est l’ensemble des valeurs partagées par le plus grand nombre qui définissent comment l’
organisation aborde les problèmes ou comment traiter avec son marché.
Le “Treeptik” gagnant du DevOps

25. 25
La culture
⇒ Malheureusement si vous n’êtes pas le CEO c’est très difficile de faire évoluer la culture
de la société ! (en fait, même pour le CEO ce n’est pas facile)
⇒ Il faut faire évoluer les comportements les uns après les autres avec une volonté globale
(du CEO) de changement
⇒ Pour faire évoluer les comportements il faut expliquer “POURQUOI” et donner du sens à
l’action.
Le “Treeptik” gagnant du DevOps

26. 26
La culture
⇒ On va apprendre à réorganiser les équipes en équipes projets..
Le “Treeptik” gagnant du DevOps

27. 27
La culture
⇒ Insuffler la vision globale et la culture du feedback (1)
Le “Treeptik” gagnant du DevOps

28. 28
La culture
⇒ Insuffler la vision globale et la culture du feedback (2)
Le “Treeptik” gagnant du DevOps

29. 29
La culture
⇒ Insuffler la vision globale et la culture du feedback (3)
Le “Treeptik” gagnant du DevOps

30. 30
Les outils
Le “Treeptik” gagnant du DevOps

31. 31
Les outils de communication
Le “Treeptik” gagnant du DevOps

32. 32
Les outils d’automatisation
Le “Treeptik” gagnant du DevOps

33. 33
Les outils de mesure
Le “Treeptik” gagnant du DevOps

34. 34
Les outils PaaS
Le “Treeptik” gagnant du DevOps

35. 35
Le Continuous Everything
Again and again and again ….
⇒ L’intégration continue
⇒ La livraison continue
⇒ Les opérations continues
⇒ L’évaluation continue

36. 36
Le Continuous Everything

37. 37
L’intégration continue
⇒ Pratique qui impose aux développeurs d'intégrer leur code plusieurs fois par jour dans
un référentiel partagé. Chaque dépôt est vérifié par génération automatisée d'un build,
et déclenchement des tests (Unitaire et fonctionnel) ce qui permet aux équipes de
détecter les problèmes dès les premiers stades du cycle.
Le Continuous Everything

38. 38
La livraison continue
⇒ Pratique qui consiste à générer les builds d'un logiciel de manière à le passer en
production à tout moment (prêt pour production). Aspects clés de la livraison en continu :
standardiser la configuration de l'infrastructure et gérer les détails de configuration en
appliquant les mêmes pratiques que pour la gestion du code source.
Le Continuous Everything

39. 39
Les opérations continues
⇒ Pratique consistant à gérer les changements apportés aux serveurs et aux logiciels sans
perturber les utilisateurs (Patch sécu, Fix Bug, changement de disque). Il est parfois
possible de désactiver les logiciels lors des opérations planifiées. Les opérations en
continue permettent d'appliquer la version précédente de l'application aux clients
jusqu'à ce que la nouvelle version ait été testée avec succès et déployée.
Le Continuous Everything

40. 40
L’évaluation continue
⇒ Supervision en continu de l'état, de la disponibilité et des performances de l'application,
mais aussi capture de l'expérience utilisateur tout au long du cycle de vie de
l'application. Transmission de ces informations aux équipes concernées. Cette pratique
permet d'améliorer et d'optimiser en continu l'application et l'expérience utilisateur.
Le Continuous Everything

41. 41
Oubliez les légendes urbaines
L'auto-stoppeuse fantôme ....
⇒ « Les rôles doivent être fusionnés. »
⇒ « Les Ops disparaissent. »
⇒ « Un bon outil et c’est parti. »
⇒ « Les développeurs n’ont plus de limite. »
⇒ « Ce n’est pas adapté à mon entreprise. »

42. 42
« Les rôles doivent être fusionnés. »
⇒ Doit-on tous devenir des ingénieurs DevOps ? Non ! Il s'agit de contextes distincts : les
équipes “Développement” écrivent du code. Les équipes “Opérations” assurent l’
administration de l'infrastructure qui héberge ce code.
⇒ Le nombre de rôles peuvent changer au fil du temps et certains rôles seront assurés par
des logiciels, mais ces compétences et cette expertise de base resteront indispensables.
Oubliez les légendes urbaines

43. 43
« Les Ops disparaissent. »
⇒ On transfère tout dans le Cloud. Non ! L'objectif de DevOps n'est pas de migrer les
opérations vers le Cloud mais de définir une infrastructure plus simple, plus standardisée
consommable à la demande, capable de livrer les mises à jour des applications avec une
plus grande fréquence et d'identifier des opportunités d'optimisation dans les systèmes.
Oubliez les légendes urbaines

44. 44
« Un bon outil et c’est parti. »
⇒ Le passage à une culture DevOps exige de nouveaux outils certes mais les considérations
managériales et de culture sont primordiales.
Oubliez les légendes urbaines

45. 45
« Les développeurs n’ont plus de limites. »
Donne moi le Root sur le serveur de prod tu comprends rien !
Avec les services à la demande (PaaS) les développeurs vont créer des serveurs pour rien !
⇒ Non ! Ce n'est pas la finalité de DevOps. DevOps vise à améliorer la communication et la
collaboration entre les équipes Dev et Ops et à rendre leurs processus plus agiles, tout
en laissant chaque fonction exceller dans son domaine d'expertise.
Oubliez les légendes urbaines

46. 46
« Ce n’est pas adapté à mon entreprise. »
Plus simple dans les petites entreprises car plus agile et plus efficace dans les grosses entreprises
car il y a beaucoup de freins qui ralentissent les projets.
⇒ Le cycle de vie de l'automatisation DevOps se traduit par des besoins différents à
différents stades. Par conséquent, l'automatisation peut être incorporée dans une
entreprise, quelle que soit la maturité des systèmes IT en place.
Oubliez les légendes urbaines

47. 47
Plan d’action vers le DevOps
J’adore quand un plan se déroule sans accroc ...
⇒ Le modèle de maturité
⇒ Les objectifs et les moyens de les mesurer
⇒ Communiquez !!!

48. 48
Le modèle de maturité
Au début de chaque projet, DevOps se pose la question de l’évaluation:
⇒ A quel niveau de maturité la société se situe-t-elle ?
⇒ Quels sont les aspects déjà traités ?
⇒ Quelles sont les prochaines étapes de progression ?
⇒ Quels sont les points forts et les points faibles de l’organisation ?
Plan d’action vers le DevOps

49. 49
Le modèle de maturité :
La grille Culture

50. 50
Le modèle de maturité :
La grille Automatisation

51. 51
Le modèle de maturité :
La grille Processus

52. 52
Le modèle de maturité
Questionnaire / Evaluation :
⇒ Il existe un questionnaire en ligne pour faire une auto-évalutation
Plan d’action vers le DevOps
⇒ De manière générale l'évaluation se
fait sous forme d’audit/d’interviews

53. 53
Les objectifs et les moyens de les mesurer
⇒ Fixez des objectifs clairs
⇒ Identifiez une “Dream Team”
⇒ Un projet simple et moderne
⇒ Ne soyez pas trop ambitieux
Plan d’action vers le DevOps

54. 54
Les objectifs et les moyens de les mesurer :
Il y a plusieurs études sur ce sujet qui semble souvent trivial. Gartner formule cette recommandation :
⇒ "Créez des métriques qui s’alignent sur les impacts et les besoins de l'entreprise, mais surtout,
qui permettent aux personnes de prendre conscience qu’elles doivent travailler ensemble.”
Plan d’action vers le DevOps

55. 55
Les objectifs et les moyens de les mesurer :
Attention aux métriques contre-productives !
Plan d’action vers le DevOps
Les métriques d’orgeuil
Nombre de lignes de code
Couverture de code
Ce sont des objectifs faciles à
faire monter. Avec parfois une
vision top micro.
Les métriques d’une équipe
Métrique Scrum / Vélocité des
DEV
Attention aux métriques qui
divisent et qui recréent les silos
Certaines métriques
traditionnelles
MTBF
Temps moyen entre pannes
Les systèmes tombent de toute
façon en panne ! Combien de
temps pour remettre le service en
route ?

56. 56
Les objectifs et les moyens de les mesurer :
Préférez des métriques “métier” et des métriques qui fédèrent les équipes.
Plan d’action vers le DevOps
Client et business
Taux de conversion / Nb de nouveaux utilisateurs entrants /
Revenus engendrés / Temps passé par les utilisateurs sur
la fonctionnalité
Qualité et technique
Temps de reprise après une erreur / Nb et fréquence des
MEP / Coût d’un RollBack …
Culture, partage
Turn-over / Satisfaction de l’équipe / Wiki / Open source /
Mentoring …

57. 57
Communiquez !!!
⇒ Utilisez des métriques compréhensibles par tous, et partagez-les.
⇒ Utilisez des plate-formes de communication communes.
⇒ Organisez des présentations internes, des Meetup, des BBL, des apéro sur des sujets
techniques mais pas seulement !
Plan d’action vers le DevOps

58. 58
Fabien AMICO
⇒ @fabienamico
⇒ f.amico@treeptik.fr
⇒ 04 42 37 06 32
..:: FIN ::..
Et ils vécurent heureux ….

59. 59
Merci de votre attention