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 6 sur la surveillance des systèmes distribués du livre Google Site Reliability Engineering . 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 blog sur le Medium, j'ai également publié un lien vers la traduction du 4ème chapitre du même livre sur les objectifs du niveau de service.

Traduction par chat. Bonne lecture!

Les équipes Google SRE ont les principes de base et les meilleures pratiques pour créer des systèmes de surveillance et de notification efficaces. Ce chapitre fournit des recommandations sur les problèmes qu'un visiteur de page Web peut rencontrer et comment résoudre les problèmes qui rendent les pages Web difficiles à afficher.

Définitions

Il n'y a pas de vocabulaire unique utilisé pour discuter des sujets liés à la surveillance. Même chez Google, les termes ci-dessous ne sont pas couramment utilisés, mais nous énumérerons les interprétations les plus courantes.

Suivi

Collecte, traitement, agrégation et affichage de données quantitatives en temps réel sur le système: nombre de demandes et types de demandes, nombre d'erreurs et types d'erreurs, temps de traitement des demandes et disponibilité du serveur.

Surveillance en boîte blanche

Surveillance basée sur les métriques affichées par les composants internes du système, y compris les journaux, les métriques de profilage de la machine virtuelle Java ou le gestionnaire HTTP qui génère des statistiques internes.

Surveillance de la boîte noire

Tester le comportement de l'application du point de vue de l'utilisateur.

Tableau de bord (tableaux de bord)

Une interface (généralement le Web) qui donne un aperçu des principaux indicateurs de santé pour les services. Le tableau de bord peut avoir des filtres, la possibilité de sélectionner des indicateurs à afficher, etc. L'interface est créée pour identifier les indicateurs les plus importants pour les utilisateurs. Les informations destinées au personnel d'assistance technique peuvent également être affichées sur le tableau de bord: file d'attente des demandes, liste des erreurs hautement prioritaires, ingénieur affecté pour un domaine de responsabilité donné.

Alerte (avis)

Notifications destinées à être reçues par une personne par e-mail ou d'une autre manière, pouvant être déclenchées à la suite d'erreurs ou d'une augmentation de la file d'attente de demandes. Les notifications sont classées comme: tickets, alertes e-mail et messages de messagerie.

Cause profonde

Un défaut logiciel ou un facteur humain qui ne devrait pas se reproduire une fois éliminé. Le problème peut avoir plusieurs raisons principales: automatisation insuffisante des processus, défaut logiciel, étude insuffisante de la logique de l'application. Chacun de ces facteurs peut être la cause profonde et chacun doit être éliminé.

Noeud et machine

Termes interchangeables pour désigner une seule instance d'une application en cours d'exécution sur un serveur physique, une machine virtuelle ou un conteneur. Il peut y avoir plusieurs services sur une même machine. Les services peuvent être:

• liés les uns aux autres: par exemple, un serveur de cache et un serveur Web;
• des services indépendants sur un seul matériel: par exemple, un référentiel de code et un assistant pour un système de configuration, comme Puppet ou Chef .

Poussez

Toute modification de la configuration logicielle.

Pourquoi la surveillance est nécessaire

Il existe plusieurs raisons pour lesquelles les applications doivent être surveillées:

Analyse des tendances longues

Quelle est la taille de la base de données et à quelle vitesse croît-elle? Comment évolue le nombre quotidien d'utilisateurs?

Comparaison des performances

Les requêtes Acme Bucket of Bytes 2,72 sont-elles plus rapides que Ajax DB 3.14? Dans quelle mesure les demandes sont-elles mises en cache après l'apparition d'un nœud supplémentaire? Le site est-il devenu plus lent que la semaine dernière?

Alertes (notifications)

Quelque chose est cassé et quelqu'un doit le réparer. Ou quelque chose va bientôt se casser et quelqu'un devrait le vérifier bientôt.

Créer des tableaux de bord

Les tableaux de bord doivent répondre aux questions de base et inclure certains des «4 signaux d'or» - latence, trafic, erreurs et charge (saturation).

Réalisation d'une analyse rétrospective (débogage)

