Dziiiiiiin! À 3 heures du matin, vous regardez un rêve merveilleux, et tout à coup - une cloche. Cette semaine, vous êtes en service, et apparemment quelque chose s'est produit. Un système automatisé appelle pour comprendre quel est le problème. C'est un point important dans la gestion des systèmes informatiques modernes, mais voyons comment rendre les notifications plus pratiques pour les utilisateurs.
Familiarisez-vous avec la philosophie de surveillance qui est née au cours de plusieurs décennies de mes fonctions dans diverses équipes de surveillance. Elle a été influencée à bien des égards par la vraie bible de Rob Evashchuk My Philosophy on Alerting , incluse dans le livre Google SRE , et le livre de John Alspo, Considerations for Alert Design .
Kelly Dunn , Aridzhit Mukheryi et Maxim Petazzoni - merci pour l'aide apportée à l'édition du message.
Qu'est-ce qu'un CAS?
J'ai décidé de trouver un bel acronyme comme la méthode USE de Brendan Gregg ou la méthode RED de Tom Wilkie . J'appelle cela la méthode CASE . Il décrit quatre points auxquels vous devez faire attention lorsque vous travaillez avec la surveillance automatique:
Si vous utilisez CASE, vous traitez les notifications avec une indifférence saine et ne réveillez pas les gens la nuit. L'utilité et l'efficacité doivent être régulièrement évaluées. Lorsqu'une personne reçoit une notification, elle aura de meilleurs modèles mentaux et plus de confiance.
Pour faciliter la mémorisation, imaginez que vous avez besoin d'un CAS [c'est-à-dire un cas, la raison est un commentaire d'interprète ] pour justifier chaque alerte. : lunettes de soleil:
Et pourquoi c'est tout?
Le devoir peut être un tourment . Pour plusieurs raisons. Et CASE ne les éliminera pas tous. Mais avec lui la nuit, vous vous réveillerez de meilleures notifications. Cette méthode couvre divers processus organisationnels qui aideront également à cet égard.
La beauté des méthodes RED et USE est qu'avec leur aide, nous savons non seulement comment travailler, mais nous parlons également la même langue les uns avec les autres. J'espère qu'avec la méthode CASE, il sera plus facile de discuter des notifications qui protègent nos systèmes, mais ne donnent pas de repos aux collègues.
L'essentiel est que vous devez créer une culture dans l'organisation où les notifications sont traitées avec une saine indifférence. Des notifications peuvent être créées dans le cas, mais pas le fait qu'elles ne perdront pas de valeur plus tard. Pourquoi avons-nous mis en place cette notification? Ses critères ont-ils été révisés depuis longtemps? Avec CASE, il est possible de répondre à ces questions.
Context-Heavy - liaison de contexte
3 heures du matin n'est pas le meilleur moment pour lire des messages contenant beaucoup de mots à la mode. Pour répondre efficacement, vous avez besoin d'informations. Idéalement, il devrait s'agir d'informations sur un problème spécifique, sur lequel le contexte est immédiatement clair, et vous devez configurer les notifications afin que cela soit possible. Ce sont «l'observation» et l '«orientation» du cycle NORD . Ce n'est pas dommage de passer du temps sur ce paramètre, car distraire constamment une personne est encore plus cher. Respectons-nous les uns les autres.
Les problèmes ont de nombreuses sources. Surtout des fantômes.
Comment aider le préposé? L'officier de service voit la notification en premier, il construit donc toutes les hypothèses sur cette base. Il regarde ensuite les instructions et les tableaux de bord, mais y a-t-il toujours des informations sur un avis spécifique, et pas seulement des informations générales? Alspo conseille «de réfléchir à la manière d'interpréter la notification ou d'y répondre» (diapositive 29) 1 . Une bonne notification est concentrée sur l'opératrice, et pas seulement configurée sur une valeur de seuil.
Par conséquent, voici des idées pour améliorer le contexte de notification:
- Montrez à l'utilisateur quelque chose d'utile et créé spécifiquement, et pas seulement des instructions ordinaires ou un tableau de bord. Auparavant, les gars et moi utilisions des tableaux de bord pour enquêter, configurés pour des notifications spécifiques. Cela vous aidera si le problème est connu, et ne confondra que dans d'autres cas. Ici, vous devez trouver un équilibre.
- Parlez-nous de l'historique des notifications: est-ce nouveau? Ça marche souvent? Est-ce saisonnier?
- Afficher les modifications récentes de l'état du système. Quelque chose a-t-il changé récemment? (Par exemple, déployez ou activez / désactivez la fonctionnalité.)
- Montrer la relation et donner des informations pour le modèle mental: les dépendances du système doivent être clairement visibles, de préférence avec une indication d'opérabilité.
- Associez rapidement l'utilisateur à l'équipe: voit-il les incidents en cours ou peut-il savoir qui d'autre dans l'entreprise a reçu la notification? Le programme de gestion des incidents est-il activé?
Idéalement, un programme de gestion des incidents fournit des conseils sur la façon d'améliorer le contexte de notification lors de l'enquête sur les incidents. Il y a toujours quelque chose à travailler!
Action - valeur pratique
Le préposé doit-il faire quelque chose en réponse à la notification? Si vous n'avez rien à faire ou si vous ne savez pas quoi faire, pourquoi avez-vous été réveillé? Il est nécessaire d'éviter les notifications qui entrent en service et ne nécessitent aucune action.
Que faire? De quoi avez-vous besoin?
Auparavant, lorsque les systèmes étaient simples et que les équipes étaient petites, nous avons mis en place un suivi pour rester à jour. La notification que la charge sur le tas a augmenté nous donnera un contexte en cas de dysfonctionnement du service. À grande échelle, de telles notifications ne feront que semer la confusion, car nos systèmes fonctionnent toujours dans un état de dégradation de gravité variable. Cela conduit rapidement à la fatigue des notifications et, bien sûr, à une perte de sensibilité. Par conséquent, l'opératrice ignore ou même filtre ces notifications et n'y répond pas toujours selon les besoins. Ne tombez pas dans ce piège! Ne configurez pas toutes les notifications d'affilée, vous pouvez donc les envoyer par la suite dans un dossier pardonné.
Voici à quoi ressemble un avis de valeur pratique:
- Une notification nécessite une action, pas seulement de rapporter les nouvelles.
- Cette action est difficile ou risquée à automatiser. Si l'action peut être automatisée, alors prenez-la et automatisez, arrêtez de harceler les gens!
- L'avis contient des recommandations urgentes sous la forme d'un contrat de niveau de service (SLA) ou d' un délai de récupération cible (RTO). L'opératrice peut ensuite utiliser le programme de gestion des incidents dans l'organisation.
Je veux clarifier: je ne dis pas que les notifications ne devraient venir que sur les SLO les plus importants (objectifs de niveau de service, objectifs de niveau de service) pour l'API. La surveillance 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 infrastructures SLO, telles que les bases de données, doivent également être surveillées. Vous devrez bientôt traiter avec des clients internes et les soutenir. Et ainsi de suite à l'infini.
Basé sur les symptômes - se concentrer sur les symptômes
Que cela vous plaise ou non, vous travaillez dans un système distribué (Kavaj) 2 . Par conséquent, vous utilisez différentes tactiques pour isoler les services et les protéger contre les défaillances (Trainor et al.) 3. Et bien qu'une récupération de place prolongée ou une requête réfléchie dans la base de données indique des problèmes, il n'est pas nécessaire de se précipiter pour les résoudre si les utilisateurs n'ont aucun problème dans un proche avenir.
Ce sont des signaux importants, et ils peuvent avoir une valeur pratique, mais s'ils n'interfèrent pas avec les utilisateurs, alors ce n'est pas si urgent qu'ils distraient le préposé. Les notifications basées sur les causes sont des instantanés de nos modèles mentaux de défaillance du système. Il est préférable de garder une trace des symptômes importants plutôt que d'essayer de répertorier toutes les causes possibles d'un échec.
Pour que les notifications aient une valeur pratique, concentrez-vous sur les indicateurs de performance qui sont importants 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 le service a des problèmes urgents quelque part au fond de l'infrastructure, l'équipe appropriée s'en occupera. La protection des systèmes contre de telles défaillances est un problème complètement différent (Trainer et al., Une section sur les stratégies pour minimiser les dépendances critiques) 3 .
Les symptômes ne sont pas si volatils
Richard Cook rappelle que dans les systèmes complexes, il existe de nombreux défauts, lacunes et problèmes 4 . Essayer d'énumérer toutes les causes possibles - Travail sisyphéen. Vous essayez de décrire les problèmes, et ils changent tout le temps. Cindy Sridharan estime que «les systèmes ne doivent pas être en parfait état à chaque seconde» et il vaut mieux utiliser une approche plus humaine ( «Distributed Systems Observability» , 7) 5 .
Évitez les notifications d'incidents
En règle générale, les notifications pour des raisons sont configurées pour corriger les incidents. Et ces notifications limitées sur le fait de ce qui s'est passé créent un faux sentiment de confiance, car chaque fois que le système propose de nouvelles façons de briser.
Ne vous laissez pas berner par les notifications de raisons. Pensez mieux:
- Pourquoi la notification basée sur les symptômes n'a-t-elle pas remarqué le problème?
- Serait-il utile d'améliorer le contexte pour l'utilisateur?
- Comment améliorer les outils de surveillance afin de diagnostiquer plus rapidement et de ne pas accumuler de notifications sur ce qui s'est passé?
Les outils de surveillance pour le diagnostic ne seront utiles que si vous les prenez comme moyen de passer d'un symptôme à une solution. Sans ces commentaires, vous serez simplement submergé de notifications et de diagrammes tardifs sur les échecs passés - et pas un mot sur les échecs futurs. Pour une organisation, c'est une belle opportunité de passer de la défense à l'attaque. Et les développeurs et les chefs de produit auront les mêmes attentes et des objectifs clairs. Case - CASE (: wink :) - pour chaque notification est claire.
Notifications basées sur une tolérance modérée
Parfois, notre système ne nous laisse presque aucun choix en termes de notifications basées sur la raison. Et parfois, les assistants sont bien conscients qu'un symptôme entraînera nécessairement un dysfonctionnement, ce qui signifie qu'il contient 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 pour la réassurance. Espérons que cette action soit temporairement requise jusqu'à ce que nous modifiions le système pour résoudre le problème de dégradation des performances.
Soyez conscient des autres composants CASE lorsque vous faites face à de telles situations. Si c'est temporaire, cela ne signifie pas que vous ne pouvez pas penser avec votre tête.
Évalué - Évaluation
Tout changement dans le système (nouveau code, nouvelle infrastructure, quelque chose de nouveau) élargit la gamme des échecs (Cook, 3). 4 Cette notification fonctionne-t-elle toujours comme prévu? Des modèles de systèmes mentaux clairs et pertinents et une expérience de réponse à certaines notifications à l'appui d'une approche préventive sont les principales caractéristiques d'une 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 afin qu'elles fonctionnent comme prévu. Chers dirigeants! Ce sera beaucoup plus facile pour vos équipes si vous les aidez à mettre en place ce processus! Voici quelques idées pour évaluer:
- Utilisez l' ingénierie du chaos , les journées de jeu ou d'autres méthodes de test de notification. L'équipe peut le faire par elle-même sans utiliser un système de gestion des incidents lourds!
- Inclure la collecte de données sur toutes les notifications d'incidents dans le programme de gestion des incidents. Marquez utile, nuisible, inapproprié, incompréhensible, etc. Utilisez-les comme commentaires.
- Les notifications correctes sont peu fréquentes et soigneusement vérifiées. Assurez-vous que tous les liens fonctionnent, pointez sur le bon contexte, etc.
- Si la notification ne se déclenche jamais ou se déclenche trop souvent, quelque chose ne va pas. Réparez-le ou supprimez-le. Méfiez-vous d'une passivité ou d'une activité excessive!
- Définissez des horodatages d'expiration pour les notifications. Si la date d'expiration est passée, évaluez l'avis à l'aide de la méthode CASE et mettez à jour l'horodatage. Vérifiez régulièrement la date d'expiration, comme pour les aliments.
- Simplifiez le processus d'amélioration des notifications. Utilisez la surveillance sous forme de code et enregistrez les notifications dans le référentiel Git. Les demandes de pool aident à attirer une équipe et vous aurez un historique des notifications passées. Et vous cesserez d'avoir peur de modifier les notifications ou de demander la permission à ceux qui en sont responsables.
- Configurez les notifications de commentaires, même s'il ne s'agit que d'un formulaire Google , afin que les personnes en devoir déclarent les notifications inutiles ou intrusives. Intégrez un lien ou un appel à l'action dans la notification elle-même et vérifiez régulièrement les commentaires.
- Établissez une règle dans l'équipe - laissez les préposés travailler pour simplifier le travail lorsqu'il y a peu de travail. Laissez tout devenir un peu mieux après vous qu'avant.
Conclusion
Je crois que la méthode CASE aide les développeurs et les organisations à discuter de la configuration et de l'envoi de notifications automatiques. Un développeur peut commencer à évaluer les notifications à l'aide de la méthode CASE, puis l'ensemble de l'organisation le rejoindra avec d'autres développeurs, des programmes de gestion et de gestion des incidents pour maintenir les notifications en bon état. Aucun outil spécial ou processus complexe n'est nécessaire pour cela.
Toute l'industrie devrait penser au facteur humain pendant son service sans compromettre le service client de première classe. Tous ces outils et pratiques peuvent et doivent être améliorés. J'espère que la méthode CASE vous y aidera.
Profitez de notifications améliorées!
