Wie entscheidest du, worauf du bei einem Backend-Service alarmierst?

Alarmier auf Symptome, die Nutzer spüren, definiert als Service Level Objectives: Verfügbarkeit und Latenz am Rand gemessen, plus Korrektheitssignale wie fehlgeschlagene Zahlungen oder eine Queue, die nicht mehr abfließt. Ruf jemanden nur, wenn ein Objective in Gefahr ist, über die Burn Rate des Error Budgets, sodass ein langsames Abdriften ein Ticket erzeugt und ein schnelles Verbrennen jemanden weckt. Ursachenbasierte Alerts wie hohe CPU bleiben Dashboards, keine Pages.

Ich starte bei dem, was ein Nutzer merken würde: Requests scheitern, Requests sind langsam, und die fachlichen Dinge, die schlimmer sind als beides, etwa Bestellungen, die nicht bestätigt werden, oder ein Consumer Lag, der immer weiter steigt. Daraus werden Objectives mit einem Ziel, sagen wir 99,9 Prozent erfolgreiche Requests und ein 95. Perzentil unter dreihundert Millisekunden, gemessen am Load Balancer statt in der Anwendung, damit ich auch die Fehler zähle, die mein Code nie sieht. Die Alert-Schwere kommt dann aus der Burn Rate: das Monatsbudget in einer Stunde zu verbrennen weckt sofort, während ein langsames Verbrennen über Tage ein Ticket ist. Ursachenmetriken wie CPU, Speicher oder Disk bleiben auf Dashboards und in Kapazitätsalerts, denn eine ausgelastete CPU, die niemand spürt, ist kein Incident. Jede Page muss handlungsfähig sein, sie verlinkt also ein Runbook, und alles, was ohne Handlung gefeuert hat, wird überprüft. In einem Team haben wir das Pager-Volumen so um rund zwei Drittel gesenkt, und der eigentliche Gewinn war, dass die verbliebenen Alerts ernst genommen wurden.