Dans un monde en constante évolution technologique, les entreprises cherchent continuellement des moyens d’améliorer l’efficacité et la fiabilité de leurs solutions. DevOps et Site Reliability Engineering (SRE) sont des approches et des méthodologies visant à améliorer le développement, le déploiement et la gestion des logiciels.
Dans cet article, nous explorons un cas concret de l’application d’une démarche DevOps SRE au sein d’une entreprise spécialisée dans l’Internet of Things (IoT). Julien Avenet, Site Reliability Engineer et Tech Lead chez Positive Thinking Company, partage son expertise et son expérience dans l’implémentation de cette méthodologie.
Il revient notamment sur les étapes clés, les défis relevés et les succès obtenus lors de la mise en œuvre de cette démarche.
Contexte et enjeux du projet
La démarche DevOps SRE a été déployée dans une jeune start-up spécialisée dans l’IoT.
La société se positionne sur le marché des serrures connectées pilotées par badge ou smartphone.
Le service est utilisé par plusieurs dizaines de milliers d’utilisateurs. Aussi bien des particuliers, des entreprises privées et coworking, que par les services publics.
Côté technique, la solution est déployée via une application mobile IPhone et Android, une application Web qui permet notamment la gestion des permissions sur les serrures dont on est propriétaire, et également une application web interne, qui permet la planification et le suivi des installations et le support client.
L’équipe technique est composée de 10 personnes. Un CTO polyvalent, 5 développeurs web pour la partie front, back et mobile, 3 développeurs embarqués pour gérer l’IoT et un ingénieur CI.
La problématique initiale portait sur deux points. D’une part, l’utilisation d’une technologie récente à l’époque et donc encore mal maîtrisée : Kubernetes. D’autre part, un déploiement sur des data centers proposant peu de services et avec une capacité planning limitée. Il y avait donc énormément de difficulté à mesurer et à avoir de l’observabilité sur le système, qui bien que simple, comportait énormément de machines à coordonner et gérer.
Cela engendrait notamment des difficultés à déployer de nouvelles fonctionnalités. Les déploiements étaient alors très espacés dans le temps, et les nouvelles fonctionnalités restaient longtemps sans être déployées. Puis, d’un coup, il y avait d’importants déploiements de 6 à 7 fonctionnalités à la fois. En découlait une difficulté à maintenir et à tester le bon fonctionnement de l’Infra, du service, etc.
Acculturation préalable à l’application de la démarche DevOps SRE
Avant toute application de changement, il convenait de cibler les objectifs principaux et d’embarquer les équipes.
Les propositions de priorisation ont été les suivantes :
- Premièrement, il s’agissait de faire évoluer l’architecture. L’architecture en elle-même était récente, mais l’utilisation des data centers n’était plus adaptée. Il fallait donc améliorer l’architecture existante et sa résilience. Autant profiter des fonctionnalités de Kubernetes pour retravailler la manière dont le projet était architecturé.
- Un point central était également d’améliorer le temps de déploiement, entre le moment où un développeur produisait une nouvelle fonctionnalité et le moment où elle arrivait en production.
- Il était aussi nécessaire de convaincre le top management. À force, la direction considérait l’ingénierie comme un point de difficulté avec des déploiements stressants. Il était donc important de les rassurer et de les convaincre de faire différemment en améliorant les process.
- Et enfin la réalisation de ces points impliquait également la mise en place de rituels SRE.
Étapes clés de l’implémentation de la démarche SRE
Pour commencer, la première étape a été de migrer dans le cloud, c’est-à-dire de migrer Kubernetes chez Amazon. À l’époque, il n’y avait pas encore les services managés Kubernetes. Pour ce faire, nous avons donc choisi d’utiliser un outil managé qui permettait de scaler le cluster assez facilement. C’était assez automatisé et cohérent vis-à-vis du besoin à ce moment-là.
Le choix d’Amazon était motivé par la maturité d’AWS à ce stade-là. Même s’il était possible d’aller sur du GCP ou Azure. En revanche, si c’était à refaire en 2023, plutôt que de faire une migration dans l’outil de provisioning, ce serait plus cohérent et plus dans l’air du temps de le faire directement sur le service managé du cloud.
Cette migration dans le cloud a aussi été l’occasion de supprimer les éléments de dette technique. En effet, malgré la récence de l’entreprise, il y avait tout même de la dette accumulée vis-à-vis de l’architecture.
Avec cette mise en place et ces changements, il y a aussi eu une montée en compétences sur Kubernetes. Nous avons alors pu davantage profiter de ses fonctionnalités comme le bon découpage en micro-services, le load balancing entre les services, etc.
Une fois cela fait, nous avons pu mettre en place de l’observabilité. À la fois technique, sur l’état de nos services, le nombre de requêtes par seconde, les erreurs, … Mais surtout fonctionnelle. Nous avons défini et suivi nos éléments de parcours client les plus importants pour observer des métriques orientées utilisateur : création de compte, permissions, ouverture de porte, …
Cela était bien sûr accompagné du cœur de métier du SRE, de la définition des SLI (Service Level Indicators) / SLO (Service Level Objectives) / SLA (Service Level Agreements).
Dans les grandes lignes, le SLA correspond au contrat de disponibilité, de fiabilité entre l’entreprise et l’utilisateur. Par exemple, l’entreprise s’engage à proposer tel service avec un taux de disponibilité de fonctionnement de 99,95% en taux de réussite de requêtes.
Le SLO correspond aux ambitions propres de l’entreprise, c’est l’objectif interne. Par exemple, si on annonce un taux de disponibilité de fonctionnement de 99,95% à l’utilisateur, on visera un objectif de 99,99% de taux de disponibilité en interne.
L’indicateur SLI correspond aux métriques qui vont permettre de mesurer l’état de bon fonctionnement et la position par rapport aux SLO et au SLA. Typiquement si on met un SLO sur l’ouverture de porte, on va mesurer les bonnes ouvertures de porte, moins les mauvaises sur le total. Ce qui va nous donner un pourcentage de réussite, qui correspond au SLI.
On mesure aussi la disponibilité du site, et principalement des applications.
Ensuite nous avons accéléré directement les déploiements. Le fait d’avoir modifié l’infrastructure, avec des micro-services, permettait de faire des déploiements plus petits, mais aussi plus fréquents et réguliers. Et ce qui a également contribué à cela, c’est l’automatisation de la création des environnements de développements et de leur mise à jour. En fait, ce qui freinait énormément les développements auparavant, c’était que les environnements de développement n’étaient pas similaires à la version en production. Donc un travail d’automatisation a été réalisé, afin de fournir de vrais environnements isoproduction aux développeurs, avec uniquement le delta de la fonctionnalité sur laquelle ils travaillaient. Ainsi, ils avaient une vue réelle de ce qui se passait et pouvait travailler dans de bonnes conditions.
Après toutes ces réalisations majeures, il s’agissait plutôt d’une seconde phase de mise en place sur l’amélioration des process.
Il y a alors eu globalement une automatisation d’un certain nombre de tâches. Avec un système plus pérenne et plus fiable, il a été possible de se rendre compte qu’il y avait beaucoup d’éléments hebdomadaires récurrents. Par exemple, le pôle Business Intelligence demandait régulièrement d’effectuer des requêtes sur les bases de données de production, auxquelles ils n’avaient pas accès. Ce processus a alors été automatisé pour que ce service ait accès aux résultats sans qu’il soit nécessaire de réaliser une action manuelle régulière.
Ce sont aussi les process et les responsabilités de l’équipe informatique qui ont été adaptés. Notamment le process de déploiement, et les responsabilités associées. À ce stade les développeurs ont été énormément impliqués dans la vie de la production. C’est-à-dire qu’ils assistaient aux déploiements, en amont sur les tests et en aval pour vérification. Ainsi ils pouvaient intervenir immédiatement sur tout ce qui était incident, pour du debug et de la résolution, et prise de décision si besoin.
En termes de rituels, le principal rituel mis en place a été le ciblage et l’identification des erreurs récurrentes. Cela afin de systématiquement les éliminer, que ce soit des erreurs techniques, mais aussi des erreurs fonctionnelles. C’était une priorité de réduire le taux d’erreur, certes faible, mais récurrent.
Et la dernière étape de la démarche a consisté à convaincre le top management de poursuivre les changements entamés. Il y avait de premiers résultats, mais il fallait encore accélérer pour continuer dans ce sens. Au vu des améliorations constatées, ils ont accepté d’aller de l’avant.
Challenges et succès rencontrés
Les challenges surmontés
La difficulté principale dans ce genre de projets est qu’on change énormément de choses rapidement.
Il y a un vrai temps d‘accompagnement qui est nécessaire, autant auprès des développeurs, que des autres collaborateurs. La manière de travailler évolue et il faut accompagner, former et ne pas hésiter à expliquer les choses.
Sinon, plus techniquement, il a été difficile de bien utiliser l’error budget au début. Cet indicateur correspond au delta entre le SLI et le SLO. Quand on a un SLI supérieur au SLO, cela signifie qu’on est au-dessus de son objectif. On peut alors se permettre d’accélérer le rythme de déploiement de fonctionnalités, jusqu’à ce qu’en général cette accélération du rythme fasse que le SLI baisse et arrive au niveau du SLO, voire en dessous. Et à ce moment-là, on va plutôt faire du déploiement de fix.
Ce concept était assez dur à utiliser, bien qu’il soit un concept fort en SRE. Mais avec un peu de persévérance, la maîtrise c’est améliorer avec la pratique.
Une autre difficulté a été de définir des SLI cohérents. Le parti pris était d’aller dans du fonctionnel, dans le parcours client, plutôt que dans le fonctionnement technique de base. Et le parcours ne correspond pas forcément à un appel qu’on peut mesurer. Donc il y a eu un vrai travail du système pour définir la manière de calculer les différentes requêtes. C’était assez challengeant mais important. Une fois qu’on mesure bien, on a une bonne vue du système et une bonne compréhension de ce qu’il se passe et des points de blocage. Finalement, c’était même l’élément le plus important sur l’ensemble des optimisations apportées.
Et une dernière difficulté, rencontrée principalement au démarrage, a été l’implication des développeurs dans les incidents.
Le produit de l’entreprise est un produit stratégique qui implique de fortes responsabilités en cas de non-fonctionnement du système. Et ce stress peut arriver jusqu’aux développeurs, qui n’ont peut-être pas l’habitude d’y être confrontés. Il a donc fallu prendre du temps pour les accompagner sur ces sujets. Mais ensuite, au bout d’environ deux ans de fonctionnement avec la méthode de DevOps SRE, il a même été possible de déléguer les temps d’astreinte. Cela a pris du temps, mais par la suite ils ont vraiment été très impliqués sur cette partie.
Une implémentation réussie
Malgré les difficultés, qui ont toutes étaient surmontées, il y a aussi eu rapidement de belles réussites.
La migration dans le Cloud a notamment été un beau succès. Cela a vraiment permis de revoir l’architecture, de supprimer les freins et les incidents liés à la dette technique, etc.
Et les rituels et le travail d’amélioration de la production ont également permis de limiter les erreurs récurrentes. Il y en avait bien moins. Ce qui permettait de passer beaucoup moins de temps à les gérer et les analyser.
Les nouveaux environnements de développement ont aussi été de suite très utiles. Ils ont contribué à l’amélioration de temps de déploiement, mais aussi du temps de développement entre la demande de création d’une nouvelle fonctionnalité, et sa création effective. Avant, les développeurs avaient un environnement qui n’était pas cohérent et un accès à une base de données qui ne correspondait qu’à 1% de la base de données réelle. Ils avaient plein de points de difficultés. Puis, on leur a fourni une version constamment semblable à celle en production, avec 100% de la base (anonymisée). Ainsi, ils avaient des conditions réelles de développement. Ils savaient ce qu’ils développaient et il n’y avait pas de différence avec la production.
Bilan
Les résultats obtenus sont la suite logique des challenges et succès qui ont été décrits.
Il a fallu environ deux ans pour que le nouveau fonctionnement tourne correctement et soit devenu naturel.
Au bout de cette période, les déploiements étaient passés de 1 à 15 par mois, soit des nouvelles fonctionnalités presque quotidiennes. Il y avait même des déploiements effectués le vendredi. Ce n’était même plus un problème. Les tests et les process étaient performants, et il était devenu possible de revenir en arrière immédiatement si nécessaire.
Les SLI orientés utilisateurs ont vraiment aidé. Ils ont permis d’identifier des problèmes présents dans le système et qui ont pu être retravaillés. Ce travail a permis d’améliorer le système, ainsi que sa disponibilité et sa fiabilité.
Les incidents étaient aussi beaucoup moins fréquents. Et s’il y en avait, ils étaient plus courts, justement grâce à la possibilité de roll back quasiment immédiatement. Mais il y avait très peu d’erreurs de développement causant des incidents.
Au niveau des processus, le fonctionnement du département a été simplifié et automatisé le plus possible.
Et concernant les autres résultats, les développeurs se sont beaucoup impliqués dans la vie de la production, après justement cette phase de formation et d’accompagnement.
Et il y a aussi eu une grosse réduction du temps de travail accordée au RUN, au profit du BUILD, et donc de la création de valeur.
Enfin, une conséquence assez forte, qui a découlé de tout ce travail, a été une cohésion d’équipe extrêmement renforcée par cette responsabilité commune, ce projet commun et ces nouvelles manières de faire.
Nous publions régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram
Vous souhaitez en savoir plus ? Naviguez sur les autres pages de notre site web et découvrez nos offres d’emploi.
