DevOps

Introduction générale
Contenu

1. Qu'est-ce que DevOps?

2. Dev et Ops
3. Quel problème DevOps résout-il ?
4. Automatisation
5. La performance
6. Comportement et attitude
7. Organisation
8. Gouvernance
9. Transformation

2
1. Qu'est-ce que DevOps?
Définitions de DevOps
‘DevOps (portmanteau de "development" et "operations") est une méthode de
développement de logiciels qui met l'accent sur la communication, la collaboration
(partage d'informations et utilisation de services web), l'intégration, l'automatisation et la
mesure de la coopération entre les développeurs de logiciels et les autres professionnels
des technologies de l'information (TI). DevOps reconnaît l'interdépendance entre le
développement de logiciels et les opérations informatiques. Il vise à aider une organisation
à produire rapidement des produits et services logiciels et à améliorer la performance des
opérations - l'assurance qualité’ ([Link]

Jez Humble
DevOps est "une communauté de pratique interdisciplinaire dédiée à
l'étude de la construction, de l'évolution et de l'exploitation de systèmes
résilients en mutation rapide à grande échelle".

DevOps est le mélange des tâches effectuées par les équipes de

développement d'applications et d'exploitation des systèmes d'une
entreprise.

4
 “DevOps n'est que le principe Agile appliqué à
l'ensemble de l'entreprise.”

‘DevOps est simplement le principe Agile appliqué à l'ensemble de l'entreprise. Il offre une perspective
plus globale de bout en bout qui permet une transformation à l'échelle de l'entreprise’

‘DevOps n'est que le prolongement naturel d'Agile. Il reprend les principes directeurs et les meilleures
pratiques qu'Agile a apportés aux développeurs et les applique à une échelle beaucoup plus large dans
l'ensemble de l'organisation.’
* DevOps is Agile for the rest of the company
Mar 4, 2015 Posted by Tony Bradley In Blogs, ([Link]

5
Quelle est la situation actuelle ? Nous avons dressé des murs -
intentionnellement ou non - qui limitent les performances

Entreprise Development Operations

To help Use
remove DevOps
this wall Here

“DevOps est une réponse à la prise de conscience croissante de l'existence d'un décalage entre ce qui
est traditionnellement considéré comme une activité de développement et ce qui est
traditionnellement considéré comme une activité d'exploitation. Cette déconnexion se manifeste
souvent par des conflits et de l'inefficacité”
(What is DevOps? [Link])
6
 Le mur de la confusion

Development Operations

Une attention extrême portée Une attention extrême portée à

au changement la stabilité
▪ Des projets plus urgents, avec des dates à respecter ▪ Défaillance des applications fragiles
▪ Code fragile mis en production ▪ Difficultés à identifier la cause première
▪ Des versions avec des "installations turbulentes". ▪ Temps trop long pour rétablir le service
▪ Des cycles de publication plus longs permettent ▪ Lutte intensive contre les incendies et travaux non
d'amortir le "coût des déploiements". planifiés
▪ Backlog de l’infrastructure du projet qui pourraient ▪ Projets planifiés inachevés
corriger les causes profondes et réduire les coûts. ▪ Clients frustrés
▪ Diminution de la part de marché

7
DevOps c’est ...

DevOps est un
moyen de créer
des logiciels tout
en accélérant la
mise sur le marché
sans sacrifier la
qualité et la
fiabilité.

8
Qu'est-ce que DevOps ?

▪ DevOps consiste à
identifier les blocages et
à éliminer les déchets du
système afin d'améliorer
continuellement votre
organisation et de fournir
de meilleurs logiciels.
Les blocages peuvent
prendre la forme de
longs processus
d'approbation, de
processus manuels et
même de certaines
ressources.

9
Le marché perçoit la solution de différents points de vue

Quels sont les points de vue sur DevOps ?

• Depuis des silos fonctionnels …

Organisation • Vers équipes pluridisciplinaires axées sur le client

• Depuis des KPI(Key Performance Indicator) différents pour le

Performance développement et l'exploitation…
• Vers des objectifs et des mesures communs

• De “différent” …
Culture • Vers “Ensemble”

• De la complexité et de la lenteur…
Flux • Vers de bout en bout et simple

• À partir d'outils propres…

Automatisation • Vers un outil intégratif

10
DevOps aide à atteindre les objectifs de l'IT

Définition de DevOps par Quint:

DevOps (portmanteau de développement et d'opérations) est une philosophie organisationnelle
qui met l'accent sur la communication, la collaboration et l'intégration entre les développeurs de
logiciels de technologie de l'information (TI) et les professionnels des opérations TI. DevOps
utilise l'interdépendance entre le développement de logiciels et les opérations informatiques
pour créer des produits et des services de meilleure qualité. Il vise à aider une organisation à
fournir rapidement la valeur recherchée par les clients des technologies de l'information.

DevOps est, en bref, un "mouvement" visant à rapprocher le

développement et les opérations afin d'atteindre quatre objectifs clés :

o Améliorer la qualité de la livraison (première fois

correcte)
o Augmenter la valeur de l'entreprise (client)
o Accroître la rapidité de livraison (performance)
o Améliorer l'efficacité (réduire les coûts)

11
Nouvelle situation

Simplifier la vie ?

Culture Performance

Entreprise DevOps

Process Tooling Organization

DevOps est la solution de la problématique

Automatisation Performance

Culture

Flux Organisation
Vocabulaire DevOps

Continuous Delivery (CD) est une stratégie logicielle qui permet aux organisations de fournir de
nouvelles fonctionnalités aux utilisateurs aussi rapidement et efficacement que possible. L'idée
de base est de créer un processus reproductible, fiable et qui s'améliore de manière
incrémentale pour faire passer le logiciel du concept au client. L'objectif est de permettre un flux
constant de changements dans la production via un pipeline automatisé de livraison continue de
logiciels.
Continuous integration (CI) est la pratique, dans le domaine du génie logiciel, qui consiste à
fusionner toutes les copies de travail des développeurs sur une ligne principale partagée plusieurs
fois par jour. L'objectif principal de l’CI est de prévenir les problèmes d'intégration

Test-driven development est un processus de développement logiciel qui repose sur la

répétition d'un cycle de développement très court : le développeur rédige d'abord un cas de test
automatisé (qui échoue initialement) définissant une amélioration souhaitée ou une nouvelle
fonction, puis produit la quantité minimale de code pour réussir ce test, et enfin remanie le
nouveau code pour qu'il réponde à des normes acceptables.

Test automation est l'utilisation d'un logiciel spécial (distinct du logiciel testé) pour contrôler
l'exécution des tests et la comparaison des résultats réels avec les résultats prévus.

14
Adoption de DevOps
L'adoption de DevOps est favorisée par des facteurs tels que :
1. Utilisation de processus et de méthodologies de développement agiles et
autres
2. Demande d'augmentation du rythme des mises en production de la part des
parties prenantes(stakeholders) des applications et de l'entreprise
3. Large disponibilité d'infrastructures virtualisées et en Cloud auprès de
fournisseurs internes et externes
4. Utilisation accrue des outils d'automatisation et de gestion de la
configuration des centres de données
5. Il a également été suggéré que l'effet secondaire de l'approche
dominante et traditionnelle des États-Unis(USA) sur le
développement de l'économie et de la société est un effet
négatif sur le développement de l'économie.
6. Le style de gestion (“the Sloan model” vs. “the Toyoda model”)
garantit le développement de silos d'automatisation, créant ainsi
"l'écart DevOps" qui nécessite alors des capacités DevOps pour y
faire face. 15
Objectifs de DevOps

▪ Mieux aligner la réactivité et les capacités informatiques sur les

besoins de l'entreprise
▪ Produire des versions de logiciels plus petites et plus fréquentes
▪ Réduire les efforts lors du développement, de la transition et de
l'exploitation des logiciels
▪ Améliorer les délais de commercialisation
▪ Améliorer la qualité du code
▪ Améliorer la qualité des déploiements de logiciels
▪ Réduire les coûts d'itération des produits et les retards
▪ Instaurer une culture de la communication et de la collaboration
▪ Améliorer la productivité
▪ Améliorer la visibilité des exigences et des processus IT

16
2. Autres méthodes
de développement
Développement classique de logiciels

1. Déterminer les besoins

2. Compléter la conception

3. Effectuer le codage et les

tests unitaires

4. Effectuer des tests

fonctionnels et d'intégration
et corriger les bogues

5. Procéder à l'acceptation et au
déployer
 Agile Software Development

La plupart des implémentations Agile utilisent une communication quotidienne routinière et

formelle en face-à-face entre les membres de l'équipe. Le représentant du client et toutes les
parties prenantes intéressées y participent en tant qu'observateurs.

Le développement agile met l'accent sur les logiciels fonctionnels comme principale mesure
du progrès. Ceci, combiné à la préférence pour la communication en face-à-face, produit
moins de documentation écrite que d'autres méthodes.

Les méthodes agiles sont parfois caractérisées comme étant à l'opposé des méthodes
planifiées ou disciplinées. Les méthodes agiles se situent du côté adaptatif de ce continuum.
Les méthodes adaptatives se concentrent sur l'adaptation rapide aux réalités changeantes.

• Individus et interactions - Dans le développement agile, l'auto-organisation et la motivation sont importantes,

tout comme les interactions telles que la colocation et la programmation en binôme. la programmation en
binôme.
• Logiciel fonctionnel - Un logiciel fonctionnel sera plus utile et mieux accueilli qu'une simple présentation de
documents aux clients lors de réunions.
• Collaboration avec le client - Les exigences ne peuvent pas être entièrement collectées au début du cycle de
développement du logiciel. C'est pourquoi il est très important d'impliquer en permanence le client ou les
parties prenantes.
• Réaction au changement - Le développement agile est axé sur la réaction rapide au changement et sur le
développement continu.
19
Traditionnel versus Agile

Waterfall Agile
• Commence par une conception complète • Chaque Sprint fournit un logiciel
• La réalisation est suivie de l'essai du fonctionnel qui peut être utilisé dans la
produit final pratique.
• Enfin, les tests en pratique • Commence par fournir une fonctionnalité
• Pas de boucles de feedback de base à laquelle sont ajoutées d’autres
• Axé sur le plan (Plan-driven) fonctionnalités.
• Axé sur la valeur(Value-driven)
Approche traditionnelle et absence de qualité à la source

• Dans les organisations traditionnelles, les processus informatiques ne sont pas

automatisés
• Il s'écoule beaucoup de temps entre la mise à jour d'un service et le moment où
les problèmes sont découverts et résolus. Comme indiquer sur la figure suivante :

21
Approche traditionnelle et absence de qualité à la source

• Une équipe DevOps ayant l'esprit de service développe un produit en utilisant le

cycle de vie comme indiqué dans la figure suivante :

22
Approche traditionnelle et absence de qualité à la source

23
Réalités du développement et des opérations

Dev et Ops prennent chacun des mesures pour améliorer la

qualité et la vélocité de leur travail:

▪ Pratiques de développement logiciel Agile et Lean

▪ Pratiques de gestion des services Agile et Lean
▪ Infrastructure virtualisée et en cloud de fournisseurs internes et externes
▪ Infrastructure as a code (IaaC)
▪ Outils d'automatisation et de gestion de la configuration des centres de
données
▪ Technologies de supervision et d'autoréparation

Malheureusement, Dev et OPS ne travaillent pas ensemble sur

ces initiatives

24
 Lean IT, Agile, ITIL and DevOps
• LSD – “Lean Software Development” Application de l'approche "Lean IT" au développement
de logiciels - mêmes principes que l'approche "Agile".
• Puisque l'un des principes Agile (et aussi très Lean) est de faire travailler les commerciaux et les
développeurs ensemble quotidiennement tout au long du projet, ne devrions-nous pas l'appeler
BusDevOps... ou gestion de la chaîne de valeur (value stream management)
• Bien qu'il s'agisse d'approches indépendantes, elles présentent de nombreuses synergies. Une
équipe DevOps pourrait utiliser :
• Approches agiles pour accélérer le TTM(Time To Market) principalement du côté du
développement (utiliser les méthodologies SCRUM et XP), et impliquer l'entreprise (utiliser
les rôles de "Product Owners" comme "Business Ambassadors").
• Techniques Lean pour créer et faire évoluer l'équipe DevOps tant du côté Dev que du côté
Ops (Team Vision, Visual Management, Team Leader Agenda, Retrospective Meeting, VSM,
VoC, …)
• ITIL Knowledge et les bonnes pratiques pour accélérer l'amélioration continue.

25
Lean est un changement de paradigme
Traditionnel Lean

Les managers ont toutes les réponses Le manager doit poser les bonnes
questions, les employés doivent avoir les
réponses en tant qu'équipe.
Les managers réfléchissent, les Les managers aident les travailleurs à
travailleurs se concentrent sur apporter de la valeur ajoutée
l'action
Les activités sont réalisées parce qu'on leur Les activités ne sont réalisées que si elles
demande d'être réalisées apportent une valeur ajoutée pour le client

Un certain taux de défaillances est inévitable Les défaillances peuvent être éliminées

Le savoir, c'est le pouvoir Le pouvoir vient du partage des

connaissances et de leur application en
équipe
 Lean, Agile et DevOps - Similarités et différences

Lean IT Agile/Scrum DevOps

Points d'intérêt La valeur pour le client Améliorer le TTM Réduire l'inefficacité des silos

Organisation Tout ou les petits processus Business & Projects Projects & Operations

Mgmt. Visuel Noyau Noyau Recommendé

Mode de Gestion de projet et des équipes Fusion des équipes(Dev

Transformation intégrale
collaboration Devs et Ops)
Project Management
Processus Valeur des Flux ITSM et PPM processes
(SCRUM, XP, ..)
Tools / CTQ, VSM, Team Vision, User stories, Kanban, Tests automatisés,
Artifacts DILO, Kaizen, A3… Product Owner Continues Deployment(CD)
% Projets réussis
% Post-release incidents
% Initiatives d'amélioration % User stories
Objectifs / % Chgmt réussits/Lancement
% Économies de temps implémentées, et le
Indicateurs %Team performance (E2E)
et de coûts Business satisfaction
28
Synergies Lean, Agile et DevOps

• Il existe des synergies entre les trois

approches, bien que vous puissiez
suivre votre chemin indépendamment.
• Il n'y a pas de parcours recommandé -
Lean bien qu'à l'étranger, la concentration de
IT Lean puisse vous guider pour couvrir
les besoins les plus urgents.
• Ils ne sont pas une fin en soi, mais ils
vous aident à atteindre vos objectifs et
à répondre à vos exigences (agilité,
efficacité, déploiement continu,
livraison continue, amélioration
continue, ...).
DevOps Agile / • Lean est l'approche la plus globale,
Scrum vous pouvez utiliser cette philosophie
aussi bien pour un département
particulier que pour l'entreprise dans
son ensemble.

29
DevOps est une évolution

30
DevOps est une évolution

Design Code Build Integrate Test Release Deploy Operate

DevOps
Continous Deployment
Continous Delivery
Continous Integration
Agile Development

31
3. Quel problème
DevOps permet-il de
résoudre ?
Pourquoi DevOps s'est-il créé ? C'est la solution à un ou
plusieurs problèmes ...

Quels sont les problèmes que nous résolvons ?

• Délai de livraison
• Qualité de livraison
• Manque de compréhension entre les Devs et les Ops
• Capacité à s'assurer que les demandes des clients sont traitées de
manière transparente
• Rapprocher les personnes qui travaillent au même service IT
• Prévenir les burnouts

33
Importance du Feed-Back: Un modèle à trois voies

34
Les trois voies
▪ La première voie - Le flux
▪ Comprendre et accroître le flux de travail (de gauche à droite)

▪ La deuxième voie – Feedback

▪ Créer des boucles de feedback courtes qui permettent une amélioration
continue (de droite à gauche)

▪ La troisième voie – Expérimentation et apprentissage continus

▪ Créer une culture qui encourage:
▪ Expérimentation, prise de risques et apprentissage par l'échec
▪ Comprendre que la répétition et la pratique sont les conditions préalables à
la maîtrise.

2 1

3 35
4. La mission des DevOps
DevOps augmente l'agilité et la stabilité

▪ Les organisations qui adoptent DevOps sont plus susceptibles d'être

performantes.
▪ Les organisations sont plus agiles(flexibles)
▪ Le code est expédié 30 fois plus vite
▪ Les déploiements sont 8000 fois plus rapides
▪ Les services sont plus fiables
▪ Il y a 50 % d'échecs en moins
▪ Le service est rétabli 12 fois plus vite
(source: 2013 State of DevOps Report – Puppet labs and IT revolution press)

42
Même rythme entre l'entreprise et l’IT

Les processus d'entreprise changent au fil du temps de manière évolutive.

Les services informatiques qui permettent la mise en œuvre de ces processus
doivent donc également évoluer.
Who is best

“Amazon has become famous for its high-

velocity deployment of more than 2500
software releases per day across its various
Cloud solution offerings. And there are
similar storied successes at eBay, Etsy,
Facebook, Netflix, Spotify, Twitter.”
[Link]

44
5. Flux
2 La solution Flux

Le problème réside dans le fait que le Dev et l’Ops utilisent différents processus

“The important theme of DevOps is that the

entire development-to-operations lifecycle
must be viewed as one end-to-end process.
Individual methodologies can be followed for
individual segments of that processes (such
as Agile on one end and Visible Ops on the
other), so long as those processes can be
plugged together to form a unified process
(and, in turn, be managed from that unified Principales remarques
point-of-view). Much like the question of • Le développement utilise la méthode
measurement and incentives, each
organization will have slightly different Agile, Scrum, TDD
requirements for achieving that unified • Les opérations utilisent ITIL
process.”
What is DevOps? [Link]
• Les processus sont perçus comme
étant différents, voire incompatibles
• Personne n'a de vision globale (end-
to-end view)
3 Aspects clés par dimension : Flux

Faire en sorte que les unités de travail "circulent" dans l'équipe pour apporter de la valeur ajoutée

Flux consiste à s'assurer que les unités de travail se déplacent

Flux rapidement à travers le processus.

Qu'est-ce que c'est ? Pourquoi est-ce

important
Connaissance des unités de Les choses auxquelles l'équipe Améliorer ses performances
travail consacre du temps pour chaque unité de travail

Avoir conscience des Comment chaque unité de travail Développer des habitudes
processus doit-elle être traitée fructueuses favorise la performance
de l'équipe
Documentation Le degré de documentation des Contribue à normaliser les
des processus processus méthodes de travail

Suivi des Comprendre le statut de Favorise l'efficacité des flux

progrès(monitoring) chaque unité de travail

Orientation client Chaque processus commence L'équipe se concentre sur la

et se termine avec un client et garantie que les processus
apporte de la valeur.
47 délivrent de la valeur.
DevOps et ITSM

43
DevOps et ITSM

44
Flux pour la création et l'exploitation de services

45
L’approche Scrum

46
L’approche Scrum

47
L’approche Scrum

48
L’approche Scrum

49
L’approche Scrum

50
L’approche Scrum

51
L’approche Scrum

52
L’approche Scrum

53
 Automation Performance

Flux Continues Behavior &

Attitude

Flow Organization

54
 Automation Performance

Flux Continues Behavior &

Attitude

Flow Organization

55
6. Performance
 Automation Performance

Performance Behavior &

Attitude

Flow Organization

The problem is because Dev and Principales remarques

Ops measure performance in a • Chgmt vs. Stabilité
different way • Chgmt rapide vs. Chgmt lent
“DevOps promises more releases in a • Différents indicateurs de
short timeframe in order to adapt to performance clés (KPI) utilisés dans
problems or changes in the market le développement et les opérations
faster. […] It also means that the metrics • Dev et Ops ont des objectifs
defined by each team can be différents
automatically measured and
automatically communicated and shared
with everybody that relies on them to
make decisions.”

Best Practices for Performance-focused

DevOps, [Link]

62
 Automation Performance

Aspects clés par dimension Behavior &

Attitude

Flow Organization

La performance consiste à comprendre comment se porte l'équipe. En apportant de la

valeur au client, la performance doit être durable.
C’est quoi? Pourquoi c’est important?
Indicateurs de Des indicateurs pour Montrer à l'équipe comment
performance comprendre les elle se comporte. Identifier les
(KPI) performances de l'équipe améliorations
Réduction de la dette Santé du service Orienter les solutions vers des
technique choix architecturaux

Niveau de performance Comprendre les performances Facteur d'hygiène de base pour les
sur de petites unités de travail clients.
Niveau de performance Understanding of performance Orienter la plus grande valeur
(Créativité) on larger units of work or ajoutée pour l'entreprise
specials

L'utilisation du temps Compréhension de l'utilisation Piloter l'utilisation du temps afin

(gain/utilisation) du temps au sein de l'équipe d'optimiser le temps disponible
pour le travail créatif

58
 Automation Performance

Mesurer le succès Behavior &

Attitude

Flow Organization

Les pratiques qui permettent aux organisations de comprendre et

d'améliorer les flux permettent d'améliorer les performances informatiques

▪ Les performances informatiques sont mesurées en termes de débit et de

stabilité:
o Le débit est mesuré par la fréquence de déploiement et le délai de
mise en œuvre des changements.
o La stabilité est mesurée par le temps moyen de récupération et la
capacité à détecter et à atténuer les problèmes de manière
préventive.

▪ Deployment frequency – mean time between deploys

▪ Cycle time – Time from start of work to ready for delivery
▪ Change Failure rate
▪ Mean time to detect incidents (MTTD)
▪ Mean time to recover (MTTR) – Component
▪ Mean time to restore (MTRS) - Service
59
7. Comportement &
attitude(Culture)
 Automation Performance

La culture, c'est avant tout Behavior &

Attitude

Flow Organization

Le changement,
c'est bien

Communication Outils

Honnêteté et
Transparence
ouverture
d'esprit

Récompenser les
Collaboration Culture bons
comportements

L'innovation à la
Confiance base

Accepter
Responsabilité
l'échec
Pas de
reproche

61
 Automation Performance

La culture Dev et Ops Behavior &

Attitude

Flow Organization

The problem is a mismatch of cultures Principales considérations

between Dev and Ops • Changement et stabilité
“DevOps is simply a culture that brings • Changement rapide ou changement lent
development and operations teams together • Les personnes chargées du
so that through understanding each others’
développement sont différentes des
perspectives and concerns, they can build
and deliver resilient software products that personnes chargées des opérations
are production ready, in a timely manner.
DevOps is not NoOps. Nor is it akin to
putting a Dev in Ops clothing. DevOps is
synergistic, rather than cannibalistic.”
Fresh Stats Comparing Traditional IT and
DevOps Oriented Productivity, [Link]

62
 Automation Performance

Aspects clés par dimension Behavior &

Attitude

Flow Organization

Une équipe de professionnels compétents ayant l'attitude, le comportement et la motivation

nécessaires pour fournir d'excellentes performances
Qu'est-ce que c'est ? Pourquoi est-ce important ?

Formation d'équipes Compréhension du stade Aider une équipe à se "geler" pour

d'évolution de l'équipe fournirdes performances élevées

Collaboration Un environnement dans lequel C'est la base de l'amélioration et

les gens sont libres d'agir de l'apprentissage continus
ensemble
Résolution de Une méthode et un état d'esprit Assurer le progrès et l'excellence
problèmes pour résoudre les problèmes dans le service
Adaptation du Leadership en fonction des Le style du leader doit être
leadership besoins de l'équipe compatible avec les besoins de
l'équipe
Motivation Comprendre le niveau de Seules des personnes motivées
motivation de l'équipe peuvent produire d'excellentes
performances à long terme

63
 Automation Performance

Détruire les anciens Silos… Behavior &

Attitude

Flow Organization

Eliminez les silos et créez des Des équipes stables, regroupées, avec
équipes interfonctionnelles un objectif commun et un mandat
intégrées suffisant
▪ Surmonter le défi du changement par ▪ Équipes des produits et équipes des plates-
rapport à la stabilité formes
▪ Créer une responsabilité partagée au ▪ Des KPI d'équipe au lieu des KPI personnels
sein de l'équipe pour toutes les
exigences ▪ Parler le même langage
▪ Analyse, conception, ingénierie, essais, ▪ Chercher d'abord à comprendre, puis à être
intégration, livraison et déploiement compris
▪ Analyse, conception, ingénierie, essais, ▪ Outils (logiciels, tableau Scrum)
intégration, livraison et déploiement ▪ Rétrospective et stand-up quotidien
Resultas:
▪ Un feedback honnête et ouvert
▪ délai de livraison plus court !
▪ Formation, partage des connaissances
▪ plus de murs de confusion
▪ plus de confiance et de plaisir ▪ Événements de renforcement de l'esprit
d'équipe
▪ une qualité supérieure, un risque
moindre
64
 Automation Performance

... et créer la transparence Behavior &

Attitude

Flow Organization

La transparence consiste à obtenir un retour d'information:

▪ de la part du client/de l'entreprise
▪ de l'équipe
▪ du logiciel/système afin de l'améliorer en permanence : inspecter et adapter
▪ La transparence, c'est la visualisation des métriques

65
Faire évoluer la culture

66
Organisation
 Automation Performance

Changement de culture "Connectez" vos équipes Behavior &

Attitude

Flow Organization

• The problem is because Dev and Principales considérations

Ops have artificially been • Traditionnellement, nous avons
organizationally kept apart organisé les compétences en silos
• When we talk about “The Wall” between fonctionnels
the Teams (Dev, Test, Ops, Business) – most • Les développeurs sont assis à côté
industry professionals we have conversed des développeurs, les opérateurs à
with understand and recognize the des opérateurs, etc.
concept. So – these walls exist – and we
have to tear them down. The best way to
start is by inviting Testing and Operations
to your daily development Stand-Ups. Let
them listen in what you are currently
working on. Invite them to your sprint
reviews and planning meetings so that they
see what is coming down the pipeline.
• Best Practices for Performance-focused
DevOps,
• [Link]

75
 Automation Performance

Aspects clés par dimension Behavior &

Attitude

Flow Organization

Les responsabilités de l'équipe et l'obligation de rendre des comptes, et qu'elle est capable de les assumer.

Qu'est-ce que c'est ? Pourquoi est-ce important ?

Définition non ambiguë du Sens de ses responsabilités et

Définition du
service service de ses objectifs

Définition du client Définition claire des Compréhension de la valeur

destinataires du service du service
Complémentarité de Les compétences, les connaissances Veiller à ce que l'équipe puisse assumer
l'équipe et les rôles nécessaires pour fournir l'entière la responsabilité du service
le service
Dépendance à l'égard Compréhension des ressources Optimiser la liberté d'agir au nom
d'autres équipes partagées et des dépendances du client

Pratiques de Gestion visuelle et autres pratiques Faciliter le travail de l'équipe en

management de gouvernance pour faciliter le apportant valeur
travail de l'équipe

69
 Automation

Faciliter les relations commerciales avec les clients Behavior &

Attit

Flow Organization
Structure
2 L'organisation des équipes et la
gouvernance

Structure

1
IT orientée vers
le service 4
3
(‘DevOps’)
Haute performance
Integration Modèle d'équipe
Modèle d'intégration Haute performante pour
DevOps pour guider Intégration performance guider l'équipe de
l'intégration des direction et les
équipes Dev et Ops. équipes DevOps

70
 Automation Performance

1 Définir les IT orientées vers le service en fonction Behavior &

du client, du service et des compétences requises Attitude

Flow Organization

Le client IT Service(s)
• Personne ▪ Toutes les
responsable du fonctionnalités qui
processus soutiennent les
commercial processus
• Les usagers du d'entreprise
service ▪ Apporter la valeur
ajoutée demandée
Equipe DevOps par les clients
▪ Responsable de la "santé" d'un service
▪ Contient toutes les connaissances et
compétences nécessaires pour soutenir et
développer le service
71
Service en Cloud

72
Modèle organisationnel : DevOps

• L'équipe chargée des systèmes d'entreprise gère les utilisateurs finaux

(clients), les services et les produits (applications).
• L'équipe chargée de la plate-forme, qui gère le produit de la plate-forme
utilisé par les équipes chargées des systèmes d'entreprise
73
 Automation Performance

1
Déterminer le périmètre d'une équipe DevOps
Behavior &
Attitude

Flow Organization

‘Technology Stack’ du service

‘Team’ Presentation Layer
Security Layer
SaaS
Desktop Infrastructure ‘Technology stack’
Application Layer determines:
▪ Le domaine de
Development Platform
responsabilité de
Database PaaS l'équipe
Operating System ▪ L'ensemble des
Server compétences requises
Storage pour l'équipe
Network IaaS

‘Cloud’

Une équipe DevOps est responsable de toutes les facettes de :

• La "santé" d'un service
• L'adéquation permanente du service avec le processus commercial qu'il
soutient
74
Focus sur les produits et services

75
 Automation Performance

1
Comprendre la demande
Behavior &
Attitude

Flow Organization
Client
Equipe DevOps

76
 Automation Performance

1
Poursuite du déploiement au sein de l'équipe Behavior &
Attitude

Flow Organization

77
 Automation Performance

1 La manière de travailler au sein des équipes Behavior &

Attitude

Flow Organization

78