Les 5 Pratiques Fondamentales Des DevOps

Les 5 pratiques
fondamentales
des DevOps
Comment les mettre en place
et les développer
Sommaire
Introduction .....................................................................................................................................1 Mise en œuvre des pratiques fondamentales dans votre organisation...................... 42
Choisissez votre aventure...........................................................................................................................2 Mais...rien ne sert de courir il faut partir à point.........................................................................46
La frise de l’évolution.....................................................................................................................................4 Partagez maintenant avec d’autres équipes.................................................................................48
Pratiques fondamentales et modèles CAMS...................................................................................7 La meilleure voie est celle qui donnera des résultats rapides............................................50
Tout est question de partage....................................................................................................................8
A propos de l’auteur............................................................................................................................................53
Les 5 pratiques fondamentales, une par une...................................................................... 10
Supervision et alertes sont configurables par l’équipe qui gère le service................ 12
Que mesurer et comment........................................................................................................................ 16
Importance du suivi des métriques métier.................................................................................... 18
Mesurer est un élément essentiel des DevOps...........................................................................26
Réutiliser les motifs de déploiement pour construire des apps ou services.............28
Réutiliser les motifs de test pour construire des apps ou services................................32
Contribuer à l’amélioration de l’outillage fourni par d’autres équipes............................36
Les configurations sont gérées par un outil de gestion dédié............................................38

Introduction
Il a fallu moins d’une décennie pour que les DevOps
passent du statut de nouveauté à la mode à celui
de bonne pratique reconnue pour la gestion des
changements technologiques et la livraison des
logiciels dans un environnement commercial
extrêmement dynamique et compétitif. Mais en
dépit des nombreux exemples présentés lors des
conférences techniques du monde entier, dans les
livres et dans les blogs réputés, la plupart des équipes
ont encore des difficultés à mettre en place les
DevOps et à savoir quoi faire ensuite.
Le Rapport Puppet 2018 sur l’état des DevOps a adopté une nouvelle approche cette année
et cherché à mettre en avant des directives à l’intention des équipes. Nous avions rédigé notre
enquête dans le but de savoir comment les organisations progressent dans leur parcours DevOps
et, après avoir analysé les données, nous avons découvert que celles qui réussissent le mieux
ont suivi des étapes bien spécifiques. Notre enquête a également mis au jour un ensemble de
pratiques de base que nous appelons « pratiques fondamentales » et qui sont indispensable
pour la réussite de l’ensemble de la transformation DevOps. Dans cet article, nous allons vous
présenter une description détaillée de ces pratiques fondamentales et vous proposer nos
conseils pour les mettre en œuvre de la façon la plus judicieuse au sein de votre organisation, en
nous appuyant sur nos résultats.
Les 5 Pratiques Fondamentales des DevOps : comment les mettre en place et les développer | Splunk 1
Choisissez
votre aventure
Le point de départ de chaque entreprise Chaque pratique fondamentale peut être
est unique. Il est constitué des technologies résumée en une phrase:
héritées, des façons de faire établies, ses
La surveillance et les alertes sont
missions commerciales spécifiques de
configurables par l’équipe qui gère le
l’entreprise et de sa culture particulière. Il
service.
n’existe donc pas de voie unique pour la
transformation DevOps, mais plutôt de Les motifs de déploiement sont
nombreux parcours d’évolution possibles. réutilisés pour élaborer des applications et
des services.
Les motifs de test sont réutilisés pour

L’analyse des données de l’étude 2018 sur
élaborer des applications et des services.
l’état des DevOps a révélé les pratiques
fondamentales utilisées par les équipes. Ces Les équipes apportent des
pratiques sont si étroitement corrélées au améliorations aux outils fournis par
succès DevOps que nous en avons conclu d’autres équipes.
qu’elles sont essentielles à chaque étape
du développement des DevOps. En d’autres Les configurations sont gérées à l’aide
termes, les pratiques qui doivent être d’un outil de gestion dédié.
adoptées à une étape donnée pour passer à Lorsque nous avons examiné plus
la suivante conservent leur pertinence même précisément chacune de ces pratiques, nous
pour les entreprises qui sont plus avancées avons découvert que les entreprises les
dans leur parcours et qui affichent déjà des plus évoluées (voir La frise de l’évolution)
résultats brillants. étaient bien plus susceptibles d’utiliser
systématiquement ces pratiques tout au long
du parcours d’évolution que les entreprises
moins avancées.
Nos conclusions sont nettes : les pratiques

