SRE (Site Reliability Engineering) - une approche pour assurer la disponibilité des projets web. Il est considéré comme un cadre pour DevOps et indique comment réussir à appliquer les pratiques DevOps. Cet article est une traduction du chapitre 4 des objectifs de niveau de service de Site Reliability Engineering de Google. J'ai préparé cette traduction moi-même et je me suis appuyée sur ma propre expérience dans la compréhension des processus de suivi. Dans la chaîne de télégramme monitorim_it et le dernier article sur Habré, j'ai également publié une traduction du chapitre 6 du même livre sur la surveillance des systèmes distribués.

Traduction par chat. Bonne lecture!

Il est impossible de gérer un service si l'on ne comprend pas quels indicateurs sont vraiment importants et comment les mesurer et les évaluer. À cette fin, nous définissons et fournissons un certain niveau de service à nos utilisateurs, qu'ils utilisent l'une de nos API internes ou un produit public.

Nous utilisons notre intuition, notre expérience et nous reconnaissons le désir des utilisateurs d'avoir une idée des indicateurs de niveau de service (SLI), des objectifs de niveau de service (SLO) et de l'accord de niveau de service (SLA). Ces mesures décrivent les principales mesures que nous voulons contrôler et auxquelles nous répondrons si nous ne pouvons pas fournir la qualité de service attendue. En fin de compte, le choix des bons indicateurs permet de gérer les bonnes actions en cas de problème et donne également confiance à l'équipe SRE dans la santé du service.

Ce chapitre décrit l'approche que nous utilisons pour traiter les problèmes de modélisation métrique, de sélection métrique et d'analyse métrique. La plupart des explications seront sans exemples, nous allons donc utiliser le service Shakespeare décrit dans l'exemple de sa mise en œuvre (recherche des travaux de Shakespeare) pour illustrer les principaux points.

Terminologie du niveau de service

De nombreux lecteurs connaissent probablement le concept de SLA, mais les termes SLI et SLO méritent une définition soigneuse, car en général le terme SLA est surchargé et a un certain nombre de significations selon le contexte. Pour plus de clarté, nous voulons séparer ces valeurs.

Indicateurs

Le SLI est un indicateur du niveau de service - une mesure soigneusement quantifiée d'un aspect du niveau de service fourni.

Pour la plupart des services, le retard dans la demande est considéré comme le SLI clé - combien de temps est nécessaire pour renvoyer une réponse à la demande. Les autres SLI courants incluent le taux d'erreur, souvent exprimé sous forme de fraction de toutes les demandes reçues, et le débit du système, généralement mesuré en demandes par seconde. Les mesures sont souvent agrégées: les données brutes sont d'abord collectées puis converties en taux de variation, moyenne ou centile.

Idéalement, le SLI mesure directement le niveau de service d'intérêt, mais parfois seule la métrique associée est disponible pour la mesure, car l'original est difficile à obtenir ou à interpréter. Par exemple, la latence côté client est souvent une mesure plus appropriée, mais il arrive que la mesure de la latence ne soit possible que sur le serveur.

Un autre type de SLI qui est important pour SRE est la disponibilité ou une partie du temps pendant lequel le service peut être utilisé. Il est souvent défini comme le pourcentage de demandes réussies, parfois appelé génération. (Espérance de vie - la probabilité que les données soient stockées pendant une longue période est également importante pour les systèmes de stockage de données.) Bien que l'accessibilité soit 100% impossible, une accessibilité proche de 100% est souvent réalisable, les valeurs d'accessibilité sont exprimées par le nombre «neuf» »Disponibilité en pourcentage. Par exemple, une disponibilité de 99% et 99,999% peut être désignée par «2 neuf» et «5 neuf». L'objectif déclaré actuel d'accessibilité pour Google Compute Engine est de "trois et demi neuf" ou 99,95%.

Buts

