Comment utiliser les budgets d’erreur pour protéger la fiabilité du service

Un « budget d’erreur » décrit la durée pendant laquelle un système peut être hors ligne avant qu’il n’ait des conséquences tangibles pour votre entreprise. Les budgets d’erreur sont utilisés parallèlement aux accords de niveau de service (SLA) et aux objectifs de niveau de service (SLO) pour informer les organisations lorsque l’indisponibilité d’un système a dégénéré en rupture de contrat.

L’intégration des budgets d’erreurs dans votre stratégie de fiabilité des applications fournit une approche méthodique pour équilibrer la prise de risque avec la stabilité. Les budgets d’erreur reconnaissent que les pannes occasionnelles, les déploiements bogués et les erreurs simples sont inévitables. Leur rôle est de vous dire combien de ces incidents vous pouvez endurer. Le budget d’erreur disponible détermine également si votre prochaine tâche consiste à créer une nouvelle fonctionnalité ou à résoudre un autre correctif de bogue.

Qu’est-ce qu’un budget d’erreur ?

Le budget d’erreur d’un service est simplement une mesure de la durée maximale pendant laquelle il peut être dans un état défaillant sans encourir de pénalités contractuelles, financières ou réglementaires. Le budget d’erreur disponible est dérivé du chiffre de disponibilité auquel vous vous engagez dans les SLA que vous envoyez aux clients. Vous pourriez être plus strict en basant votre marge d’erreur sur un SLO à la place.

• SLA – La disponibilité à laquelle vous vous engagez publiquement, par exemple 99,95 %. La plupart des organisations utilisant des SLA seront contractuellement tenues de récompenser les clients si la disponibilité réelle du service tombe en dessous de ce chiffre.
• SLO – La disponibilité que vous visez en interne, par exemple 99,99 %. Cela signifie qu’un chiffre de disponibilité entre 99,95 % et 99,99 % n’est pas souhaitable et indique que des améliorations de la fiabilité sont nécessaires. Cependant, cela ne vous rend pas responsable de récompenser les clients.
• Marge d’erreur – Un calcul de la durée d’indisponibilité autorisée par un SLA ou un SLO.

Vous pouvez calculer votre budget d’erreur en utilisant une simple multiplication. Par exemple, un SLA indiquant que votre service aura une disponibilité de 99,99 % au cours d’une année vous donne un budget d’erreur total de 52 minutes et 35 secondes. Une panne qui dure 30 minutes n’affectera pas directement votre entreprise. Celui qui dure une heure dépassera le budget d’erreur et nécessitera une compensation pour les clients.

Voici quelques autres exemples :

99,99 %	52 minutes, 35 secondes	4 minutes, 23 secondes
99,95 %	4 heures, 23 minutes	21 minutes, 54 secondes
99,90 %	8 heures, 46 minutes	43 minutes, 49 secondes

Les budgets d’erreur peuvent être dérivés de n’importe quel type de SLA, pas seulement du temps de disponibilité. Le nombre de demandes réussies, les mesures de performances et les métriques d’utilisation des ressources sont également souvent utilisés comme SLA et SLO. Un SLA indiquant que 99 % des demandes seront traitées avec succès chaque jour déclenchera son budget d’erreur si 10 000 demandes ont été effectuées et que moins de 9 900 d’entre elles ont abouti.

Budgets d’erreur et ingénieurs

Les budgets d’erreur ne sont pas seulement un moyen plus simple de déterminer si votre SLA a été violé. Ils sont également utilisés pour définir les priorités de vos équipes de développement. Un budget d’erreur est un mécanisme de contrôle qui détermine le type de travail sur lequel se concentrer.

Lorsque votre marge d’erreur est pleine, les développeurs peuvent travailler sans restriction. Ils peuvent aborder de nouvelles fonctionnalités, apporter des modifications radicales aux systèmes et appliquer des migrations risquées aux environnements de production. Ces actions ont le potentiel d’introduire des bugs et des comportements instables, épuisant le budget d’erreur. Le budget d’erreur est « dépensé » grâce à cette innovation.

Lorsque le budget d’erreur disponible atteint un seuil convenu, les développeurs doivent prendre des mesures pour l’empêcher de baisser davantage. Les efforts d’ingénierie doivent s’orienter vers des corrections de bogues et des optimisations qui amélioreront la fiabilité et stabiliseront le service. Cela réduit le risque qu’un autre problème se produise et épuise entièrement le budget d’erreur.

Il est important de reconnaître que les marges d’erreur sont censé à consommer, jusqu’au seuil d’alerte. Ils favorisent l’autonomie des développeurs en permettant aux ingénieurs de prendre des risques et d’innover de leur propre initiative. Les budgets d’erreur fournissent simultanément des garde-corps qui empêchent les développeurs de se focaliser sur le mouvement vers l’avant au détriment de la fiabilité du service. Un budget d’erreur épuisant protège l’entreprise en indiquant aux développeurs quand ils doivent se recentrer sur la stabilité.

