Superviser un SaaS : détecter les incidents avant les utilisateurs

Partir du service rendu plutôt que du nombre de graphiques

Choisissez quelques parcours essentiels : se connecter, importer des données, consulter un dossier ou obtenir un rapport. Pour chacun, définissez ce qui constitue une réussite et où la constater. Une requête acceptée peut seulement signifier qu’un travail a été mis en file ; elle ne démontre pas que le client a reçu son résultat.

Un SLO, ou objectif de niveau de service, fixe un niveau visé sur un indicateur et une période. Il doit être relié à l’usage et rester mesurable. Un objectif interne n’est pas automatiquement un engagement contractuel. Décrivez les exclusions et la population observée. Un service globalement disponible peut rester inutilisable pour un seul client si sa file ou son connecteur est bloqué.

Cette observabilité doit rester orientée vers les questions de l’équipe : où le parcours échoue, quel client est concerné et quelle action a modifié le comportement. Elle se construit à partir de ces besoins de diagnostic.

Combiner métriques, journaux et traces

Les métriques montrent des volumes, taux et distributions au fil du temps. Les journaux décrivent des événements et leur contexte. Les traces relient les étapes d’une opération à travers plusieurs composants. OpenTelemetry documente ces signaux et leurs usages ; leur collecte doit servir une question de diagnostic, plutôt qu’une accumulation de données.

Attribuez un identifiant de corrélation aux opérations importantes et propagez-le aux traitements asynchrones. Une erreur d’import doit pouvoir être reliée au travail concerné, à sa version et au service qui l’a refusé. Évitez de copier systématiquement les documents, mots de passe ou clés dans les traces. Définissez les accès, la durée de conservation et la manière d’examiner un incident sans exposer inutilement les contenus clients.

Pour approfondir : OpenTelemetry — signaux de télémétrie

Choisir des mesures qui montrent l’expérience réelle

Le chapitre de Google consacré au monitoring présente notamment latence, trafic, erreurs et saturation comme signaux essentiels. Adaptez-les au service : demandes reçues, résultats produits, délais et ressources proches de leurs limites. Ajoutez des mesures métier, comme l’âge du plus ancien travail en attente ou la proportion de rapports consultables après génération.

Les moyennes peuvent masquer les cas lents. Examinez des percentiles et la distribution, avec les effectifs correspondants. Un p95 indique un seuil sous lequel se trouvent environ 95 % des observations selon la méthode de calcul ; il ne décrit pas les cas au-delà. Avec peu de requêtes, les variations peuvent être fortes. Une file qui grossit régulièrement mérite une attention même lorsque le processeur paraît peu occupé.

Pour approfondir : Google SRE — monitoring des systèmes distribués

Déclencher une alerte qui permet d’agir

Une alerte urgente doit signaler une situation qui exige une action dans un délai court. Les anomalies à examiner plus tard peuvent alimenter un ticket ou une revue. Si chaque variation mineure réveille l’équipe, les signaux importants risquent de devenir difficiles à reconnaître.

Associez à l’alerte un impact compréhensible, un responsable, un lien vers les observations utiles et une première procédure de diagnostic. Les seuils dépendent du service et de son trafic ; un pourcentage calculé sur deux requêtes mérite une lecture différente de celui calculé sur un grand volume. Vérifiez également que la surveillance elle-même fonctionne. L’absence de données peut être un problème de collecte, et non la preuve d’une absence d’erreur.

Préparer la réponse et le retour au service

Une procédure courte précise les vérifications initiales, les opérations autorisées et les conditions de retour arrière. Identifiez qui coordonne, qui intervient et qui informe les personnes concernées. Une petite équipe peut cumuler les rôles, mais doit savoir qui prend la décision pendant l’incident.

Conservez une chronologie : changement observé, hypothèse, action, effet et vérification. Évitez de multiplier les modifications simultanées sans trace, au risque de ne plus comprendre ce qui rétablit le service. Après correction, vérifiez les travaux en attente, les données partielles et les clients encore affectés. Le retour d’une métrique à la normale n’efface pas automatiquement les effets produits pendant l’interruption.

Limiter le coût et apprendre des incidents

La télémétrie consomme du stockage, du calcul et du temps de lecture. Choisissez les détails utiles, limitez la cardinalité des dimensions et prévoyez une stratégie d’échantillonnage lorsque nécessaire. Un identifiant unique par requête convient à une trace, mais peut rendre certaines séries de métriques très coûteuses. Conservez assez d’informations pour les incidents importants tout en documentant ce que l’échantillonnage peut manquer.

Après un incident, identifiez une amélioration vérifiable : un signal absent, un contrôle de déploiement ou une procédure de reprise. Testez ensuite une panne représentative dans un environnement adapté. La valeur du dispositif se mesure à sa capacité à détecter, expliquer et résoudre un problème réel, pas au nombre de tableaux de bord installés.