Méthode CASE : surveillance sans cruauté

Dziiiiin! Il est 3 heures du matin, vous faites un rêve merveilleux et soudain, un appel retentit. Vous êtes de service cette semaine et apparemment quelque chose s'est passé. Le système automatisé appelle pour savoir ce qui ne va pas. Il s'agit d'un aspect important de la gestion des systèmes informatiques modernes, mais voyons comment améliorer les notifications pour les utilisateurs.

Familiarisez-vous avec la philosophie du monitoring, née au cours de plusieurs décennies de mes fonctions au sein de différentes équipes de monitoring. Elle a été largement influencée par la vraie bible de Rob Evashchuk Ma philosophie sur l'alerte (Ma philosophie de notification) inclus dans le livre sur Google SRE, et livre de John Alspaugh Considérations relatives à la conception des alertes (Remarques sur la configuration des alertes).

Kelly Dunn, Arijit Mukheryi и Maxime Petazzoni — merci pour votre aide dans la modification du message.

Qu’est-ce que CASE ?

J'ai décidé de trouver une belle abréviation comme La méthode USE de Brendan Gregg ou La méthode RED de Tom Wilkie. je l'appelle Méthode CAS. Il décrit quatre points auxquels il faut prêter attention lorsque l'on travaille avec la surveillance automatique :

• Clourd en texte (lié au contexte)
• Aexploitable (valeur pratique)
• Sbasé sur des symptômes (accent mis sur les symptômes)
• Evalorisé (grade)

Si vous utilisez CASE, vous traitez les notifications avec une saine indifférence et ne réveillez pas les gens la nuit. L’utilité et l’efficacité du suivi doivent être régulièrement évaluées. Lorsqu’une personne reçoit la notification, elle aura de meilleurs modèles mentaux et plus de confiance.

Pour faciliter la mémorisation, imaginez que vous ayez besoin d'un CAS [c'est-à-dire un cas, une raison - note du traducteur] pour justifier chaque alerte. :des lunettes de soleil:

Et pourquoi tout cela ?

Être de service peut être pénible. Pour de nombreuses raisons. Et CASE ne les éliminera pas tous. Mais grâce à lui, vous vous réveillerez la nuit avec de meilleures notifications. Cette méthode couvre divers processus organisationnels qui seront également utiles dans ce domaine.

La beauté des méthodes RED et USE est qu'avec leur aide, nous savons non seulement travailler, mais aussi parler le même langage les uns avec les autres. J'espère que la méthode CASE facilitera la discussion des notifications qui protègent nos systèmes mais occupent nos collègues.

Le fait est que vous devez créer une culture dans votre organisation où les notifications sont traitées avec une saine indifférence. Les notifications peuvent être créées dans un but précis, mais ce n'est pas un fait qu'elles ne perdront pas de valeur plus tard. Pourquoi avons-nous mis en place cette notification ? Depuis combien de temps ses critères ont-ils été révisés ? Avec CASE, il est possible de répondre à ces questions.

Contexte-Heavy - liaison de contexte

3 heures du matin n'est pas le meilleur moment pour lire des messages contenant beaucoup de mots intelligents. Pour réagir efficacement, vous avez besoin d’informations. Idéalement, il devrait s'agir d'informations sur un problème spécifique, pour lequel le contexte est immédiatement clair, et les notifications devraient être configurées de manière à ce que cela soit possible. C'est "l'observation" et "l'orientation" de Boucle OODA. Ce n'est pas une honte de consacrer du temps à cette configuration, car distraire constamment une personne coûte encore plus cher. Respectons-nous les uns les autres.

Les problèmes ont de nombreuses sources. Surtout les fantômes.

Comment puis-je aider l'officier de service ? La première chose que voit l'officier de service est une notification, il construit donc toutes les hypothèses sur cette base. Ensuite, il regarde les instructions et les tableaux de bord, mais y a-t-il toujours des données sur une notification spécifique, et pas seulement des informations générales ? Alspaugh conseille de « réfléchir à la façon dont vous pourriez interpréter ou répondre à la notification » (diapositive 29)1. Une bonne notification se concentre sur la personne en service et ne se limite pas à un seuil.

Voici donc quelques idées pour améliorer le contexte de notification :

• Montrez à l'utilisateur quelque chose d'utile et spécialement créé, et pas seulement des instructions ordinaires ou un tableau de bord. Auparavant, les gars et moi utilisions des tableaux de bord d'enquête configurés pour des notifications spécifiques. Cela sera utile si le problème est connu, mais ne fera que dérouter les autres. Nous devons trouver un équilibre ici.
• Parlez-nous de l'historique de la notification : est-ce nouveau ? Est-ce que ça marche souvent ? Est-ce saisonnier ?
• Afficher les modifications récentes apportées à l'état du système. Est-ce que quelque chose a changé récemment ? (Par exemple, déploiement ou activation/désactivation d'une fonctionnalité.)
• Montrez les relations et fournissez des informations pour le modèle mental : les dépendances du système doivent être clairement visibles, de préférence avec une indication de fonctionnalité.
• Connectez rapidement l'utilisateur à l'équipe : peuvent-ils voir les incidents en cours ou peuvent-ils savoir qui d'autre dans l'entreprise a reçu une notification ? Programme la gestion des incidents activé ?