Le délai de traitement des demandes a augmenté et que s'est-il passé d'autre à la même époque?
Les systèmes de surveillance sont utiles comme source de données pour les systèmes de Business Intelligence et pour simplifier l'analyse des incidents de sécurité. Étant donné que ce livre se concentre sur les domaines d'ingénierie dans lesquels les SRE ont une expertise, nous ne discuterons pas ici des techniques de surveillance.

La surveillance et les alertes permettent au système de savoir s'il est en panne ou sur le point de se briser. Lorsque le système ne peut pas se récupérer automatiquement, nous voulons que l'alerte soit analysée par la personne, déterminée si le problème est pertinent, corrigé et déterminé sa cause première. Si vous n'auditez pas les composants du système, vous ne recevrez jamais d'alerte simplement parce que «quelque chose semble un peu étrange».

La charge des alertes humaines est une utilisation assez coûteuse du temps des employés. Si un employé travaille, une alerte interrompt le flux de travail. Si l'employé est à la maison, la notification interrompt le temps personnel et, éventuellement, le sommeil. Lorsque les alertes se produisent trop souvent, les employés analysent, retardent ou ignorent rapidement les alertes entrantes. De temps en temps, ils ignorent la véritable alerte, masquée par les événements sonores. Les interruptions de service peuvent durer longtemps, car les événements sonores interfèrent avec un diagnostic et un dépannage rapides. Les systèmes d'avertissement efficaces ont un bon rapport signal / bruit.

Définir les attentes raisonnables d'un système de surveillance

La mise en place de la surveillance d'une application complexe est en soi une tâche d'ingénierie difficile. Même avec une infrastructure importante d'outils de collecte, d'affichage et d'alerte, l'équipe Google SRE de 10 à 12 membres comprend généralement une ou deux personnes dont le but principal est de créer et de maintenir des systèmes de surveillance. Ce montant a diminué au fil du temps à mesure que nous généralisons et centralisons l'infrastructure de surveillance, mais chaque équipe SRE a généralement au moins un personnel de surveillance. Je dois dire que bien qu'il soit assez intéressant de regarder les tableaux de bord du système de surveillance, les équipes SRE évitent soigneusement les situations qui obligent quelqu'un à regarder l'écran pour surveiller les problèmes.

En général, Google est passé à des systèmes de surveillance simples et rapides avec des outils optimaux pour l'analyse post-factum. Nous évitons les systèmes «magiques» qui tentent de prédire des seuils ou de détecter automatiquement la cause première. Les capteurs qui détectent le contenu inapproprié dans les demandes des utilisateurs finaux sont les seuls contre-exemples; tant que ces capteurs restent simples, ils permettent d'identifier rapidement les causes d'anomalies graves. D'autres formats d'utilisation des données de surveillance, tels que la planification de la capacité ou les prévisions de trafic, sont plus difficiles. Une observation menée sur une très longue période (mois ou années) avec un faible taux d'échantillonnage (heures ou jours) révélera une tendance à long terme.

L'équipe Google SRE a travaillé avec un succès variable avec des hiérarchies de dépendances complexes. Nous utilisons rarement des règles telles que "si je découvre que la base de données a commencé à fonctionner lentement, je reçois une notification indiquant que la base de données ralentit, sinon je reçois une alerte concernant un site à fonctionnement lent". Les règles basées sur les dépendances s'appliquent généralement aux parties invariables de notre système, comme un système de filtrage du trafic utilisateur vers un centre de données. Par exemple, «si le filtrage du trafic vers le centre de données est configuré, ne m'avertissez pas des retards dans le traitement des demandes des utilisateurs» - il s'agit d'une règle générale pour les notifications du centre de données. Peu d'équipes chez Google prennent en charge les hiérarchies de dépendances complexes, car notre infrastructure a un taux de refactoring continu et constant.

Certaines des idées décrites dans ce chapitre sont toujours pertinentes: il est toujours possible de passer plus rapidement d'un symptôme à une cause profonde, en particulier dans des systèmes en constante évolution. Par conséquent, bien que ce chapitre détaille certains objectifs des systèmes de surveillance et les moyens d'atteindre ces objectifs, il est important que les systèmes de surveillance soient simples et compréhensibles pour tous les membres de l'équipe.

