Le DevOps : La clé de la transformation digitale ?

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
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
⇒ 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
⇒ 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
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
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
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
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
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
Des objectifs et des missions différentes
⇒ Création VS Exploitation
⇒ Rapidité VS Stabilité
⇒ Scrum VS ITIL
L’origine du mal

12
Un vocabulaire différent
L’origine du mal

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
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
Les “N” effets Kisscool
Mais pourquoi donc tout le monde veut faire du DevOps
⇒ Le Time To Market
⇒ La qualité
⇒ L’innovation

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

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

19
Améliorer la Qualité
⇒ Qualité globale de l’application
⇒ Réduction de la dette technique
⇒ Améliorer la satisfaction des utilisateurs

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

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

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 …)

23
Les Personnes
⇒ Communiquer
⇒ Donner du sens
⇒ Expliquer les risques

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

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.

26
La culture
⇒ On va apprendre à réorganiser les équipes en équipes projets..

27
La culture
⇒ Insuffler la vision globale et la culture du feedback (1)

28
La culture

29
La culture

30
Les outils

31
Les outils de communication

32
Les outils d’automatisation

33
Les outils de mesure

34
Les outils PaaS

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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

50
La grille Automatisation

51
La grille Processus

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

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

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

55
Attention aux métriques contre-productives !
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
Préférez des métriques “métier” et des métriques qui fédèrent les équipes.
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
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 !

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

Le DevOps : La clé de la transformation digitale ?

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Le DevOps : La clé de la transformation digitale ?

Ähnlich wie Le DevOps : La clé de la transformation digitale ? (20)

Le DevOps : La clé de la transformation digitale ?