L’espoir n’est pas une stratégie. Ce que dit un SRE traditionnel
C’est une vérité universellement reconnue que les systèmes ne s’exécutent pas tout seuls. Comment, dès lors, un système - en particulier un système informatique complexe fonctionnant à grande échelle - devrait-il être exécuté ?
Historiquement, les entreprises ont employé des administrateurs de systèmes pour gérer des systèmes informatiques complexes.
Cette approche de l’administrateur de systèmes, ou sysadmin, consiste à assembler des composants logiciels existants et à les déployer pour qu’ils fonctionnent ensemble et produisent un service. Les administrateurs de systèmes sont ensuite chargés de faire fonctionner le service et de répondre aux événements et aux mises à jour au fur et à mesure qu’ils se produisent. À mesure que le système gagne en complexité et en volume de trafic, générant une augmentation correspondante des événements et des mises à jour, l’équipe d’administrateurs système s’agrandit pour absorber le travail supplémentaire. Le rôle de l’administrateur système exigeant un ensemble de compétences très différent de celui des développeurs d’un produit, les développeurs et les administrateurs système sont divisés en équipes distinctes : “développement” et “opérations” ou “ops”.
Le modèle sysadmin de gestion des services présente plusieurs avantages. Pour les entreprises qui décident de la manière de gérer et de doter en personnel un service, cette approche est relativement facile à mettre en œuvre : en tant que paradigme industriel familier, il existe de nombreux exemples dont on peut s’inspirer. Une réserve de talents pertinents est déjà largement disponible. Un ensemble d’outils existants, de composants logiciels (prêts à l’emploi ou non) et de sociétés d’intégration sont disponibles pour aider à faire fonctionner ces systèmes assemblés, de sorte qu’une équipe d’administrateurs système novice n’a pas à réinventer la roue et à concevoir un système à partir de zéro.
L’approche sysadmin et la division développement/opérations qui l’accompagne présentent un certain nombre d’inconvénients et de pièges. Ils se répartissent en deux grandes catégories : les coûts directs et les coûts indirects.
Les coûts directs ne sont ni subtils ni ambigus. Faire fonctionner un service avec une équipe qui s’appuie sur une intervention manuelle pour la gestion des changements et le traitement des événements devient coûteux à mesure que le service et/ou le trafic vers le service augmente, car la taille de l’équipe évolue nécessairement en fonction de la charge générée par le système.
Les coûts indirects de la séparation entre le développement et les opérations peuvent être subtils, mais sont souvent plus coûteux pour l’organisation que les coûts directs. Ces coûts découlent du fait que les deux équipes sont très différentes en termes de formation, de compétences et d’incitations. Elles utilisent un vocabulaire différent pour décrire les situations ; elles ont des hypothèses différentes sur les risques et les possibilités de solutions techniques ; elles ont des hypothèses différentes sur le niveau cible de stabilité du produit. Le clivage entre les groupes peut facilement devenir un problème non seulement d’incitations, mais aussi de communication, d’objectifs, et finalement de confiance et de respect. Ce résultat est une pathologie.
Les équipes d’exploitation traditionnelles et leurs homologues du développement de produits finissent donc souvent par entrer en conflit, surtout en ce qui concerne la rapidité avec laquelle les logiciels peuvent être mis en production. Au fond, les équipes de développement veulent lancer de nouvelles fonctionnalités et les voir adoptées par les utilisateurs. De leur côté, les équipes d’exploitation veulent s’assurer que le service ne tombe pas en panne pendant qu’elles tiennent le pager. Comme la plupart des pannes sont causées par un changement quelconque - une nouvelle configuration, le lancement d’une nouvelle fonctionnalité ou un nouveau type de trafic utilisateur - les objectifs des deux équipes sont fondamentalement en tension.
Les deux groupes comprennent qu’il est inacceptable d’énoncer leurs intérêts dans les termes les plus simples possibles (“Nous voulons lancer n’importe quoi, n’importe quand, sans entrave” contre “Nous ne voudrons jamais rien changer au système une fois qu’il fonctionnera”). Et parce que leur vocabulaire et leurs hypothèses de risque diffèrent, les deux groupes ont souvent recours à une forme familière de guerre de tranchées pour faire valoir leurs intérêts. L’équipe des opérations tente de protéger le système en cours d’exécution contre le risque de changement en introduisant des portes de lancement et de changement. Par exemple, les revues de lancement peuvent contenir une vérification explicite de tous les problèmes qui ont causé une panne dans le passé - il peut s’agir d’une liste arbitrairement longue, dont tous les éléments n’ont pas la même valeur. L’équipe de développement apprend rapidement à réagir. Il y a moins de “lancements” et plus de “retournements de drapeau”, de “mises à jour incrémentielles” ou de “sélection”. Elle adopte des tactiques telles que le partage du produit afin que moins de fonctionnalités soient soumises à l’examen du lancement.
Le conflit n’est pas un élément inévitable de l’offre d’un service logiciel. Google a choisi de gérer ses systèmes selon une approche différente : nos équipes d’ingénierie de la fiabilité des sites s’attachent à recruter des ingénieurs logiciels pour faire fonctionner nos produits et créer des systèmes permettant d’accomplir le travail qui, autrement, serait effectué, souvent manuellement, par les administrateurs système.
Qu’est-ce que l’ingénierie de fiabilité des sites, telle qu’elle est définie chez Google ? Mon explication est simple : Le SRE est ce qui se passe lorsque vous demandez à un ingénieur logiciel de concevoir une équipe d’exploitation. Lorsque j’ai rejoint Google en 2003 et que j’ai été chargé de diriger une “équipe de production” composée de sept ingénieurs, toute ma vie jusque-là avait été consacrée au génie logiciel. J’ai donc conçu et géré le groupe de la manière dont je voudrais qu’il fonctionne si je travaillais moi-même en tant que SRE. Ce groupe a depuis évolué pour devenir l’équipe SRE actuelle de Google, qui reste fidèle à ses origines, telles qu’elles ont été imaginées par un ingénieur logiciel de longue date.
La composition de chaque équipe SRE est l’un des principaux éléments constitutifs de l’approche de Google en matière de gestion des services. Dans l’ensemble, les SRE peuvent être répartis en deux grandes catégories.
50 à 60 % sont des ingénieurs logiciels de Google, ou plus précisément, des personnes qui ont été embauchées via la procédure standard pour les ingénieurs logiciels de Google. Les 40 à 50 % restants sont des candidats qui étaient très proches des qualifications d’ingénieur logiciel Google (c’est-à-dire 85 à 99 % de l’ensemble des compétences requises), et qui possédaient en outre un ensemble de compétences techniques utiles au SRE mais rares pour la plupart des ingénieurs logiciels. Les internes des systèmes UNIX et l’expertise en matière de réseaux (couches 1 à 3) sont de loin les deux types les plus courants de compétences techniques alternatives que nous recherchons.
Tous les SRE ont en commun la conviction et l’aptitude à développer des systèmes logiciels pour résoudre des problèmes complexes. Au sein de SRE, nous suivons de près l’évolution de la carrière des deux groupes et n’avons constaté à ce jour aucune différence concrète de performance entre les ingénieurs des deux filières. En fait, les antécédents quelque peu diversifiés de l’équipe SRE aboutissent souvent à des systèmes intelligents et de haute qualité qui sont clairement le produit de la synthèse de plusieurs ensembles de compétences.
Le résultat de notre approche du recrutement de SRE est que nous nous retrouvons avec une équipe de personnes qui (a) s’ennuient rapidement en effectuant des tâches manuelles et (b) possèdent les compétences nécessaires pour écrire des logiciels afin de remplacer leur travail manuel, même si la solution est compliquée. Les SRE finissent également par partager leur bagage académique et intellectuel avec le reste de l’organisation de développement. Par conséquent, le SRE fait fondamentalement le même travail que l’équipe d’exploitation, mais en faisant appel à des ingénieurs spécialisés dans les logiciels et en misant sur le fait que ces ingénieurs sont intrinsèquement prédisposés et capables de concevoir et de mettre en œuvre l’automatisation avec des logiciels pour remplacer le travail humain.
Par conception, il est crucial que les équipes SRE se concentrent sur l’ingénierie. Sans une ingénierie constante, la charge des opérations augmente et les équipes auront besoin de plus de personnes simplement pour suivre le rythme de la charge de travail. À terme, un groupe traditionnel axé sur les opérations évolue linéairement avec la taille du service : si les produits pris en charge par le service ont du succès, la charge opérationnelle augmentera avec le trafic. Cela signifie qu’il faut embaucher davantage de personnes pour effectuer les mêmes tâches, encore et encore.
Pour éviter ce sort, l’équipe chargée de gérer un service doit coder, sinon elle se noiera. C’est pourquoi Google plafonne à 50 % le travail “opérationnel” global de tous les SRE (billets, garde, tâches manuelles, etc.). Ce plafond garantit que l’équipe SRE dispose de suffisamment de temps dans son emploi du temps pour rendre le service stable et opérationnel. Ce plafond est une limite supérieure ; au fil du temps, laissée à elle-même, l’équipe SRE devrait se retrouver avec très peu de charge opérationnelle et se consacrer presque entièrement aux tâches de développement, car le service fonctionne et se répare de lui-même : nous voulons des systèmes automatiques, pas seulement automatisés. Dans la pratique, l’échelle et les nouvelles fonctionnalités obligent les SRE à rester vigilants.
Selon la règle empirique de Google, une équipe SRE doit consacrer les 50 % restants de son temps au développement. Alors, comment faire respecter ce seuil ? Tout d’abord, nous devons mesurer le temps passé par les SRE. Une fois cette mesure en main, nous veillons à ce que les équipes qui consacrent systématiquement moins de 50 % de leur temps au développement modifient leurs pratiques. Cela signifie souvent qu’il faut transférer une partie de la charge des opérations à l’équipe de développement, ou ajouter du personnel à l’équipe sans lui confier de responsabilités opérationnelles supplémentaires. Le maintien conscient de cet équilibre entre les opérations et le développement nous permet de garantir que les SRE disposent de la bande passante nécessaire pour s’engager dans une ingénierie créative et autonome, tout en conservant la sagesse glanée dans le cadre de l’exploitation d’un service.
Nous avons constaté que l’approche de Google SRE en matière de fonctionnement des systèmes à grande échelle présente de nombreux avantages. Comme les SRE modifient directement le code dans le but de faire fonctionner les systèmes de Google, les équipes SRE se caractérisent à la fois par une innovation rapide et une grande acceptation du changement. Ces équipes sont relativement peu coûteuses : pour assurer le même service avec une équipe axée sur les opérations, il faudrait un nombre beaucoup plus important de personnes. Au lieu de cela, le nombre de SRE nécessaires pour exécuter, maintenir et améliorer un système augmente de façon sub-linéaire avec la taille du système. Enfin, non seulement le SRE permet de contourner le dysfonctionnement de la séparation entre le développement et l’exploitation, mais cette structure améliore également nos équipes de développement de produits : les transferts faciles entre les équipes de développement de produits et le SRE permettent de former l’ensemble du groupe et d’améliorer les compétences des développeurs qui, autrement, pourraient avoir des difficultés à apprendre comment construire un système distribué à un million de cœurs.
Malgré ces gains nets, le modèle SRE se caractérise par un ensemble distinct de défis. Le recrutement des SRE est un défi permanent pour Google : non seulement les SRE sont en concurrence avec les autres candidats du développement de produits, mais le fait que nous plaçons la barre si haut en termes de compétences en codage et en ingénierie système signifie que notre bassin de recrutement est nécessairement restreint. Comme notre discipline est relativement nouvelle et unique, il n’existe pas beaucoup d’informations sectorielles sur la manière de constituer et de gérer une équipe SRE (même si nous espérons que ce livre fera des progrès dans ce sens !) Et une fois l’équipe SRE en place, ses approches potentiellement peu orthodoxes de la gestion des services nécessitent un soutien fort de la part de la direction. Par exemple, la décision d’arrêter les publications pour le reste du trimestre une fois que le budget des erreurs est épuisé pourrait ne pas être adoptée par une équipe de développement de produits, à moins qu’elle ne soit mandatée par sa direction.
Le terme “DevOps” est apparu dans l’industrie fin 2008 et, au moment où nous écrivons ces lignes (début 2016), il est encore en pleine évolution. Ses principes fondamentaux - implication de la fonction informatique dans chaque phase de la conception et du développement d’un système, forte dépendance à l’égard de l’automatisation par rapport à l’effort humain, application de pratiques et d’outils d’ingénierie aux tâches d’exploitation - sont cohérents avec de nombreux principes et pratiques du SRE. On pourrait considérer DevOps comme une généralisation de plusieurs principes fondamentaux de la SRE à un plus large éventail d’organisations, de structures de gestion et de personnel. On pourrait également considérer la SRE comme une mise en œuvre spécifique de DevOps avec quelques extensions idiosyncratiques.
Si les nuances des flux de travail, des priorités et des opérations quotidiennes varient d’une équipe SRE à l’autre, toutes partagent un ensemble de responsabilités de base pour le(s) service(s) qu’elles prennent en charge et adhèrent aux mêmes principes fondamentaux. En général, une équipe SRE est responsable de la disponibilité, de la latence, des performances, de l’efficacité, de la gestion des changements, de la surveillance, des interventions d’urgence et de la planification des capacités de son ou ses services. Nous avons codifié des règles d’engagement et des principes concernant la manière dont les équipes SRE interagissent avec leur environnement - non seulement l’environnement de production, mais aussi les équipes de développement de produits, les équipes de test, les utilisateurs, etc. Ces règles et pratiques de travail nous aident à rester concentrés sur le travail d’ingénierie, par opposition au travail d’exploitation.
La section suivante aborde chacun des principes fondamentaux de Google SRE.
Comme nous l’avons vu, Google limite le travail opérationnel des SRE à 50 % de leur temps. Le reste de leur temps doit être consacré à l’utilisation de leurs compétences en codage dans le cadre de projets. En pratique, cela se fait en contrôlant la quantité de travail opérationnel effectué par les SRE et en redirigeant le travail opérationnel excédentaire vers les équipes de développement de produits : réaffectation des bogues et des tickets aux responsables du développement, [ré]intégration des développeurs dans les rotations des pagers de garde, etc. La réorientation prend fin lorsque la charge opérationnelle retombe à 50 % ou moins. Cela fournit également un mécanisme de retour d’information efficace, guidant les développeurs vers la construction de systèmes qui ne nécessitent pas d’intervention manuelle. Cette approche fonctionne bien lorsque l’ensemble de l’organisation - l’ER et le développement - comprend la raison d’être du mécanisme de soupape de sécurité et soutient l’objectif de ne pas avoir d’événements de débordement parce que le produit ne génère pas assez de charge opérationnelle pour le nécessiter.
Lorsqu’ils se concentrent sur le travail opérationnel, les SRE devraient recevoir en moyenne un maximum de deux événements par quart de garde de 8 à 12 heures. Ce volume cible donne à l’ingénieur d’astreinte suffisamment de temps pour traiter l’événement avec précision et rapidité, nettoyer et rétablir le service normal, puis effectuer un post-mortem. Si plus de deux événements se produisent régulièrement par équipe d’astreinte, les problèmes ne peuvent pas être étudiés en profondeur et les ingénieurs sont suffisamment débordés pour ne pas pouvoir tirer de leçons de ces événements. Un scénario de fatigue des téléavertisseurs ne s’améliorera pas non plus avec l’échelle. À l’inverse, si les SRE d’astreinte reçoivent systématiquement moins d’un événement par équipe, le fait de les garder à l’œil est une perte de temps.
Les post-mortems doivent être rédigés pour tous les incidents importants, qu’ils aient été ou non signalés par un pager ; les post-mortems qui n’ont pas déclenché de pager sont encore plus précieux, car ils indiquent probablement des lacunes claires en matière de surveillance. Cette enquête doit établir ce qui s’est passé en détail, trouver toutes les causes profondes de l’événement et attribuer des actions pour corriger le problème ou améliorer la façon dont il sera traité la prochaine fois. Google opère dans le cadre d’une culture post-mortem sans reproche, avec pour objectif d’exposer les failles et d’appliquer l’ingénierie pour les corriger, plutôt que de les éviter ou de les minimiser.
Les équipes de développement de produits et de SRE peuvent entretenir une relation de travail productive en éliminant le conflit structurel dans leurs objectifs respectifs. Le conflit structurel se situe entre le rythme de l’innovation et la stabilité du produit, et comme décrit précédemment, ce conflit s’exprime souvent de manière indirecte. Dans SRE, nous mettons ce conflit en évidence, puis nous le résolvons en introduisant un budget d’erreur.
Le budget d’erreur découle de l’observation que 100 % n’est pas le bon objectif de fiabilité pour pratiquement tout (les stimulateurs cardiaques et les freins antiblocage étant des exceptions notables). En général, pour tout service ou système logiciel, 100% n’est pas le bon objectif de fiabilité car aucun utilisateur ne peut faire la différence entre un système disponible à 100% et un système disponible à 99,999%. Il y a beaucoup d’autres systèmes sur le chemin entre l’utilisateur et le service (son ordinateur portable, le WiFi de sa maison, son ISP, le réseau électrique…) et ces systèmes sont collectivement bien moins disponibles que 99,999%. Ainsi, la différence marginale entre 99,999% et 100% se perd dans le bruit des autres indisponibilités, et l’utilisateur ne reçoit aucun bénéfice de l’énorme effort requis pour ajouter ce dernier 0,001% de disponibilité.
Si 100 % n’est pas le bon objectif de fiabilité pour un système, quel est donc le bon objectif de fiabilité pour ce système ? Il ne s’agit pas du tout d’une question technique, mais d’une question de produit, qui doit prendre en compte les considérations suivantes :
L’entreprise ou le produit doit établir l’objectif de disponibilité du système. Une fois cet objectif établi, le budget d’erreur est égal à un moins l’objectif de disponibilité. Un service disponible à 99,99 % est indisponible à 0,01 %. Ce 0,01% d’indisponibilité autorisée est le budget d’erreur du service. Nous pouvons dépenser ce budget pour tout ce que nous voulons, tant que nous ne le dépassons pas.
Alors, comment voulons-nous dépenser le budget d’erreurs ? L’équipe de développement veut lancer des fonctionnalités et attirer de nouveaux utilisateurs. Idéalement, nous devrions dépenser tout notre budget d’erreur en prenant des risques avec les choses que nous lançons afin de les lancer rapidement. Ce principe de base décrit l’ensemble du modèle des budgets d’erreur. Dès que les activités de SRE sont conceptualisées dans ce cadre, libérer le budget d’erreur par des tactiques telles que les déploiements progressifs et les expériences à 1 % peut permettre d’optimiser les lancements plus rapides.
L’utilisation d’un budget d’erreur résout le conflit structurel d’incitations entre le développement et le SRE. L’objectif du SRE n’est plus " zéro panne “, mais les SRE et les développeurs de produits cherchent plutôt à dépenser le budget d’erreurs pour obtenir une vitesse maximale des fonctionnalités. Ce changement fait toute la différence. Une panne n’est plus une " mauvaise " chose : c’est un élément attendu du processus d’innovation et un événement que les équipes de développement et de SRE gèrent au lieu de le craindre.
La surveillance est l’un des principaux moyens par lesquels les propriétaires de services suivent l’état de santé et la disponibilité d’un système. En tant que telle, la stratégie de surveillance doit être élaborée de manière réfléchie. Une approche classique et commune de la surveillance consiste à surveiller une valeur ou une condition spécifique, puis à déclencher une alerte par courriel lorsque cette valeur est dépassée ou que cette condition se produit. Toutefois, ce type d’alerte par courrier électronique n’est pas une solution efficace : un système qui exige qu’un être humain lise un courrier électronique et décide si un certain type d’action doit être entrepris en réponse est fondamentalement défectueux. La surveillance ne devrait jamais exiger qu’un humain interprète une partie du domaine d’alerte. Au contraire, le logiciel devrait faire l’interprétation et les humains ne devraient être avertis que lorsqu’ils doivent prendre des mesures.
Il existe trois types de résultats de surveillance valides :
Signifie qu’un humain doit agir immédiatement en réponse à quelque chose qui se produit ou qui est sur le point de se produire, afin d’améliorer la situation.
Signifie qu’une personne doit prendre des mesures, mais pas immédiatement. Le système ne peut pas gérer automatiquement la situation, mais si un humain prend des mesures dans quelques jours, aucun dommage ne sera causé.
Personne n’a besoin de consulter ces informations, mais elles sont enregistrées à des fins de diagnostic ou d’expertise judiciaire. On s’attend à ce que personne ne lise les journaux, sauf si quelque chose d’autre l’incite à le faire.
La fiabilité est une fonction du temps moyen de défaillance (MTTF) et du temps moyen de réparation (MTTR) [Sch15]. La mesure la plus pertinente pour évaluer l’efficacité d’une intervention d’urgence est la rapidité avec laquelle l’équipe d’intervention peut remettre le système en état, c’est-à-dire le MTTR.
Les humains ajoutent de la latence. Même si un système donné subit un plus grand nombre de défaillances réelles, un système qui peut éviter les urgences nécessitant une intervention humaine aura une disponibilité plus élevée qu’un système qui nécessite une intervention manuelle. Lorsque l’intervention humaine est nécessaire, nous avons constaté que le fait de réfléchir et d’enregistrer à l’avance les meilleures pratiques dans un “livre de jeu” permet d’améliorer le MTTR d’environ 3 fois par rapport à la stratégie consistant à “improviser”. L’ingénieur d’astreinte héros et touche-à-tout fonctionne, mais l’ingénieur d’astreinte expérimenté et armé d’un livre de jeu fonctionne beaucoup mieux. Bien qu’aucun manuel, aussi complet soit-il, ne puisse se substituer à des ingénieurs intelligents capables de réfléchir à la volée, des étapes et des conseils de dépannage clairs et complets sont précieux lorsqu’il s’agit de répondre à une page à fort enjeu ou à délai critique. C’est pourquoi le service SRE de Google s’appuie sur des manuels d’intervention sur appel, ainsi que sur des exercices tels que la “roue de l’infortune “7, pour préparer les ingénieurs à réagir aux événements sur appel.
Le SRE a constaté qu’environ 70 % des pannes sont dues à des modifications apportées à un système actif. Les meilleures pratiques dans ce domaine utilisent l’automatisation pour accomplir ce qui suit :
Ce trio de pratiques minimise efficacement le nombre total d’utilisateurs et d’opérations exposés à de mauvais changements. En retirant les humains de la boucle, ces pratiques évitent les problèmes normaux de fatigue, de familiarité/contemplation et d’inattention aux tâches hautement répétitives. En conséquence, la vitesse de publication et la sécurité augmentent.
La prévision de la demande et la planification de la capacité peuvent être considérées comme la garantie d’une capacité et d’une redondance suffisantes pour répondre à la demande future prévue avec la disponibilité requise. Ces concepts n’ont rien de particulier, si ce n’est qu’un nombre surprenant de services et d’équipes ne prennent pas les mesures nécessaires pour s’assurer que la capacité requise est en place au moment où elle est nécessaire. La planification de la capacité doit tenir compte à la fois de la croissance organique (qui découle de l’adoption et de l’utilisation naturelles du produit par les clients) et de la croissance inorganique (qui résulte d’événements tels que le lancement de fonctionnalités, les campagnes de marketing ou d’autres changements dictés par l’entreprise).
Plusieurs étapes sont obligatoires dans la planification des capacités :
La capacité étant essentielle à la disponibilité, l’équipe SRE doit naturellement être chargée de la planification de la capacité, ce qui signifie qu’elle doit également être chargée du provisionnement.
Le provisionnement combine à la fois la gestion du changement et la planification de la capacité. D’après notre expérience, le provisionnement doit être effectué rapidement et uniquement en cas de besoin, car la capacité coûte cher. Cet exercice doit également être réalisé correctement, faute de quoi la capacité ne fonctionnera pas en cas de besoin. L’ajout d’une nouvelle capacité implique souvent de faire tourner une nouvelle instance ou un nouvel emplacement, d’apporter des modifications importantes aux systèmes existants (fichiers de configuration, équilibreurs de charge, mise en réseau) et de valider que la nouvelle capacité fonctionne et fournit des résultats corrects. Il s’agit donc d’une opération plus risquée que le transfert de charge, qui est souvent effectué plusieurs fois par heure, et qui doit être traitée avec un degré correspondant de prudence supplémentaire.
L’utilisation efficace des ressources est importante chaque fois qu’un service se préoccupe de l’argent. Étant donné que SRE contrôle en fin de compte le provisionnement, il doit également être impliqué dans tout travail sur l’utilisation, car l’utilisation est fonction du fonctionnement d’un service donné et de son provisionnement. Il s’ensuit qu’en accordant une attention particulière à la stratégie de provisionnement d’un service, et donc à son utilisation, on obtient un levier très, très important sur les coûts totaux du service.
L’utilisation des ressources est fonction de la demande (charge), de la capacité et de l’efficacité du logiciel. Les SRE prévoient la demande, fournissent la capacité et peuvent modifier le logiciel. Ces trois facteurs constituent une grande partie (mais pas la totalité) de l’efficacité d’un service.
Les systèmes logiciels deviennent plus lents à mesure qu’ils sont chargés. Un ralentissement dans un service équivaut à une perte de capacité. À un moment donné, un système qui ralentit cesse de servir, ce qui correspond à une lenteur infinie. Les SRE prévoient d’atteindre un objectif de capacité à une vitesse de réponse spécifique, et s’intéressent donc de près aux performances d’un service. Les SRE et les développeurs de produits vont (et doivent) surveiller et modifier un service pour améliorer ses performances, ce qui permet d’augmenter la capacité et d’améliorer l’efficacité8.
L’ingénierie de la fiabilité des sites représente une rupture importante par rapport aux meilleures pratiques du secteur en matière de gestion de services complexes et de grande envergure. Motivée à l’origine par un sentiment de familiarité - " en tant qu’ingénieur logiciel, c’est ainsi que je voudrais investir mon temps pour accomplir un ensemble de tâches répétitives " - elle est devenue bien plus que cela : un ensemble de principes, un ensemble de pratiques, un ensemble d’incitations et un domaine d’activité au sein de la discipline plus large du génie logiciel. Le reste du livre explore en détail la méthode SRE.