Devops, une refondation nécessaire ?

Introduction

Je me suis lancé sur la refonte de mon site en un site de documentation sur le DevOps. En rédigeant les pages de celui-ci, je me suis fait la réflexion, comme beaucoup d'ailleurs. Mais qu'avons-nous fait du DevOps ? Du grand n'importe quoi ! A-t-on besoin de recréer des fondations solides pour mieux repartir ? Oui, je le pense. Est-ce-que le Platform Engineering est la réponse ? Non, car il ne s'adresse pas au cœur du problème ! Mais c'est quoi le coeur du problème ?

Pourquoi le DevOps est devenu du grand n'importe quoi

Je ne vous le cache pas, moi aussi, j'ai tordu le concept pour finir à l'éloigner des grands principes fondateurs de cette philosophie. Si on parcourt les annonces d'emplois sur Linkedin, on peut vite comprendre vers quoi à évoluer le terme DevOps. C'est devenu un poste à part entière et non plus une philosophie. Mais on ne peut le réduire à un poste, c'est une philosophie !

Sur bluesky suite à la publication de l'évolution de ma roadmap de formation au DevSecOps, Winael m'a fait cette même remarque.

Je dirai qu'un "DevOps", c'est comme une chimère, ça n'existe pas puisque DevOps est la contraction de "Development & Operations". C'est comme dire "un Agile", ça n'a pas de sens. Tant qu'on continuera à dire "un DevOps" les organisations continueront à faire n'importe quoi avec DevOps

Cet avis, je le partage. On a totalement déformé le concept pour le faire entrer dans une fiche de poste. Mais ce n'est pas une fiche de poste, c'est une philosophie, une culture d'entreprise !

Les fondations du Devops

Pour rappel, le mouvement DevOps est issu d'une succession de conférences, dont les DevOpsDays, qui se sont déroulées à partir de 2008.

Le constat qu'ils tiraient est que le cloisonnement des équipes de développement (Dev) et des opérations (Ops) était contre-productif. De plus leurs méthodes de travail s'opposaient. L'un était agile et l'autre utilisait encore le cycle en V. Vous voulez plus de détail sur ce qui a amené ce constat, alors je vous invite à lire ce billet.

C'est en 2010 que les principes fondateurs du DevOps ont été posés par Damon Edwards et John Willis. Ils ont inventé l'acronyme CAMS, qui signifie Culture, Automation, Measures and Share (Partage). Jez Humble, dans son livre HandBook Devops publié en 2016, a amendé cet acronyme en ajoutant Lean, pour former l'acronyme CALMS. Revenons maintenant en détail ces cinq grands principes.

Culture

Si vous n’avez pas cette Culture, toutes les tentatives de l'adopter seront vaines. Je ne vous apprendrai rien en vous disant que sans appui des dirigeants tout projet est voué à l'échec. Le DevOps appelle à un renforcement de la collaboration entre deux équipes, que sont les Dev et les Ops. Cela ne peut se faire sans cet appui.

Automatisation

L'automatisation consiste à libérer les équipes des tâches répétitives et sans véritables valeurs ajoutées. Il s’agit aussi de donner aux gens les moyens de faire se concentrer sur celles qui ont réellement de la valeur.

Mesure

Si vous ne pouvez pas mesurer, vous ne pouvez pas vous améliorer. On ne se limite pas à mesurer le temps d’un déploiement logiciel. Il faut mettre en place d'autres indicateurs pour que le processus puisse être amélioré continuellement.

Sharing (Partage)

Le partage exprime la nécessité d'une communication permanente entre les équipes chargées des développements et ceux de l'exploitation. L'objectif est de créer une contribution partagée. Les gens sont prêts à travailler ensemble si leurs pensées et leurs opinions sont entendues. Ils partagent donc leurs idées, leurs analyses, leurs données et leurs résultats.

Lean

Le lean, qui signifie "sans gras", est une méthode de gestion de la production qui se concentre sur la "chasse aux gaspillages". Ce principe de rationalisation cherche à réduire des excès, en limitant au minimum le nombre et la durée des réunions, la taille des équipes et le nombre d'outils susceptibles de fournir les résultats attendus.

Mais que manque-t-il ?

Oui à force de le tordre, on a limité le DevOps à ce qu'il nous arrangeait. Certains y ont même trouvé le moyen de prendre du pouvoir et d'autres un moyen de baisser la masse salariale. "Bein oui, on automatise, donc on a plus besoin de personnes à l'exploitation".

De plus, je ne sais pas si c'est la faute au partage sur internet ou aux conférences, mais force est de constater que beaucoup y reprennent le code exposé sans aucune analyse de son contenu et sur ce que cela implique.

Tout ce qui est disponible l'est à des fins de démonstrations, voir de formation. Il est vidé, pour en faciliter la compréhension, de toute notion de fiabilité, de maintenabilité, d'exploitabilité et de sécurité

La sécurité

Oui, nous ne vivons pas dans le monde des bisounours où tout le monde est gentil. La menace d'une cyberattaque pèse sur nous à tout moment. Cela n'arrive pas qu'aux autres !

Un jour, vous subirez l'attaque qui vous coutera très cher, plusieurs milliers voir millions d'euros, mais aussi qui entachera votre réputation. Cette attaque pourrait vous être fatale.

Cela passe par un rappel aux devoirs de chacun de sécuriser ce qu'il produit. La sécurité, c'est l'affaire de tous pas d'un seul d'un spécialiste !

