SRE (Site Reliability Engineering) est une approche permettant d’assurer la disponibilité des projets web. Il est considéré comme un cadre pour DevOps et explique comment réussir dans l'application des pratiques DevOps. Traduction dans cet article livres de Google. J'ai préparé cette traduction moi-même et je me suis appuyé sur ma propre expérience dans la compréhension des processus de surveillance. Dans la chaîne des télégrammes и J'ai également publié une traduction du chapitre 6 du même livre sur les objectifs de niveau de service.
Traduction par chat. Bonne lecture!
Il est impossible de gérer un service sans comprendre quels indicateurs sont réellement importants et comment les mesurer et les évaluer. A 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 notre compréhension du désir des utilisateurs de comprendre les indicateurs de niveau de service (SLI), les objectifs de niveau de service (SLO) et les accords de niveau de service (SLA). Ces dimensions décrivent les principales métriques que nous souhaitons surveiller et auxquelles nous réagirons si nous ne pouvons pas fournir la qualité de service attendue. En fin de compte, choisir les bonnes mesures aide à guider les bonnes actions en cas de problème et donne également à l'équipe SRE confiance dans la santé du service.
Ce chapitre décrit l'approche que nous utilisons pour lutter contre les problèmes de modélisation, de sélection et d'analyse des métriques. La plupart des explications se feront sans exemples, nous utiliserons donc le service Shakespeare décrit dans son exemple d'implémentation (recherche des œuvres de Shakespeare) pour illustrer les points principaux.
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 minutieuse 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 souhaitons séparer ces valeurs.
Indicateurs
Le SLI est un indicateur de niveau de service, une mesure quantitative soigneusement définie d'un aspect du niveau de service fourni.
Pour la plupart des services, la clé SLI est considérée comme la latence de la demande, c'est-à-dire le temps nécessaire pour renvoyer une réponse à une demande. D'autres SLI courants incluent le taux d'erreur, souvent exprimé en fraction de toutes les requêtes reçues, et le débit du système, généralement mesuré en requêtes 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, SLI mesure directement le niveau de service qui vous intéresse, mais parfois seule une métrique associée est disponible pour la mesure car celle d'origine est difficile à obtenir ou à interpréter. Par exemple, la latence côté client est souvent une mesure plus appropriée, mais il arrive parfois que la latence ne puisse être mesurée que sur le serveur.
Un autre type de SLI important pour les SRE est la disponibilité, ou la durée pendant laquelle un service peut être utilisé. Souvent défini comme le taux de requêtes réussies, parfois appelé rendement. (La durée de vie – la probabilité que les données soient conservées pendant une période prolongée – est également importante pour les systèmes de stockage de données.) Bien qu'une disponibilité à 100 % ne soit pas possible, une disponibilité proche de 100 % est souvent réalisable ; les valeurs de disponibilité sont exprimées sous la forme le nombre de « neuf » » pourcentage de disponibilité. Par exemple, une disponibilité de 99 % et 99,999 % peut être étiquetée comme « 2 neuf » et « 5 neuf ». L'objectif de disponibilité actuellement déclaré de Google Compute Engine est de "trois neuf et demi" ou 99,95 %.
Objectifs
Un SLO est un objectif de niveau de service : une valeur cible ou une plage de valeurs pour un niveau de service qui est mesurée par le SLI. Une valeur normale pour SLO est « SLI ≤ Target » ou « Lower Limit ≤ SLI ≤ Upper Limit ». Par exemple, nous pourrions décider de renvoyer « rapidement » les résultats de recherche Shakespeare en définissant le SLO sur une latence moyenne des requêtes de recherche inférieure à 100 millisecondes.
Choisir le bon SLO est un processus complexe. Premièrement, vous ne pouvez pas toujours choisir une valeur spécifique. Pour les requêtes HTTP entrantes externes vers votre service, la métrique Requête par seconde (QPS) est principalement déterminée par le désir de vos utilisateurs de visiter votre service, et vous ne pouvez pas définir de SLO pour cela.
D’un autre côté, vous pouvez dire que vous souhaitez que la latence moyenne pour chaque requête soit inférieure à 100 millisecondes. Fixer un tel objectif peut vous obliger à écrire votre interface avec une faible latence ou à acheter du matériel offrant une telle latence. (100 millisecondes est évidemment un nombre arbitraire, mais il est préférable d'avoir des chiffres de latence encore plus faibles. Il existe des preuves suggérant que les vitesses rapides sont meilleures que les vitesses lentes, et que la latence dans le traitement des demandes des utilisateurs au-dessus de certaines valeurs oblige en fait les gens à rester à l'écart. de votre service.)
Encore une fois, c’est plus ambigu qu’il n’y paraît à première vue : vous ne devez pas exclure complètement le QPS du calcul. Le fait est que le QPS et la latence sont étroitement liés : un QPS plus élevé entraîne souvent des latences plus élevées, et les services connaissent généralement une forte diminution des performances lorsqu'ils atteignent un certain seuil de charge.
La sélection et la publication d'un SLO définissent les attentes des utilisateurs quant au fonctionnement du service. Cette stratégie peut réduire les plaintes infondées contre le propriétaire du service, telles que des performances lentes. Sans SLO explicite, les utilisateurs créent souvent leurs propres attentes concernant les performances souhaitées, qui peuvent n'avoir rien à voir avec les opinions des personnes qui conçoivent et gèrent le service. Cette situation peut conduire à des attentes exagérées à l'égard du service, lorsque les utilisateurs croient à tort que le service sera plus accessible qu'il ne l'est en réalité, et susciter une méfiance lorsque les utilisateurs pensent que le système est moins fiable qu'il ne l'est en réalité.
Accord
Un accord de niveau de service est un contrat explicite ou implicite avec vos utilisateurs qui inclut les conséquences du respect (ou du non-respect) des SLO qu'ils contiennent. Les conséquences sont plus facilement identifiables lorsqu’elles sont financières – une remise ou une amende – mais elles peuvent prendre d’autres formes. Un moyen simple de parler de la différence entre les SLO et les SLA est de se demander « que se passe-t-il si les SLO ne sont pas respectés ? S’il n’y a pas de conséquences claires, il s’agit presque certainement d’un SLO.
Le SRE n'est généralement pas impliqué dans la création des SLA, car ceux-ci sont étroitement liés aux décisions commerciales et relatives aux produits. Le SRE contribue toutefois à atténuer les conséquences de l’échec des SLO. Ils peuvent également aider à déterminer le SLI : Évidemment, il doit y avoir un moyen objectif de mesurer le SLO dans l’accord, sinon il y aura un désaccord.
La recherche Google est un exemple de service important qui ne dispose pas de SLA 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. Cependant, l'indisponibilité de la recherche a toujours des conséquences : l'indisponibilité entraîne une baisse de notre réputation ainsi qu'une réduction des revenus publicitaires. De nombreux autres services Google, tels que Google for Work, disposent d'accords de niveau de service explicites avec les utilisateurs. Qu'un service particulier dispose ou non d'un SLA, il est important de définir le SLI et le SLO et de les utiliser pour gérer le service.
Tant de théorie - maintenant à l'expérience.
Les indicateurs en pratique
Étant donné que nous avons conclu qu'il est important de sélectionner des mesures appropriées pour mesurer le niveau de service, comment savoir maintenant quelles mesures sont importantes pour un service ou un système ?
Qu’est-ce qui vous intéresse, vous et vos utilisateurs ?
Vous n'avez pas besoin d'utiliser chaque métrique comme SLI que vous pouvez suivre dans un système de surveillance ; Comprendre ce que les utilisateurs attendent d'un système vous aidera à sélectionner plusieurs métriques. Choisir trop d’indicateurs rend difficile la concentration sur les indicateurs importants, tandis qu’en choisir un petit nombre peut laisser de grandes parties de votre système sans surveillance. Nous utilisons généralement plusieurs indicateurs clés pour évaluer et comprendre la santé d’un système.
Les services peuvent généralement être décomposés en plusieurs parties en termes de SLI qui leur sont pertinentes :
- Des systèmes frontaux personnalisés, tels que les interfaces de recherche du service Shakespeare de notre exemple. Ils doivent être disponibles, sans retard et disposer d’une bande passante suffisante. Dès lors, des questions peuvent être posées : peut-on 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. Ils apprécient la faible latence de réponse, la disponibilité et la durabilité. Questions connexes : combien de temps faut-il pour lire ou écrire des données ? Pouvons-nous accéder aux données sur 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 écrivez pour une discussion détaillée de ces problèmes.
- Les systèmes Big Data tels que les pipelines de traitement de données reposent sur le débit et la latence du traitement des requêtes. Questions connexes : Quelle quantité de données est traitée ? Combien de temps faut-il pour que les données transitent entre la réception d’une demande et l’émission d’une réponse ? (Certaines parties du système peuvent également présenter des retards à certaines étapes.)
Collecte d'indicateurs
De nombreux indicateurs de niveau de service sont collectés le plus naturellement côté serveur, à l'aide d'un système de surveillance tel que Borgmon (voir ci-dessous). ) ou Prometheus, ou simplement en analysant périodiquement les journaux, en identifiant les réponses HTTP avec le statut 500. Cependant, 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 utilisateurs, mais n’affectent pas les métriques côté serveur. Par exemple, se concentrer sur la latence de réponse du backend de notre application de test de recherche Shakespeare peut entraîner une latence du côté utilisateur en raison de problèmes JavaScript : dans ce cas, mesurer le temps nécessaire au navigateur pour traiter la page est une meilleure mesure.
Agrégation
Pour des raisons de simplicité et de facilité d'utilisation, nous regroupons souvent les mesures brutes. Cela doit être fait avec soin.
Certaines mesures semblent simples, comme les requêtes par seconde, mais même cette mesure apparemment simple agrège implicitement les données au fil du temps. La mesure est-elle reçue spécifiquement une fois par seconde ou la mesure est-elle calculée en moyenne sur le nombre de requêtes par minute ? Cette dernière option peut masquer un nombre instantané de requêtes beaucoup plus élevé qui ne durent que quelques secondes. Considérons 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 la charge instantanée ne sont pas la même chose. De même, la moyenne des latences des requêtes peut sembler intéressante, mais elle cache un détail important : il est possible que la plupart des requêtes soient rapides, mais de nombreuses requêtes seront lentes.
La plupart des indicateurs sont mieux considérés comme des distributions plutôt que des moyennes. Par exemple, pour la latence SLI, certaines requêtes seront traitées rapidement, tandis que d’autres prendront toujours plus de temps, parfois beaucoup plus. Une simple moyenne peut masquer ces longs délais. La figure montre un exemple : bien qu'une requête typique prenne environ 50 ms pour être traitée, 5 % des requêtes 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 requêtes (ligne la plus haute).
Latence du système de 50, 85, 95 et 99 centiles. L'axe Y est au format logarithmique.
L'utilisation de percentiles pour les indicateurs vous permet de voir la forme de la distribution et ses caractéristiques : un niveau de percentile élevé, tel que 99 ou 99,9, montre la pire valeur, tandis que le 50 percentile (également appelé médiane) montre l'état de la métrique. Plus la dispersion des temps de réponse est grande, plus les requêtes de longue durée ont un impact sur l'expérience utilisateur. L'effet est renforcé sous une charge élevée et en présence de files d'attente. Les recherches sur l'expérience utilisateur ont montré que les utilisateurs préfèrent généralement un système plus lent avec une variance de temps de réponse élevée. C'est pourquoi certaines équipes SRE se concentrent uniquement sur les scores centiles élevés, en partant du principe que si le comportement d'une métrique au centile 99,9 est bon, la plupart des utilisateurs ne rencontreront pas de problèmes. .
Remarque sur les erreurs statistiques
Nous préférons généralement travailler avec des percentiles plutôt qu’avec la moyenne (moyenne arithmétique) d’un ensemble de valeurs. Cela nous permet de considérer des valeurs plus dispersées, qui présentent souvent des caractéristiques sensiblement 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 faussées, par exemple, aucune requête ne peut recevoir de réponse en moins de 0 ms, et un délai d'attente de 1000 XNUMX ms signifie qu'il ne peut pas y avoir de réponses réussies avec des valeurs supérieures. que le délai d'attente. Par conséquent, nous ne pouvons pas accepter que la moyenne et la médiane puissent être identiques ou proches l’une de l’autre !
Sans tests préalables, et à moins que certaines hypothèses et approximations standards soient vérifiées, nous veillons à ne pas conclure que nos données sont normalement distribuées. Si la distribution ne se déroule pas comme prévu, le processus d'automatisation qui résout le problème (par exemple, lorsqu'il détecte des valeurs aberrantes, il redémarre le serveur avec des latences de traitement des requêtes élevées) peut le faire trop souvent ou pas assez souvent (ces deux cas ne sont pas corrects). très bien).
Standardiser les indicateurs
Nous vous recommandons de normaliser les caractéristiques générales du SLI afin que vous n'ayez pas à spéculer à leur sujet à chaque fois. Toute fonctionnalité qui satisfait aux modèles standards 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 de prise des mesures : « Toutes les 10 secondes »
- Quelles requêtes sont incluses : « HTTP GET à partir des tâches de surveillance de la boîte noire »
- Comment les données sont obtenues : "Grâce à notre surveillance mesurée sur le serveur"
- Latence d'accès aux données : « Délai jusqu'au dernier octet »
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 certain SLI.
Objectifs en pratique
Commencez par réfléchir (ou découvrir !) à ce qui intéresse vos utilisateurs, et non à ce que vous pouvez mesurer. Souvent, ce qui intéresse vos utilisateurs est difficile, voire impossible, à mesurer, vous finissez donc par vous rapprocher de leurs besoins. Cependant, si vous commencez simplement par ce qui est facile à mesurer, vous vous retrouverez avec des SLO moins utiles. En conséquence, nous avons parfois constaté qu’il était plus efficace d’identifier initialement les objectifs souhaités, puis de travailler avec des indicateurs spécifiques, que de choisir des indicateurs puis d’atteindre les objectifs.
Définir des objectifs
Pour un maximum de clarté, il convient de définir la manière dont les SLO sont mesurés et les conditions dans lesquelles ils sont valables. Par exemple, nous pourrions dire ce qui suit (la deuxième ligne est la même que la première, mais utilise les valeurs par défaut du SLI) :
- 99 % (en moyenne sur 1 minute) des appels Get RPC se termineront en moins de 100 ms (mesuré sur tous les serveurs backend).
- 99 % des appels Get RPC se termineront en moins de 100 ms.
Si la forme des courbes de performances est importante, vous pouvez spécifier plusieurs SLO :
- 90 % des appels Get RPC terminés en moins de 1 ms.
- 99 % des appels Get RPC terminés en moins de 10 ms.
- 99.9 % des appels Get RPC terminés en moins de 100 ms.
Si vos utilisateurs génèrent des charges de travail hétérogènes : traitement de masse (pour lequel le débit est important) et traitement interactif (pour lequel la latence est importante), il peut être intéressant de définir des objectifs distincts pour chaque classe de charge :
- 95 % des demandes des clients nécessitent du débit. Définissez le nombre d’appels RPC exécutés <1 s.
- 99 % des clients se soucient de la latence. Définissez le nombre d'appels RPC avec un trafic <1 Ko et une exécution <10 ms.
Il n'est ni réaliste ni souhaitable d'insister sur le fait que les SLO seront respectés à 100 % du temps : cela peut réduire le rythme d'introduction et de déploiement de nouvelles fonctionnalités et nécessiter des solutions coûteuses. Au lieu de cela, il est préférable d'autoriser un budget d'erreur - le pourcentage de temps d'arrêt du système autorisé - et de surveiller cette valeur quotidiennement ou hebdomadairement. La haute direction peut souhaiter des évaluations mensuelles ou trimestrielles. (Le budget d'erreur est simplement un SLO à comparer avec un autre SLO.)
Le pourcentage de violations de SLO peut être comparé au bilan d'erreurs (voir chapitre 3 et section ), la valeur de différence étant utilisée comme entrée dans le processus qui décide du moment de déployer les nouvelles versions.
Sélection des valeurs cibles
La sélection des valeurs de planification (SLO) n'est pas une activité purement technique en raison des intérêts produits et commerciaux qui doivent être reflétés dans les SLI, SLO (et éventuellement SLA) sélectionnés. De même, il peut être nécessaire d'échanger des informations sur les questions liées au personnel, aux délais de commercialisation, à la disponibilité des équipements et au financement. Le SRE devrait faire partie de cette conversation et aider à comprendre les risques et la viabilité des différentes options. Nous avons proposé quelques questions qui pourraient contribuer à garantir une discussion plus productive :
Ne choisissez pas un objectif basé sur les performances actuelles.
S’il est important de comprendre les forces et les limites d’un système, adapter les mesures sans raisonner peut vous empêcher de maintenir le système : cela nécessitera des efforts héroïques pour atteindre des objectifs qui ne peuvent être atteints sans une refonte significative.
Rester simple
Les calculs SLI complexes peuvent masquer les changements dans les performances du système et rendre plus difficile la recherche de la cause du problème.
Évitez les absolus
Bien qu’il soit tentant de disposer d’un système capable de gérer une charge indéfiniment croissante sans augmenter la latence, cette exigence est irréaliste. Un système qui se rapproche de tels idéaux nécessitera probablement beaucoup de temps pour être conçu et construit, sera coûteux à exploiter et sera trop performant pour les attentes des utilisateurs qui feraient avec moins.
Utilisez le moins de SLO possible
Sélectionnez un nombre suffisant de SLO pour garantir une bonne couverture des attributs du système. Protégez les SLO que vous choisissez : si vous ne parvenez jamais à gagner un débat sur les priorités en spécifiant un SLO spécifique, cela ne vaut probablement pas la peine d'envisager ce SLO. Cependant, tous les attributs du système ne se prêtent pas aux SLO : il est difficile de calculer le niveau de satisfaction des utilisateurs à l'aide des SLO.
Ne recherchez pas la perfection
Vous pouvez toujours affiner les définitions et les objectifs des SLO au fil du temps, à mesure que vous en apprenez davantage sur le comportement du système sous charge. Il est préférable de commencer avec un objectif flottant que vous affinerez au fil du temps plutôt que de choisir un objectif trop strict qu'il faudra assouplir lorsque vous estimez qu'il est inaccessible.
Les SLO peuvent et doivent être un facteur clé dans la priorisation du travail des SRE et des développeurs de produits, car ils reflètent une préoccupation pour les utilisateurs. Un bon SLO est un outil d’application utile pour une équipe de développement. Mais un SLO mal conçu peut conduire à un gaspillage de travail 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 faible. Le SLO est un levier puissant, utilisez-le à bon escient.
Contrôlez vos mesures
SLI et SLO sont des éléments clés utilisés pour gérer les systèmes :
- Surveiller et mesurer les systèmes SLI.
- Comparez SLI à SLO et décidez si une action est nécessaire.
- Si une action est nécessaire, déterminez ce qui doit se produire pour atteindre l’objectif.
- Terminez cette action.
Par exemple, si l'étape 2 montre que la requête expire et rompra le SLO dans quelques heures si rien n'est fait, l'étape 3 peut impliquer de tester l'hypothèse selon laquelle les serveurs sont liés au processeur et l'ajout de serveurs supplémentaires répartira la charge. Sans SLO, vous ne sauriez pas si (ni quand) agir.
Définir le SLO - les attentes des utilisateurs seront alors définies
La publication d'un SLO définit les attentes des utilisateurs concernant le comportement du système. Les utilisateurs (et les utilisateurs potentiels) veulent souvent savoir à quoi s'attendre d'un service pour comprendre s'il est adapté à son utilisation. Par exemple, les personnes souhaitant utiliser un site Web de partage de photos voudront peut-être éviter d’utiliser un service qui promet longévité et faible coût en échange d’une disponibilité légèrement moindre, même si le même service peut être idéal pour un système de gestion d’archives.
Pour définir des attentes réalistes pour vos utilisateurs, utilisez l’une ou les deux tactiques suivantes :
- Conservez une marge de sécurité. Utilisez un SLO interne plus strict que celui annoncé aux utilisateurs. Cela vous donnera la possibilité de réagir aux problèmes avant qu’ils ne deviennent visibles de l’extérieur. Le tampon SLO vous permet également de disposer d'une marge de sécurité lors de l'installation de versions qui affectent les performances du système et de garantir que le système est facile à maintenir sans avoir à frustrer les utilisateurs avec des temps d'arrêt.
- Ne dépassez pas les attentes des utilisateurs. Les utilisateurs se basent sur ce que vous proposez et non sur ce que vous dites. Si les performances réelles de votre service sont bien meilleures que le SLO indiqué, les utilisateurs se fieront aux performances actuelles. Vous pouvez éviter une dépendance excessive en arrêtant intentionnellement le système ou en limitant les performances sous des charges légères.
Comprendre dans quelle mesure un système répond aux attentes permet de décider s'il convient d'investir pour accélérer le système et le rendre plus accessible et plus résilient. Alternativement, si un service fonctionne trop bien, une partie du temps du personnel devrait être consacrée à d'autres priorités, comme rembourser la dette technique, ajouter de nouvelles fonctionnalités ou introduire de nouveaux produits.
Les accords en pratique
La création d'un SLA nécessite que les équipes commerciales et juridiques définissent les conséquences et les sanctions en cas de violation de celui-ci. Le rôle du SRE est de les aider à comprendre les défis probables liés au respect des SLO contenus dans le SLA. La plupart des recommandations pour la création de SLO s'appliquent également aux SLA. Il est sage d'être prudent dans ce que vous promettez aux utilisateurs, car plus vous en avez, plus il est difficile de modifier ou de supprimer les SLA qui semblent déraisonnables ou difficiles à respecter.
Merci d'avoir lu la traduction jusqu'au bout. Abonnez-vous à ma chaîne de télégrammes sur la surveillance и .
Source: habr.com