Budget d'erreur

Le concept de budget d'erreur

Le concept de budgétisation des erreurs (EB) a été popularisé dans l'industrie du logiciel par la vision DevOps de Google, appelée "Site Reliability Engineering" (SRE) [Beyer 2016].

L'EB a été introduite pour permettre au Product Owner ou au gestionnaire (PO ou PM) d'équilibrer les questions de qualité avec les situations où une livraison rapide est obligatoire, comme une réparation rapide en production pour faire face à une panne complète du système. Ainsi, l'EB est fortement liée à la disponibilité d'un service et cette disponibilité est souvent appelée"les neuf de la disponibilité", plus il y a de 9, plus la disponibilité est élevée. Ainsi, une disponibilité de 99% ("deux neuf") correspond à une disponibilité minimale de 23 heures 45 minutes et 36 secondes par jour. Pour faciliter la représentation, nous indiquons plutôt la durée d'indisponibilité (c'est-à-dire 14,40 minutes par jour). Habituellement, l'indisponibilité des services est couverte par des accords de niveau de service (SLA), des objectifs de niveau de service(SLO) pour garantir les SLA [Ross 2017] et le budget d'erreur est la quantité de temps que vous êtes prêt à permettre à vos systèmes d'être hors service.

La disponibilité peut être améliorée de différentes manières telles que la réplication, la redondance, l'auto-scaling, les sauvegardes et tout ce qui rend les systèmes plus robustes, mais la robustesse implique d'être conservateur et donc de réduire l'innovation ; d'un autre côté, personne n'achètera un système qui ne fournit pas de valeurs [Meléndez 2021] ou de caractéristiques innovantes alors que d'autres produits fourniront plus de valeur. C'est là que l'EB entre en ligne de compte, car il offre un certain espace pour laisser la qualité et l'innovation se produire :

• lorsque l'innovation est créée, l'EB diminue
• lorsque la consolidation est fournie, EB est soulevé

et en tant que "bon père de famille", l'EB doit rester positif avec une marge suffisante pour gérer les problèmes graves qui introduiront des défauts en même temps que la correction. L'EB est donc lié à la gestion des risques car il aide les équipes à gérer les risques pour [Watts 2020] [Jankovski 2021] :

• Tirer le meilleur parti de leurs ressources
• Améliorer la qualité du service sans sacrifier trop de fiabilité

L'EB permet aux organisations de se concentrer sur le client, de s'organiser autour de la valeur et d'adopter une vision économique.

De plus, pour garantir les SLA, les membres de l'équipe doivent collaborer pour les atteindre en accordant une attention particulière aux indicateurs pertinents avec une marge plus élevée, le SLO. Lorsque le seuil de l'ALS a été atteint, Andon peut être soulevé pour aboutir à un groupe de travail, par exemple dans la saveur 8D.

Si les équipes ont déjà l'habitude de travailler en mode task force, elles vont naturellement collaborer efficacement autour du problème qui heurte les objectifs du service. Ce faisant, les équipes démontreront qu'elles sont responsables de la qualité du produit.

Impact sur la maturité des tests

L'EB n'est pas quelque chose créé par Google. Ce terme est utilisé depuis longtemps dans la conception de systèmes aérospatiaux complexes, car le domaine exige une précision extrême [Briggs 2008]. Dans ce contexte, ce qui est géré est un peu différent des SLA et de la satisfaction des clients puisqu'il s'agit de la précision de certains engins spatiaux ; cependant, le concept reste le même : contrôler la tolérance accordée sur certaines parties du système pour faciliter la livraison sans compromettre le résultat. Dans le domaine des engins spatiaux, l'EB est introduit au moins dès la conception avec de multiples facteurs tels que la température, les vibrations, les matériaux impliqués, les approximations de modélisation des joints, etc. Cet EB est une approche préventive des erreurs auxquelles le vaisseau spatial sera confronté, ce qui semble plus intelligent que de simplement faire face à une déclaration sur une perte de qualité à corriger après coup.