fondamentales énumérées ci-dessus
font partie intégrante des DevOps et
indispensable à leur réussite.
90%
Intermédiaire
La frise de l’évolution
Pour produire le Rapport 2018 sur l’état 90 % des entreprises participantes étaient
des DevOps, nous avons mis au point un au moins dans la catégorie « Intermédiaire ».
modèle visant à mesurer la position de Près de 11 % étaient « Faible » et un peu
chaque entreprise participante sur la moins de 10 %, « Avancée ». On en déduit
11% 10%
frise de l’évolution. Nous avons noté les
réponses en comptabilisant la fréquence à
que les pratiques DevOps sont devenues
courantes et qu’il est bien plus difficile de
Faible
Avancé laquelle chaque organisation participante passer du stade intermédiaire à avancé
appliquait chaque pratique (1 = jamais ; 2 que du stade faible à intermédiaire. On
= rarement ; 3 = parfois ; 4 = la plupart du peut ensuite extrapoler que les entreprises
temps ; 5 = toujours). Nous avons ensuite peuvent acquérir un avantage compétitif
résumé ces scores pour produire un considérable en se concentrant sur
score composite. En fonction de ce score l’évolution de leurs pratiques DevOps.
composite, nous avons groupé les réponses
Nous pensons que le passage au stade
en trois catégories : Faible, Intermédiaire et
intermédiaire demande moins d’effort
Avancé. Les entreprises qui emploient toutes
parce que le parcours d’automatisation est
les pratiques à une fréquence élevée sont
relativement bien défini, mais l’accès au
hautement évoluées, donc « Avancées ». Les
stade avancé nécessite la création d’une
entreprises qui emploient les pratiques à une
culture DevOps et de processus de partage
fréquence basse sont « Faibles » et celles
qui sont bien plus difficiles à appréhender et
qui les appliquent de temps à autre sont
concrétiser.
« Intermédiaires ». Consultez la méthodologie
complète du Rapport Puppet 2018 sur l’état
des DevOps pour une explication détaillée.
Pratiques fondamentales
et modèle CAMS
Quiconque a pour les DevOps un intérêt de l’importance des indicateurs au partage
authentique ne sera pas surpris par en passant par l’impératif d’automatisation.
l’importance des éléments fondamentaux de D’autres tropes et méthodologies
Culture
cette approche. D’autres concepts réputés courantes dans le discours DevOps –
sont élaborés sur les mêmes fondements. mouvement latéral, autonomie des équipes,
Le modèle CAMS,1 qui est l’une des toutes développement basé sur les tests, etc. –
Automatisation
premières descriptions des DevOps, englobe viennent encore renforcer ces pratiques
ces pratiques fondamentales et reconnues, fondamentales.
Mesure
Partage
1 Culture, Automatisation, Mesure, Partage (Sharing). Le modèle CAMS a été défini par Damon Edwards et
John Willis en 2010. Pour une discussion plus détaillée du modèle CAMS et des DevOps, consultez « CAMS et
le modèle d’évolution DevOps, » un chapitre du Rapport Puppet 2018 sur l’état des DevOps.
Tout est question de
partage
En étudiant les pratiques fondamentales révélées par notre étude, nous avons pris conscience
qu’elles reposent toutes sur le partage et que toutes l’encouragent.
La supervision et les alertes sont configurables par l’équipe qui gère le service. La
surveillance et les alertes sont la clé du partage des informations sur l’état des systèmes et
des applications, et elles sont indispensables pour atteindre une compréhension commune
de la situation. Cette compréhension commune est vitale pour apporter des améliorations,
que ce soit au sein d’une seule équipe ou fonction ou à une échelle plus vaste.
Les motifs de déploiement et de test sont réutilisés pour élaborer des applications et
des services. Partager les motifs qui fonctionnent entre plusieurs applications et services
implique souvent de les partager entre différentes équipes, en établissant des méthodes de
travail convenues servant de fondement à de futures améliorations.
Les équipes apportent des améliorations aux outils fournis par d’autres équipes. Cette
forme de partage encourage les discussions entre les équipes au sujet des priorités et des
projets d’amélioration des outils, des processus et des mesures.
Les configurations sont gérées à l’aide d’un outil de gestion dédié. Un outil de gestion
des configurations permet aux équipes de développement et de sécurité ainsi qu’aux
autres équipes en-dehors des Opérations d’apporter des modifications aux configurations
du système et des applications. La responsabilité de l’opérabilité et de la sécurité est ainsi
partagée entre les différentes fonctions de l’entreprise.
Nous avons observé que toutes les pratiques fondamentales permettent ou reposent sur le
partage, ce dont nous pouvons déduire que la clé de l’élargissement des DevOps réside dans
l’adoption de pratiques qui encouragent le partage.
C’est logique : quand on voit une approche qui fonctionne bien, on cherche à reproduire cette
réussite et à la faire connaître. Imaginons que votre équipe ait réussi à déployer une application
10 fois, alors que ce type de déploiement est généralement source de nombreuses difficultés
pour votre équipe (et pour d’autres). Il y a fort à parier que quelqu’un s’en apercevra et voudra
savoir comment vous avez fait. C’est comme cela que les pratiques DevOps se diffusent chez
plusieurs équipes.
Les cinq pratiques
fondamentales,
une par une
Dans cette section, nous décrivons chacune des
pratiques fondamentales en détail, en précisant
de quelle façon la pratique en question contribue
à l’évolution des DevOps.
La supervision
et les alertes
sont configurables Au cœur du mouvement DevOps se trouvent l’autonomie et la responsabilité –
par l’équipe qui gère les deux faces d’une même médaille – ce que Werner Vogels, directeur technique
d’Amazon, résume dans cette célèbre déclaration : « Ce que vous développez, vous
le gérez »2 Notre étude a donc cherché à savoir combien d’équipes supervisant des
le service applications et des services en production – qu’elles soient composées de développeurs,

d’opérateurs, d’ingénieurs de publication ou autres – ont la possibilité de définir leurs
propres critères de surveillance et d’alerte.
Les équipes autonomies qui administrent des applications et des services en production
savent définir ce qu’est un bon service, comment déterminer s’il fonctionne correctement
et comment savoir si ce n’est pas le cas. Cette approche autonome de la surveillance
peut prendre de nombreuses formes. Par exemple :
« Déposez une configuration de surveillance à tel emplacement et nous la mettrons en

place. »
« Connectez-vous à cette interface web pour configurer votre surveillance. »
« Ajoutez des sorties que l’on puisse interroger à votre code d’infrastructure. »
« Voici une API pour configurer la surveillance sous forme de code. »
Selon nos observations des entreprises qui enregistrent de bons résultats avec les
DevOps, 47 % des organisations avancées sont en mesure de définir leurs propres
critères de surveillance et d’alertes pour les applications et les services en production,
contre 2 % seulement au sein de la cohorte faible. La cohorte avancée est 24 fois plus
susceptible d’avoir adopté cette pratique ! À l’inverse, elle était mise en œuvre 23 fois
moins souvent au sein de la cohorte faible.
2. Gray, J., Vogels, W., A Conversation with Werner Vogels, ACM Queue, https://queue.acm.org/detail.cfm?id=1142065,
June 2006, juin 2006, consulté en août 2018.
Les 5 Pratiques Fondamentales des Devops : comment les mettre en place et les développer | Splunk 13
SUPERVISION ET ALERTES
Dans notre étude, nous avons demandé « À quelle

