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 support (SLA) et aux objectifs de niveau de services (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 programs 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 price range 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 finances d’erreur ?
Le finances d’erreur d’un service est simplement une mesure de le temps utmost qu’il peut être dans un état défaillant sans encourir de pénalités contractuelles, financières ou réglementaires. Le funds d’erreur disponible est dérivé du chiffre de disponibilité auquel vous vous engagez dans les SLA que vous envoyez aux clientele. Vous pourriez être additionally strict en basant votre marge d’erreur sur un SLO à la position.
- 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 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 clientele.
- 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 services aura une disponibilité de 99,99 % au cours d’une année vous donne un overall spending plan 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 spending plan d’erreur et nécessitera une compensation pour les clientele.
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 style 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 spending plan 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 straightforward 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 budget d’erreur est un mécanisme de contrôle qui détermine le style 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 creation. Ces actions ont le potentiel d’introduire des bugs et des comportements instables, épuisant le budget d’erreur. Le funds 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 company. Cela réduit le risque qu’un autre problème se produise et épuise entièrement le price range d’erreur.
Il est vital 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 support. 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 spending 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 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 as well as de pouvoir d’achat, vous ne devriez donc pas investir dans de nouvelles improvements. Un funds d’erreur peut être assimilé à une ligne de crédit de vos purchasers : 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 finances. Cela doit se produire immédiatement lorsque le spending plan 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 in addition rapide de restaurer le provider. 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 checks 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 furthermore 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 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 additionally importants dans votre organisation. Vous pourriez essayer d’aller trop vite avec une feuille de route trop ambitieuse. Cela peut exercer une pression extreme 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 remedies logicielles les moreover 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 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 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 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 price range d’erreur.
L’utilisation des marges d’erreur vous permet de créer des programs moreover 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 secure. Cela crée la cohérence qui manque dans de nombreux solutions existants d’aujourd’hui.