Ainsi, dans une approche "Prevent bugs "appliquée à l'industrie du logiciel, de nombreux facteurs peuvent affecter la disponibilité du service mais aussi sa précision ou tout autre aspect qualitatif que le client peut attendre d'un service numérique. Ces multiples critères devraient mériter des techniques d'ingénierie appropriées :

• Capacité de charge
• Capacité à fournir de nouvelles fonctionnalités
• Précision du service
• Disponibilité du service

Ces facteurs peuvent varier en fonction de la situation, du temps et surtout de l'environnement concurrentiel [Seth 2004]. Ces facteurs attendus seront généralement des exigences non fonctionnelles (NFR) ou tout autre élément de test en décalage à gauche qui mériterait d'être testé et anticipé [Meléndez 2021]. Naturellement, ces éléments liés au décalage vers la gauche peuvent également être complétés par des éléments liés au décalage vers la droite et, éventuellement, faire quelques répétitions dans des situations extrêmes telles que l'effondrement d'un serveur/réseau ou même l'exécution de plans de reprise après sinistre.

L'EB doit également prendre en compte un point spécifique qui n'est pas particulièrement visible comme les SLA mais qui interfère sournoisement avec la réactivité d'une équipe et sa capacité à traiter les demandes, la dette technique car elle ralentit et finit par bloquer le lancement de nouvelles fonctionnalités et la correction de bug . Nous pouvons donc en déduire que la dette technique est liée au budget d'erreur [Hartmann 2020][Howard 2021][Gurumoorthi 2020] tout comme EB accélère la dette technique. De plus, les actions de remédiation doivent être planifiées de manière régulière afin d'éviter que d'énormes efforts soient faits dans l'urgence et introduisent des problèmes supplémentaires : " Lesproblèmes d'aujourd'hui proviennent des solutions d'hier" [Senge 2010]. 

‍

Ainsi, pour éviter les baisses d'EB dues à une mauvaise libération, l'équipe doit définir une stratégie de déploiement telle que le Dark Launch, le Canary Releasing ou le Blue/Green deployment qui sont vraiment utiles pour déployer soigneusement une nouvelle version, mais l'analyse du trafic peut également être utilisée pour limiter l'impact d'une mauvaise libération si le déploiement a lieu en dehors des heures de pointe pour limiter les impacts sur l'EB [Climent 2020].

Les stratégies d'automatisation poussée et de petits lots de livraison (approche incrémentale) réduisent également l'impact sur l'EB car elles permettent des déploiements rapides de correctifs et réduisent le risque de faire face à d'énormes impacts négatifs.

Quelle que soit votre liste de critères, l'éternelle difficulté réside dans le dilemme entre l'urgence et l'importance. En règle générale, vous pouvez simplement garder à l'esprit que les questions importantes doivent être abordées de manière continue et progressive, à petit pas...

De plus, dans une équipe Scrum, si les développeurs sont responsables du maintien de l'EB à un niveau équitable, le Product Owner (PO) en sera responsable ; par conséquent, le PO doit toujours s'assurer qu'un espace suffisant est accordé aux développeurs pour leur permettre de maintenir l'EB à un niveau raisonnable.

Le point de vue d'Agilitest sur cette pratique

L'automatisation réduit le coût de la transaction [SAFe 2021-06] et évite d'introduire des erreurs de régression dans la production, diminuant ainsi l'EB. Chaque fois qu'une automatisation est sautée, elle devrait alors générer une "dette d'automatisation" qui pourrait également faire partie de l'EB.

Cependant, l'automatisation doit également prendre en compte 

• sa propre dette technique [Wiklund 2012]. 
• impact sur le flux de livraison, notamment si les scripts génèrent des faux positifs

Heureusement, grâce à son approche #nocode [Forsyth 2021], le montant de la dette technique et de la dette dite "flaky tests" et de la dette technique est maintenu plus bas qu'avec le codage standard.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