L’espoir n’est pas une stratégie : 7 principes d’ingénierie de la fiabilité des sites (SRE)

L’ingénierie de la fiabilité des sites, ou SRE, est une approche qui traite les problèmes opérationnels comme s’il s’agissait de problèmes logiciels. Il a été nommé et décrit à l’origine en 2003 par Ben Treynor Sless, ingénieur chez Google. En tant que discipline, la SRE vise à maintenir la disponibilité, la performance et l’efficacité d’un système particulier.

La SRE peut être difficile à cerner. Il s’agit d’une approche ou d’une discipline plutôt que d’un ensemble de tâches prescriptives, qui prend différentes formes en fonction des besoins d’une organisation donnée. Heureusement, sept principes d’ingénierie de la fiabilité des sites peuvent aider une équipe SRE à réussir.

Une grande partie du développement logiciel est à juste titre axée sur la création, y compris le DevOps, un domaine connexe, mais distinct, qui s’intéresse davantage à l’ensemble du cycle de vie d’un produit. Mais le travail est à peine terminé lorsque le système est lancé. Dans la préface du guide de Google sur l’ingénierie de fiabilité des sites, les auteurs indiquent que « 40 à 90 % des coûts totaux d’un système sont encourus après la naissance ». La SRE s’intéresse à ce qui se passe après le lancement, visant à aider à garantir qu’un produit reste aussi utilisable que possible.

L’élément le plus important de la SRE est la fiabilité et le temps de fonctionnement du système. Le meilleur service du monde ne servira pas à grand-chose s’il n’est pas opérationnel. La SRE se concentre donc sur la réduction des temps d’arrêt et la création de systèmes fiables.

Les équipes SRE s’assurent également que tous les éléments du produit sont à jour, grâce à une gestion minutieuse des mises à jour logicielles et de sécurité. Les normes et réglementations sont susceptibles de changer et les équipes d’ingénierie assurent une conformité continue.

Les pratiques d’ingénierie de fiabilité des sites (SRE) peuvent également permettre de réaliser des économies financières. De nombreux principes fondamentaux de la SRE concernent les gains d’efficacité qui peuvent conduire à des économies significatives de coûts et d’efforts, notamment grâce à l’automatisation et à la gestion des ressources.

Voici les sept principes de la SRE :    

• Accepter les risques
• Objectifs de niveau de service
• Éliminer le travail
• Surveillance
• Automatisation
• Ingénierie de la publication
• Simplicité

Bien que la SRE soit fortement préoccupée par la gestion et la limitation des temps d’arrêt, cette tendance ne signifie pas que l’objectif est que les services maintiennent une fiabilité parfaite, avec une disponibilité de service de 100 %. En fait, l’un des piliers clés de la SRE est que la fiabilité à 100 % n’est pas seulement irréaliste, elle n’est même pas nécessairement un résultat privilégié.

Dans la SRE, le risque est compris sur un continuum, où la réduction des risques devient exponentiellement plus difficile et coûteuse, car elle approche une fiabilité proche de 100 %. Passer d’une fiabilité de 99,99 % à 99,999 % est beaucoup plus difficile que de passer de 80 % à 99 %. Les ressources nécessaires pour se rapprocher de 100 % réduisent la capacité d’une équipe de développement à effectuer d’autres tâches, comme le développement de nouvelles fonctionnalités et mises à jour. Au lieu de cela, une équipe dispose de budgets d’erreurs pour représenter des quantités appropriées d’échecs.

Un autre point contre la fiabilité totale, aussi paradoxal que cela puisse paraître, c’est que les clients ne remarquent généralement pas d’amélioration de la fiabilité au-delà d’un certain seuil. Ce n’est pas seulement coûteux, il y a aussi peu de récompenses. Idéalement, un objectif est fixé et atteint, mais pas dépassé de manière excessive.