De même, afin de maintenir un niveau de bruit faible et un niveau de signal élevé, les approches de surveillance des objets pour lesquels des alertes sont effectuées devraient être très simples et fiables. Les règles qui génèrent des avertissements pour les personnes doivent être faciles à comprendre et présenter un problème clair.

Symptômes vs causes

Votre système de surveillance devrait répondre à deux questions: «ce qui a cassé» et «pourquoi s'est cassé».
«Ce qui est brisé» parle du symptôme et «pourquoi il est brisé» de la cause. Le tableau ci-dessous montre des exemples de tels bundles.

«Quoi» et «pourquoi» sont quelques-uns des éléments de construction les plus importants pour créer un bon système de surveillance avec un signal maximum et un bruit minimum.

Black-box vs White-box

Nous combinons une surveillance étendue de la boîte blanche avec une surveillance modeste de la boîte noire pour les mesures critiques. La façon la plus simple de comparer la Black-box avec la White-box est que la Black-box est orientée sur les symptômes et est une surveillance réactive plutôt que proactive: "le système ne fonctionne pas en ce moment". La boîte blanche dépend des capacités de vérification interne du système: journaux d'événements ou serveurs Web. Ainsi, la White-box vous permet de détecter des problèmes futurs, des dysfonctionnements qui ressemblent à une retransmission d'une demande, etc.

Veuillez noter que dans un système multicouche, un symptôme dans le domaine de responsabilité d'un ingénieur est un symptôme dans le domaine de responsabilité d'un autre ingénieur. Par exemple, les performances de la base de données ont diminué. Les lectures de bases de données lentes sont un symptôme pour les SRE sur les bases de données qui les détectent. Cependant, pour le SRE frontal, qui observe un site Web lent, la raison de la même lecture lente de la base de données est le lent fonctionnement de la base de données. Par conséquent, la surveillance en boîte blanche est parfois centrée sur les symptômes, et parfois sur les raisons, selon son étendue.

Lors de la collecte de la télémétrie, une surveillance en boîte blanche est requise pour le débogage. Si les serveurs Web répondent lentement aux requêtes de base de données, vous devez savoir à quelle vitesse le serveur Web interagit avec la base de données et à quelle vitesse il répond. Sinon, vous ne pouvez pas distinguer un serveur de base de données lent d'un problème de réseau entre le serveur Web et la base de données.

La surveillance de la boîte noire présente un avantage clé lors de l'envoi d'alertes: vous lancez une notification au destinataire lorsque le problème a déjà conduit à de vrais symptômes. En revanche, pour un problème de boîte noire qui n'est pas encore apparu, mais qui est imminent, la surveillance est inutile.

Quatre signaux dorés

Les quatre signaux de surveillance dorés sont la latence, le trafic, les erreurs et la saturation. Si vous ne pouvez mesurer que quatre mesures dans un système utilisateur, concentrez-vous sur ces quatre.

Retard

Le temps requis pour traiter la demande. Il est important de distinguer le retard des demandes réussies et des demandes infructueuses. Par exemple, une erreur HTTP 500 provoquée par une perte de connexion à une base de données ou à un autre serveur principal peut être diagnostiquée très rapidement, cependant, une erreur HTTP 500 peut indiquer une demande ayant échoué. L'identification de l'effet de l'erreur 500 sur le retard global peut conduire à des conclusions erronées. D'un autre côté, une erreur lente est même une erreur rapide! Par conséquent, il est important de suivre le retard avec une erreur, et pas seulement de filtrer les erreurs.

Trafic

Le nombre de demandes adressées à votre système est mesuré par des métriques système de haut niveau. Pour un service Web, cette dimension représente généralement le nombre de requêtes HTTP par seconde, séparé par la nature de la requête (par exemple, le contenu statique ou dynamique). Pour un système audio en streaming, cette mesure peut être concentrée sur la vitesse d'E / S du réseau ou le nombre de sessions simultanées. Pour un système de stockage de valeurs-clés, une telle mesure peut être des transactions ou des résultats de recherche par seconde.

Erreurs

