Omar BITEYE

Le CALMS et les cinq piliers du DevOps

Contrairement aux méthodologies agiles ou au Framework ITIL, il n’existe pas (encore) de référentiel de
bonnes pratiques spécifiques sur lequel il est possible de s’appuyer.

L’avantage du CALMS, c’est qu’il va pouvoir fournir un certain « cadre » pour évaluer et comparer la
maturité des équipes concernant le DevOps, ainsi que la manière dont ils réagissent aux changements
transformationnels que cette nouvelle culture va impliquer au sein de ces équipes.

1. Le « c » de la culture

La culture correspond au premier pilier et se concentre sur les exécutants techniques, les décisionnaires,
les managers, ou encore la sécurité. En somme, toutes les personnes qui vont avoir une interaction avec
le(s) produit(s) et service(s).

L’accent est mis sur les changements, la manière dont les mutations de structure et de culture au sein des
équipes sont amenées, et surtout sur la capacité à évoluer vers une culture de l’expérimentation.

Cela signifie qu’il n’y a pas de problème à échouer, à commettre des erreurs, ou à ne pas réussir à atteindre
l’objectif fixé. L’important est alors d’essayer, de gagner en connaissances et en maturité, permettant ainsi
de ne pas réitérer les erreurs déjà commises.

© Editions ENI - Tous droits réservés - Copie personnelle de Omar BITEYE -1-
 Omar BITEYE

2. L’automatisation : une méthode indispensable

Le second pilier autour duquel se concentre le DevOps correspond à l’automatisation. Même si ce pilier
revêt une très grande importance, il ne résume pas à lui tout seul le DevOps.

Il est question, cette fois, de déploiement continu (CD) et d’intégration continue (CI), permettant
d’automatiser la mise en production des nouveaux codes développés grâce à plusieurs phases de tests,
de build et de scans.

La partie Ops, relative à l’infrastructure, peut, elle aussi, être automatisée avec les notions d’IaC,
intimement liées au Cloud et à l’utilisation des technologies d’orchestration de conteneurs (notamment
Kubernetes).

 Ces notions seront abordées plus en détail dans les chapitres suivants.

Il s’agit d’un des concepts fondamentaux du DevOps et du DevSecOps, qui doit être au premier plan de
toutes les réflexions autour des développements et de l’infrastructure.

Ainsi, les questions que tout intervenant doit se poser pourraient être les suivantes :

ˇ Qu’est-ce qui peut être automatisé ?

ˇ Qu’est-ce qui ne peut pas être automatisé, et pour quelles raisons ?
ˇ Si l’ensemble ne peut être automatisé, il existe nécessairement des étapes qui peuvent l’être.
Lesquelles ?

3. Le Lean ou le zéro déchet

Dans l’industrie, notamment en automobile, le Lean est fondamental. En informatique, l’accent est mis sur
la capacité à produire de la valeur, tout en diminuant les zones et les

© Editions ENI - Tous droits réservés - Copie personnelle de Omar BITEYE -2-
 Omar BITEYE

moments dans desquels nous risquons de produire du « déchet ». Par déchet, il est question, surtout, de la
perte de temps lors du passage d’une étape à la suivante : les fameux goulots d’étranglement.

C’est aussi au Lean que l’on doit la volonté de réaliser des releases (versions) de faible taille. En effet,
plutôt que de déployer des mises à jour, lorsque de grandes quantités de fonctionnalités ont été
améliorées ou développées, il est préférable de déployer au fur et à mesure chaque petite amélioration ou
modification. C’est une méthode très utile lorsqu’il est nécessaire de revenir à une version précédente (à
cause de bugs) sans perdre trop de fonctionnalités déjà mises à disposition du client.

En somme, le Lean est là pour maximiser la valeur du produit auprès des clients en diminuant les déchets
et en améliorant les flux de développement.

4. En DevOps, il faut tout mesurer

Pourquoi faut-il tout mesurer ? Car en prenant en compte ce pilier, il est possible de démontrer de manière
objective l’amélioration et la progression des équipes, des processus et des technologies, en matière de
performance et de productivité.

Quel meilleur moyen pour faire adopter une nouvelle culture, ou méthode, que de démontrer qu’elle est
efficace ?

a. L’enseignement du TDD (Test Driven Development)

En français, il est question de « développements pilotés par tests », correspondant à une méthode de
développement permettant de concevoir un service ou une application, pas à pas, de manière itérative et
incrémentale (comme en méthode agile).

Une des spécificités de cette méthode consiste à écrire chaque test à effectuer, avant même d’écrire le
code source lui-même.