fréquence avez-vous appliqué ces pratiques
Faible Intermédiaire Avancé
après avoir commencé à enregistrer de bons
résultats avec les DevOps ? » À droite se trouve Toujours 2% 17% 47%
La plupart du temps 8% 37% 47%

la répartition des réponses pour la pratique « La Parfois 27% 32% 5%
surveillance et les alertes sont configurables par Rarement 38% 11% <1%
l’équipe qui gère le service. » Jamais 23% 3% —
Donner aux équipes les moyens de définir, gérer et partager leurs propres critères de
mesure et d’alerte favorise plusieurs aspects de la transformation DevOps :
Le partage des indicateurs encourage l’amélioration permanente
Création et promotion d’une culture de l’apprentissage continu
Collaboration inter-équipes et autonomie des équipes
Développement d’une réflexion systémique chez les personnes et au sein des équipes
Ces facteurs sont essentiels pour une culture DevOps solide, comme nous en avons
discuté plus tôt, et on ne sera donc pas surpris que les organisations les plus avancées que
nous ayons interrogées aient adopté cette pratique de façon précoce.
56%
Que mesurer—
Nous mesurons
manuellement les
métriques système
Et comment essentielles.
43%
Nous mesurons
Notre enquête a mis en évidence les éléments à surveiller et des critères d’alerte : automatiquement les
Indicateurs techniques clés tels que la latence, les temps de réponse, l’utilisation métriques système
essentielles.
des ressources, etc. Une majorité de participants (56 %) les évoquent.
Objectifs commerciaux dérivés des indicateurs techniques : par exemple, le délai

de réponse peut être une mesure de la satisfaction des clients. Plus d’un tiers des
participants (37 %) mesurent ces indicateurs.
Accès à la demande à de véritables indicateur métier tels que le temps passé sur
le site, les ouvertures d’applications, les inscriptions de clients, les taux de revenus,
etc. Ces indicateurs sont disponibles chez 20 % des participants.
Au fil de leur évolution, les organisations sont de plus en plus susceptibles d’intégrer
des techniques de mesure automatisées à leurs pratiques de surveillance. Parmi
les entreprises les plus avancées de notre étude, 66 % mesurent automatiquement
20%
les métriques système, contre 32 % seulement des entreprises situées à l’autre Les indicateurs
métier sont
extrémité du spectre de l’évolution DevOps. La génération manuelle de métriques
automatiquement
système concerne 59 % des entreprises peu avancées contre 38 % seulement des
organisations hautement évoluées.
disponibles sur
demande.
37%
Les indicateurs
métier sont collectés
manuellement à
l’aide des métriques
système.
Évolution Évolution Évolution
Importance du suivi faible intermédiaire avancée
des métriques métier 66%

58%
59%
Lorsque les entreprises évoluent, la façon dont elles mesurent leurs résultats
commerciaux change également.
42%
Notre étude montre qu’aux plus hauts niveaux d’évolution DevOps, les entreprises
sont presque cinq fois plus nombreuses (34 %) à recueillir automatiquement des
38%
38% 36%
métriques métier, alors que 7 % seulement des entreprises moins avancées ont 26% 34%
automatisé la collecte des indicateurs commerciaux. 26%
Certaines équipes informatiques utilisent ces métriques comme mesure principale
des performances de l’IT. Par exemple, les ingénieurs en fiabilité du site d’un service 19%
de diffusion vidéo vont suivre le nombre de « démarrage de vidéo réussi » comme
indicateur principal de l’état du service, tandis que les développeurs d’un service 7%
de jeu en ligne surveilleront le nombre d’inscriptions et d’annulation, ainsi que les
sommes pariées et versées, pour mesurer le succès d’une nouvelle publication.
Nous mesurons manuellement les métriques système essentielles.
Nous mesurons automatiquement les métriques système essentielles.
Les indicateurs des objectifs métier sont collectés manuellement

à l’aide des métriques de niveau système.
Les indicateurs des objectifs métier sont automatiquement

disponibles sur demande.
Les métriques métier répondent à des

questions quotidiennes:
Est-ce que les clients sont en mesure de faire des achats chez nous ?
Combien de personnes servons-nous ?
Combien gagnons-nous ?
Ce motif est-il normal ?
Les métriques métier sont également

essentielles pour mesurer le succès à
plus long terme
Est-ce que la nouvelle version rencontre le succès escompté ?
Est-ce qu’elle donne de meilleurs résultats commerciaux ?
Quel est son impact sur l’entreprise par rapport aux autres versions ?
Pour les entreprises plus avancées qui utilisent l’analyse de données, le machine learning
et l’intelligence artificielle, les données métier peuvent offrir des signes avant-coureurs
d’échec – baisse des revenus par minute, taux de rebond plus élevé que d’habitude, etc. –
pouvant être causés par des erreurs non détectées sur le site.
La surveillance des indicateurs commerciaux peut aussi permettre à une équipe d’obtenir
des ressources supplémentaires pour son initiative DevOps en apportant des preuves de
succès tangibles dans des termes compréhensibles par les interlocuteurs métier.
SURVEILLANCE ET ALERTES
Observabilité, télémétrie et Observabilité des systèmes industriels
journalisation sémantique Observability in industrial systems
Parmi les entreprises les plus avancées, 51 % déploient des systèmes de journalisation
parallèlement aux applications et services afin de faciliter la surveillance et la
production d’alertes en aval, dans les opérations de production. Cette pratique apporte
ce que l’on appelle « observabilité », une caractéristique qui permet de déduire l’état
interne d’un système à partir de la connaissance de ses résultats externes.
Faible Intermédiaire Avancé
Toujours 3% 16% 51%
La plupart du temps 7% 39% 44%
Parfois 23% 32% 5%