Que se passe-t-il lorsqu’un budget d’erreur est dépensé ?

Un budget d’erreur entièrement dépensé peut se produire parce que vous avez traversé une période de forte innovation ou que vous avez connu une succession de longues pannes. Il existe de nombreuses chaînes d’événements qui pourraient conduire à l’épuisement d’un budget d’erreur ; ce qui compte, c’est comment vous réagissez quand cela arrive.

L’épuisement du budget d’erreur ne doit pas être pris à la légère. Vous n’avez plus de pouvoir d’achat, vous ne devriez donc pas investir dans de nouvelles innovations. Un budget d’erreur peut être assimilé à une ligne de crédit de vos clients : dépenser au-delà de votre limite aggravera la situation et pourrait gravement nuire aux perspectives de votre marque.

Le gel de tous les travaux non essentiels devrait être votre première réponse au dépassement de budget. Cela doit se produire immédiatement lorsque le budget est épuisé. Empêchez les nouveaux déploiements d’atteindre la production, réaffectez les développeurs qui créent de nouvelles fonctionnalités et évaluez le moyen le plus rapide de restaurer le service. Votre marge d’erreur se rétablira naturellement au fil du temps après la résolution de l’incident.

Vous devriez remplir une rétrospective lors de la résolution pour analyser ce qui s’est passé. Il pourrait y avoir des opportunités d’augmenter la fiabilité en changeant d’outils ou en améliorant votre processus. Appliquer des révisions de code plus strictes, exécuter automatiquement votre suite de tests dans les pipelines CI et utiliser l’analyse statique pour repérer les pièges courants sont trois moyens efficaces d’augmenter rapidement la qualité du code.

Les impacts commerciaux des budgets d’erreur régulièrement dépensés

L’utilisation régulière de votre marge d’erreur est un signe que votre application est instable et doit être plus résistante. Un flux continu d’incidents de non-respect des SLA créera une mauvaise perception de votre produit. Les utilisateurs s’attendent à ce que les logiciels soient disponibles de manière fiable lorsqu’ils en ont besoin. La confiance des clients sera compromise si ce n’est pas le cas, ce qui pourrait vous faire perdre face à des concurrents.

Bien que le dépassement d’un budget d’erreur puisse se produire pour d’innombrables raisons, le faire à plusieurs reprises peut laisser entrevoir des problèmes plus importants dans votre organisation. Vous pourriez essayer d’aller trop vite avec une feuille de route trop ambitieuse. Cela peut exercer une pression excessive sur les ingénieurs et créer un environnement propice aux erreurs.

Les budgets d’erreur peuvent donner l’impression qu’ils bloquent les organisations au rythme naturellement rapide. Se souvenir de l’intention derrière les budgets d’erreur devrait aider à garder tout le monde à bord. Il s’agit d’une forme de gestion des risques qui fournit des mesures exploitables pour décider des priorités d’ingénierie. Les budgets d’erreur sont là pour protéger votre entreprise des impacts négatifs des incidents en vous indiquant quand prendre du recul et ralentir. Tenter de les remplacer ou de les ignorer peut compromettre l’avenir de votre service.

Sommaire

Les solutions logicielles les plus performantes associent innovation continue et stabilité fiable. De nombreuses équipes de développeurs ont du mal à équilibrer avec succès ces deux préoccupations contradictoires. Les développeurs sont souvent naturellement tournés vers l’avenir alors que les utilisateurs veulent une solution familière sur laquelle ils peuvent compter.

Les budgets d’erreurs sont un mécanisme efficace pour résoudre ce dilemme. Ils permettent aux développeurs d’innover librement dans le cadre de contraintes fixes qui préservent la fiabilité du service. Les budgets d’erreur protègent l’entreprise des impacts des violations de SLA en demandant aux ingénieurs de se recentrer sur la stabilité à mesure que le temps d’arrêt augmente.

Vous pouvez implémenter des marges d’erreur en établissant un SLA ou un SLO, puis en calculant le degré d’indisponibilité qu’il autorise. Vous devrez également suivre la durée des nouveaux incidents afin de savoir quand votre marge d’erreur est consommée. Les plates-formes de gestion des incidents telles que Opsgenie, Pagerduty et Blameless peuvent capturer automatiquement ces informations et fournir des alertes en temps réel pour les événements d’épuisement du budget d’erreur.

L’utilisation des marges d’erreur vous permet de créer des applications plus fiables qui répondent systématiquement aux attentes des utilisateurs. Les budgets d’erreur fournissent des données pour éclairer les décisions d’ingénierie et équilibrer l’innovation avec un fonctionnement stable. Cela crée la cohérence qui manque dans de nombreux services existants d’aujourd’hui.