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 services (SLA) et aux objectifs de niveau de service (SLO) pour informer les organisations lorsque l’indisponibilité d’un système a basculé dans une rupture de contrat.

L’intégration des budgets d’erreurs dans votre stratégie de fiabilité des purposes 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 spending 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 spending plan d’erreur ?

Le budget d’erreur d’un support est simplement une mesure de le temps greatest qu’il peut être dans un état défaillant sans encourir de pénalités contractuelles, financières ou réglementaires. Le spending 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 moreover strict en basant votre marge d’erreur sur un SLO à la put.

• 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 customers si la disponibilité réelle du company 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.

Tu peux calculer votre marge d’erreur à l’aide d’une multiplication easy. Par exemple, un SLA indiquant que votre assistance aura une disponibilité de 99,99 % au cours d’une année vous donne un complete funds d’erreur 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 price range d’erreur et nécessitera une payment pour les consumers.

Voici quelques autres exemples :

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 furthermore simple de déterminer si votre SLA a été violé. Ils sont aussi habitués à fixer les priorités de vos équipes de développement. Un finances 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 output. Ces actions ont le potentiel d’introduire des bugs et des comportements instables, épuisant le spending plan d’erreur. Le spending budget d’erreur est « dépensé » grâce à cette innovation.

Lorsque le spending 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 company. Cela réduit le risque qu’un autre problème se produise et épuise entièrement le spending budget d’erreur.

Il est critical 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 assistance. Un spending plan 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 price range 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 spending budget d’erreur ce qui compte, c’est remark vous réagissez quand cela arrive.

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

Le gel de tous les travaux non essentiels devrait être votre première réponse au dépassement de spending budget. Cela doit se produire immédiatement lorsque le finances est épuisé. Empêchez les nouveaux déploiements d’atteindre la creation, réaffectez les développeurs qui créent de nouvelles fonctionnalités et évaluez le moyen le furthermore rapide de restaurer le assistance. 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 furthermore strictes, exécuter automatiquement votre suite de assessments 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 in addition résistante. Un flux continu d’incidents de non-respect des SLA créera une mauvaise notion 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 customers sera compromise si ce n’est pas le cas, ce qui pourrait vous faire perdre facial area à des concurrents.

Bien que le dépassement d’un funds d’erreur puisse se produire pour d’innombrables raisons, le faire à plusieurs reprises peut laisser entrevoir des problèmes as well as importants dans votre organisation. Vous pourriez essayer d’aller trop vite avec une feuille de route trop ambitieuse. Cela peut exercer une pression abnormal 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 memento 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 additionally performantes associent innovation continue on 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 remedy 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 provider. 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 plateformes de gestion des incidents telles que Opsgénie, Devoir de webpageet Irréprochable peut capturer automatiquement ces informations et fournir des alertes en temps réel pour les événements d’épuisement du spending budget d’erreur.

L’utilisation des marges d’erreur vous permet de créer des programs as well as 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 expert services existants d’aujourd’hui.