Rarement 37% 10% <1%
Jamais 30% 4% <1%
Le terme « observabilité » est utilisé pour les systèmes industriels et elle peut être
obtenue très simplement, par exemple en ajoutant une jauge de débit dans une
conduite d’eau (mesure interne) et en la connectant à un affichage externe (télémétrie).
Ce dispositif permet à un opérateur d’observer une propriété interne du système (la
vitesse à laquelle l’eau s’écoule dans un tuyau) en observant un résultat externe (le
débit-mètre monté à l’extérieur de la conduite).
Les 5 Pratiques Fondamentales des DevOps : comment les mettre en place et les développer. | Splunk
Observabilité des systèmes logiciels
Dans une application, l’observabilité est souvent acquise par l’ajout d’une
journalisation sémantique décrivant son activité réelle, ce qui peut inclure à la
fois des métriques techniques telles que le délai de réponse de bout en bout, et des
indicateurs métier comme les revenus par transaction. Cela permet aux équipes de
configurer leur surveillance à l’aide de véritables indicateurs de succès – aussi bien
technique de métier – plutôt que de se contenter d’approximations reposant sur des
signes moins fiables.
L’observabilité permet aux équipes de travailler avec des architectures modulaires

modernes comme le cloud, les microservices, les conteneurs, les API et les
infrastructures sans serveur. En dépit de leurs nombreux avantages, ces architectures
n’offrent souvent aucune visibilité sur les performances de l’infrastructure, aucune
possibilité d’injecter du code d’instrumentation ni aucun moyen d’exécuter des
transactions synthétiques. Dans ces systèmes complexes et opaques, utiliser la
journalisation sémantique (et d’autres techniques) pour intégrer l’observabilité dans le
système dès la publication de version, confère un contrôle maximal aux équipes DevOps
qui peuvent définir et configurer une surveillance pertinente.
Mesurer, un éléments
essentiel des DevOps
La supervision autonome n’intéresse pas seulement les Opérations ou les équipes Quelles que soient les circonstances, l’approche « libre-service » de la surveillance
DevOps fraîchement formées : elle est utile à toutes les équipes qui travaillent avec et des alertes s’impose comme une contre-mesure face à l’isolement traditionnel
des technologies. L’adoption de la supervision autonome dans toutes les équipes souligne du développement et des opérations. Il suffit d’ouvrir l’accès à ces indicateurs clés
l’un des aspects essentiels des DevOps : nul besoin de créer une nouvelle équipe dotée pour favoriser une culture du partage, créer des boucles de rétroaction, permettre le
de superpouvoirs, il vaut mieux donner de nouveaux moyens aux équipes en place afin feedback continu et encourager l’apprentissage permanent au sein des équipes.
qu’elles puissent collaborer de façon plus fructueuse.
La transformation culturelle DevOps repose fortement sur l’autonomie et la
La surveillance et les alertes en libre-service s’avèrent aussi accessibles qu’utiles pour : responsabilisation, qui s’instillent en donnant aux équipes d’exécution la possibilité de
Les développeurs qui administrent leur propre code, collecter, partager et personnaliser les données de performance, et ce changement
d’approche entraîne de nouvelles évolutions plus fondamentales encore.
Une équipe de développeurs qui collaborent avec leurs collègues des opérations pour
livrer des applications administrables,
Une équipe DevOps travaillant en tant que groupe autonome pour définir ses propres
pratiques de surveillance,
Un groupe complexe d’équipes dans lequel des spécialistes des opérations assurent la
supervision des applications livrées par les développeurs dans le cadre d’un système
plus vaste.
Réutiliser
les motifs de Notre étude met au jour une deuxième compétence de référence indispensable à la
déploiement réussite de l’approche DevOps : la possibilité de réutiliser des routines de déploiement,

des processus, des systèmes et des outils pour élaborer des applications ou même des
services de bout en bout.
pour construire des Une fois parvenues à une certaine maturité avec leurs initiatives DevOps, 46 % des
organisations participantes hautement évoluées indiquaient qu’elles réutilisaient
applications et des
toujours les motifs de déploiement pour élaborer des applications et des services,
contre 2 % seulement des organisations moins avancées. Les équipes « Avancées »
employaient donc cette pratique 23 fois plus souvent.
services
RÉUTILISER LES MOTIFS DE DÉPLOIEMENT
Nous avons demandé : « À quelle fréquence avez-vous appliqué ces pratiques
après avoir commencé à enregistrer de bons résultats avec les DevOps ? » Et
voici la répartition des réponses pour la pratique « Nous réutilisons des motifs de Nous avons posé la question de la réutilisation des
déploiement pour élaborer des applications et des services ».
motifs de déploiement en raison de la nature spéciale
FAIBLE INTERMÉDIAIRE AVANCÉ
du déploiement des applications dans la plupart
TOUJOURS 2% 14% 46%
des entreprises, sinon toutes. Situé à la frontière
LA PLUPART DU TEMPS 7% 44% 47%
34% 33% 6%
entre développement et production, le déploiement
PARFOIS
RAREMENT 40% 8% 1% d’applications est le point de rencontre le plus

