Le QAOps émerge pour intégrer la qualité dans l’entièreté du cycle de vie du développement logiciel.
La démarche vient complémenter les approches DevOps existantes, en mettant l’accent sur la perspective de qualité, de l’entreprise et de ses clients jusqu’aux opérations.
« QAOps: Building an Observability Pipeline » était le thème de notre table ronde, un concept combinant les pratiques de supervision, visualisation et de data engineering.
Je remercie chaque participant pour sa participation et sa contribution :
- Eduardo Piairo, Directeur des opérations chez Deeper Insights
- Ricardo Castro, Senior Site Reliability Engineering chez Farfetch
- Pedro Esteves, Senior Tech Lead
- Luís Bastião Silva, CTO chez BMD Software
Cet article est le résumé des points clés nous avons identifié lors de notre partage,
Rejoignez la QE Unit pour accéder à plus de contenu de la communauté.
L’Observabilité, un fondement du QAOps
Le QAOps consiste à améliorer l’impact de la qualité tout au long du développement logiciel. La partie « Ops» ne restreint pas son prisme à l’aspect opérationnel ; cela commence du point de vue de l’entreprise et des utilisateurs, avant même de coder. Où s’inscrit donc l’Observabilité dans tout cela ? Nous devons commencer par le pourquoi.
En tant que contributeur à l’entreprise, notre objectif est de créer plus de valeur. Par conséquent, la mesure devient une exigence, « Nous ne pouvons pas améliorer ce que nous ne pouvons pas mesurer ». L’Observabilité est la pratique consistant à comprendre un système à partir de ses points de données externes, le rendant ainsi « Observable ».
En note de contexte, beaucoup de choses ne sont pas mesurables, malheureusement et pour l’instant.
L’Observabilité ne fonctionne pas par elle-même, du moins pour l’instant. Nous devons créer les données sources, les collecter et les rendre utiles. Ces trois étapes se retrouvent dans les architectures de data engineering, expliquant le terme de « Pipeline d’Observabilité ». Dans notre cas, nous collectons et traitons une variété de métriques, de logs et de traces.
Quant au QAOps, l’Observabilité n’est pas seulement une question d’environnement de production.
L’Observabilité ne se résume pas à un état
Nous associons naturellement l’Observabilité à un tableau de surveillance, avec des cases vertes et rouges appliquées à l’environnement de production. Cette association est partiellement vraie pour deux raisons: L’Observabilité s’applique à tous les environnements, et le statut est l’une des mesures possibles.
L’objectif d’un pipeline d’Observabilité est de mesurer des domaines d’activité spécifiques tout en soutenant le processus de développement logiciel. Par conséquent, notre Observabilité devrait être appliquée à tous les environnements pour garder une perspective holistique. Une part importante des améliorations opérationnelles proviennent d’améliorations réalisées en amont.
La deuxième perspective consiste à étendre les données observées. Nous sommes habitués à regarder des états, comme OK/KO ou en valeur absolue. C’est bien un premier pas. Le fait est que nos systèmes sont en mouvement, notre Observabilité doit donc permettre la visualisation de processus dynamiques. Le Value-Stream et le Process Mining sont des techniques répondant à ces exigences.
Nous pouvons devenir très enthousiastes avec toutes ces possibilités. Cependant, il n’y a pas de raccourcis pour créer un pipeline d’Observabilité.
L’Observabilité, une approche étape par étape
Nous commençons à saisir la complexité de l’Observabilité. Une approche incrémentale est un moyen d’équilibrer la création de valeur et la gestion des risques, en évitant une autre initiative à effet tunnel. Un élément essentiel est de rester concentré sur la création de valeur.
Notre « Pourquoi » initial aide à trouver la valeur pour les parties prenantes au travers de cas d’utilisation. Notre initiative doit fournir des gains rapides répondant aux besoins concrets de survie ; nous devons nous concentrer sur les incréments d’Observabilité de bout en bout. Une approche technologique cloisonnée échouera tôt ou tard, même si les fondations technologiques restent structurantes.
« La scalabilité n’est pas qu’une question d’échelle. Il s’agit d’augmenter la création de valeur avec des fondations extensives et évolutives. »
Antoine Craske
Nos premières itérations apporteront de la valeur sur un ensemble limité d’applications et de complexité. Une fois que nous commençons à augmenter la portée des données, seules les fondations structurées peuvent soutenir une expansion. Les normes partagées de formats de données, de schémas et de gouvernance sont trop souvent négligées ; ils doivent évoluer de manière collaborative et incrémentale, en ligne avec la maturité de notre initiative d’Observabilité.
Les fondations ne sont pas seulement techniques et comportent plusieurs défis.
Les défis d’un pipeline d’Observabilité
Fournir de l’Observabilité à travers notre pipeline consiste à développer un écosystème complexe de données créateur de la valeur pour ses parties prenantes. Nous rencontrons un défi important des organisations : les interactions humaines.
Nos premières interactions commencent avec nos parties prenantes pour identifier le pourquoi avant de les convaincre. Pour répondre à leurs besoins, nous avons besoin de la collaboration d’autres équipes pour créer nos solutions d’Observabilité. Pour réussir notre expansion, nous devons travailler sur la culture, pilier fondamental de la mise à l’échelle des pratiques d’ingénierie.
« La culture est un pilier fondamental de la scalabilité de pratiques d’ingénierie. »
Antoine Craske
La croissance consiste à augmenter la taille de l’équipe pour accélérer et augmenter la création de valeur. Nous sommes confrontés à un nouveau problème : nous devons intégrer de nouveaux membres tout en ne consommant pas les équipes existantes en formation. Une documentation actionnable peut faire la différence en plus d’un peer affecté, supportant un processus d’intégration évolutif et en libre-service. La difficulté réside dans la structure, le niveau d’abstraction et la stabilité de la documentation sous ses diverses formes (générées par du code, des wikis, des vidéos).
Les technologies s’accompagnent également d’un ensemble de défis. Une façon de structurer les fondations est de fournir une plateforme de développement avec des normes et des modèles. La difficulté réside dans son adoption. Nos clients sont les développeurs qui, traditionnellement, préfèrent leur propre cuisine. Notre adoption réussira avec une utilisation plus facile, d’un facteur 10. De plus, une myriade de solutions doivent être intégrées pour répondre à des besoins uniques.
« Il n’existe pas d’outil universel pour répondre à des exigences uniques. »
Eduardo Piairo
Relever les défis avec succès peut nous permettre de passer au niveau supérieur de valeur, comme soutenir une initiative de Reliability.
Une approche de Reliability repose sur l’Observability
Ricardo a partagé avec nous l’accent mis sur une initiative de Reliability chez Farfetch. L’objectif est d’encourager l’organisation à considérer des expériences fiables dans leurs plateformes numériques. Encore une fois, la mesure est une nécessité, en s’appuyant sur l’Observabilité.
La fiabilité se matérialise dans un ensemble d’engagements tels que les indicateurs de niveau de service (Service Level Indicator, SLI) et les objectifs de niveau de service (Service Level Objective, SLO). Ils peuvent même être un accord contractuel sous la forme d’accords de niveau de service (Service Level Agreements, SLA). Un niveau de service se traduit par un indicateur en pourcentage absolu. Le paradigme « 9 » est un standard du marché, par exemple en « four nines » pour 99,99 %.
La mesure du service ne se limite pas à leur disponibilité. Google a popularisé les quatre signaux d’or ou « 4 Golden Signals » de sa pratique de SRE. Nous pouvons trouver le taux d’erreur et la latence aussi importants que la disponibilité. Des normes émergent au sein de l’écosystème pour faciliter notre évolutivité, intégration et interopérabilité. La « SLOConf » est d’ailleurs une conférence dédiée à ce thème des SLO.
Néanmoins, des indicateurs pour des indicateurs ont une valeur limitée. Nous pouvons faire mieux.
Un pipeline d’Observabilité pour le Quality at Speed
Nous devons comprendre le « Pourquoi » de ces mesures. Contre-intuitivement, leurs principaux moteurs n’étaient pas une perspective contractuelle liée à des pénalités financières. Au lieu de cela, c’était un moyen de soutenir l’accélération et la stabilité des changements. De nombreux thèmes humains concernent un équilibre d’éléments contradictoires ; cela s’applique à la livraison de logiciels via la notion d’« error budget ».
Le concept de « error budget » est un crédit que l’équipe peut utiliser en introduisant des changements qui peuvent impacter le niveau de service. Une fois le crédit consommé, ils ne peuvent plus déployer jusqu’à la prochaine remise à zéro du compteur. Pendant ce temps, ils peuvent s’attaquer aux causes profondes des interruptions de service, améliorer leur application et réduire leur dette technique. Google est l’un des principaux initiateurs de ces pratiques pour faire évoluer et accélérer leur capacité d’innovation en garantissant une qualité de l’expérience, à l’échelle.
La combinaison de ces principes est puissante si nous réussissons notre pipeline d’Observabilité.
Quelles lignes directrices pour démarrer un pipeline d’Observabilité
Pedro s’interrogeait sur les étapes à suivre pour lancer une initiative d’Observabilité et de qualité. Comme tout processus, les éléments contextuels sont fondamentaux, soutenus par un ensemble de bonnes pratiques. Nous avons ici décrit les étapes vitales.
Nous devons trouver le sens, la raison et la motivation dans le « Pourquoi ». Le Pourquoi doit être lié à la création de valeur pour quelqu’un. C’est le concept de la qualité. Le quelqu’un n’est pas seulement une personne ; un large panel d’acteurs est nécessaire : nos utilisateurs, clients, sponsors jusqu’aux différentes équipes opérationnelles. Nous ne pouvons formuler une proposition valable qu’en comprenant chaque perspective ; d’où l’importance de l’implication des parties prenantes.
« Commencez par pourquoi et pour qui. Ensuite, concentrez-vous sur le sponsor et l’équipe « early win ».
Antoine Craske
Les différentes parties prenantes ont besoin d’un engagement dès le début de l’initiative. Le niveau d’engagement varie en fonction d’une matrice de parties prenantes traditionnelles. Cependant, deux acteurs cruciaux se démarquent : le sponsor et l’équipe « early win ». Les sponsors sont ceux qui investissent, défendent et soutiennent votre initiative s’ils captent de la valeur. L’équipe « early win » est fondamentale pour atteindre des résultats et embarquer le reste de l’organisation par la suite.
« Il y a deux raisons d’investir : pour gagner de l’argent, ou arrêter de perdre de l’argent. »
Eduardo Piairo
Les étapes suivantes résident dans une approche itérative afin d’équilibrer la création de valeur et les risques. Des risques importants résident dans les défis des changements culturels, des fondements et des capacités d’évolutivité que nous avons identifiés. Le contenu de chaque itération dépend de votre contexte, remontant à la valeur, pour qui et à sa mesure. « La communication, la communication et la communication » restera fondamentale.
La mesure et la communication nous ont, encore une fois, ramenés au besoin d’Observabilité.
L’Observabilité au cœur du QAOps
Notre conversation sur la création d’un pipeline d’Observabilité conduit à la création de valeur et à la scalabilité des organisations. Nous matérialisons le besoin de motivations d’entreprise et métier dès le départ et tout au long de notre initiative. Il faut du courage pour entretenir une telle dynamique.
Nous devons avoir le courage de partager et de comprendre les différentes perspectives des parties prenantes tout en alignant nos fondations technologiques. Nous devons avoir le courage de trouver un sponsor, de favoriser une culture d’ingénierie qui peut évoluer, en sachant communiquer régulièrement.
Nous avons besoin de courage à travers tous les revers que nous rencontrerons au cours de notre aventure. Le courage est également requis lors de la mise en œuvre d’« error budget », en privilégiant la durabilité à moyen terme sur la livraison de fonctionnalités à court terme.
Le QAOps et la pipeline d’Observabilité créent de la valeur pour les personnes grâce à la combinaison d’architectures, organisations, produits et technologies. Gardons donc une perspective holistique, incrémentale, sans oublier le principe « First things First ».
Références
Surveillance pratique : stratégies efficaces pour le monde réel, Mike Julian https://www.amazon.com/Practical-Monitoring-Effective-Strategies-World/dp/1491957352
SLO Con, Conférence sur les objectifs de niveau de service https:// www.sloconf.com
Implémentation des objectifs de niveau de service : guide pratique des SLI, SLO et budgets d’erreur, Alex Hidalgo https://www.amazon.com/Implementing-Service-Level-Objectives-Practical/dp/1492076813
Approche Google Golden Signals & SRE https://sre.google/sre-book/table-of-contents/
https://blog.qatestlab.com/2019/04/16/trends-2019-qaops-in-software-testing/