Idéalement, un programme de gestion des incidents fournira des conseils sur la manière d'améliorer le contexte de notification des enquêtes sur les incidents. Il y a toujours quelque chose à travailler !

Actionnable – valeur pratique

L'officier de service devrait-il faire quelque chose en réponse à la notification ? Si vous n’avez rien à faire ou si vous ne savez pas quoi faire, pourquoi l’avez-vous réveillé ? Vous devez éviter les notifications qui gênent les personnes en service et ne nécessitent aucune action.

Voir le post sur imgur.com

Que dois-je faire? Que veux-tu?

Dans le passé, lorsque les systèmes étaient simples et les équipes petites, nous mettions en place une surveillance uniquement pour rester au courant. La notification indiquant que la charge sur le tas a augmenté nous donnera un contexte en cas de dysfonctionnement ultérieur du service. À grande échelle, de telles notifications ne feront que créer de la confusion car nos systèmes fonctionnent toujours dans un état de dégradation plus ou moins grave. Cela conduit rapidement à fatigue des notifications et bien sûr à la perte de sensibilité. Par conséquent, l'agent de service ignore ou même filtre ces notifications et n'y répond pas toujours comme nécessaire. Ne tombez pas dans ce piège ! Ne configurez pas toutes les notifications à la suite, puis envoyez-les par e-mail dans un dossier perdu.

Voici à quoi ressemble un avis ayant une valeur pratique :

• Une notification nécessite une action plutôt que de simplement rapporter des nouvelles.
• Cette action est difficile ou risquée à automatiser. Si une action peut être automatisée, alors automatisez-la, arrêtez de harceler les gens !
• L'avis contient des recommandations urgentes sous la forme Accords de Niveau de Service (SLA) ou objectif de temps de récupération (RTO). L'agent de service peut alors activer le programme de gestion des incidents de l'organisation.

Je tiens à clarifier : je ne dis pas que les notifications ne doivent arriver que pour les SLO (objectifs de niveau de service) les plus importants pour l'API. La surveillance des SLO est constamment fragmentée et divisée et nécessite la même approche pour tous les services. Il est clair que vous suivrez les SLO les plus importants pour les clients qui vous paient. Mais les SLO d’infrastructure, tels que les bases de données, doivent également être surveillés. Bientôt, vous devrez traiter avec des clients internes et les accompagner. Et ainsi de suite à l’infini.

Basé sur les symptômes – accent mis sur les symptômes

Que cela vous plaise ou non, vous travaillez dans un système distribué (Kavaj)2. En conséquence, vous utilisez différentes tactiques pour isoler les services et les protéger des pannes (Trainor et al.)3. Et même si un garbage collection retardé ou une requête de base de données bloquée indique des problèmes, il n'est pas nécessaire de se précipiter pour les résoudre si les utilisateurs n'ont pas de problèmes dans un avenir proche.

Ce sont des signaux importants et peuvent avoir une valeur pratique, mais s'ils ne dérangent pas les utilisateurs, ils ne sont pas suffisamment urgents pour distraire l'opérateur. Les notifications basées sur la cause sont des instantanés de nos modèles mentaux concernant une panne du système. Il est préférable de suivre les symptômes importants plutôt que d’essayer de lister toutes les causes possibles d’une panne.

Pour rendre les notifications significatives, concentrez-vous sur des indicateurs de performance, important pour les utilisateurs. Evashchuk appelle cela « la surveillance des utilisateurs ». N'oubliez pas que cette philosophie doit être appliquée dans toute l'organisation. Si un service rencontre des problèmes urgents quelque part au cœur de l’infrastructure, l’équipe appropriée s’en chargera. Protéger les systèmes contre de telles pannes est une tout autre affaire (Trainer et al., section sur les stratégies pour minimiser les dépendances critiques)3.

Les symptômes ne sont pas aussi variables

Richard Cook nous rappelle que les systèmes complexes regorgent de défauts, de lacunes et de problèmes4. Essayer d’énumérer toutes les raisons possibles est une tâche de Sisyphe. Vous essayez de décrire les problèmes, mais ils changent tout le temps. Cindy Sridharan estime que « les systèmes ne doivent pas nécessairement être en parfait état à chaque seconde » et qu'il est préférable d'utiliser une approche plus humaine ("Observabilité des systèmes distribués" (« Surveillance des systèmes distribués »), 7)5.

Évitez les notifications après un incident

En règle générale, les notifications de causes sont configurées pour corriger les incidents. Et ces notifications limitées sur ce qui s'est passé créent un faux sentiment de sécurité, car le système propose à chaque fois de nouvelles façons de s'introduire.