JAMAIS 18% 1% — fréquent des développeurs et des opérations – et
bien souvent aussi un point de conflit. L’amélioration
du déploiement d’applications est donc au cœur
Nous avons demandé : « À quelle fréquence avez-vous appliqué ces pratiques lorsque
vous élargissiez votre approche DevOps ? » Voici la répartition des réponses pour la des DevOps qui vise à faire tomber le « mur de
pratique « Nous réutilisons des motifs de déploiement pour élaborer des applications
et des services ». confusion »3 à l’interface entre « dev » et « ops ».
TOUJOURS — 11% 52%

L’emploi de motifs réutilisables, qu’ils soient créés à l’interne ou qu’ils proviennent d’une
source extérieure, fait bien plus que soulager la pénibilité et la confusion propres au
PARFOIS 30% 35% 1% déploiement. C’est aussi un moyen de partager et de diffuser le savoir-faire du déploiement
RAREMENT 45% 8% — dans l’entreprise, ce qui permet à de nouvelles équipes et personnes de travailler ensemble
sur ce qui doit devenir une compétence fondamentale dans n’importe quelle entreprise.
JAMAIS 18% 1% —
3. http://dev2ops.org/2010/02/what-is-devops/
Réutiliser les Tout comme elles partagent et réutilisent les motifs de déploiement, les entreprises
qui sont les plus avancées dans leur évolution DevOps emploient des motifs de test
motifs de test
reproductibles.
Au stade où les DevOps commencent à donner des résultats, 44 % des organisations
très avancées indiquent qu’elles utilisent systématiquement des motifs de test
pour construire reproductibles, alors qu’elles sont moins de 1 % à le faire parmi les moins avancées.
Les entreprises avancées sont donc 44 fois plus susceptibles d’utiliser des motifs de
des applications
test reproductibles.
Nous avons demandé : « À quelle fréquence avez-vous appliqué ces pratiques après
avoir commencé à enregistrer de bons résultats avec les DevOps ? » Et voici la
et des services répartition des réponses pour la proposition « Nous réutilisons des motifs de test
pour élaborer des applications et des services ».
TOUJOURS <1% 10% 44%
PARFOIS 32% 39% 7%
RAREMENT 40% 11% <1%
JAMAIS 21% 2% —
REUTILISER LES MOTIFS DE TESTS
Les motifs de test peuvent être moins réutilisables que les motifs de
déploiement dans la mesure où les tests traitent des aspects spécifiques d’une
Les tests automatisés et la réutilisation de application ou d’un service et couvre de nombreux processus différents – tests de
fumée, tests unitaires, tests fonctionnels, tests de conformité, tests de complexité –
motifs de test peuvent constituer l’un des plus dans des environnements statiques (boîte blanche) ou dynamiques (boîte noire).
grands défis pour votre organisation, selon Les tests en production sont souvent plus délicats et complexes qu’en pré-
production, car leurs objectifs ne sont pas les mêmes. Les équipes de qualité qui
sa structure et sa complexité. Bien que l’on interviennent en pré-production testent la conformité, la stabilité, la sécurité, la
satisfaction des clients et d’autres objectifs fondamentaux. Avec la livraison en
observe cette pratique chez les organisations continu, les équipes peuvent réaliser des expériences en production pour tester de
nouvelles idées (déploiement bleu/vert, test du canari). C’est très utile mais cela reste
avancées dès les premières étapes de différent d’un test en production qui se concentre sur la qualité, la fonctionnalité, la
l’évolution DevOps, ce n’est pas forcément la résilience et la stabilité, entre autres.
tâche la plus urgente. Nous en concluons que l’adoption de processus de test réutilisables est une
pratique fondamentale, mais qu’elle est souvent reportée à un stade ultérieur du
parcours d’évolution, une fois les motifs de déploiement bien établis. Si vous devez
faire un choix, nous recommandons d’attendre pour les motifs de test et de donner
Quelques considérations pour bien hiérarchiser cette pratique : la priorité aux autres pratiques. Toutefois, une fois cette pratique adoptée, il est
important de veiller à ce que les motifs de test puissent être partagés. Par exemple,
Si vos équipes de qualité sont bien séparées des équipes de développement
vous pouvez encoder des tests réutilisables dans des outils de test automatisés et
et d’opérations, il est préférable d’attendre et de les intégrer ultérieurement
donner l’accès à ces outils – ainsi qu’aux rapports et tableaux de bord résultats – à
à l’initiative DevOps. Commencez par établir de solides motifs de test avec votre
toutes les parties concernées.
propre équipe. Pour l’équipe des opérations, cela peut consiste à mettre en place
un processus permettant de tester les changements d’infrastructure avant le
déploiement en production. Les équipes de développement, quant à elles, pourront
mettre en place une méthodologie de développement basé sur les tests (test-driven
development ou TDD) ou autre dans le cadre d’un workflow agile.
Les activités les plus proches de la production comme le provisionnement, la

surveillance, les alertes, etc. sont souvent plus prioritaires pour les équipes
car c’est souvent là que le plus de problèmes se manifestent. Commencez par
résoudre les problèmes propres au déploiement pour libérer du temps que vous
pourrez ensuite consacrer à l’amélioration de vos pratiques de test.
Contribuer à Une fois que les organisations parviennent au stade où elles élargissent leurs
pratiques DevOps, 44 % des plus avancées indiquent que les équipes peuvent
l’amélioration
systématiquement apporter des améliorations aux outils des autres équipes, alors
que c’est le cas pour moins de 1 % seulement de la cohorte faible. En d’autres
termes, la cohorte avancée est 44 fois plus susceptible d’employer cette pratique.
de l’outillage fourni par

