Gestion des incidents pour les équipes haute vélocité
Qu'est-ce qu'un budget d'erreur, et pourquoi est-ce important ?
Toutes les équipes de développement, opérationnelles et informatiques savent que des incidents peuvent survenir.
Même les plus grandes entreprises aux plus grands talents et à la réputation de bénéficier d'un temps d'activité frôlant les 100 % sont parfois frustrées de voir leurs systèmes tomber en panne. Il suffit de regarder Apple, Delta ou Facebook : toutes ces entreprises ont perdu des dizaines de millions en raison d'incidents au cours des cinq dernières années.
Compte tenu de ce constat, les accords de niveau de service (SLA) ne devraient jamais promettre des temps d'activité de 100 %. En effet, aucune entreprise ne peut tenir cette promesse.
Cela signifie aussi que si votre entreprise sait parfaitement comment éviter ou résoudre les incidents, vous pourrez systématiquement atteindre vos objectifs de temps d'activité. Peut-être avez-vous promis un temps d'activité de 99 % et atteignez en réalité 99,5 %. Peut-être avez-vous promis un temps d'activité de 99,5 % qui se rapproche en réalité de 99,99 % sur un mois classique.
Dans ce cas, les experts du secteur recommandent qu'au lieu de rehausser les attentes des utilisateurs à force de dépasser constamment vos engagements, vous considériez ce 0,99 % supplémentaire comme un budget d'erreur, c'est-à-dire un temps que votre équipe peut mettre à profit pour prendre des risques.
Qu'est-ce qu'un budget d'erreur ?
Un budget d'erreur désigne la durée maximale pendant laquelle un système technique peut échouer sans conséquences juridiques.
Par exemple, si votre accord de niveau de service (SLA) spécifie que l'entreprise n'aura à indemniser les clients en cas de panne que si les systèmes fonctionnent moins de 99,99 % du temps, cela signifie que votre budget d'erreur (ou la durée pendant laquelle vos systèmes peuvent tomber en panne sans conséquence) est de 52 minutes et 35 secondes par an.
Si votre SLA promet une disponibilité de 99,95 %, votre budget d'erreur est de 4 heures, 22 minutes et 48 secondes. Et avec un SLA d'activité de 99,9 % garantie, votre budget d'erreur est de 8 heures, 46 minutes et 12 secondes.
Pourquoi les équipes techniques ont-elles besoin de budgets d'erreur ?
À première vue, les budgets d'erreur ne semblent pas si importants. Ce n'est qu'une autre métrique que les équipes informatiques et DevOps doivent suivre pour s'assurer que tout fonctionne bien, n'est-ce pas ?
Fort heureusement, non. Les budgets d'erreur ne sont pas seulement un moyen pratique de vous assurer que vous respectez les engagements contractuels. Ils permettent également aux équipes de développement d'innover et de prendre des risques.
Comme nous l'expliquons dans notre article sur l'ingénierie de la fiabilité des sites (SRE),
« L'équipe de développement peut en quelque sorte utiliser ce budget d'erreur comme elle le souhaite. Si le produit fonctionne actuellement sans problème, avec peu ou pas d'erreurs, elle peut lancer ce qu'elle veut, quand elle le souhaite. À l'inverse, si elle a atteint ou dépassé le budget d'erreur et respecte tout juste le SLA défini, tous les lancements sont gelés jusqu'à ce qu'elle réduise le nombre d'erreurs à un niveau permettant de procéder au lancement. »
L'avantage de cette approche ? Elle encourage les équipes à minimiser les incidents réels et à maximiser l'innovation en prenant des risques dans des limites acceptables. Elle permet également de combler le fossé entre les équipes de développement, dont les objectifs sont l'innovation et l'agilité, et les équipes opérationnelles, qui sont préoccupées par la stabilité et la sécurité. Tant que les temps d'arrêt restent faibles, les développeurs peuvent rester agiles et pusher des changements sans subir de frictions de la part des équipes opérationnelles.
Comment utiliser un budget d'erreur
Tout d'abord, vous devrez consulter vos SLA et SLO. Quels objectifs avez-vous déjà définis pour le temps d'activité ou les demandes système réussies ? Quelles promesses votre entreprise a-t-elle faites aux clients ? Cela dictera votre budget d'erreur.
Budgets d'erreur basés sur le temps d'activité
La plupart des équipes surveillent le temps d'activité tous les mois. Si la disponibilité est supérieure au SLA/SLO auquel vous vous êtes engagé, l'équipe peut livrer de nouvelles fonctionnalités et prendre des risques. Si elle est inférieure à l'objectif, les livraisons sont interrompues jusqu'à ce que les chiffres cible soient conformes aux attentes.
Pour utiliser cette méthode efficacement, vous devez traduire votre SLO cible (généralement un pourcentage) en chiffres réels sur lesquels vos développeurs peuvent travailler. Cela signifie qu'il faut calculer à combien d'heures et de minutes correspondent les 1 %, 0,5 % ou 0,1 % de temps d'arrêt autorisé. Les objectifs courants sont les suivants :
Objectif SLA | Temps d'arrêt autorisé par an | Temps d'arrêt autorisé par mois | |
|---|---|---|---|
| Disponibilité de 99,99 % | Temps d'arrêt autorisé par an 52 minutes, 35 secondes | Temps d'arrêt autorisé par mois 4 minutes, 23 secondes | |
| Disponibilité de 99,95 % | Temps d'arrêt autorisé par an 4 heures, 22 minutes, 48 secondes | Temps d'arrêt autorisé par mois 21 minutes, 54 secondes | |
| Disponibilité de 99,9 % | Temps d'arrêt autorisé par an 8 heures, 45 minutes, 57 secondes | Temps d'arrêt autorisé par mois 43 minutes, 50 secondes | |
| Disponibilité de 99,5 % | Temps d'arrêt autorisé par an 43 heures, 49 minutes, 45 secondes | Temps d'arrêt autorisé par mois 3 heures, 39 minutes | |
| Disponibilité de 99 % | Temps d'arrêt autorisé par an 87 heures, 39 minutes | Temps d'arrêt autorisé par mois 7 heures, 18 minutes | |
Budgets d'erreurs basés sur les demandes réussies
Les SLO sont plus appréciés que les SLA, mais peuvent susciter autant de problèmes s'ils sont vagues, trop compliqués ou impossibles à mesurer. Pour éviter que les ingénieurs s'arrachent les cheveux, il est essentiel que les SLO soient à la fois simples et clairs. Seuls les indicateurs les plus importants sont admissibles au statut de SLO. Les objectifs doivent être formulés dans un langage clair, et, à l'instar des SLA, doivent toujours prendre en compte d'éventuels problèmes comme les retards côté client.
Maîtrisez les SLA pour résoudre les demandes en fonction des priorités et utilisez des règles de remontée automatisées pour avertir les membres de l'équipe concernés et éviter toute violation des SLA grâce à Jira Service Management.
Découvrez la communication sur les incidents grâce à Statuspage
Dans ce tutoriel, nous allons vous montrer comment utiliser des modèles d'incident pour communiquer efficacement pendant les pannes. Vous pouvez les adapter à de nombreux types d'interruption de service.
Lire ce tutorielEn quoi un processus de post-mortem d'incident est-il important ?
Un post-mortem d'incident, également appelé revue post-incident, est le meilleur moyen de travailler sur ce qui s'est passé lors d'un incident et de consigner les leçons apprises.
Lire cet article