Le sens de la décision

Un serveur sain peut masquer du travail client bloqué. Surveillez le résultat attendu en plus des erreurs techniques. Pour chaque circuit important, définissez déclenchement, états intermédiaires durables et preuve de fin. Leur écart explique parfois ce qu'un compteur d'erreurs ignore.

Rôles et alternatives

Commencez par des signaux exploitables. Disponibilité et délai décrivent l'application ; ancienneté du travail en attente, échecs de finalisation et absence inhabituelle d'événements décrivent le processus. Google SRE distingue symptômes et causes. Priorisez les symptômes visibles puis investiguez techniquement, sans alerter sur chaque ligne isolée.

Parcourir le changement

Un formulaire fictif enregistre la demande et prépare une notification. Le site réussit, mais le processus de courrier s'arrête. Suivez l'âge du plus ancien message non envoyé. L'alerte doit nommer la file, expliquer l'inspection sûre et la reprise. Le rétablissement exige livraison du travail en attente sans perte ni duplication de demande.

Vérifier les échecs

Un tableau calme peut signifier aucune demande, une collecte cassée ou une entrée bloquée. Distinguez-les. Évitez les alertes sans responsable ou action et les messages personnels dans leur contenu. Arrêtez localement un worker ou simulez une dépendance défaillante pour vérifier alerte et retour à la normale.

Donner à chaque alerte une réponse praticable

Décrivez le travail client retardé plutôt qu'un seul nom de processus. Incluez file, ancienneté maximale, heure d'observation et accès sûr à l'inspection. Excluez les messages personnels. L'intervenant doit distinguer worker arrêté et dépendance de courrier défaillante sans recevoir tous les détails clients.

Définissez les actions sûres. Le guide vérifie santé, dernier échec nettoyé et travail réservé ou terminé. Il précise reprise, récupération d'une réservation expirée et escalade. Tout répéter aveuglément peut dupliquer un effet externe déjà terminé dont la réponse s'est perdue. En cas d'ambiguïté, consignez puis rapprochez, sans inventer un succès net.

Testez la chaîne dans un environnement contrôlé : arrêtez le worker, créez une demande fictive et observez l'attente. Vérifiez réception locale, rétablissez et confirmez achèvement et retour normal. Testez aussi le collecteur : l'absence de mesures ne doit pas paraître saine. Après incident, retirez doublons, clarifiez responsables et améliorez le premier diagnostic. Ne masquez pas un symptôme devenu familier.

Liste de revue opérationnelle

QuestionPreuve utile
Absence de travail ou de mesure ?La dernière observation réussie apparaît séparément du nombre en attente.
L'alerte a-t-elle un responsable ?Un rôle connaît délai, inspection et escalade.
La reprise est-elle complète ?Le travail atteint son état métier ; redémarrer seul ne clôt pas l'incident.
La reprise peut-elle répéter un effet ?Le guide vérifie les preuves et traite l'ambiguïté externe comme rapprochement, pas échec automatique.

Convenir de ces règles

Que signifie réussir ce circuit ? Combien de temps peut-il attendre ? Qui reçoit l'alerte et que peut-il faire sûrement ? La revue doit produire une carte d'exploitation concise plutôt que des métriques inutilisées.

Sources et lectures complémentaires

  1. Google SRE — Monitoring distributed systems
Services

Logiciel sur mesure

Un logiciel adapté à votre façon de travailler.

Parlons de ce service