d’autres équipes Nous avons demandé : « À quelle fréquence avez-vous appliqué ces pratiques
lorsque vous élargissiez votre approche DevOps ? » Voici la répartition des
réponses relatives à la pratique « Les équipes apportent des améliorations aux
outils fournis par d’autres équipes. »
La possibilité d’apporter des améliorations aux outils fournis par d’autres équipes
s’avère fondamentale.
TOUJOURS <1% 11% 44%
PARFOIS 26% 40% 11%
RAREMENT 46% 15% —
JAMAIS 23% 3% <1%
Lorsqu’une équipe améliore un outil, c’est souvent à la main, de façon ponctuelle, et

l’amélioration reste confinée dans le silo de l’équipe jusqu’à ce qu’un changement
justifie son élargissement à d’autres. Ce changement peut être une évolution
culturelle ou organisationnelle touchant toute une division, l’apparition de nouvelles
sources de données interfonctionnelles comme la journalisation sémantique ou
la mise en place d’une nouvelle collaboration entre différentes fonctions, afin
d’automatiser le provisionnement ou la publication, par exemple.
Comme l’amélioration des outils d’autres équipes nécessite d’abord que chaque
équipe mette de l’ordre chez elle, nous pensons que l’adoption de cette pratique
peut être reportée à un stade ultérieur avec les mêmes chances de succès.
Les configurations systématiquement la gestion des configurations, contre 2 % de celles de la
cohorte faible. Les organisations avancées sont donc 27 fois plus susceptibles
sont gérées par un

d’utiliser systématiquement un outil de gestion des configurations.
outil de gestion dédié Nous avons demandé : « À quelle fréquence avez-vous appliqué ces pratiques après
avoir commencé à enregistrer de bons résultats avec les DevOps ? » Voici la répartition
La pratique consistant à gérer les configurations à l’aide d’un outil dédié prend vite des réponses concernant la proposition « Les configurations sont gérées à l’aide d’un
racine lorsque les organisations commencent à cueillir les fruits de leur évolution outil de gestion dédié ».
DevOps. En effet, 53 % des entreprises de la cohorte avancée disent utiliser
TOUJOURS 2% 19% 53%
PARFOIS 28% 31% 8%
RAREMENT 36% 10% —
JAMAIS 24% 3% —
Pour les pratiquants DevOps de longue date, il n’est pas surprenant que cette
pratique émerge comme un facteur fondamental de succès. La gestion automatisée
des configurations a été un moteur essentiel des DevOps pendant de nombreuses
années, en particulier quand on commençait tout juste à envisager l’infrastructure
comme du code, et le mouvement DevOps s’est largement articulé autour des
premiers innovateurs dans le domaine de la gestion automatisée des configurations.
L’examen des premiers moteurs des DevOps explique l’importance de la gestion

des configurations.
LES CONFIGURATIONS SONT GÉRÉES
Lorsque les développeurs et les opérateurs ont commencé à travailler ensemble pour
résoudre les difficultés associées au provisionnement, il était naturel que de nombreuses
La consumérisation de l’informatique a initiative DevOps commencent par automatiser la configuration et le provisionnement.
C’est une solution gagnante pour les développeurs comme pour les opérations, car
stimulé une demande sans précédent en elle permet aux développeurs d’agir à la vitesse du marché tout en encapsulant et en
codifiant des configurations éprouvées pour réduire le fardeau des opérateurs.
termes de vitesse et de service, et face Avec l’évolution et l’élargissement des DevOps, et comme les développeurs, dont la
à cela, l’incapacité des développeurs à charge de travail a été allégée grâce à l’automatisation du provisionnement, adoptent de
plus en plus la livraison continue, les Opérations sont soumises à une pression accrue
provisionner et configurer des ressources clés quant au maintien de la disponibilité et de la performance en production. Des questions
de développement et de test – sans parler de de contrôle et d’audit émergent également avec la maturation des processus d’une
organisation. Par conséquent, l’automatisation de la configuration et du provisionnement
production – est devenue un frein important à devient tout aussi importante pour la production que pour le développement et le test.
Atteindre la répétabilité grâce à la gestion des configurations assure un environnement
la livraison rapide de logiciels de haute qualité de production stable, fiable et contrôlable, et rend également possible des capacités
ultérieures – le libre-service, par exemple – qui deviennent de nouveaux objectifs pour
répondant aux besoins des clients et des l’initiative DevOps.
entreprises. Enfin, l’importance de l’automatisation du provisionnement et de la configuration n’est

pas seulement liée à la vitesse. C’est également une protection contre l’une des toutes
premières craintes entourant les DevOps : que des développeurs autonomes puissent
Parallèlement à cela, les équipes des opérations IT étaient tout aussi frustrées par faire la loi dans les systèmes de production sans recours, sans audits et sans contrôle.
l’impossibilité d’apporter des changements substantiels aux applications et services La codification des processus éprouvés et leur exécution à l’aide de routines prédéfinies
qu’ils administraient, alors que ces changements devaient les rendre plus stables, plus vient répondre à ces craintes sans empêcher les équipes Dev et Ops de gagner en
efficaces et plus faciles à administrer. agilité. Dans les grandes organisations et dans les secteurs réglementés tels que la
santé, la finance et l’administration, l’automatisation offre l’avantage supplémentaire de
L’émergence du cloud computing a donné aux développeurs les moyens de répondre consigner chaque intervention sur un système avec son auteur, son contenu, ses date et
rapidement à leurs propres besoins simplement en sortant une carte de crédit. Mais heure ainsi que, bien souvent, sa justification.
cette nouvelle capacité est aussi source de problèmes et de frustration pour les
Opérations. Les développeurs ayant recours à l’IT de l’ombre, les équipes des opérations
se sont trouvées confrontées à une multitude d’outils aux configurations uniques,
difficiles à gérer, extrêmement fragiles et sources d’erreurs.
Mise en œuvre nos lecteurs veulent avoir des conseils sur leur mise en œuvre.
Heureusement, notre étude fournit plusieurs indices sur les
des pratiques
pratiques à adopter en priorité.
En général, nos recherches suggèrent de commencer par
fondamentales dans
établir des bases qui serviront de fondement à la croissance et
au développement à venir, tout en contribuant à délivrer une
valeur immédiate. La pratique par laquelle commencer dépend
votre organisation beaucoup de la situation de départ de l’entreprise et de ses

