Dans un environnement cloud, sur quoi alertez-vous et qu'est-ce que vous vous contentez de journaliser ?

Alertez sur des symptômes qu'un client remarquerait et sur lesquels un humain peut agir tout de suite, en général liés à vos objectifs de service : taux d'erreur élevé, latence qui dépasse la cible, file qui grossit sans limite, sauvegarde en échec. Journalisez et mettez en tableau de bord tout le reste, y compris les métriques de ressource comme le CPU, utiles au diagnostic mais mauvaises comme déclencheurs. Si la réponse à une alerte est d'acquitter et de se rendormir, ça devrait être un ticket.

Ma barre tient en trois points : un client est affecté ou sur le point de l'être, c'est urgent, et il y a quelque chose qu'un humain peut faire tout de suite. Si l'un des trois est faux, c'est un ticket ou un tableau de bord. Donc un taux d'erreur au-dessus de l'objectif, une latence qui dépasse la cible, une file qui grossit sans limite, le paiement qui échoue, ça bipe. Un CPU à quatre-vingts pour cent, non, parce que ça peut être parfaitement sain et ça ne me dit rien sur le fait que quelqu'un souffre ; sa place est sur un tableau de bord pour quand je diagnostique. Alerter sur les causes plutôt que sur les symptômes, c'est comme ça qu'on finit avec quarante alertes pour un seul incident et une équipe qui a coupé le canal. Il y a des exceptions que je garde toujours : l'expiration de certificat, parce que c'est masqué jusqu'à ce que ce soit catastrophique, les échecs de sauvegarde, et les limites de quota dur qui approchent, puisque ces trois-là sont silencieux jusqu'à la seconde où ils vous ruinent la semaine. Et je relis les alertes régulièrement, en regardant ce qui s'est déclenché et ce que quelqu'un en a réellement fait. Tout ce qui se déclenche souvent sans jamais mener à une action est supprimé ou déclassé, parce qu'un bipeur bruyant est pire que pas de bipeur du tout.