Il s'agit de la fréquence des demandes infructueuses qui sont explicitement (par exemple, HTTP 500), implicitement (par exemple, HTTP 200, mais en combinaison avec le mauvais contenu), ou une stratégie (par exemple, "Si vous avez enregistré la réponse en une seconde, une seconde est une erreur"). Si les codes de réponse du protocole HTTP sont insuffisants pour exprimer toutes les conditions de défaillance, des protocoles secondaires (internes) peuvent être nécessaires pour détecter une défaillance partielle. La surveillance de toutes ces demandes erronées peut ne pas être informative, tandis que les tests système de bout en bout vous aideront à découvrir que vous traitez le mauvais contenu.

Saturation

La mesure indique le niveau d'utilisation de votre service. Il s'agit d'une mesure de surveillance du système qui identifie les ressources les plus limitées (par exemple, dans un système avec une mémoire limitée, elle affiche la mémoire, dans un système avec des limitations d'E / S, le nombre d'E / S est affiché). Notez que de nombreux systèmes dégradent les performances avant d'atteindre 100% d'utilisation, il est donc important d'avoir un but d'utilisation.

Dans les systèmes complexes, la saturation peut être complétée en mesurant la charge d'un niveau supérieur: votre service peut-il gérer correctement le trafic double, traiter seulement 10% de trafic en plus ou traiter encore moins de trafic qu'il ne le fait actuellement? Pour les services simples qui n'ont pas de paramètres qui modifient la complexité de la demande (par exemple, «Ne me donnez rien» ou «J'ai besoin d'un seul entier monotone unique») qui changent rarement leur configuration, la valeur statique du test de charge peut être adéquate. Cependant, comment discuté dans le paragraphe précédent, la plupart des services devraient utiliser des signaux indirects, tels que l'utilisation du processeur ou la bande passante du réseau, qui ont une limite supérieure connue. Une latence accrue est souvent un indicateur principal de saturation. La mesure du temps de réponse du 99e centile dans une petite fenêtre (par exemple, une minute) peut donner un signal de saturation très précoce.

Enfin, la saturation est également associée à des prédictions de saturation imminente, par exemple: "Il semble que votre base de données remplisse votre disque dur en 4 heures."

Si vous mesurez les quatre signaux dorés et lorsqu'un problème survient avec l'une des métriques (ou, en cas de saturation, presque un problème), prévenez la personne, votre service sera plus ou moins surveillé.