SLO est l'objectif d'un niveau de service: une valeur cible ou une plage de valeurs pour le niveau de service qui est mesurée par SLI. La valeur normale pour SLO est «SLI ≤ valeur cible» ou «limite inférieure ≤ SLI ≤ limite supérieure». Par exemple, nous pouvons décider que nous retournerons les résultats de recherche pour les œuvres de Shakespeare «rapidement», en prenant sous forme de SLO la valeur du délai moyen de la requête de recherche est inférieure à 100 millisecondes.

Choisir le bon SLO est un processus complexe. Premièrement, vous ne pouvez pas toujours sélectionner une valeur spécifique. Pour les requêtes HTTP entrantes externes à votre service, la métrique du nombre de requêtes par seconde (QPS) est principalement déterminée par le désir de vos utilisateurs de visiter votre service, et vous ne pouvez pas installer SLO pour cela.

En revanche, vous pouvez dire que vous souhaitez que le délai moyen pour chaque demande soit inférieur à 100 millisecondes. Fixer un tel objectif peut vous obliger à rédiger votre front-end avec un faible retard ou à acheter du matériel qui fournit un tel retard. (100 millisecondes est évidemment une valeur arbitraire, mais il vaut mieux avoir des taux de latence encore plus bas. Il y a des raisons de croire que la vitesse élevée est meilleure que lente et que le fait de retarder les demandes des utilisateurs au-dessus de certaines valeurs force en fait les gens à rester loin de votre service.)

Encore une fois, c'est plus ambigu qu'il n'y paraît à première vue: cela ne vaut pas la peine de jeter QPS hors du calcul. Le fait est que le bundle QPS et le retard sont fortement liés l'un à l'autre: un QPS plus élevé entraîne souvent des délais plus longs et les services connaissent généralement une forte baisse des performances lorsqu'un certain seuil de charge est atteint.

Le choix et la publication de SLO définissent les attentes des utilisateurs quant au fonctionnement du service. Cette stratégie peut réduire les plaintes déraisonnables concernant le propriétaire du service, par exemple, concernant sa lenteur de travail. Sans SLO explicite, les utilisateurs créent souvent leurs propres attentes concernant les performances souhaitées, qui ne sont en aucun cas liées aux opinions des personnes qui conçoivent et gèrent le service. Cet alignement peut conduire à des attentes élevées de la part du service, lorsque les utilisateurs croient à tort que le service sera plus accessible qu'il ne l'est en réalité et suscitent la méfiance lorsque les utilisateurs pensent que le système est moins fiable qu'il ne l'est réellement.

Accord

Un accord de niveau de service est un contrat explicite ou implicite avec vos utilisateurs qui inclut les conséquences de l'apparition (ou de l'absence) des SLO qu'ils contiennent. Les conséquences sont plus facilement reconnaissables lorsqu'elles sont financières - une remise ou une pénalité - mais elles peuvent prendre d'autres formes. Un moyen facile de parler de la différence entre les SLO et les SLA est de demander: "Que se passe-t-il si les SLO ne sont pas respectés?" S'il n'y a pas de conséquences évidentes, vous examinerez certainement SLO.

Les SRE ne sont généralement pas impliqués dans la création de SLA car les SLA sont étroitement liés aux solutions commerciales et de produits. SRE, cependant, participe à la prévention des conséquences d'échecs des SLO. Ils peuvent également aider à déterminer les SLI: évidemment, il doit y avoir un moyen objectif de mesurer les SLO dans un accord ou il y aura des désaccords.

Google Search est un exemple d'un service important qui n'a pas de SLA pour le public: nous voulons que tout le monde utilise la recherche aussi efficacement que possible, mais nous n'avons pas signé de contrat avec le monde entier. Cependant, il y a toujours des conséquences si la recherche n'est pas disponible - l'inaccessibilité entraîne une baisse de notre réputation, ainsi qu'une diminution des revenus publicitaires. De nombreux autres services Google, tels que Google for Work, ont des accords de niveau de service explicites avec les utilisateurs. Indépendamment du fait qu'un service particulier ait ou non un SLA, il est important de déterminer le SLI et le SLO et de les utiliser pour gérer le service.

Tellement de théorie - maintenant à expérimenter.

