Dans la suite de notre trilogie dédiée au DevOps et après avoir parlé de l’Agilité comme base essentielle à la démarche, Stéphane (Ingénieur innovation chez Orange) nous propose ici d’en aborder les objectifs et principes.
Bonne lecture !
Une vision commune
C’est un souhait du DevOps.
Traditionnellement, on affronte les équipes de développement aux équipes opérationnelles.
Vous l’avez peut-être vécu ou le vivez encore : sur le projet, on a une équipe de développement qui est là pour livrer et valider. Elle passe ensuite la main aux équipes opérationnelles qui sont là pour mettre en production. Ils récupèrent des choses plus ou moins bien validées, avec des risques plus ou moins sensibles vis-à-vis des clients (utilisateurs finaux).
Le but du DevOps n’est pas de remplacer de l’agilité et du lean : ils en sont les bases. Il est là pour proposer de la vitesse et de la stabilité pour tous.
Les équipes de développement livrent toujours à leur rythme tandis que les opérationnels possèdent tous les moyens de mettre en œuvre une stabilité accrue de ce qui a été livré. Ce qui apporte une meilleure qualité de service.
L’objectif recherché est bien de dépasser ce fameux « mur d’incompréhension ».
Le symbole du DevOps ressemble d’ailleurs à celui de l’infini, avec un lien entre les deux équipes à travers le package et la release. Mais aussi du monitoring vers les plans des dévs.
Je dis ce que je vais faire. Je fais ce que je dis. Je prouve, en validant, ce que j’ai réalisé. Et je mets tout en œuvre pour vérifier que tout cela reste bon sans sortir de ce qui était attendu.
Le DevOps est un cercle d’amélioration continue.
Qu’attend-on du DevOps ?
La structure formée sur le projet ne sera donc plus deux équipes distinctes mais une seule et même équipe où les membres travaillent tous ensemble.
On recherche avant tout à augmenter la confiance entre les Dév et les Ops, en garantissant un contexte sécurisé pour tous. Cela permet de réduire les erreurs et de diminuer la durée et le coût. Moins on passe de temps sur quelque chose et moins cela coûte cher. L’ensemble de l’équipe aura également une meilleure visibilité du projet : c’est l’essentiel.
Chaque personne de l’équipe sait ce qu’elle doit faire et quelle est sa responsabilité.
On sait ce qu’il y a à l’intérieur, on sait quelle est la configuration mise en œuvre et surtout, on est capables de répéter. On peut la remettre en œuvre sur la production et également sur d’autres plateformes et environnements intermédiaires pour refaire de la validation par la suite.
Etre C.A.L.M.S.
Le DevOps repose sur 5 principes :
- Culture : améliorer l’organisation de l’entreprise pour un objectif commun. La finalité est le client.
- Automation : tout ce qui peut être automatisé doit l’être. Tout ce que l’on fait manuellement en ligne de commandes doit être absolument automatisé.
- Lean : économie de coûts et optimisation des ressources.
- Mesure : partie monitoring, remonter les informations et les erreurs pour une analyse d’impact sur les utilisateurs. Lorsqu’il y a quelque chose qui ne va pas, je dois avoir toutes les informations pour pouvoir le corriger.
- Sharing : partage et communication entre les équipes.
Comment mettre en oeuvre ?
- Feedback : il est important d’avoir des retours que ce soit côté technique ou business. Cela peut s’appliquer grâce à des sondages auprès des clients, avoir des indicateurs de réajustement qui remontent etc…
- Transversabilité de l’organisation et des équipes : la hiérarchie ne sert à rien vis-à-vis d’un client, l’important sont plutôt les rôles de chacun. On recherche de l’efficacité avant tout et l’on doit analyser les freins afin de les remplacer en proposant de la valeur au client.
- Responsabilisation : si une équipe n’a pas les moyens de prendre des décisions directement, le produit ne pourra pas être livré régulièrement. Fournir aux équipes les moyens d’être autonomes permet de livrer le client de manière plus fluide et plus rapide.
- Polyvalence des équipes : les équipes doivent être compétentes en sachant gérer tous les rôles nécessaires dans la production du produit. Les équipes ou les personnes doivent être multi-compétences.
Chez Google, les développeurs mettent en production et suivent la production.
- Amélioration continue : si on mesure les choses, on peut ainsi suivre la réalisation et fixer des objectifs. Cela peut être dans les coûts, les délais, la qualité et aussi dans les échecs. « Qui n’essaie pas ne se trompe pas ». Il faut essayer, expérimenter et avoir des indicateurs nous permettant de savoir si l’on est sur la bonne route. Une équipe qui reste dans sa zone de confort n’a souvent même pas conscience qu’elle peut s’améliorer.
- Automatisation : CI/CD, IaC, Cloud Native.
Comment s’organise-t-on ?
Pour évoluer dans un cadre favorable, les équipes doivent être communes, transverses et compétentes. Tous les membres sont orientés vers un objectif commun : le client.
On assume le droit à l’erreur et on favorise l’expérimentation.
L’organisation doit faciliter la décision et limiter les processus « administratifs ». L’environnement favorise la production rapide des développements logiciel.
Quels indicateurs ?
Sans être trop nombreux, chacun doit comprendre l’indicateur et savoir à qui il s’adresse. Ils sont à partager entre tous :
- Pour le client (SLA – contractuel)
- Pour la production (SLI, SLO)
- Pour les dév’, référence DORA (DevOps Research & Assessment) avec fréquence et temps de déploiement, et pour la stabilité : temps de réparation et taux d’incident.
Le taux d’incident par exemple correspond au nombre de fois où j’ai mis des erreurs en production. Cela permet de classifier les entreprises qui ont mis en œuvre du DevOps et quel est leur niveau de maturité dans la démarche. Le taux d’incident peut être le même en pourcentage mais les entreprises matures répareront les erreurs beaucoup plus rapidement.
Les indicateurs servent à savoir où l’on va.
Quels sont les outils DevOps ?
La liste pouvant être très longue, il s’agit principalement ici de répertorier les catégories dont vous aurez besoin.
Nous y reviendrons dans le prochain Wiki Déj’ dédié au CI/CD.
- Centralisation des demandes (Use Case, Epic, Backlog…)
- Images et conteneurs (Registry, Docker, Kubernetes). On ne travaille plus sur des VM mais des conteneurs.
- Infra Cloud (IaaS, CaaS, PaaS) et IaC (Infra as Code) avec Terraform, Ansible…
- Repository de code et incident commun (Git, GitHub, GitLab…)
- Outils d’analyses, de tests et de sécurité (Lint, Postman, Selenium, Trivy, Chaos…)
- Observation – Surveillance (Prometheus, Grafana…)
Les évolutions liées au DevOps
Les métiers SysAdmin, Dév, Intégrateurs et valideurs évoluent vers
- Ingénieur DevOps (attention au rôle attribué au sein de l’organisation)
- Ingénieur SRE (Site Realibility Engineering) ou l’ingénierie de la fiabilité des serveurs et services, dans l’environnement « site web ». Ce métier est davantage transverse.
Emergent également DevSecOps (orienté sécurité), GitOps, NoOPS, AIOps, FinOps.
A retenir
Le DevOps :
- Se concentre sur la culture
- Met l’accent sur les rôles
- Souligne la réactivité
L’intérêt d’entamer cette démarche est de renforcer votre agilité, votre productivité et la qualité de vos projets !
Les Wiki’Déj étant avant tout un moment d’échanges et de partages, la présentation s’est poursuivie par une discussion avec les participants. Peut-être que vous partagez les mêmes questionnements !
Vous retrouverez également des références de ressources pour aller plus loin.