La séparation des DEV et des OPS conduit à des objectifs distincts :
Il en résulte le mur de la confusion.
Pour remédier à cette situation, il sera impératif de replacer le produit et la création de valeur au centre en fixant un objectif commun aux DEV et OPS :
Livrer rapidement des évolutions tout en assurant la disponibilité
Le partage de ce même objectif conduira à unifier les processus de développement et de déploiement :
Nous reconnaîtrons dans ce processus la roue de Deming bien connue dans le domaine de la qualité et l'agilité :
(Source : wikimedia.org - Michel Weinachter)
Avec DevOps, il est principalement question de ne pas avoir deux processus distincts pour le développement et le déploiement.
Nous conviendrons que la mise en oeuvre d'un tel processus prendra du temps et qu'il sera toujours perfectible.
A ce titre, il conviendra de l'améliorer en continu.
La gestion des infrastructures est un sujet sensible faisant l'objet d'un cadre réglementaire (sécurité des systèmes d'information, RGPD,...) et de recommandations (ex : cyber.gouv.fr - Recommandations relatives à l'administration sécurisée des SI).
Pour faire évoluer les pratiques et les processus, il faudra d'abord une compréhension partagée :
Avant de cibler une infrastructure agile, il faudra être nombreux à constater un problème quand :
En pratique, s'orienter vers la méthode DevOps sera délicat sans une politique globale permettant l'agilité au niveau de l'entreprise. Sans entrer dans les détails :
Concrètement, il faudra aller au-delà de Microsoft Office Excel pour la gestion de projets (support.microsoft.com) et revoir la gestion du cycle de vie des applications (ALM) pour :
MCO = maintien en condition opérationnelle / MCS = Maintien en Condition de Sécurité.
Nous trouverons à ce titre des framework d'agilité à l'échelle tels Scaled agile framework (SAFe) qui incluront DevOps dans une démarche plus globale.
Il en va de même pour le référentiel ITIL 4 qui se concentre sur les flux de valeur et l'amélioration continue (ce qui n'était pas forcément le cas dans les versions précédentes).
Voir www.alenia.io - ITIL 4 versus ITIL v3 : qu'est-ce qui change ? et www.atlassian.com - DevOps et ITIL : lequel est essentiel à votre équipe ?
DevOps mettra un fort accent sur l'automatisation. Elle prendra plusieurs formes :
Le concept Lean trouve ses origines chez Toyota avec deux fondamentaux :
La lecture de LEAN PRIMER par Craig Larman et Bas Vodde en donnera une idée plus précise mais nous soulignerons que l'accent est mis sur :
Au niveau du développement logiciel, Le Lean se retrouvera à travers les principes suivants :
c.f. www.journaldunet.com - Lean Software Development et gestion de projet : décryptage
Nous noterons que les principes du Lean entrent en résonance avec :
Le Lean ne doit pas être perverti en se contentant de chiffres assurant que les ressources sont occupées à 100% (1). Pour gagner réellement en efficacité, Il faut plutôt observer le processus de création dans son ensemble et permettre les optimisations. Par ex :
(1) www.usinenouvelle.com - Dérives du lean : pourquoi la méthode s’est écartée des principes originaux
L'adage dit que "ce qui ne se mesure pas n'existe pas" (Niels Bohr). Du moins, ce qui est affiché en rouge sur un graphique sera plus visible au niveau de la direction :
Illustration de la problématique des temps d'attente avec l'approche traditionnelle
A ce titre, on s'efforcera de définir des objectifs et les métriques associées.
Le partage et la transparence seront importants à plusieurs niveaux. Ils favoriseront :
Définir des métriques pertinentes et faire en sorte pouvoir les calculer sera loin d'être trivial. Se contenter d'avoir des métriques et avoir des métriques non pertinentes sera contre-productif.
Nous allons ici nous limiter à quelques métriques parlantes en nous interrogeant en séance sur les méthodes permettant de les calculer. Vous en rencontrerez bien d'autres.
Voir effectivesoftwaredesign.com - Lean Startup Principles: Vanity Metrics and Actionable Metrics qui décrit la distinction entre Vanity Metrics et Actionable Metrics proposée par Eric RIES dans "The Lean Startup".
Les métriques suivantes seront caractéristiques du niveau d'automatisation du déploiement :
Les métriques suivantes donneront une indication sur la qualité de l'automatisation du déploiement :
La mesure du temps moyen pour détecter une problème (Mean Time To Detect (MTTD)) donnera quand à elle une indication sur la qualité de l'instrumentation de l'infrastructure.
Pour mesurer la qualité du code, il sera possible de s'appuyer sur :
SonarQube a le mérite d'offrir une interface unifiée pour différents langages (ce qui plait aux décideurs) mais les outils d'analyse de code dédiés aux langages (jshint, jslint, phpmd, phpstan, cppcheck...) offriront souvent des alertes plus pertinentes ainsi qu'une démarche "as code" dans la gestion des exceptions.
Les indicateurs suivants donneront une vision plus globale de la qualité d'une application :
Exemple de visualisation de métriques sur des tickets.
Le calcul de telles métriques sera délicat sans :
En outre, pour raisonner sur des éléments comparables et identifier des axes d'amélioration, il sera intéressant de :
Les outils de supervision système (Grafana/Prometheus, centreon, munin, netdata,...) permettront de surveiller la consommation de ressources (RAM, CPU, stockage, bande passante,...) :
Les outils de supervision permettront aussi mettre en oeuvre des alertes pour :
Ils offriront au passage un terrain de discussion intéressant entre les DEV et les OPS.
Une sonde web interroge périodiquement une URL en vérifiant la réponse (code de retour 200) et en mesurant le temps de réponse. Elle permet ainsi de :
Pour les services exposés en ligne, la mise en oeuvre sera triviale avec des outils tels UptimeRobot, Uptrends...
Source uptimerobot.com - sondes des Géoservices
Nous pourrons aussi étendre les outils de supervision pour ajouter ce type de sonde ce qui sera particulièrement intéressante pour les services non exposés :
Surveillance d'une URL à l'aide de prometheus/blackbox_exporter
La mise en oeuvre de sondes web permettra d'améliorer facilement le Mean Time To Detect (MTTD). Toutefois, en vue d'améliorer le Mean Time To Recovery (MTTR), nous constaterons que :
Pour identifier rapidement l'origine des problèmes, il sera intéressant de prévoir des URL dédiées à la surveillance au niveau de l'application :
/health/db
/health/wfs-geoplateforme
Voir learn.microsoft.com - Modèle Surveillance de point de terminaison.
En cas de problème, il sera nécessaire d'avoir une vision sur les traitements réalisés dans une application. En ce sens, il convient de :
La référence historique en matière de puits de logs est la suite ELK (ElasticSearch, Logstash et Kibana) :
Illustration de l'architecture de la stack ELK.
Il sera là aussi possible de choisir des variantes et alternatives :
(1) Fork de ElasticSearch et Kibana pour des raisons de license.
Nous trouverons aussi des offres SaaS spécifiques aux hébergeurs telles :
Pour diagnostiquer des problèmes de performances dans des systèmes complexes, il sera intéressant d'instrumenter le système avec un outil tel jaeger qui permettra d'avoir le détail des temps de traitement derrière une requête.
L'approche Infrastructure as Code (IaC) sera fondamentale en matière d'automatisation des déploiements. Elle consiste à gérer une infrastructure informatique à l'aide de programmes :
L'automatisation d'un déploiement concernera plusieurs couches du système :
Nous veillerons à nous assurer que les scripts de déploiement puissent :
Nous privilégierons une approche déclarative à une approche impérative pour faciliter la mise en oeuvre de ces principes.
L'approche IaC laissera une grande liberté de choix dans les outils du cadre technique dès lors qu'ils sont compatibles avec l'automatisation. Il conviendra principalement d'être attentif aux méthodes de configuration disponibles :
En substance, seuls les outils pouvant être configurés uniquement via une IHM sont à bannir!
En fonction des possibilités offertes par l'infrastructure et de la politique de l'entreprise, l'automatisation pourra être partielle mais il faudra être conscient des conséquences.
En particulier, si la configuration du reverse proxy/load balancer n'est pas automatisée :
Nous trouverons différents outils pour la mise en oeuvre d'IaC (ex : Terraform, Ansible, Docker, Kubernetes, Helm,...)
Nous noterons à ce stade que :
Nous les verrons par la suite sur des exemples concrets.
L'approche GitOps ira un cran plus loin que Infrastructure as Code :
L'approche GitOps permet ainsi de :
GitOps est ainsi une illustration de l'utilisation du concept de pull request en lieu et place d'un processus de validation plus traditionnel.
L'approche Docs as Code invite à gérer la documentation avec les mêmes outils que ceux qui servent à construire des applications :
Cette approche induit la production d'une documentation au format HTML qui a de nombreux avantages notamment en terme de capacité à structurer la documentation :
Dans le cas de DevOps, elle est importante pour :
Au final, il sera très vite tentant de gérer un maximum d'élément à l'aide du gestionnaire de code source car il offre un cadre pour la gestion des évolutions
Nous trouverons ainsi :
La seule exception concernera les secrets qui ne devront jamais être stockés dans un dépôt! (pas même dans un dépôt privé, car il sera peut-être ouvert un jour!)