besoins les plus urgents. Toutefois, sachez bien que toutes les
pratiques fondamentales sont adoptées rapidement par les
Devant toutes ces preuves que ces pratiques fondamentales organisations avancées.
conduisent au succès des DevOps, nous savons que
Trois pratiques étaient toujours présentes Les deux autres pratiques fondamentales
chez la majorité des organisations avancées sont celles que nous recommandons de
au moment où leurs initiatives DevOps mettre en place une fois les trois premières
commençaient à donner des résultats : bien établies :
Réutilisation des motifs de déploiement Réutiliser les motifs de test pour élaborer des applications et des services
Utilisation d’un outil de gestion des configurations Donner aux équipes les moyens d’apporter des améliorations aux outils des autres équipes
Possibilité pour les équipes de configurer la surveillance et les alertes des services
qu’elles administrent
Ces pratiques sont toutes des compétences fondamentales et forme une base pour
progresser vers des niveaux supérieurs d’évolution DevOps, mais l’ordre dans lequel elles
sont mises en œuvre n’a pas d’importance. Le plus important est de commencer par ces
trois pratiques-là. L’une d’entre elle apparaîtra sans doute prioritaire pour votre entreprise.
Un point à garder à l’esprit : notre enquête suggère fortement que les entreprises doivent
avoir mis en place plusieurs bases avant de commencer à observer des résultats. Nous
recommandons par conséquent de s’efforcer d’adopter les trois pratiques ci-dessus puis
de les élargir à d’autres équipes aussi tôt que possible..
Mais. . . rien ne sert de
courir, il faut partir à point
Chaque entreprise est unique. Vous devez d’abord observer votre point de départ.
Identifiez la situation actuelle dans votre organisation et choisissez l’approche la
plus à même d’avoir rapidement un impact positif là où vous en avez le plus besoin.
Comme les pratiques fondamentales permettent d’améliorer la surveillance, le contrôle
des configurations, les motifs de déploiement et les contrôles qualité, mais aussi de
collaborer sur les outils, le choix est vaste.
Établissez et partagez des valeurs de référence pour les métriques du système, des
clients et des activités, afin que chacun sache d’où il part et ce qui doit être amélioré,
et puisse voir l’impact de son travail sur le système de bout en bout. Vous aiderez ainsi
tous les membres de l’équipe à adopter des concepts DevOps comme le feedback
continu et l’amélioration permanente.
Partagez dès que possibles les pratiques et les processus pour que toute
l’organisation progresse ensemble. Automatisez et élargissez horizontalement
l’automatisation de la configuration et du provisionnement pour aider les développeurs
à gagner en agilité, et les opérateurs à atteindre la prévisibilité. Les deux équipes
seront ainsi plus enclines à croire dans la valeur de cette aventure. Faciliter la vie
professionnelle des gens est une excellente manière de gagner leur confiance et de
s’assurer leur coopération à long terme.
Les motifs et les bonnes pratiques sont partagés...
Maintenant, partagez avec ...en-dehors de l’organisation.

...au sein de l’organisation.
d’autres équipes ...entre les équipes.
...entre les membres d’une même équipe.
L’une des hypothèses clés de notre étude était que – tout comme dans le cas de la
culture – l’automatisation commence au sein des équipes, pour leur propre usage. Au
fil de son évolution, une organisation va progressivement partager ses bonnes pratiques Évolution Évolution Évolution
faible intermédiaire avancée
avec d’autres équipes.
Notre étude confirme cette hypothèse. Au niveau le plus bas de l’évolution DevOps, une 3% 4% 4%
grande proportion de participants (59 %) ne partagent les bonnes pratiques qu’au sein
de leur équipe. Dans 26 % des cas, elles sont communiquées avec d’autres équipes, et
dans 12 % des cas seulement elles le sont à l’échelle de toute l’entreprise. Mais lorsque 12%
les organisations atteignent les niveaux supérieurs de maturité DevOps, elles sont 33 % 22%
à partager les bonnes pratiques avec d’autres équipes, voire toute l’entreprise. Elles ne
sont plus que 29 % à limiter cette collaboration à leur propre équipe.
33%
Ces conclusions montrent nettement le passage progressif de silos étroits aux niveaux 26%
faibles d’évolution DevOps à un partage bien plus large dans les organisations qui sont
très avancées dans leur parcours. Il est donc visible que les pratique DevOps passent
des équipes individuelles à des groupes d’équipes puis à toute l’organisation au fil de 38%
l’évolution des DevOps.
33%
59%
36% 30%
La meilleure voie est celle qui
donne des résultats rapides
Chaque entreprise est unique : commencez par ce qui compte le plus pour ceux que
vous avez besoin d’impressionner. Choisissez une initiative qui produira des résultats
à même de faire naître la confiance chez les décideurs de votre entreprise. Vous
obtiendrez ainsi du temps, des ressources et du budget pour avancer et progresser
sur la base de ces premiers succès.
Nous adorons écouter les aventures DevOps. Dites-nous comment vous avez mis
en œuvre les pratiques fondamentales et comment vous avez mesuré votre succès.
Nous sommes toute ouïe : devops@splunk.com.
À propos de l’auteur
Andi Mann est ambassadeur technologique en chef chez Splunk. Ce professionnel
accompli du numérique possède une expertise internationale de stratège, de
technologique, d’innovateur et de communicant. Depuis plus de 30 ans et sur cinq
continents, Andi a contribué au succès de groupes des Fortune 500, de grandes
entreprises et de gouvernements, et a officié en tant qu’analyste et consultant. Ses
opinions et commentaires sont également très recherchés dans le domaine des
technologies de l’entreprise. Il a été publié dans USA Today, The New York Times,
Forbes, CIO et The Wall Street Journal, il a donné des conférences à Gartner ITxpo,
VMworld, CA World, Interop, Cloud Expo et DevOps Summit, et a été l’invité ou
l’animateur de nombreuses émissions de radio et de télévisions, de webcasts, de
podcasts et d’événements.
À propos de Splunk
Splunk Inc. (NASDAQ : SPLK) transforme vos données en actions. Les entreprises
utilisent les solutions Splunk de pointe en combinaison avec le machine learning
pour relever leurs défis les plus difficiles en matière d’informatique, d’Internet des
objets et de sécurité. Rejoignez des millions d’utilisateurs passionnés et vivez une
révélation avec Splunk dès aujourd’hui : splunk.com.
À propos de Puppet
Puppet ouvre la voie vers un monde de progrès logiciel sans limites. Sa plateforme
révolutionnaire est devenue la norme de l’industrie pour l’automatisation de la
livraison et de l’administration des logiciels qui font tourner le monde autour de
nous. Plus de 40 000 entreprises, dont plus de 75 % du classement Fortune 100,
utilisent les solutions open-source et commerciales de Puppet pour adopter les
pratiques DevOps, acquérir une connaissance parfaite de leur situation et mettre
en œuvre des changements logiciels en toute confiance. Basée à Portland dans
l’Oregon, Puppet est une entreprise privée comptant plus de 500 employés dans le
monde. Pour en savoir plus, rendez-vous sur puppet.com.
En savoir plus
Splunk, Splunk>, Data-to-Everything, D2E et Turn Data Into Doing sont des marques commerciales et des marques
déposées de Splunk Inc. aux États-Unis et dans d’autres pays. Tous les autres noms de marques, noms de produits
ou marques déposées appartiennent à leurs propriétaires respectifs. © 2020 Splunk Inc. Tous droits réservés.
20-33892-SPLK-5 Foundational DevOps Practices-EB-FR-114