Il devient alors évident de comprendre l’intérêt de mesurer les résultats attendus (sinon comment écrire
les tests unitaires en amont ?).

Une règle importante à appliquer au DevOps serait de ne jamais effectuer de modification

© Editions ENI - Tous droits réservés - Copie personnelle de Omar BITEYE -3-
 Omar BITEYE

du code, ou du produit, sans mesurer l’efficacité et l’intérêt de cet ajustement.

b. Quelques exemples de mesures

Concernant les différentes mesures, cherchons à nous concentrer sur :

ˇ le nombre et la fréquence des déploiements ;

ˇ le ratio du nombre de déploiements échoués vs le nombre de déploiements réussis ;
ˇ le Mean Time to Discovery (MTTD), correspondant au temps nécessaire pour identifier la
vulnérabilité d’un produit ;
ˇ le Mean Time to Patch (MTTP), correspondant au temps nécessaire pour patcher les
environnements une fois qu’une vulnérabilité est identifiée ;
ˇ le Mean Time to Recovery (MTTR), correspondant au temps nécessaire pour résoudre un
problème lié à une mise en production ;
ˇ le Lead Time, permettant de mesurer le temps nécessaire pour passer d’une idée de concept à
son implémentation ;
ˇ le taux de disponibilité des services ;
ˇ le nombre d’anomalies détectées ;
ˇ etc.

Il est presque toujours possible de tout mesurer, et cela apporte une réelle plus-value lorsque la culture et
la méthode sont encore nouvelles au sein des équipes et de l’entreprise.

5. Le sharing (partage) au centre de toute la culture DevOps

Le DevOps a été créé par des acteurs de l’IT, pour des acteurs de l’IT, avec un partage de toutes les
informations et les retours d’expérience de chacun.

C’est pourquoi la collaboration et la communication sont des éléments fondamentaux. Il faut donc sortir
d’une logique de compétition interne qui peut exister dans certains

© Editions ENI - Tous droits réservés - Copie personnelle de Omar BITEYE -4-
 Omar BITEYE

services.

Cependant, ce pilier ne fait pas uniquement référence au partage entre les Devs, les Ops, la Sécurité, et
tous les autres acteurs techniques ou fonctionnels. Il fait aussi référence au partage entre les clients et les
créateurs de valeur. En effet, il convient de communiquer aux clients l’ensemble des informations
correspondant aux produits et services : du bug détecté à la mise à jour, en passant par les phases de
maintenance.

Le client se sent ainsi intégré dans les projets, et la transparence dont fait preuve l’entreprise ne fait que
renforcer la confiance en ses services.

Quelques clés pour réussir à développer cette culture de la coopération :

ˇ ne pas se concentrer sur les performances individuelles, mais sur celles d’une équipe entière ;
ˇ lever le maximum de barrières (souvent le rôle du coach DevOps/DevSecOps) ;
ˇ communiquer sur les activités et la valeur apportée par les développements effectués par
l’équipe ;
ˇ être certain que les objectifs et les contraintes des projets sont bien intégrés par
l’ensemble des membres de l’équipe.

6. Et le DevSecOps ?

Le DevSecOps prend logiquement ses origines dans le DevOps et ses cinq piliers fondamentaux. Il met
l’accent sur l’adoption de mesures de sécurité et sur la volonté de toujours chercher à automatiser au
maximum les tâches correspondantes.

Le véritable intérêt du DevSecOps apparaît lorsqu’il s’intègre au sein du workflow (flux de travail) et des
pipelines CI/CD (intégration continue et déploiement continu). Il prend réellement son importance au
moment de vérifier la sécurité du code (Security By Design) utilisé sur les produits en développement, ou
celle des images des conteneurs utilisés au sein d’infrastructures sous Kubernetes, ou encore sur les
environnements Cloud.

© Editions ENI - Tous droits réservés - Copie personnelle de Omar BITEYE -5-
 Omar BITEYE

 Nous reprendrons ces différents termes et leur signification un peu plus tard dans
cet ouvrage.

Certains ont l’habitude de dire que le DevSecOps correspond tout simplement à du DevOps
« correctement » effectué, avec la prise en compte de la sécurité comme partie intégrante du processus
de développement et de la mise en production, et non pas comme une étape en aval une fois le
développement terminé.

Dans la culture DevOps, il est beaucoup question de « Shift Left » pour aborder les notions concernant la
sécurité, ce qui fait référence à la gestion de la sécurité le plus en amont possible de tout processus.

Dans le DevSecOps, « la sécurité est l’affaire de tous ». Ainsi, tout le monde est responsable de la sécurité
dans l’entreprise.

© Editions ENI - Tous droits réservés - Copie personnelle de Omar BITEYE -6-