Ne vous laissez pas berner par les avis de cause. Mieux vaut penser :

• Pourquoi la notification basée sur les symptômes n'a-t-elle pas détecté le problème ?
• Serait-il utile d'améliorer le contexte pour l'utilisateur ?
• Comment améliorer les outils de surveillance pour établir un diagnostic plus rapidement, plutôt que d’accumuler des notifications sur ce qui s’est passé ?

Les outils de surveillance pour le diagnostic ne seront utiles que si vous les considérez comme un moyen de passer du symptôme à la solution. Sans ces commentaires, vous serez simplement bombardé de notifications tardives et de graphiques sur les échecs passés, et pas un mot sur les échecs futurs. Il s’agit d’une excellente opportunité pour une organisation de passer de la défense à l’attaque. Et les développeurs et chefs de produit auront les mêmes attentes et les mêmes objectifs clairs. Le cas - CASE (:wink:) - est clair pour chaque notification.

Les notifications basées sur un motif sont tolérables avec modération

Parfois, notre système nous laisse peu de choix en termes de notifications basées sur une cause. Et parfois, les personnes de service comprennent parfaitement qu'un symptôme conduira certainement à un échec et qu'il contient donc une valeur pratique. Peut-être que vous n'êtes tout simplement pas sûr de ce qui se passe et que vous configurez des notifications par mesure de sécurité. Espérons que cette action soit temporaire jusqu'à ce que nous puissions modifier le système pour résoudre le problème de performances.
Gardez les autres composants de CASE à l’esprit lorsque vous faites face à ces situations. Ce n’est pas parce que c’est temporaire que vous pouvez arrêter de penser avec votre tête.

Évalué - évaluation

Toute modification apportée au système (nouveau code, nouvelle infrastructure, tout ce qui est nouveau) élargit la gamme de pannes (Cook, 3).4 Cette notification fonctionne-t-elle toujours comme prévu ? Modèles mentaux clairs et actuels des systèmes et expérience en réponse à certaines notifications d'assistance approche préventive - ce sont les principales caractéristiques organisation axée sur l'apprentissage. Les défauts des systèmes évoluent constamment et nous devons les suivre.

Vous devez constamment évaluer la qualité de chaque notification pour vous assurer qu’elle fonctionne comme prévu. Chers dirigeants ! Ce sera beaucoup plus simple pour vos équipes si vous les aidez à mettre en place cette démarche ! Voici quelques idées d’évaluation :

• utilisation ingénierie du chaos, jours de match ou d'autres méthodes de test de notification. L’équipe peut le faire elle-même sans avoir à s’appuyer sur un lourd système de gestion des incidents !
• Intégrez la collecte de toutes les notifications liées aux incidents dans votre programme de gestion des incidents. Marquez les éléments utiles, nuisibles, inappropriés, peu clairs, etc. Utilisez-les comme commentaires.
• Les bonnes notifications sont rarement déclenchées et sont soigneusement testées. Assurez-vous que tous les liens fonctionnent, pointent vers le bon contexte, etc.
• Si une notification ne se déclenche jamais ou se déclenche trop souvent, il y a un problème. Réparez-le ou supprimez-le. Attention à la passivité ou à l'activité excessive !
• Définissez des horodatages de notification avec des dates d'expiration. Si la date d'expiration a expiré, évaluez la notification à l'aide de la méthode CASE et mettez à jour l'horodatage. Tout comme pour les aliments, vérifiez régulièrement la date de péremption.
• Simplifiez le processus d’amélioration des notifications. Utilisez la surveillance sous forme de code et stockez les notifications dans un référentiel Git. Les demandes de tirage aident à impliquer l'équipe et vous donnent un historique des notifications passées. Et vous n'aurez plus peur de modifier les notifications ou de demander l'autorisation aux responsables.
• Configurez des commentaires pour les notifications, même si c'est simple Formulaire Google, de sorte que les agents de service marquent les notifications comme inutiles ou intrusives. Intégrez un lien ou un appel à l'action dans la notification elle-même et consultez régulièrement vos commentaires.
• Établissez une règle dans l'équipe : laissez les personnes de service travailler pour simplifier le travail lorsqu'il y a peu de travail. Que tout après vous soit un peu meilleur qu'avant.

Conclusion

Je pense que la méthode CASE aide les développeurs et les organisations à discuter de la configuration et de l'envoi de notifications automatisées. Un développeur peut commencer à évaluer les notifications à l'aide de la méthode CASE, puis l'ensemble de l'organisation se joindra à d'autres développeurs, programmes de gestion et de gestion des incidents pour maintenir les notifications en bon état. Cela ne nécessite aucun outil spécial ni processus complexe.

L’ensemble du secteur doit penser au facteur humain lorsqu’il est en service sans sacrifier un service client de premier ordre. Tous ces outils et pratiques peuvent et doivent être améliorés. J'espère que la méthode CASE vous aidera.

Profitez de notifications améliorées !

Source: habr.com