Les 5 Pratiques Fondamentales Des DevOps

Transféré par

Droits d'auteur :

Formats disponibles

Les 5 Pratiques Fondamentales Des DevOps

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Les 5 Pratiques Fondamentales Des DevOps

Transféré par

Droits d'auteur :

Formats disponibles

Les 5 pratiques

Choisissez votre aventure...........................................................................................................................2 Mais...rien ne sert de courir il faut partir à point.........................................................................46

La frise de l’évolution.....................................................................................................................................4 Partagez maintenant avec d’autres équipes.................................................................................48

Tout est question de partage....................................................................................................................8

Les 5 pratiques fondamentales, une par une...................................................................... 10

Supervision et alertes sont configurables par l’équipe qui gère le service................ 12

Que mesurer et comment........................................................................................................................ 16

Importance du suivi des métriques métier.................................................................................... 18

Mesurer est un élément essentiel des DevOps...........................................................................26

Réutiliser les motifs de déploiement pour construire des apps ou services.............28

Réutiliser les motifs de test pour construire des apps ou services................................32

Contribuer à l’amélioration de l’outillage fourni par d’autres équipes............................36

Les configurations sont gérées par un outil de gestion dédié............................................38

Les motifs de test sont réutilisés pour

Nos conclusions sont nettes : les pratiques

le service applications et des services en production – qu’elles soient composées de développeurs,

« Déposez une configuration de surveillance à tel emplacement et nous la mettrons en

« Connectez-vous à cette interface web pour configurer votre surveillance. »

« Voici une API pour configurer la surveillance sous forme de code. »

Dans notre étude, nous avons demandé « À quelle

La plupart du temps 8% 37% 47%

l’équipe qui gère le service. » Jamais 23% 3% —

Le partage des indicateurs encourage l’amélioration permanente

Création et promotion d’une culture de l’apprentissage continu

Collaboration inter-équipes et autonomie des équipes

Objectifs commerciaux dérivés des indicateurs techniques : par exemple, le délai

Évolution Évolution Évolution

Importance du suivi faible intermédiaire avancée

des métriques métier 66%

Nous mesurons manuellement les métriques système essentielles.

Nous mesurons automatiquement les métriques système essentielles.

Les indicateurs des objectifs métier sont collectés manuellement

Les indicateurs des objectifs métier sont automatiquement

Les métriques métier répondent à des

Combien de personnes servons-nous ?

Ce motif est-il normal ?

Les métriques métier sont également

Est-ce qu’elle donne de meilleurs résultats commerciaux ?

Observabilité, télémétrie et Observabilité des systèmes industriels

journalisation sémantique Observability in industrial systems

Faible Intermédiaire Avancé

Toujours 3% 16% 51%

La plupart du temps 7% 39% 44%

Parfois 23% 32% 5%

Observabilité des systèmes logiciels

L’observabilité permet aux équipes de travailler avec des architectures modulaires

déploiement réussite de l’approche DevOps : la possibilité de réutiliser des routines de déploiement,

RAREMENT 40% 8% 1% d’applications est le point de rencontre le plus

TOUJOURS — 11% 52%

FAIBLE INTERMÉDIAIRE AVANCÉ

TOUJOURS <1% 10% 44%

LA PLUPART DU TEMPS 6% 38% 48%

PARFOIS 32% 39% 7%

RAREMENT 40% 11% <1%

Les activités les plus proches de la production comme le provisionnement, la

de l’outillage fourni par

TOUJOURS <1% 11% 44%

LA PLUPART DU TEMPS 4% 31% 45%

PARFOIS 26% 40% 11%