En revanche, la SRE utilise des indicateurs de disponibilité pour mesurer l’acceptabilité du risque de temps d’arrêt. Selon un indicateur, une année fiable à 99,99 % comprendrait 52,6 minutes de temps d’arrêt. Des indicateurs plus complexes prennent en compte le potentiel de temps d’arrêt d’un site ou d’un élément d’un service alors que d’autres restent opérationnels.

Une équipe SRE doit évaluer chaque service et déterminer un niveau acceptable de non-fiabilité. Combien de temps d’arrêt sont autorisés ? Les différents types de défaillances, résultant de différentes causes racines, ont-ils des effets différents sur l’expérience utilisateur ? Combien cela coûtera-t-il (en termes de main-d’œuvre et de financement) de dépasser cet objectif ? Où se trouve l’équilibre ?

Il est essentiel pour une équipe SRE de choisir des objectifs, de mesurer l’efficacité avec laquelle ces objectifs sont atteints et d’en déterminer les raisons. Un objectif de niveau de service, ou SLO, est une cible spécifique et mesurable qui représente un niveau de qualité qu’une équipe d’ingénierie de fiabilité des sites s’est fixé comme but. Ces SLO peuvent prendre la forme de divers indicateurs, mais la disponibilité, le taux d’interrogation, le taux d’erreur et le temps de réponse sont tous communs.

Ces objectifs sont mesurés à l’aide d’un indicateur de niveau de service (SLI), qui est une mesure brute de performance telle que la latence. Dans ce cas, le SLI serait l’indicateur de latence, et le SLO permettrait à cette mesure de rester sous un certain seuil. Les SLO, quant à eux, peuvent faire partie d’un accord de niveau de service (SLA), qui est un contrat entre le fournisseur et l’utilisateur qui définit les SLO ainsi que les conséquences en cas de non-respect.

Choisir des SLO peut être délicat. Idéalement, les SLO doivent être structurés autour de ce qui est le plus important pour les utilisateurs. Pour un service de jeu sur le cloud, par exemple, le SLO peut être axé sur une faible latence, mais la latence n’aurait pas autant d’importance pour un service de comptabilité.

Idéalement, un ingénieur en fiabilité du site utiliserait relativement peu de SLO pour se concentrer sur la réalisation de ces objectifs. Il est très important de bien faire la tâche principale. Il est également important de se fixer des objectifs réalistes. Comme nous l’avons vu précédemment, la perfection n’est ni un objectif réaliste ni un objectif souhaité.

Les créateurs de SRE s’efforcent de définir le « travail pénible » comme une catégorie de travail qui se chevauche, mais n’est pas identique à celui-ci. Le travail est plutôt synonyme de tâches manuelles qui évoluent de manière linéaire, qui sont généralement manuelles et répétitives, et qui peuvent souvent être accomplies par automatisation.

Le travail qui doit être fait en permanence est considéré comme un travail. De préférence, une tâche individuelle ne devrait nécessiter qu’une ou deux procédures virtuelles. Les travaux qui ne permettent pas d’améliorer le produit sont également des travaux pénibles. « Si votre service reste dans le même état après que vous avez terminé une tâche, celle-ci a probablement été réalisée », note Vivek Rau de Google. Les correctifs, les améliorations de fonctionnalités et les optimisations ne sont pas considérés comme un travail pénible, mais le téléchargement manuel des indicateurs l’est. La réponse aux incidents, qui peut inclure une coordination importante entre les ingénieurs et les opérations, n’est pas laborieuse, et les tactiques de gestion des incidents doivent être planifiées avant la publication.

Citons aussi le travail cognitif. Avez-vous déjà eu une recette de base que vous utilisez de temps en temps, mais pour laquelle vous devez à chaque fois rechercher les ingrédients et les mesures ? C’est un travail pénible cognitif : c’est une perte de temps et d’efforts de devoir réapprendre quelque chose, encore et encore. Au lieu de cela, la SRE prône la création de plus de guides et de normes, qui éliminent le besoin de se rappeler ou de réapprendre continuellement les méthodologies et les tâches.

