Les cinq étapes de l'évolution DevOps identifiées par le state of devops 2018, présentées par Puppet et Splunk
Les cinq étapes de l'évolution DevOps identifiées par le state of devops 2018,
présentées par Puppet et Splunk
La paternité du terme DevOps revient à un Belge du nom de Patrick Debois autour de 2009. Faisant suite à une frustration croissante lors de ses missions pour le compte du gouvernement belge à propos des conflits entre développeurs et administrateurs système.
Historiquement, les DSI séparent les équipes de développement des équipes d'exploitation du SI (Operations en anglais d'où le Ops).
Ces équipes ont des intérêts divergents, les développeurs souhaitent du changement (nouvelles technologies, nouvelles pratiques, etc.) et les opérationnels souhaitent de la stabilité puisque le bon fonctionnement du SI est sous leur responsabilité.
L'objectif de ce mouvement, identifié également comme un courant de pensée ou une culture, est de faire tomber les barrières pour fluidifier l'évolution du SI.
Depuis l'avènement du cloud la sécurité est devenue également un sujet majeur, on voit désormais aussi apparaître le terme de DevSecOps pour placer la sécurité informatique au cœur des évolutions du SI.
À partir de 2013, la société Puppet qui propose un outil du même nom permettant de gérer les configurations de systèmes de manière déclarative (on parle d'Infrastructure As Code), publie chaque année les résultats d'une enquête cherchant à mieux comprendre l'évolution de la culture DevOps au sein des organisations.
Mercredi 12 septembre 2018, Puppet a publié le State Of Devops 2018, le rapport fait 83 pages.
Les participants
Pour cette cuvée, 3000 personnes ont répondu à l'enquête.
La ventilation des positions hiérarchiques des participants dans leur organisation est la suivante :
- Directeurs (CEO, CTO, ...) 9 %
- Senior management 14 %
- Management 25 %
- Team lead 21 %
- Individus 26 %
- Autres 5 %
Seulement 12 % des participants appartiennent à un service de développement, l'écrasante majorité faisant partie de services liés à l'exploitation du SI.
L'enquête a été réalisée cette année en quatre (4) langues en plus de l'anglais : Français, Allemand, Japonnais et Malaisien.
L'Europe représente 29 % des réponses. Un tiers des participants européens vivent en Grande-Bretagne, un quart en Allemagne et un autre quart en France. La France représente donc un peu plus de 7 % des réponses à l'échelle mondiale.
Cette statistique est à relativiser dans le sens où les trois (3) pays les plus représentés ont pu répondre avec leur langue natale ce qui a nécessairement un impact.
Les participants à l'enquête travaillent principalement dans des organisations de technologie (on imagine qu'il s'agit de sociétés purement IT comme des fournisseurs de services ou des sociétés de service) pour 38 % d'entre eux, dans la Finance (12 %) et dans l'Industrie (8 %). Les personnes travaillant pour des états représentent à peine 5 % des participations.
La taille des organisations des participants est évaluée par rapport à leur chiffre d'affaires :
- supérieur à 2 milliards de $ : 17 %
- entre 1 et 2 milliards de $ : 7 %
- entre 500 millions de $ et 1 milliard de $ : 9 %
- entre 250 millions de $ et 500 millions de $ : 10 %
- entre 100 millions de $ et 250 millions de $ : 13 %
- entre 50 millions de $ et 100 millions de $ : 15 %
- moins de 50 millions de $ : 29 %
L'enquête porte donc sur une grande variété d'organisation en termes de taille économique.
Une des hypothèses de départ de l'enquête est que les organisations qui réussissent la transition vers les techniques DevOps se basent généralement sur des petites équipes très avancées dans le processus qui essaiment au sein de l'organisation. Les initiatives top-down opérées avant un quelconque succès dans l'organisation ont tendance à échouer.
Les cinq (5) étapes de l'évolution DevOps
L'un des principaux objectifs de l'enquête de cette année était de comprendre comment s'opérait l'évolution de la culture DevOps dans les organisations.
Les fondements méthodologiques utilisés dans cette enquête ne seront pas abordés dans cette actualité. Une dizaine de pages en fin de rapport détaille la démarche.
Étape 0 : bâtir les fondations
Cette première étape numérotée zéro ne fait pas à proprement parler des étapes identifiées, elle ne compte pas dans les 5.
Elle référence les pratiques nécessaires à l'évolution vers les autres étapes. Ces pratiques doivent perdurer dans le temps pour permettre la continuité de l'évolution et même son maintien.
- Les systèmes de supervision et d'alertes sont configurables et à la main des équipes opérant le service.
- Les modèles de déploiement pour construire (build) les applications ou les services sont réutilisés.
- Les modèles de test (tout type de tests) pour construire les applications ou les services sont réutilisés.
- Les équipes contribuent à l'amélioration des outils proposés par les autres équipes.
- Les configurations sont gérées par un outil de gestion de configuration (Un SCM : SVN, git, bitbucket...).
Étape 1: normaliser la pile technologique
À cette étape, les équipes de développement tentent de se coordonner pour utiliser plus de pratiques agiles.
Pratiques clefs
- Les équipes de développement utilisent un outil de contrôle de version (SVN, git, bitbucket...)
- Les équipes de développement déploient sur un éventail d'OS standardisés.
Pratiques contribuant au succès
- Bâtir sur un éventail standardisé de technologies.
- La configuration des applications est versionnée.
- Les changements dans l'infrastructure sont testés avant d'arriver en production.
- Les codes sources de tous les outils et applications sont libres d'accès pour toutes les équipes.
Étape 2 : standardiser et réduire la variance
À cette étape les équipes Dev et Ops se concentrent sur l'homogénéisation du SI.
Par exemple un seul système (ou famille de système), nombre de langages limités, etc.
L'objectif est de réduire la complexité du SI.
Pratiques clefs
- Utiliser un jeu standard de technologies.
- Les équipes déploient sur un OS unique.
Pratiques contribuant au succès
- Les modèles de déploiement pour construire (build) les applications et les services sont réutilisés.
- Les applications sont ré-architecturées pour correspondre aux besoins métiers.
- Les configurations système sont versionnées comme les applications.
Étape 3 : montée en puissance des pratiques DevOps
À ce stade, la réutilisation des processus de build et le test de l'infrastructure sont maîtrisés complètement.
Les pratiques DevOps se répandent dans l'organisation, la collaboration augmente.
La complexité administrative pour effectuer des changements est réduite en donnant plus de pouvoir aux techniciens.
Pratiques clefs
- Les personnels peuvent travailler sans recourir à des autorisations manuelles extérieures à l'équipe.
- Les modèles de déploiement pour construire (build) les applications et les services sont réutilisés.
Pratiques contribuant au succès
- Les personnels peuvent effectuer des changements sans temps d'attente.
- Les changements dans les services peuvent avoir lieu en pleine journée de travail.
- Les retours d'expérience post-incidents et les statistiques associées sont publics et partagés.
- Les équipes travaillent sur des technologies standardisées.
- Les équipes utilisent de l'intégration continue.
- Les équipes gérant l'infrastructure utilisent le contrôle de version.
Étape 4 : automatisation de la livraison de l'infrastructure
Cette étape est définie par l'automatisation de la configuration des systèmes et de leur livraison (le provisioning).
L'automatisation poussée permet aux opérationnels de livrer aux développeurs et à la QA (les services de testeurs) des environnements conformes à ce qu'ils ont en production.
L'automatisation permet également de dégager du temps pour développer le self-service, permettant aux développeurs et à la QA de commencer à générer eux-mêmes leurs environnements.
Pratiques clefs
- Les configurations système sont automatisées.
- La livraison des systèmes est automatisée.
Pratiques contribuant au succès
- Les configurations de politiques de sécurités sont automatisées.
- Les ressources sont mises à disposition en self-service.
Étape 5 : fournir des capacités de self-service
À cette étape, les équipes de développement sont libérées des contraintes administratives et des temps d'attente pour obtenir les outils nécessaires à leur travail, elles n'ont qu'à se servir elles-mêmes.
Pratiques clefs
- La réponse aux incidents est automatisée.
- Les ressources sont disponibles en self-service.
Pratiques contribuant au succès
- Les configurations de politiques de sécurités sont automatisées.
- Les développeurs déploient leurs environnements de tests par eux-mêmes.
- Les métriques des projets sont visibles.
- Le provisioning est automatisé.
Sources : State Of DevOps 2018 sur puppet.com.
Les rapports des années précédentes : 2013, 2014, 2015, 2016, 2017 .
Et vous ?
Êtes-vous familier avec les pratiques DevOps ?
Répondre avec citation
Partager