Equipe SRE : pourquoi toute ESN doit s’en doter
La maintenance des outils de production de logiciels est parfois oubliée. Indispensables à la valeur principale produite par les ESN, il est nécessaire de s’assurer que ces outils soient mis au cœur de l’entreprise. A travers mon expérience, je vous propose de découvrir comment une équipe SRE (Site Reliability Engineering) représente une réponse adéquate pour y parvenir.
La maintenance des outils de production de logiciels est parfois oubliée. Indispensables à la valeur principale produite par les ESN, il est nécessaire de s’assurer que ces outils soient mis au cœur de l’entreprise. A travers mon expérience, je vous propose de découvrir comment une équipe SRE (Site Reliability Engineering) représente une réponse adéquate pour y parvenir.
Equipe SRE : explications
Dans toute ESN la volonté d’apporter au quotidien les solutions aux problématiques de développement des collaborateurs prédomine. Au sein du centre de services de SQLI, une équipe auto-organisée, composée de 2 Ops et 3 Devs, a émergé pour remettre les outils de production au cœur des préoccupations. Autobaptisée EMP (Equipe des Moyens de Production), notre équipe se rapproche du fonctionnement de l’équipe SRE (Site Reliability Engineering) créée par Google gérant la maintenance de l’infrastructure mais également son industrialisation et la mise en place de nouvelles fonctionnalités. L’équipe EMP fournit ainsi aux collaborateurs une infrastructure stable à travers ces 5 actions :
- Héberger, maintenir et faire évoluer les outils internes
- Fourniture de l’ensemble des services de production nécessaires aux équipes : Gitlab, Jenkins, Sonar, Nexus, Registry Docker, Jira…
- SLA (Service-Level Agreement) de production pour les outils critiques que nous hébergeons : l’indisponibilité durant la journée des outils, tels que Jenkins et Gitlab, serait bloquante pour les équipes
- Héberger, monitorer et industrialiser la fourniture de VM (Virtual Machine) pour les projets
- Simplifier l’expérience développeur en adoptant les démarches et outils qui leur permettent de travailler plus efficacement
- Accompagner les équipes sur la mise en place des bonnes pratiques d’industrialisation
- Définir et maintenir les outils mis à disposition sur les postes des collaborateurs
Son credo est de fournir la plus grande autonomie possible pour les collaborateurs dans la réalisation de leur profession.
Une équipe qui favorise l’autonomie
Avant de commencer, un petit rappel sur DevOps : c’est une culture d’entreprise où les équipes de développement et les équipes opérationnelles ne sont plus isolées et cherchent ensemble à livrer des applications stables de façon automatisée, monitorée et prenant en compte une boucle d’amélioration continue. La composition de notre équipe EMP et notre attirance pour la philosophie DevOps a eu dans un premier temps l’effet bénéfique de nous faire progresser sur :
- La montée en compétence sur la maintenance d’un cloud privé, bénéfique pour les Dev pour comprendre les problématiques des Ops et anticiper les demandes en provenance des équipes
- L’utilisation des outils des Dev (Gitlab et Jenkins) : notamment par les Ops, ce qui leur a permis de faciliter l’automatisation d’une grande partie de leurs actions manuelles
Ces 2 items ont permis à l’ensemble des membres de notre équipe d’élargir leur champ de compétences, d’accroître leur autonomie, mais également d’accompagner plus efficacement les équipes projets. Il arrive désormais fréquemment que les Ops conseillent les équipes projets sur la mise en place de pipelines sur leurs projets. Le second effet bénéfique concerne l’accroissement de l’autonomie des équipes via :
- La mise en place d’environnements de développement (le plus souvent dockerisés)
- La mise en place de pipelines
- L’accroissement de la vélocité des demandes des projets, notamment par la création de VM à la volée et éphémères
- La compréhension des équipes d’exploitation et d’infogérance de nos clients
- L’expérimentation de pratiques sur quelques projets pour en mesurer les effets et intégrer les collaborateurs sur certains choix d’implémentation
- La diffusion du savoir auprès des équipes à l’aide d’ambassadeurs
Amélioration continue des pratiques
Le renforcement de l’autonomie des équipes n’est pas le seul résultat notable de l’existence de l’équipe SRE. Nous avons également constaté les avantages suivants :
- Mise en place d’une infra as code, permettant notamment une réinstallation de notre plateforme sans action manuelle
- Industrialisation des montées de versions de nos outils internes et Open Source jusqu’à nos environnements de préproduction, le passage en production constituant l’action manuelle restante
- Accroissement des compétences Cloud et d’orchestration de conteneurs Docker
- Développement d’une offre de service sur l’accompagnement et d’audit sur les pratiques de déploiement au sein d’entreprises clientes
- Uniformisation des pratiques au sein de projets multi-clients (dockerisation, pipeline, création de VM à la volée et éphémère) facilitant le switching de projet
Quelques difficultés à surmonter
Pour arriver à ces résultats, nous avons été confrontés aux difficultés suivantes, auxquelles toute ESN peut également faire face :
- Afin que l’équipe soit comprise par le management de l’entreprise, nous avons désigné un sponsor « managérial » de celle-ci
- Le risque de cette auto-organisation est qu’elle peut être vouée à disparaître si les membres de cette équipe ne trouvent pas de remplaçants, c’est une problématique inhérente au turnover des ESN
- Les systèmes informatiques évoluent très rapidement, ce qui demande une adaptabilité à chaque instant et qui rend assez difficile la projection sur le futur
- Dans l’organisation parfois complexe des ESN, souvent découpée en silos, nous ajoutons une nouvelle dimension transverse, ce qui peut être bouleversant d’un point de vue organisationnel. Quelqu’un se posera toujours la question : « Qui soutient financièrement cette activité ? »
Pour conclure, essayer une équipe SRE, c’est l’adopter. Il faut briser le cycle infernal du « Les cordonniers sont les plus mal chaussés ». C’est en se reconcentrant en interne sur ses outils de production qu’une ESN démontrera à ses clients le savoir qu’elle a acquis.