Le DevOps : La clé de la transformation digitale ?

1

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

3Pré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 malLa 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 KisscoolMais 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é

Les N effets Kisscool

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

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

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

Le “Treeptik” gagnant du DevOpsAttention 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 …)

Le “Treeptik” gagnant du DevOps

23

Les Personnes

⇒ Communiquer

⇒ Donner du sens

⇒ Expliquer les risques

Le “Treeptik” gagnant du DevOps

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

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

La culture

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

Le “Treeptik” gagnant du DevOps

27

La culture

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

Le “Treeptik” gagnant du DevOps

28

La culture

⇒ Insuffler la vision globale et la culture du feedback (2)

Le “Treeptik” gagnant du DevOps

29

La culture

⇒ Insuffler la vision globale et la culture du feedback (3)

Le “Treeptik” gagnant du DevOps

30

Les outils

Le “Treeptik” gagnant du DevOps

31

Les outils de communication

Le “Treeptik” gagnant du DevOps

32

Les outils d’automatisation

Le “Treeptik” gagnant du DevOps

33

Les outils de mesure

Le “Treeptik” gagnant du DevOps

34

Les outils PaaS

Le “Treeptik” gagnant du DevOps

35

Le Continuous EverythingAgain and again and again ….

⇒ L’intégration continue

⇒ La livraison continue

⇒ Les opérations continues

⇒ L’évaluation continue

36Le Continuous Everything

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

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

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

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

Oubliez les légendes urbainesL'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.

Oubliez les légendes urbaines

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

« 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

« 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

« 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

Plan d’action vers le DevOpsJ’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 ?

Plan d’action vers le DevOps

49

Le modèle de maturité :

La grille Culture

50

Le modèle de maturité :

La grille Automatisation

51

Le modèle de maturité :

La grille Processus

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

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

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

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

MTBFTemps moyen entre pannes

Les systèmes tombent de toute façon en panne ! Combien de temps pour remettre le service en route ?

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 businessTaux 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 !

Plan d’action vers le DevOps

58

Fabien AMICO

⇒ @fabienamico

⇒ f.amico@treeptik.fr

⇒ 04 42 37 06 32

..:: FIN ::..Et ils vécurent heureux ….

59

Merci de votre attention