Site Reliability Engineering #3 Risque et budget d’erreur

Naviguer vers les autres articles du dossier :

• #1 Implements DevOps >> Lire l’article >
• #2 Niveaux de service >> Lire l’article >
• #4 Allez plus loin dans le SRE >> Lire l’article >

Manager le risque et le budget d’erreur

Le SRE apporte aussi les notions de risque et de budget d’erreur dans sont concept. Car elles ont justement pour but de garantir l’équilibre entre dev et ops en répondant à la questions suivante :

Même avec SLI, SLO et SLA, qu’est-ce qui empêche les équipes de rompre leurs SLO si elles souhaitent proposer de nouvelles fonctionnalités ?

La différence entre la disponibilité réelle, SLI, et la disponibilité cible calculée à partir de notre SLO est le budget d’indisponibilité que nous pouvons tolérer pour que le système soit stable sur toute la fenêtre du SLO. Nous appelons donc cela le bilan d’erreur. Si vos SLI échouent tout le temps, alors le budget d’erreurs sera brûlé rapidement. Les éventuels déploiements prévus devront être arrêtés afin de concentrer les efforts sur l’amélioration de la fiabilité et la restructuration de l’application afin qu’elle puisse rendre le service en respectant les SLO dans le futur.

Quant au risque, prenons un cas assez simple. Si mon réseau cellulaire n’est fiable qu’à 99 %, mais que mon service est fiable à 99,9 %, mes utilisateurs ne bénéficieront jamais de ces 0,9 % de fiabilité supplémentaires, car leur réseau cellulaire risque de tomber en panne avant mon service.
Ainsi, même si nous souhaitons réduire le risque de panne du système, nous devons accepter un certain degré de risque afin de fournir ces produits et fonctionnalités.

Si je perturbe la fiabilité de mon système en introduisant de nouvelles fonctionnalités, j’augmente le risque de diminuer sa fiabilité et donc sa disponibilité. Augmenter le risque expose mon budget d’erreur.

Comment déterminer le niveau de risque qu’un service est prêt à tolérer ?

Au-delà du renforcement de la fiabilité au profit de l’utilisateur, il y a beaucoup d’autres choses à considérer. Notamment, il ne faut pas oublier les coûts engendrés pour atteindre cet objectif : l’ajout d’une tolérance aux pannes supplémentaire, ou les tests supplémentaires, ou la réduction de la fréquence des déploiements, ou l’augmentation du temps de décision pour la validation d’une version.

Ainsi, le risque acceptable d’un système dicte le SLO, et le SLO définit mathématiquement le budget d’erreurs. Si le service subit trop de temps d’arrêt, il faut réduire le risque pour rester dans le SLO, ce qui peut impliquer l’arrêt des déploiements. En effet, si les product owner souhaitent proposer de nombreuses fonctionnalités risquées, ils doivent être prêts à accepter un SLO beaucoup plus souple. Car choisir un SLO strict, c’est prendre le risque de dépasser rapidement son budget d’erreur. Cela pourrait interrompre les futurs déploiements.

Au bout du compte, le principal avantage d’un budget d’erreur est donc qu’il s’agit d’une mesure quantitative partagée entre les équipes produit et SRE. Cela signifie qu’il est possible d’équilibrer l’innovation et la stabilité à un niveau approprié.

Qui applique les politiques du budget d’erreur ?

Si les équipes SRE n’ont pas la capacité de faire respecter les budgets d’erreur, alors le système ne tient pas. C’est pourquoi l’approbation du budget d’erreur par l’équipe dirigeante est indispensable. D’ailleurs, certaines équipes n’autorisent qu’un nombre limité de jetons que vous pouvez remettre à un vice-président, par exemple. Donc, si une équipe produit tient absolument à publier une fonctionnalité critique, malgré le dépassement du budget d’erreur, elle devra demander au vice-président une exception unique et elle n’en obtiendra qu’un certain nombre par an.

Qu’en est-il de la disponibilité de mes dépendances externes ?

Il arrive que les causes des indisponibilités soient externes à l’équipe de développement ou à l’équipe produit. Imaginons qu’un câble sous-marin soit sectionné ou qu’un data center tombe ? Cela ne devrait pas avoir d’impact sur le budget d’erreurs car « Ce n’était pas ma faute ! ».
Il est important d’avoir des budgets d’erreurs pour tout ce qui se trouve dans l’écosystème du service. De cette façon, on alloue aussi bien un budget d’erreur réservé aux développeurs, qu’un budget d’erreur réservé aux dépendances. D’ailleurs, c’est une autre raison pour laquelle viser une disponibilité à 100 % n’est pas réaliste. En effet, il n’est pas possible de maîtriser la disponibilité des dépendances, encore moins de leur garantir un SLO de 100 %.

En somme, les budgets de risque et d’erreur sont directement liés à de nombreux principes DevOps. En les quantifiant, ils admettent clairement que les accidents sont normaux. Cela impose également que le changement soit progressif, car un changement non progressif pourrait rapidement épuiser le budget d’erreur d’un produit particulier, rompant le SLO et empêchant un déploiement ultérieur pour le trimestre ou pour l’année.