Mise en place d’une organisation DevOps

Cyrille Le Clerc

Comme le mouvement Agile a rapproché donneurs d’ordre et équipes de réalisation autour d’une vision commune orientée « produit », le mouvement DevOps rapproche aujourd’hui les équipes de développement (DEV) et d’exploitation (OPS) autour d’une vision commune orientée « service », afin de mieux concilier réactivité et qualité de service.

DevOps aborde le paradoxe entre des équipes projets qui cherchent à livrer toujours plus fréquemment des nouvelles fonctionnalités d’une part et d’autre part des équipes d’exploitation qui cherchent à stabiliser et fiabiliser les systèmes tout en maitrisant leur coût.

On peut décrire DevOps selon trois axes :

• Aligner l’exploitation sur les enjeux métiers comme l’agilité a déjà aligné le développement sur le métier.
• Aligner le développement sur les réalités de l’exploitation pour rendre possible la mise en production, la disponibilité et la fiabilité des fonctionnalités métier.
• La transformation du métier d’OPS pour gérer des topologies chaque jour plus grosses et plus complexes avec l’adoption d’infrastructure as code et d’outils comme Chef ou Puppet. Les nouveaux OPS sont des programmeurs ! Ils débattent à la machine à café de TDD, de Ruby vs. DSL, de choix d’IDE, de Git vs. SVN, …

DevOps est souvent associé à la mise en place d’un processus de Continuous Delivery qui, dans la mouvance Lean, vise à déployer les fonctionnalités en production au plus vite et de maximiser les feedbacks. Nous reviendrons dans un autre billet sur les processus de Continuous Delivery.

La mise en place d’une culture DevOps touche les humains, les processus et les outils. Nous proposons une démarche englobant ces trois aspects en prenant comme point d’entrée les processus et, de proche en proche, faire évoluer les humains et les outils.

Les processus

Tous les processus impliquant la collaboration des équipes de développement et d’exploitation sont sujets à la mise en place d’une culture « DevOps ». Nous proposons pour la première étape de nous focaliser sur les processus de livraison, de déploiement et de troubleshooting.

Processus de livraison

Le processus de livraison (aka processus de packaging de la release) est la première interaction entre les équipes de développement et de production. Ses défauts causent l’allongement des projets et des interruptions de service. A l’inverse, l’automatisation du processus de livraison concilie « time to market » et diminution des risques en déployant plus fréquemment des changements au périmètre limité.

Nous proposons d’accorder les équipes de développement et d’exploitation sur les points suivants :

• Périmètre du package pour éviter les transformations et manipulations de mise en production : binaires identiques sur tous les environnements, fichiers de configurations épurées, etc.
• Rôles et responsabilités des équipes de développement et d’exploitation dans le packaging : binaires pour les développeurs, scripts et paramètres de configuration gouvernés par l’exploitation, etc.
• Définition des outils et techniques de packaging : tag Subversion/Git, build Maven, repository Maven Nexus, etc.
• Alignement des environnements de développement, d’intégration et de production pour éviter les écarts dev/prod : on doit tester sur un environnement le plus iso-prod possible.

Processus déploiement

Une fois le packaging clarifié, nous proposons d’automatiser et d’unifier les processus de déploiement du dev à la prod. Les bénéfices sont :

• L’accélération des feedbacks des équipes de Q&A par des déploiements plus fréquents sur les environnements de validation.
• La fiabilisation des déploiements en les testant avant la mise en production.

L’objectif est la banalisation : les déploiements deviennent des « non événements ».

Processus de troubleshooting et de diagnostique

Réussir l’analyse de problèmes en production nécessite une préparation et un entrainement conjoints des équipes d’exploitation et de développement.

Des répétitions impliquant à la fois OPS et DEV permettront de valider :

• Que les applications sont debuggables : clarté des messages de log, clarté des exceptions, indicateurs de monitoring (JMX), etc.
• Que les outils de diagnostique sont installés : activation et collecte de logs, accès sans problèmes de firewall, disponibilité des outils sur les serveurs (curl, screen, jstat, jmap, etc.).
• Que les OPS et les DEV ont les bons outils de collaboration lors de problèmes en production : accès en lecture seule pour les DEV, messagerie instantanée, partage d’écran, micro-casques, etc.

Amélioration continue dev/prod

Les sujets d’amélioration continue transverse développement / exploitation sont gérés à la fois dans la continuité avec des réunions « dev/prod », et lors d’événements particuliers sous forme de points « post mortem » (panne, mise en production importante, etc.). Les sujets abordés relèvent d’enjeux à court, moyen et long terme :

• Monitoring & KPI : mise en place d’indicateurs techniques et métiers de bonne santé des applications (choix des outils, adaptation du code métier, health checks, etc.).
• Gestion des logs et des exceptions : amélioration des messages, outils de concentration et d’analyse de logs.
• Robustesse, tenue à la charge et capacity planning : suppression des points de faiblesse, mise en place de modes dégradés et de mécanismes de protection contre les saturations (e.g. : circuit breaker pattern), plans d’action de test en charge, plan d’ajout de capacité.
• Sécurité : patchs à appliquer, règles de sécurité de l’entreprise, etc.
• Fiabilisation des mises en production : activation progressive (feature toggle) ou partielle (canary testing) de fonctionnalités, etc.
• Processus et outillage : amélioration des processus dev/prod, alignement et partage des outils.
• Suivi du schéma directeur : gestion des montées de version des middlewares, migrations techniques, rationalisation des environnements.
• Evolutions de l’application et de l’infrastructure : refactoring de l’infrastructure, introduction de nouvelles technologies, plan de montée en compétence.

L’organisation : You build it, you run it ?

L’organisation est le sujet le plus complexe à aborder dans la mise en place d’une culture « DevOps ». Certaines entreprises comme Amazon ont intégré les équipes de développement et de production au point d’avoir pour devise « You build it, you run it ».

Un point essentiel est de s’assurer que les objectifs des différents acteurs soient alignés vers une amélioration de la disponibilité et de l’évolutivité des applications. Si les intérêts des uns et des autres sont contradictoires et ne sont pas alignés sur ce même objectif, l’adoption d’une culture « DevOps » touchera vite ses limites.

Nous proposons d’étudier les changement organisationnels au fur et à mesure de la mise en place des principes DevOps dans les processus que nous avons cité en veillant à prendre en compte les réalités de chaque entreprise.