Anxiété à propos de la queue (ou de l'instrumentation et des performances)

Lors de la création d'un système de surveillance à partir de zéro, il est tentant de développer un système basé sur des valeurs moyennes: latence moyenne, utilisation moyenne du processeur des nœuds ou occupation moyenne de la base de données. Le danger des deux derniers exemples est évident: les processeurs et les bases de données sont éliminés de manière très imprévisible. Il en va de même pour le retard. Si vous exécutez un service Web avec un délai moyen de 100 ms à 1 000 requêtes par seconde, 1% des requêtes peuvent prendre 5 secondes. Si les utilisateurs dépendent de plusieurs de ces services Web, le 99e centile d'un backend peut facilement devenir le temps de réponse médian de l'interface.

La manière la plus simple de faire la distinction entre une moyenne lente et une «queue» très lente de requêtes est de collecter les dimensions des requêtes exprimées en statistiques (un outil approprié pour afficher les histogrammes) plutôt que les retards réels: combien de requêtes ont été traitées par le service, qui ont pris entre 0 ms et 10 ms, entre 10 ms et 30 ms, entre 30 ms et 100 ms, entre 100 ms et 300 ms, etc. L'élargissement approximativement exponentiel des bordures de l'histogramme (avec un coefficient approximatif de 3) est souvent un moyen simple de visualiser la distribution des requêtes.

Choisir le bon niveau de détail pour les mesures

Différents éléments du système doivent être mesurés avec différents degrés de détail. Par exemple:

• La surveillance de l'utilisation de la charge du processeur à un intervalle de temps spécifique n'affichera pas de valeurs aberrantes à long terme entraînant des latences élevées.
• En revanche, pour un service Web qui se concentre sur pas plus de 9 heures d'indisponibilité par an (99,9% du temps de fonctionnement annuel), la vérification d'une réponse HTTP de 200 plus d'une ou deux fois par minute sera probablement inutilement fréquente.
• De même, la vérification de l'espace libre sur le disque dur pour une disponibilité de 99,9% plus d'une fois toutes les 1-2 minutes n'est probablement pas nécessaire.

Prenez soin de structurer la granularité des dimensions. La fréquence de collecte de la charge CPU une fois par seconde peut fournir des données intéressantes, mais ces mesures fréquentes peuvent être très coûteuses à collecter, à stocker et à analyser.Si l'objectif de surveillance nécessite une granularité élevée et ne nécessite pas un taux de réaction élevé, vous pouvez réduire ces coûts en configurant la collecte de métriques sur le serveur, puis en configurant un système externe pour collecter et agréger ces métriques. Vous pourriez:

1. Mesurez l'utilisation du processeur à chaque seconde.
2. Découpez les détails à 5%.
3. Statistiques agrégées toutes les minutes.

Cette stratégie permettra de collecter des données avec une granularité élevée sans subir de surcharge d'analyse et de stockage élevée.

Aussi simple que possible, mais pas plus facile

S'imposer des exigences différentes peut conduire à un système de surveillance très complexe. Par exemple, votre système peut comporter les éléments de complication suivants:

• Alertes selon différentes valeurs de seuil pour le retard dans le traitement des demandes, dans différents percentiles, pour toutes sortes d'indicateurs différents.
• Écriture de code supplémentaire pour détecter et identifier les causes possibles.
• Créez des tableaux de bord associés pour chacune des causes possibles de problèmes.

Les sources de complications potentielles ne cessent jamais. Comme tous les systèmes logiciels, la surveillance peut devenir si compliquée qu'elle devient fragile et difficile à modifier et à maintenir.

Par conséquent, concevez votre système de surveillance afin de le simplifier au maximum. Lorsque vous choisissez ce que vous souhaitez suivre, n'oubliez pas les points suivants:

• Les règles qui détectent le plus souvent des incidents réels doivent être aussi simples, prévisibles et fiables que possible.
• Les configurations de collecte de données, d'agrégation et d'alertes rarement effectuées (par exemple, moins d'une fois par trimestre pour certaines commandes SRE) doivent être supprimées.
• , , - - , .

Chez Google, la collecte et l'agrégation de base des indicateurs, combinées avec des alertes et des tableaux de bord, fonctionnent bien comme un système relativement autonome (En fait, le système de surveillance de Google est divisé en plusieurs sous-systèmes, mais généralement les gens connaissent tous les aspects de ces sous-systèmes). Il peut être tentant de combiner la surveillance avec d'autres méthodes de vérification de systèmes complexes: profilage système détaillé, débogage de processus, suivi des détails sur les exceptions ou les pannes, test de charge, collecte et analyse des journaux ou vérification du trafic. Bien que la plupart de ces éléments aient des caractéristiques communes avec la surveillance de base, leur mélange entraînera trop de résultats pour créer un système complexe et fragile. Comme pour de nombreux autres aspects du développement logiciel, la prise en charge de divers systèmes est claire, simple,Les points d'intégration faiblement couplés constituent une meilleure stratégie (par exemple, utiliser une API Web pour récupérer des données récapitulatives dans un format qui peut rester constant pendant une longue période).

Relier les principes entre eux

Les principes abordés dans ce chapitre peuvent être intégrés dans une philosophie de surveillance et d'alerte approuvée et respectée par les équipes de Google SRE. L'adhésion à cette philosophie de surveillance est souhaitable, c'est un bon point de départ pour créer ou réviser une méthodologie d'alerte et peut aider à poser les bonnes questions au service d'exploitation, quelle que soit la taille de votre organisation ou la complexité du service ou du système.

Lorsque vous créez des règles de surveillance et d'alerte en posant les questions suivantes, vous pouvez éviter les faux positifs et les alertes inutiles:

• Cette règle détecte-t-elle un état autrement indétectable du système qui est urgent, appelant à l'action et affectant inévitablement l'utilisateur?
• , , ? ?
• , ? , , , - , ?
• ? ? ? ?
• , ?

Ces questions reflètent la philosophie fondamentale des alertes et des systèmes d'alerte:

• Chaque fois qu'une alerte arrive, je dois répondre d'urgence. Je peux réagir d'urgence plusieurs fois par jour avant de me fatiguer.
• Chaque alerte doit être pertinente.
• Chaque réponse à une alerte doit nécessiter une intervention humaine. Si l'alerte peut être traitée automatiquement, elle ne devrait pas arriver.
• Les alertes doivent concerner un nouveau problème ou événement qui n'existait pas auparavant.

Cette approche efface certaines différences: si la notification remplit les quatre conditions précédentes, peu importe que la notification soit envoyée par le système de surveillance de la boîte blanche ou la boîte noire. Cette approche renforce également certaines différences: il vaut mieux consacrer beaucoup plus d'efforts à l'identification des symptômes qu'aux causes; en ce qui concerne les raisons, vous n'avez qu'à vous soucier des raisons inévitables.

Surveillance à long terme

Dans les environnements productifs d'aujourd'hui, les systèmes de surveillance suivent un système productif en constante évolution avec une architecture logicielle, des caractéristiques de charge et des performances cibles en constante évolution. Les alertes qui sont actuellement difficiles à automatiser peuvent devenir fréquentes, peut-être même dignes d'être résolues. À ce stade, quelqu'un devrait trouver et éliminer les causes profondes du problème; si une telle autorisation n'est pas possible, la réponse à la notification nécessite une automatisation complète.

Il est important que les décisions de suivi soient prises en tenant compte des objectifs à long terme. Chaque avertissement qui est émis aujourd'hui dissuade une personne d'améliorer le système demain, il y a donc souvent une diminution de la disponibilité ou de la productivité d'un système productif par le temps nécessaire pour améliorer le système de surveillance à long terme. Regardons deux exemples illustrant ce phénomène.

Bigtable SRE: historique des alertes

L'infrastructure interne de Google est généralement fournie et mesurée en termes de niveau de service (SLO). Il y a de nombreuses années, le service SLO de Bigtable était basé sur les performances moyennes d'une transaction synthétique simulant un client fonctionnel. En raison de problèmes dans Bigtable et à des niveaux inférieurs de la pile de stockage de données, les performances moyennes étaient dues à la «grande» queue: les 5% des demandes les plus défavorables étaient souvent beaucoup plus lentes que les autres.

Des notifications par e-mail ont été envoyées à l'approche du seuil de SLO et des alertes ont été envoyées au messager lorsque le SLO a été dépassé. Les deux types d'alertes ont été envoyés assez souvent, ce qui a nécessité un temps d'ingénierie inacceptable: l'équipe a passé beaucoup de temps à analyser les alertes pour en trouver quelques-unes qui étaient vraiment pertinentes. Nous avons souvent manqué un problème qui affectait réellement les utilisateurs, car seules certaines des alertes concernaient spécifiquement ce problème. De nombreuses alertes n'étaient pas urgentes en raison de problèmes compréhensibles dans l'infrastructure et ont fonctionné de manière standard, ou n'ont pas été traitées du tout.

Pour remédier à la situation, l'équipe a adopté une approche en trois volets: tout en faisant de grands efforts pour améliorer les performances de Bigtable, nous avons temporairement fixé le 75e centile comme objectif SLO pour retarder la réponse à la demande. Nous avons également désactivé les alertes par e-mail, car elles étaient si nombreuses qu'il était impossible de passer du temps à les diagnostiquer.

Cette stratégie nous a permis de prendre une pause pour commencer à résoudre les problèmes à long terme dans Bigtable et les niveaux inférieurs de la pile de stockage de données, plutôt que de résoudre constamment les problèmes tactiques. Les ingénieurs pouvaient en fait faire le travail lorsqu'ils n'étaient pas constamment attaqués par des alertes. Au final, le retard temporaire dans le traitement des notifications nous a permis d'améliorer la qualité de service.

Gmail: réponses algorithmiques prévisibles de la part des utilisateurs

Au tout début, Gmail était basé sur un système de contrôle de processus Workqueue modifié, qui a été créé pour traiter par lots des fragments d'index de recherche. Workqueue a été adapté à des processus de longue durée, puis appliqué à Gmail, mais certaines erreurs dans le code du planificateur opaque se sont révélées très difficiles à corriger.

À cette époque, la surveillance de Gmail était structurée de telle manière que des alertes étaient déclenchées lorsque des tâches individuelles étaient annulées à l'aide de Workqueue. Cette approche n'était pas idéale, car même à cette époque, Gmail effectuait plusieurs milliers de tâches, chacune étant fournie à des fractions d'un pour cent de nos utilisateurs. Nous nous sommes assurés que les utilisateurs de Gmail avaient une bonne interface utilisateur, mais il était impossible de trouver autant d'alertes.

Pour résoudre ce problème, Gmail SRE a créé un outil qui a aidé à déboguer le planificateur le mieux possible afin de minimiser l'impact sur les utilisateurs. L'équipe a eu plusieurs discussions pour savoir s'il était juste nécessaire d'automatiser tout le cycle de la détection d'un problème à sa résolution jusqu'à ce qu'une solution à long terme soit trouvée, mais certains d'entre eux craignaient qu'une telle solution ne retarde la véritable correction du problème.

Cette tension était courante dans l'équipe et reflétait souvent un manque de confiance dans l'autodiscipline: alors que certains membres de l'équipe veulent donner du temps pour une correction correcte, d'autres craignent que la correction finale soit oubliée et que la correction temporaire dure pour toujours. Ce problème mérite notre attention, car il est trop facile de résoudre temporairement les problèmes, plutôt que d'avoir à régler la situation sur une base continue. Les gestionnaires et le personnel technique jouent un rôle clé dans la mise en œuvre de correctifs à long terme, en soutenant et en priorisant les correctifs potentiellement à long terme, même lorsque la «douleur» initiale disparaît.

Les alertes récurrentes régulières et les réponses algorithmisées devraient être un drapeau rouge. La réticence de votre équipe à automatiser de telles alertes signifie que l’équipe n’est pas certaine de pouvoir faire confiance aux algorithmes. Il s'agit d'un grave problème qui doit être résolu.

À long terme

Un thème commun relie les exemples Bigtable et Gmail: la concurrence entre la disponibilité à court terme et à long terme. Souvent, un effort important peut aider un système fragile à atteindre une haute disponibilité, mais ce chemin est généralement de courte durée, chargé d'épuisement professionnel et de dépendance à l'égard d'un petit nombre de membres de cette équipe très héroïque.

Une diminution contrôlée et à court terme de la disponibilité est souvent une tâche douloureuse mais stratégiquement importante pour la stabilité à long terme du système. Il est important de ne pas considérer chaque alerte de manière isolée, mais de déterminer si le niveau global d'alertes conduit à un système sain et accessible avec une équipe viable et un pronostic favorable. Nous analysons les statistiques de la fréquence des alertes (généralement exprimées en incidents de quart de travail, lorsqu'un incident peut se composer de plusieurs incidents liés) dans des rapports trimestriels avec la direction, ce qui permet aux décideurs de représenter en permanence la charge du système d'alerte et l'état général de l'équipe.

Conclusion

La voie vers une surveillance et des alertes saines est simple et directe. Il se concentre sur les symptômes du problème pour lesquels des alertes sont émises et la surveillance de la cause sert d'aide au débogage des problèmes. La surveillance des symptômes est d'autant plus facile que vous vous trouvez sur la pile que vous contrôlez, bien que la surveillance de la charge et des performances de la base de données doive être effectuée directement sur celle-ci. Les notifications par e-mail ont des avantages très limités et ont tendance à se transformer facilement en bruit; à la place, vous devez utiliser un tableau de bord qui surveille tous les problèmes actuels qui sont envoyés par courrier électronique. Le tableau de bord peut également être associé à un journal des événements pour analyser les corrélations historiques.

À long terme, il est nécessaire de parvenir à une alternance réussie d'alertes sur les symptômes et les problèmes réels inévitables, d'adapter les objectifs pour garantir que le suivi permet un diagnostic rapide.

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 .