Alors, replaçons la sécurité comme une fondation de toute construction.

La fiabilité

Pourtant, on en a tellement parlé avec le SRE. Rappel, l'ingénierie de fiabilité d'un site, d'un SI, se consacre à la concevoir et à mettre en œuvre des systèmes hautement évolutifs et robustes, en adoptant des principes d'ingénierie logicielle pour résoudre les défis liés à l'infrastructure et à l'exploitation. On y parle indicateurs, haute disponibilité, auto-remédiation…,

L'exploitabilité

On voit apparaître des nouvelles technos où on chasse l'exploitant. On entend parler de NoOps, sans en comprendre les conséquences. Un système automatique n'est pas infaillible. On a beaucoup exemples où ce genre de système s'emballe jusqu'à l'accident fatal. Un simple grain de sable suffit. Ces technologies ne sont pas matures et leurs utilisations doivent se limiter dans un premier temps à des systèmes non vitaux pour votre production.

La maintenabilité

Oui un système doit être maintenable. La maintenabilité est une aptitude d'un équipement industriel à être maintenu en état de bon fonctionnement. Cela appelle à maîtriser ce que l'on déploie. Il faut se préparer à toute éventualité comme la perte de données dû à une mauvaise manipulation jusqu'à la destruction d'un site de production. Vous devez mettre en place des systèmes pour assurer la sauvegarde des données nécessaires au bon fonctionnement de votre SI, mais aussi de documenter ces procédures de reprises. Il faut aussi les tester à intervalles réguliers. Ces exercices s'appellent les PCA, PRA.. N'oubliez pas de former les personnels qui sont appelés à les maintenir.

L'industrialisation

Tout ce que l'on conçoit et qui est voué à perdurer dans le temps doit être industrialisé. Industrialiser veut dire sérialiser. Cela veut dire construit de manière cohérente. Comment voulez-vous assurer une bonne exploitation d'un système construit à partir de bric et de broc ?

Un système doit être organisé et cohérent pour éviter toutes mauvaises manipulations.

Et les principes du manifeste Agile ?

En rédigeant ce billet, je me suis rappelé qu'une partie de ces principes existent déjà dans le manifeste Agile.

Les Principes qui sous-tendent le Manifeste Agile (source) :

• Notre principale priorité est de satisfaire le client en livrant rapidement et régulièrement des solutions qui apportent de la valeur. Accueillez chaleureusement les changements de besoins, même tardifs dans le développement. Les processus agiles tirent parti du changement pour renforcer l’avantage concurrentiel du client.
• Livrez souvent des solutions opérationnelles, à une fréquence allant de quelques semaines à quelques mois, avec une préférence pour les échelles de temps les plus courtes.
• Les personnes en charge du métier ou des affaires et les personnes en charge de la réalisation doivent travailler ensemble chaque jour, tout au long du projet.
• Construisez les projets à partir de personnes motivées. Donnez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour mener à bien le travail.
• La conversation en face à face est la méthode la plus efficace et la plus économique pour donner des informations à une équipe de réalisation et pour échanger des informations à l’intérieur de l’équipe.
• La disponibilité de solutions opérationnelles est la principale mesure d’avancement.
• Les processus agiles encouragent à respecter un rythme soutenable lors de la réalisation. Les commanditaires, les réalisateurs et les utilisateurs devraient pouvoir maintenir indéfiniment un rythme constant.
• Porter continuellement attention à l’excellence technique et à la qualité de la conception renforce l’agilité.
• La simplicité – l’art de maximiser la quantité de travail qu’on ne fait pas – est essentielle.
• Les meilleures architectures, les meilleures spécifications de besoins et les meilleures conceptions émergent d’équipes auto-organisées.
• À intervalles réguliers, l’équipe réfléchit aux façons de devenir plus efficace, puis modifie son comportement et l’ajuste en conséquence.

Personnellement, je ne partage pas tous ces principes et en particulier sur la documentation. La documentation et pas seule celle du produit, doit être la base de toute entreprise. Les écrits restent, les paroles s'envolent !

Parlons aussi de la simplicité qui souvent sert de justification à ne pas respecter les principes de sécurité, de maintenabilité et de disponibilité.

Conclusion

Souvent on me dit de regarder du côté de DORA, ceux qui ont produit le livre Accelerate. Mais j'ai vu tellement de raccourcis pris par certains suite à cette publication, que j'en ai peur. Juste une remarque, ils s'appuient sur les données des entreprises qui ont réussi et non de celles qui ont échoué. Je pars du principe qu'on apprend plus des erreurs que des succès.

La démarche DevOps a conduit à l'émergence de nouveaux outils, de nouvelles pratiques qui maintenant ont besoin d'être étendue à toute l'entreprise.

Nous avons besoin d'un cadre qui pose les fondations d'une construction solide, d'un support pour nous rappeler sans cesse à nos obligations et devoirs. C'est de la responsabilité de toute entreprise et pas d'une communauté.

Doit-on rédiger un manifeste de xxxxxx ? OUI, je le pense ! Doit-on l'afficher pour garder sans cesse les principes en ligne de mire, OUI, je le pense !

xxxxxxxx : le nom de votre choix.

Vous n'êtes pas d'accord, alors discutons-en lors du Devops DDAY qui aura lieu le 23 Novembre à Marseille.