L’une des parties les plus importantes de l’ingénierie de la fiabilité des sites est la surveillance : à l’aide d’outils, on peut mesurer, analyser et améliorer en permanence les fonctionnalités de base et les performances du système. Ces fonctionnalités de base incluent souvent ce que l’on appelle les « quatre signaux d’or » de la surveillance :

Latence : dans sa forme la plus élémentaire, combien de temps faut-il pour traiter une demande ? Notez que cela peut varier selon que la demande a été réussie ou non. Le traitement d’un message d’erreur peut parfois prendre beaucoup plus de temps.

Trafic : Quelle est la charge ou la demande qui pèse sur le service ? Les unités spécifiques peuvent varier d’une entreprise à l’autre. Il peut s’agir de pages vues, de transactions ou de requêtes HTTP.

Erreurs : généralement mesurées par le débit, les erreurs peuvent inclure la récupération de données incorrectes, la récupération des données plus lentement que prévu dans une SLA, ou un échec de récupération.

Saturation : essentiellement, la saturation est une mesure de la proximité de la capacité d’un service. Il est important de comprendre la saturation, car certains services commencent à tomber en panne, à ralentir ou à générer davantage d’erreurs à mesure qu’ils approchent de 100 % de saturation.

De nombreux outils de surveillance peuvent collecter des données, définir des points de référence, déboguer et analyser les problèmes, fournir des tableaux de bord d’observabilité utiles et alerter les SRE en cas de pannes potentielles ou d’autres problèmes. Il est également important de fournir des rapports post-mortem fiables une fois qu’un incident est résolu, en expliquant le contexte de l’incident, ses causes profondes et ses déclencheurs, son impact, la méthodologie de résolution et les leçons pour l’avenir. Une analyse détaillée et objective peut s’avérer précieuse pour éviter de répéter la même erreur.

Comme pour de nombreux autres éléments de la technologie moderne, l’objectif de l’intégration de l’automatisation dans un workflow est de libérer les ingénieurs de tâches répétitives qui n’apportent aucune valeur ajoutée. Grâce à l’extension du temps libre, les ingénieurs peuvent ensuite se consacrer à des tâches que l’automatisation ne peut pas accomplir : création, idéation, guidage à grande échelle, etc.

L’automatisation peut être particulièrement utile pour atteindre les objectifs suivants :

Cohérence : l’inconvénient des tâches manuelles répétitives n’est pas seulement qu’elles peuvent être ennuyeuses et qu’elles peuvent faire perdre du temps à des actions plus utiles. Si ces tâches, telles que la création de comptes utilisateurs, sont réalisées par des outils d’automatisation, les erreurs et les incohérences peuvent être presque éliminées. Un nouvel employé peut faire les choses différemment d’un ancien. Un utilisateur peut accidentellement saisir une valeur dans le mauvais champ, ce qui (en général) ne se produit pas avec un processus automatisé.

Évolutivité : l’évolutivité est l’un des principaux avantages à long terme de l’automatisation. Reprenons notre exemple précédent de création d’un compte utilisateur. Si la création de comptes augmente de façon exponentielle, le workload pour la personne responsable de la création du compte augmente également de façon exponentielle, éloignant cet employé d’autres aspects potentiellement plus importants de son travail. Un système automatisé n’aura pas ce problème.

Rapidité : certaines tâches, comme la découverte et la correction de bugs dans le code, peuvent prendre beaucoup de temps à un humain. Les systèmes logiciels automatisés ont la capacité de contrôler d’énormes quantités de données et peuvent souvent détecter des erreurs plus rapidement que les humains grâce à des outils avancés de reconnaissance des formes et autres. Les correctifs peuvent être appliqués tout aussi rapidement, souvent sans aucune intervention humaine.

Bien entendu, tout processus d’automatisation comporte aussi des dangers. En voici quelques exemples :

Coûts initiaux : les automatisations doivent être créées avant d’être déployées. Cela peut nécessiter beaucoup de temps, d’efforts et même de coûts matériels. La valeur de l’automatisation doit être considérée comme un équilibre entre l’effort nécessaire à sa création et les ressources réelles qu’elle permettra d’économiser une fois lancées.