Indicateurs en pratique

Étant donné que nous avons conclu qu'il est important de sélectionner les indicateurs appropriés pour mesurer le niveau de service, comment savez-vous maintenant quels indicateurs sont pertinents pour le service ou le système?

Ce dont vous et vos utilisateurs vous souciez

Vous n'avez pas besoin d'utiliser chaque indicateur comme un SLI, que vous pouvez suivre dans le système de surveillance; Comprendre ce que les utilisateurs attendent du système vous aidera à choisir quelques mesures. Si vous choisissez trop d'indicateurs, il est difficile de prêter attention aux indicateurs importants, tandis que le fait d'en choisir trop peu peut laisser des morceaux importants de votre système sans surveillance. Habituellement, nous utilisons plusieurs indicateurs clés pour évaluer et comprendre l'état du système.

Les services, en règle générale, peuvent être divisés en plusieurs parties en termes de SLI, qui sont pertinentes pour eux:

• Systèmes frontaux personnalisés, tels que les interfaces de recherche de service Shakespeare de notre exemple. Ils doivent être accessibles, non retardés et avoir une bande passante suffisante. En conséquence, vous pouvez poser des questions: pouvons-nous répondre à la demande? Combien de temps a-t-il fallu pour répondre à la demande? Combien de demandes peuvent être traitées?
• Systèmes de stockage. La faible latence, la disponibilité et la durabilité sont importantes pour eux. Questions connexes: combien de temps faut-il pour lire ou écrire des données? Pouvons-nous accéder aux données à la demande? Les données sont-elles disponibles lorsque nous en avons besoin? Voir le chapitre 26 Intégrité des données: ce que vous lisez est ce que vous avez écrit pour une discussion détaillée de ces problèmes.
• Les systèmes de Big Data, tels que les pipelines de traitement des données, dépendent du débit et de la latence du traitement des demandes. Questions pertinentes: combien de données sont traitées? Combien de temps faut-il pour que les données passent de la réception d'une demande à l'émission d'une réponse? (Certaines parties du système peuvent également présenter des retards à certaines étapes.)

Collection d'indicateurs

Il est plus naturel de collecter de nombreux indicateurs de niveau de service côté serveur, en utilisant un système de surveillance tel que Borgmon (voir Chapitre 10 Pratique des alertes de séries chronologiques ) ou Prometheus, ou tout simplement en analysant périodiquement les journaux, révélant les réponses HTTP avec un statut de 500. Néanmoins, certains systèmes doivent être équipés d'une collecte de métriques côté client, car le manque de surveillance côté client peut conduire à manquer un certain nombre de problèmes qui affectent les utilisateurs mais n'affectent pas les métriques côté serveur. Par exemple, se concentrer sur la réponse retardée du backend de notre application de test à la recherche des œuvres de Shakespeare peut entraîner un retard dans le traitement des demandes côté utilisateur en raison de problèmes JavaScript: dans ce cas, mesurer le temps que la page mettra à traiter dans le navigateur est le meilleur indicateur.

Agrégation

Pour plus de simplicité et de facilité d'utilisation, nous regroupons souvent les dimensions brutes. Cela doit être fait avec soin.

Certains indicateurs semblent simples, par exemple le nombre de requêtes par seconde, mais même cette mesure, évidente et directe, agrège implicitement les données dans le temps. La mesure est-elle obtenue spécifiquement une fois par seconde ou cette mesure est-elle moyenne sur le nombre de requêtes par minute? Cette dernière option peut masquer un nombre instantané beaucoup plus élevé de demandes stockées pendant quelques secondes seulement. Prenons un système qui traite 200 requêtes par seconde avec des nombres pairs et 0 le reste du temps. Une constante sous la forme d'une valeur moyenne de 100 requêtes par seconde et deux fois plus de charge instantanée n'est pas la même chose. De même, la moyenne des latences des demandes peut sembler intéressante, mais elle cache un détail important: il est possible que la plupart des demandes soient rapides, mais il y aura de nombreuses demandes qui seront lentes.

