Dans une première partie nous avons vu le contexte de gestion des opérations de mon client, comme il en existe tant d’autres, ainsi que ses modes de fonctionnement actuels. Il faut désormais penser à une organisation qui puisse rendre les services attendus dans un contexte de transformation globale vers l’agilité. Cette partie se concentre sur les différentes approches organisationnelles devops qui sont enseignées, ou qui bénéficient de retours d’expériences documentés.
Tout d’abord il faut reprendre les mantras devops qu’il est nécessaire de s’approprier, par analogie aux mantras Bouddhiste qui sont des figures vocales répétitives dont les sons ont le pouvoir canaliser le mental et de se rappeler à soi certaines vertus de bienfaisance. Pour ce qui nous concerne, les mantras qui sont évoqués ici permettent de se référer à des principes fondateurs qui servent de points de repère pour à la fois mettre en place l’organisation mais aussi pour la réaligner régulièrement face aux enjeux et difficultés immanquablement rencontrées durant la vie d’un produit. Nous reprenons ici les principes énoncés dans le programme de certification du DASA (Devops Agile Skills Association) ainsi que dans le framework SAFe.
DASA expose ainsi des principes fondateurs :
- Customer-centric actions : Devops doit répondre à un objectif global centré sur la satisfaction et le besoin utilisateur. Pour cela il faut avoir le retour de l’utilisateur final au plus tôt, pivoter sans hésiter, innover en continu. Cela concoure également à éviter que l’organisation soit centrée sur son propre fonctionnement plutôt que sur le rendu utilisateur.
- Create with end in mind : Chaque membre de l’équipe doit avoir en tête la vision globale de l’attendu et non une compréhension parcellaire par composant dont seul le management en comprendrait l’aboutissement en fin d’assemblage. Chaque membre de l’organisation doit agir pour créer un produit qui fonctionne pour l’utilisateur final.
- End-to-end responsibility : L’équipe type devops est responsable du produit « from concept to grave ». Il n’y a pas de transfert de responsabilité entre les développeurs et les opérations. Il s’agit d’une seule et même activité globale visant à construire, faire vivre, et exploiter le produit. Autrement dit il n’y a pas d’équipe dédiée au développement, une autre à la MCO, une autre au déploiement, et encore une autre au run et à la supervision. Il s’agit d’une seule équipe responsable de bout en bout.
- Cross-functional autonomous teams : Une équipe produit doit être autonome et donc en capacité de pouvoir l’être. Les ressources doivent donc être polyvalente, « T-shaped », c’est-à-dire avec des compétences transverses (barre horizontale) en plus de leur profondeur de spécialisation (barre verticale). Cela suppose de la formation et du partage de connaissance.
- Continuous improvement : Pilier de la qualité et de l’adaptabilité, ce principe lean et agile doit être suivi avec discipline pour éliminer les déchets de production, satisfaire à l’exigence de qualité du produit, optimiser constamment le delivery, se frotter aux sujets douloureux pour les rendre faciles et maîtrisés. « If it hurts, do it more often ». Plus la fréquence de déploiement est élevée, plus il est maîtrisé et dérisqué. A l’inverse plus on retient le moment du déploiement, plus on prend de risque en cumulant incertitude et complexité.
- Automate everything you can : L’automatisation permet d’éliminer le plus possible de tâches inutiles, y compris les barrières administratives qui peuvent être incluses dans des workflows automatisés. L’automatisation suit un chemin de plus en plus couvrant tout au long du cycle de vie du produit : Continuous Integration –> Continuous Deployment –> Infrastructure As Code (et versionnée) –> Maintenance automation (prédictivité des pannes, remontage automatique des machines, scalabilité automatique, etc…)
SAFe construit son approche devops autour de l’acronyme CALMR qui définit les principes suivants :
C : Culture. La culture devops, le mindset, est le tout premier principe fondateur du devops, et probablement le plus structurant. Si vous ne prenez pas en compte la culture devops, même si vous automatisez la totalité du déploiement sur votre plateforme, vous ne bénéficierez pas des principes d’agilité liés au devops. Cette culture érige des principes forts :
- Casser le mur de la confusion qui sépare les développeurs et ingénieurs de production.
- Privilégier une attitude collaborative et interactive plutôt qu’une documentation procédurale et des transferts de compétence qui tendent à figer une exploitation.
- Tolérer la prise de risque, et même l’encourager, en mettant en place des systèmes de failover et de rollback efficaces et éprouvés en permanence.
- Partager la connaissance au travers de communauté et de toute instance propice à échanger.
- Favoriser la polyvalence des compétences plutôt que de les enfermer dans leur domaine d’expertise. Un intégrateur de production doit avoir des compétences de développement, et un développeur des compétences systèmes et réseaux.
A : Automation. Automatiser tout ce qui est possible de l’être.
L : Lean. Construire en lean, par petit batch, progressivement. Le gros plan d’architecture construit en amont est à proscrire car il est statique, fige les options et au final empêche d’apprendre. Il faut au contraire penser à des solutions simples, suffisantes et permettant de prendre des décisions définitives plus tardivement et donc de réduire l’écart entre l’attendu et le réalisé.
M : Measurement. Pour prendre des décisions avisées, il est nécessaire d’avoir des données sur le comportement du système. Les données permettent des décisions objectives, partageables et évitent les blaming game habituels (rejets de responsabilité).
R : Recovery. Être capable de remonter un système sans perte de service et sur la version choisie. Cette exigence technique doit être incluse dans chaque choix réalisé et est nécessaire pour favoriser l’acceptation de la prise de risque. Les procédures de recovery doivent être jouées en permanence durant les sprints. Il ne doit pas y avoir de doute sur leur fonctionnement.
On voit au travers de ces deux approches qu’elles tendent vers les mêmes objectifs avec des accents fortement appuyés sur la culture de l’agilité et l’autonomisation des équipes. Casser le mur de la confusion, you build it you run it, fail fast, automate everything, improve meantime to recovery, improve time to market, if it hurts do it more often, T-shapes competences…. Ces mantras définis ci-dessus doivent revenir dans chaque rétrospective afin de s’assurer que l’organisation suit le chemin du devops. Il convient de garder en tête ces grands principes, parfois contre-intuitifs pour les organisations cloisonnées, mais essentiels à une transformation durable et profonde des organisations IT.