Principes et pratiques majeurs de l’ingénierie de fiabilité de site : cycles vertueux
S’il est vrai dans une certaine mesure que « vous êtes ce que vous faites », alors nous avons atteint le cœur de ce module. Dans cette unité, nous allons étudier deux des pratiques souvent considérées comme étant au cœur de l’ingénierie de fiabilité de site. Toutes deux sont issues du principe qu’il est important de créer des « cycles vertueux ». Dans ce contexte, les cycles vertueux sont des pratiques qui génèrent des boucles de commentaires au sein d’une organisation qui l’aident à s’améliorer en permanence. Nous ne proposerons ici qu’un survol de ces pratiques, car des modules ultérieurs y seront entièrement consacrés et les décriront en détail.
Cycle vertueux 1 : SLI et SLO
Plus haut dans ce module, nous avons souligné qu’il était essentiel d’atteindre le « niveau approprié de fiabilité ». C’est précisément ici que ce concept prend de l’importance.
Supposez que vous prévoyez de mettre en production un nouveau service (ayant déjà été créé ou étant encore en cours de planification). Dans le cadre de ce processus, il est important de prendre certaines décisions concernant sa fiabilité souhaitée. Si vous n’écrivez pas tout le code vous-même, ces décisions sont prises (et ce point est crucial) en collaboration avec les développeurs qui effectuent ce travail.
La première décision à prendre est : qu’est-ce qui doit être utilisé comme indicateurs de l’intégrité du service (indicateur de niveau de service ou SLI) ? Il s’agit donc de répondre à la question : « Comment savoir quand le service est opérationnel et performant ? ». Il existe de nombreuses façons de suivre les SLI et nous en explorerons quelques-unes en détail plus tard. Toutefois, ces indicateurs sont généralement les suivants :
- Mesures de réussite et d’échec. Le service a-t-il réussi une opération dans un certain pourcentage du temps ?
- Mesures de délai. Avons-nous retourné une réponse dans un certain délai ?
- Mesures de débit. Avons-nous traité une certaine quantité de données ?
Ou, une combinaison de toutes ces mesures.
En guise d’exemple simple, nous pourrions dire qu’un SLI pour notre service est la fréquence à laquelle il a retourné un indicateur de réussite, signalé par un code HTTP 200 (par opposition à un code 500 ou autre).
Maintenant, nous avons un indicateur clair qui nous indique les performances du service. Nous devons décider du niveau de fiabilité attendu ou souhaité. Par exemple, allons-nous nous attendre à un taux d’échec du service de 20 % sur une période d’une journée ? Nous utilisons ici des chiffres ronds et élevés, car il sont plus pratiques au début pour illustrer notre raisonnement. Dans les modules suivants, nous augmenterons la complexité et la précision (« quels utilisateurs voient ce taux d’erreur ? Certains d’entre eux ? La plupart ? », etc.). Cette attente, créée en collaboration avec le développeur du service, est un objectif de niveau de service (SLO).
Le SLO doit être quelque chose qui peut être mesuré et représenté avec précision dans votre système de supervision. Il est censé être un but bien compris et objectif en ce qui concerne la fiabilité du service (quel est le chiffre suffisant ?). Il n’est pas question de répondre : « Et bien, je pense que le service est OK cette semaine, mais c’est difficile à dire ». Soit le service respecte son SLO, soit il ne le respecte pas. Les données doivent être claires. S’il ne respecte pas son SLO (en particulier à plusieurs reprises durant un intervalle de temps), quelque chose ne va pas et le problème doit être examiné.
Budgets d’erreurs
On peut comprendre qu’une organisation puisse prendre des mesures si un service ne respecte pas son SLO. Mais l’ingénierie de fiabilité de site étend ce concept pour les cas où le SLO est respecté ou dépassé. Certaines organisations utilisent des SLO pour créer ce qu’elles appellent des « budgets d’erreurs ».
Afin d’illustrer cette idée, reprenons l’exemple de service que nous avons vu plus haut et son SLO de réussite de 80 % (il doit « être opérationnel 80 % du temps »). Avec le SLO de 80 % de temps d’activité, nous avons déclaré que notre service devait être opérationnel 80 % du temps. Mais qu’en est-il des autres 20 % ? Si notre service est en panne pendant ces autres 20 %, cela nous importe peu, car nous avons décidé qu’être opérationnel pendant ces 20 % supplémentaires n’avait pour nous aucune importance en tant qu’objectif de service.
Par conséquent, si nous ne nous soucions pas de ce qui se passe pendant ce temps, que pouvons-nous faire avec le service ? Nous pourrions par exemple perturber le service en cours d’exécution en le mettant à niveau avec une nouvelle version qui ajoute des fonctionnalités. Si cette nouvelle mise en production reste opérationnelle et n’ajoute aucun temps d’arrêt, c’est très bien. Si elle rend le service moins stable et retourne des erreurs 10 % du temps à cause du débogage, là encore tout va bien. Nous sommes dans les limites de notre budget de non-fiabilité autorisée.
Un budget d’erreur est la différence entre la fiabilité parfaite potentielle du service et sa fiabilité souhaitée (100-80 % = 20 %). Ici, le budget d’erreur nous donne un fonds de non-fiabilité de 20 % : 20 % du temps où « peu importe si le service est opérationnel ou non, car la spécification est toujours respectée ». Nous pouvons consacrer ces 20 % du temps comme bon nous semble (par exemple pour d’autres mises à jour) jusqu’à ce qu’il soient épuisés, comme n’importe quel autre budget.
Les budgets d’erreurs sont également utilisés dans certaines organisations pour les cas les moins désirables, ceux où le SLO n’est pas respecté. Dans ce cas, vous pourriez choisir de faire quelque chose un peu plus draconien que simplement « prendre des mesures ». Supposez que notre service rencontre des problèmes et que le SLI choisi précédemment montre qu’il est opérationnel uniquement 60 % du temps. Notre objectif (le SLO) n’est pas respecté. Notre service a utilisé tout son budget d’erreur. L’organisation peut choisir de retarder une mise en production planifiée, car elle sait que perturber davantage le système à ce stade risque fortement d’aggraver la situation de fiabilité. Les budgets d’erreurs sont généralement calculés pour une durée donnée (un mois, un trimestre, et ainsi de suite) ou en continu. Ainsi, si la fiabilité du service s’améliore, ce budget est réalloué.
Avant cette nouvelle mise en production, l’organisation peut choisir d’utiliser des ressources d’ingénierie non plus pour le développement des fonctionnalités, mais pour le travail de fiabilité, afin de détecter et d’améliorer la source des problèmes ayant provoqué le non-respect du SLO par le service.
La raison pour laquelle nous disons « certaines organisations » quand il s’agit de budgets d’erreurs est que leur implémentation, en particulier dans les cas où elle sert à espacer les mises en production, nécessite une certaine adoption institutionnelle. L’organisation doit être prête à dire que face à une décision de mise en production, si la fiabilité du service à ce jour n’a pas été suffisante, cette mise en production sera retardée. Ce n’est pas une décision que toutes les organisations sont prêtes à prendre. Ce n’est pas non plus la seule réponse possible à un budget d’erreur épuisé, mais c’est celle dont on parle le plus.
Dans un module distinct, nous parlons beaucoup plus en détail des SLI, des SLO et des budgets d’erreurs. Mais il vaut la peine ici de souligner l’aspect « cycle vertueux » de ces pratiques. En théorie, il permet à une organisation de décrire, de communiquer et d’agir sur la fiabilité d’un service d’une manière qui incite tout le monde à contribuer en vue d’améliorer la fiabilité. Cette boucle de commentaires peut être extrêmement importante.
Cycle vertueux 2 : analyses post mortem sans blâme
L’idée d’une analyse post mortem (analyse rétrospective d’un événement significatif et généralement indésirable) est loin d’être propre à l’ingénierie de fiabilité de site. Elle n’est même pas rare dans le monde des opérations. Ce qui caractérise davantage l’ingénierie de fiabilité de site est qu’elle insiste sur la nécessité d’avoir des analyses rétrospectives « sans blâme ». Ces analyses doivent être axées sur la défaillance du processus ou de la technologie durant l’incident, et non sur les actions de personnes spécifiques. « Dans le processus que nous avons mis en place, qu’est-ce qui a permis à X de faire ce qui a provoqué la défaillance ? Quelles informations cette personne n’a-t-elle pas eu à sa disposition, ou étaient remarquables au moment qui l’a conduite à sa conclusion incorrecte ? Quels garde-fous auraient dû être en place pour qu’une telle défaillance catastrophique ne puisse pas avoir lieu ? » C’est ce genre de questions que l’on se pose lors d’une analyse post mortem sans blâme.
Le ton et le sens de ces questions sont cruciaux. Nous cherchons à identifier des moyens d’améliorer les systèmes ou les processus, et non de punir les personnes de bonne foi dont l’utilisation des systèmes et des processus a contribué à la panne. Il est important de se souvenir que « l’on ne peut pas atteindre la fiabilité simplement en se débarrassant des fautifs ». D’après notre expérience, une organisation qui licencie une personne chaque fois qu’un incident de production survient (à quelques exceptions près) ne tire aucun enseignement de ces incidents. Au lieu de cela, il ne restera qu’une seule personne, tremblant de peur dans son coin à l’idée d’apporter le moindre changement.
En revanche, un processus post mortem efficace au sein d’une organisation crée un cycle vertueux. Il permet à l’organisation de tirer des enseignements des défaillances et d’améliorer en permanence ses systèmes (à condition qu’il y ait une analyse et un suivi appropriés).
Cette relation envers les défaillances et les erreurs, adoptée par l’organisation en tant qu’opportunités d’enseignement et d’amélioration, est un principe de base de l’ingénierie de fiabilité de site. La construction de cycles vertueux afin de tirer parti de ces opportunités et de guider l’organisation vers une plus grande fiabilité en est un autre.
Dans l’unité suivante, nous allons explorer d’autres principes et pratiques, axés sur le côté humain de l’ingénierie de fiabilité de site.