La plupart des indicateurs sont mieux considérés comme des distributions que comme des moyennes. Par exemple, pour les retards SLI, certaines demandes seront traitées rapidement, tandis que d'autres prendront toujours plus de temps, parfois beaucoup plus de temps. Une simple moyenne peut masquer ces longs délais. La figure montre un exemple: bien qu'une demande typique soit servie pendant environ 50 ms, 5% des demandes sont 20 fois plus lentes! La surveillance et les alertes basées uniquement sur la latence moyenne ne montrent pas de changements de comportement au cours de la journée, alors qu'en fait il y a des changements notables dans le temps de traitement de certaines demandes (la ligne supérieure).


50, 85, 95 et 99 centile du retard du système. L'axe des Y est au format logarithmique.

L'utilisation des centiles pour les indicateurs vous permet de voir la forme de la distribution et ses caractéristiques: un niveau élevé d'un centile, tel que 99 ou 99,9, affiche la pire valeur, et à 50 centile (également connu sous le nom de médiane), vous pouvez voir l'état le plus fréquent de la métrique. Plus la variance du temps de réponse est grande, plus les requêtes à long terme affectent l'expérience utilisateur. L'effet est amélioré à charge élevée en présence de files d'attente. Les études d'expérience utilisateur ont montré que les gens préfèrent généralement un système plus lent avec une dispersion élevée du temps de réponse, de sorte que certaines équipes SRE se concentrent uniquement sur les valeurs de centile élevées, en supposant que si le comportement métrique sur le 99,9 centile est bon, la plupart des utilisateurs ne connaîtront pas problèmes.

Remarque sur les erreurs statistiques

Habituellement, nous préférons travailler avec des centiles plutôt qu'avec un ensemble moyen (moyenne arithmétique) de valeurs. Cela nous permet de considérer des valeurs plus dispersées, qui ont souvent des caractéristiques significativement différentes (et plus intéressantes) que la moyenne. En raison de la nature artificielle des systèmes informatiques, les valeurs métriques sont souvent déformées, par exemple, aucune demande ne peut recevoir de réponse en moins de 0 ms, et un délai d'expiration de 1000 ms signifie qu'il ne peut y avoir de réponses réussies avec des valeurs dépassant le délai. En conséquence, nous ne pouvons accepter que la moyenne et les médianes puissent être identiques ou proches l'une de l'autre!

