Concevoir un tableau de bord d'exploitation : une question par panneau, un écran par public

Objectif

Construire un tableau de bord qu'une personne appelée en pleine nuit peut lire en moins d'une minute et qui répond à un ensemble fixe de questions, plutôt qu'un mur affichant toutes les métriques exportées par le service.

Prérequis

Une source de métriques aux noms et étiquettes cohérents, la liste des alertes qui pointeront vers le tableau de bord, et un public nommé (personne d'astreinte, responsable du service, planificateur de capacité). Le guide de bonnes pratiques de Grafana énonce la règle que suit cette méthode : un tableau de bord doit raconter une histoire ou répondre à une question, et s'il n'a pas d'objectif, il n'est peut-être pas nécessaire. Le livre SRE dit la même chose des tableaux de bord en général : ils doivent répondre à des questions de base sur le service.

Étapes

1. Écrire les questions, dans l'ordre où une personne d'astreinte se les pose : le service atteint-il son objectif en ce moment ? Le problème vient-il du trafic, des erreurs ou de la latence ? Quelle dépendance ou quelle instance est concernée ? Qu'est-ce qui a changé récemment ?
2. Affecter exactement un panneau par question et titrer le panneau avec le sujet de la question (« Taux d'erreur, 30 dernières minutes », pas « http_requests_total »). Supprimer tout panneau sans question associée.
3. Ordonner de haut en bas, du général au particulier, comme le suggère le guide Grafana : les signaux d'objectif et orientés utilisateur en premier, les lignes par dépendance et par instance en dessous, l'utilisation des ressources en dernier.
4. Normaliser : la même plage temporelle sur chaque panneau, des pourcentages plutôt que des comptes bruts lorsque les machines diffèrent en taille, des unités de base avec des axes qui en tiennent compte, des seuils colorés selon leur signification.
5. Remplacer les copies par des variables de modèle pour l'environnement, le cluster et l'instance, afin qu'un seul tableau de bord serve à tous ; le guide désigne cette pratique comme le moyen d'éviter la prolifération.
6. Ajouter un repère de déploiement ou de changement pour que « ce qui a changé » reste visible sans quitter la page.
7. Relier chaque alerte à ce tableau de bord avec les variables pré-remplies, et relier les panneaux au tableau de bord d'approfondissement ou à la recherche de traces.
8. Conserver le JSON du tableau de bord sous contrôle de version et le revoir après chaque incident : n'ajouter un panneau que pour une question réellement posée, supprimer les panneaux que personne n'utilise.

Résultat attendu

Un écran par public avec une poignée de panneaux, chacun répondant à une question, accessible depuis l'alerte qui a poussé la personne d'astreinte à l'ouvrir.

Limites et base de vérification

Il s'agit d'un protocole de création, pas d'une comparaison mesurée ; la question de savoir si moins de panneaux raccourcit le diagnostic est formulée séparément comme une hypothèse. Les tableaux de bord ne peuvent pas remplacer les alertes (personne ne les surveille en continu) et affichent des agrégats qui peuvent masquer une instance défaillante isolée, sauf s'il existe un panneau par instance.