Les cinq étapes de l'évolution DevOps identifiées par le state of devops 2018,
Présentées par Puppet et Splunk

Le , par Marco46, Modérateur
À quelle étape de l'évolution DevOps se situe votre organisation ?
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 ?
Travaillez-vous dans une organisation utilisant certaines de ces pratiques ?
Que pensez-vous des cinq étapes décrites par le rapport ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de Placide Avorton Placide Avorton - Membre averti https://www.developpez.com
le 15/09/2018 à 0:04
Êtes-vous familier avec les pratiques DevOps?

Malheureusement non. Étant salarié d’une ESN en appui technique d’une seconde ESN mandatée par le client final personne ne s’active pour former. C’est à nous en tant qu’individus d’anticiper cette «révolution».

C’est d’ailleurs assez emmerdant car le client final a déjà amorcé sa migration depuis ITIL vers le DevOps.

Travaillez-vous dans une organisation utilisant certaines de ces pratiques?

Oui, par exemple nous proposons déjà un portail basé sur vmWare vRA permettant aux équipes de dev d’approvisionner une vm en quelques clics. Le même portail permet de mettre a dispo des conteneurs applicatifs, de nouveaux VLAN générés dynamiquement à chaque évolution d’un projet depuis la dev vers la recette, la prod, etc.

Que pensez-vous des cinq étapes décrites par le rapport?

Je pense que l’ops est desservi par ce modèle. Dans la mesure où l’intervention d’un tech ou d’un sysadmin n’est plus nécessaire dans la chaîne d’approvisionnement ou de maintenance d’un environnement de travail.

Par exemple en cas de rupture d’un service applicatif l’automatisation va permettre à un dev de stopper les applicatifs ou de rebooter un serveur via des scripts déposés par les ops systèmes et hyperviseur. Le développeur sera bientôt «admin» de son environnement de travail, c’est j’estime, l’affaire de 5 ou 10 ans.

La prise en main à distance a fusillée le métier de technicien de proximité il y a 20 ans.

La virtualisation celui de technicien en datacenter il y a 10 ans.

Le DevOps celui des techniciens d’exploitation à l’heure actuelle.

A nous Ops de rester à bord, pitète via l’apprentissage de technos telles qu’Hadoop, mais je redoute ce jour proche où l’automatisation aura achevé de faire de nous des produits périmés.

 
Contacter le responsable de la rubrique ALM