Sans vérification préliminaire, et si certaines hypothèses et approximations standard ne sont pas remplies, nous essayons de ne pas tirer de conclusions selon lesquelles nos données sont normalement distribuées. Si la distribution n'est pas comme prévu, un processus d'automatisation qui résout le problème (par exemple, lorsqu'il voit des valeurs aberrantes au-delà des valeurs limites, il redémarre le serveur avec des latences élevées pour traiter la demande) peut le faire trop souvent ou pas assez souvent (les deux options ne sont pas très bonnes).

Standardiser les indicateurs

Nous vous recommandons de standardiser les caractéristiques générales des SLI afin que vous n'ayez pas à en parler à chaque fois. Toute fonction qui satisfait aux modèles standard peut être exclue de la spécification d'un SLI individuel, par exemple:

• Intervalles d'agrégation: "en moyenne sur 1 minute"
• Zones d'agrégation: «Toutes les tâches du cluster»
• Fréquence des mesures: «toutes les 10 secondes»
• Quelles demandes sont incluses: "HTTP GET à partir des tâches de surveillance de la boîte noire"
• Comment les données ont été reçues: «Grâce à notre surveillance mesurée sur le serveur»,
• Délai d'accès aux données: «Time to Last Byte»

Pour économiser des efforts, créez un ensemble de modèles SLI réutilisables pour chaque métrique commune; ils permettent également à chacun de comprendre plus facilement ce que signifie un SLI particulier.

Objectifs d'entraînement

Commencez par penser (ou découvrez!) Ce qui intéresse vos utilisateurs, pas ce que vous pouvez mesurer. Souvent, ce qui dérange vos utilisateurs est difficile ou impossible à mesurer, vous finissez donc par vous rapprocher de leurs besoins. Cependant, si vous commencez par ce qui est facile à mesurer, vous obtiendrez des SLO moins utiles. En conséquence, nous avons parfois constaté que la définition initiale des objectifs souhaités et le travail ultérieur avec des indicateurs spécifiques fonctionnent mieux que le choix d'indicateurs, puis la réalisation des objectifs.

Définir des objectifs

Pour une clarté maximale, il convient de déterminer comment les SLO sont mesurés et les conditions dans lesquelles ils sont valides. Par exemple, nous pouvons dire ce qui suit (la deuxième ligne est la même que la première, mais utilise les valeurs SLI par défaut):

• 99% (en moyenne sur 1 minute) des appels Get RPC seront effectués en moins de 100 ms (mesurés sur tous les serveurs principaux).
• 99% des appels Get RPC seront effectués en moins de 100 ms.

Si la forme des courbes de performances est importante, vous pouvez spécifier plusieurs objectifs SLO:

• 90% des appels Get RPC sont terminés en moins de 1 ms.
• 99% des appels Get RPC sont terminés en moins de 10 ms.
• 99,9% des appels Get RPC se sont terminés en moins de 100 ms.

Si vos utilisateurs génèrent des charges hétérogènes: traitement de masse (pour lequel la bande passante est importante) et traitement interactif (pour lequel le délai est important), il peut être judicieux de définir des objectifs distincts pour chaque classe de charge:

• 95% des demandes des clients concernent une bande passante importante. Définissez le nombre d'appels RPC en cours <1 s.
• 99% des clients apprécient le retard. Configurez le nombre d'appels RPC avec un trafic <1 Ko et en cours <10 ms.

Il est irréaliste et indésirable d'insister pour que les SLO soient exécutés dans 100% des cas: cela peut ralentir le rythme d'introduction de nouvelles fonctionnalités et de nouveaux déploiements, et nécessiter des solutions coûteuses. Au lieu de cela, il vaut mieux autoriser un budget d'erreurs - une fraction du temps d'arrêt du système et surveiller cette valeur quotidiennement ou hebdomadairement.La direction peut souhaiter une évaluation mensuelle ou trimestrielle. (Le budget d'erreur n'est qu'un SLO pour comparaison avec un autre SLO).

Le pourcentage de violation de SLO peut être comparé au budget d'erreurs (voir le chapitre 3 et la section «Motivation des budgets d'erreurs» ), et la valeur de différence est utilisée comme entrée dans le processus qui décide quand déployer les nouvelles versions.

Sélectionnez les valeurs du plan

La sélection des valeurs planifiées (SLO) n'est pas une activité purement technique en raison des intérêts du produit et de l'entreprise, qui devraient se refléter dans le SLI, le SLO (et, éventuellement, le SLA) sélectionnés. De même, il peut être nécessaire d'échanger des informations sur des questions liées au personnel, au délai de mise sur le marché, à la disponibilité de l'équipement et au financement. Le SRE devrait faire partie de cette conversation et aider à gérer les risques et la viabilité des différentes options. Nous avons trouvé quelques questions qui pourraient aider à fournir une discussion plus productive:

ne choisissez pas un objectif basé sur les performances actuelles.
Bien qu'il soit important de comprendre les mérites et les limites du système, l'adaptation des indicateurs sans raisonnement peut vous empêcher de soutenir le système: il faudra des efforts héroïques pour atteindre des objectifs qui ne peuvent être atteints sans une réorganisation majeure.

Restez simple Les
calculs SLI complexes peuvent masquer les modifications des performances du système et rendre plus difficile la recherche de la cause du problème.

Évitez l'absolu.
Bien qu'il soit tentant d'avoir un système capable de supporter une charge croissante illimitée sans augmenter la valeur de retard, cette exigence est irréaliste. Un système qui approche de tels idéaux est susceptible de forcer beaucoup de temps à concevoir et à construire, coûtera cher à utiliser sera trop bon pour les attentes des utilisateurs qui en auraient eu moins.

Utilisez le moins de SLO possible.
Choisissez suffisamment de SLO pour assurer une bonne couverture des attributs du système. Protégez les SLO que vous choisissez: si vous ne pouvez jamais gagner un différend sur les priorités en spécifiant un SLO spécifique, vous ne devriez probablement pas considérer ce SLO. Cependant, tous les attributs du système ne se prêtent pas à SLO: il est difficile de calculer le niveau d'enthousiasme des utilisateurs avec SLO.

Ne poursuivez pas la perfection
Vous pouvez toujours clarifier les définitions et les objectifs de SLO au fil du temps, lorsque vous en apprendrez plus sur le comportement du système sous charge. Il vaut mieux commencer par un objectif flottant, que vous clarifierez au fil du temps, que de choisir un objectif trop strict, qui devrait être affaibli lorsque vous constatez qu’il est impossible à atteindre.

Les SLO peuvent et doivent être le principal moteur de la priorisation du travail pour SRE et les développeurs de produits, car ils reflètent l'attention des utilisateurs. Un bon SLO est un outil utile pour contraindre une équipe de développement. Mais un SLO mal conçu peut entraîner un travail inutile si l'équipe fait des efforts héroïques pour atteindre un SLO trop agressif ou un produit médiocre si le SLO est trop bas. SLO est un levier puissant, utilisez-le à bon escient.

Mesures de contrôle

SLI et SLO sont les éléments clés utilisés pour gérer les systèmes:

• Surveillez et mesurez les systèmes SLI.
• Comparez SLI avec SLO et décidez si une action est nécessaire.
• Si une action est requise, découvrez ce qui doit se produire pour atteindre l'objectif.
• Effectuez cette action.

Par exemple, si l'étape 2 montre que le délai d'expiration de la demande augmente et casse le SLO après quelques heures si rien n'est fait, l'étape 3 peut inclure le test de l'hypothèse que la charge du serveur est liée aux processeurs et l'ajout de nouveaux serveurs répartira la charge . Sans SLO, vous ne sauriez pas si (ou quand) prendre des mesures.

Définir SLO - les attentes des utilisateurs sont alors définies
La publication d'un SLO définit les attentes des utilisateurs quant au comportement du système. Les utilisateurs (et les utilisateurs potentiels) veulent souvent savoir à quoi s'attendre d'un service pour voir s'il convient à une utilisation. Par exemple, les personnes qui souhaitent utiliser un site Web de partage de photos peuvent vouloir éviter d'utiliser un service qui promet la durabilité et un faible coût en échange d'une disponibilité légèrement inférieure, bien que le même service puisse être idéal pour un système de gestion d'enregistrement d'archives.

Pour définir des attentes réalistes pour vos utilisateurs, utilisez l'une ou les deux tactiques suivantes:

• . SLO, . , . SLO , .
• . , , . , SLO, . , .

Comprendre dans quelle mesure le système répond aux attentes permet de décider d'accélérer le système et de le rendre plus accessible et plus stable. Alternativement, si le service fonctionne trop bien, une partie du temps du personnel devrait être consacrée à d'autres priorités, telles que le remboursement de la dette technique, l'ajout de nouvelles fonctionnalités ou la mise en service de nouveaux produits.

Ententes de pratique

La création d'un SLA nécessite que les équipes commerciales et juridiques déterminent les conséquences et les sanctions en cas de violation. Le rôle du SRE est de les aider à comprendre les difficultés probables avec l'exécution des SLO contenus dans les SLA. La plupart des directives SLO s'appliquent également aux SLA. Il est conseillé d'être prudent dans ce que vous promettez à vos utilisateurs, car plus ils sont nombreux, plus il est difficile de modifier ou de supprimer des SLA qui semblent déraisonnables ou difficiles à mettre en œuvre.

Merci d'avoir lu la traduction jusqu'au bout. Abonnez-vous à ma chaîne de télégramme sur la surveillance de monitorim_it et le blog sur le Medium .