Maintenance : les tâches automatisées peuvent sembler pouvoir fonctionner indéfiniment, mais ce n’est souvent pas le cas. Le code d’automatisation doit être tenu à jour et synchronisé avec les autres mises à jour du code et du système. Si de nouvelles fonctionnalités sont ajoutées, le code d’automatisation devra peut-être être mis à jour via une intervention humaine pour inclure de nouvelles actions ou éviter les erreurs.

L’intelligence artificielle offre des possibilités nouvelles et excitantes pour la SRE, notamment dans le domaine de l’automatisation. Les coûts initiaux et la maintenance peuvent théoriquement être modulés par les nouveaux modèles d’IA. Cela dit, l’IA comporte également de nouveaux points faibles potentiels : hallucination, sécurité et confidentialité, notamment.

L’ingénierie de mise en production est une sous-discipline de l’ingénierie logicielle spécifiquement axée sur les étapes nécessaires à la mise en production d’un logiciel. Ces étapes comprennent la gestion des versions, les calendriers de publication, les versions continues ou périodiques, la sélection et la collecte des indicateurs de publication, etc. Dans le domaine de la SRE, l’ingénierie de la publication est intégrée au début, et non une réflexion après coup. L’objectif est d’éviter une affectation aléatoire des tâches d’ingénierie de publication à la dernière minute.

L’ingénierie de la publication, en tant que discipline, comprend plusieurs principes clés. En voici quelques exemples :

Automatisation et libre-service : Idéalement, de nombreux processus d’édition peuvent être automatisés et ne nécessitent que peu ou pas d’interaction de la part des ingénieurs. Cela garantit des versions rapides et stables.

Velocity : En matière d’ingénierie des versions, la philosophie des sorties rapides et fréquentes est préférée. En déployant rapidement des versions, peut-être aussi souvent que chaque heure autour du lancement, il y a moins de changements entre les versions. Cette rapidité facilite les tests et le dépannage.

Constructions hermétiques : les processus de compilation doivent être totalement indépendants de la machine de compilation elle-même, en utilisant les compilateurs, bibliothèques et outils les plus populaires. « Si deux personnes tentent de construire le même produit avec le même numéro de révision dans le référentiel de code source sur des machines différentes, nous nous attendons à des résultats identiques », écrit Dinah McNutt de Google.

Normes et politiques : pour des raisons de sécurité, il est essentiel de contrôler certaines tâches, notamment le déploiement, les changements dans le code source, les nouvelles versions et les changements dans la configuration des versions.

Une grande partie de l’ingénierie de la fiabilité des sites est au service de la simplicité. Comme le précise Max Luebbe de Google, le logiciel est « intrinsèquement dynamique et instable ». Dans cette optique, la simplicité est essentielle pour minimiser les problèmes potentiels et tenter de maîtriser cette instabilité inhérente.

À cette fin, l’ingénierie de la fiabilité des sites favorise diverses tâches qui peuvent simplifier et clarifier un projet.

1. Il est utile de sélectionner avec soin les fonctionnalités à inclure, mais il peut être tout aussi utile de simplement supprimer toutes les fonctionnalités qui n’ajoutent pas de manière significative à la fonctionnalité du produit. Plus de fonctionnalités, c’est plus de complexité.
2. Des versions plus petites et plus fréquentes facilitent le débogage et le dépannage. Une nouvelle version avec des dizaines de nouvelles fonctionnalités pourrait introduire des erreurs qui pourraient être extrêmement difficiles à traquer. Une version avec une nouvelle fonctionnalité ? Les problèmes potentiels ne peuvent provenir que d’un seul endroit.
3. De même, il peut être tentant d’ajouter de la complexité aux API en utilisant plusieurs points de terminaison, microservices, etc. Cela doit être évité. Des API plus simples sont plus rapides à configurer, nécessitent moins de documentation et réduisent le temps et les coûts d’intégration.