Wie wir die Zahl der Benachrichtigungen um 95,7 % reduziert und die Alert-Fatigue verbessert haben

Problemhintergrund: Kritische und Warning-Alert-Kanäle wurden getrennt und für kritische Alerts wurde die telefonische Benachrichtigung eingeführt. Durch die Explosion von mehr als 10.000 Warning-Alerts pro Monat kam es jedoch dazu, dass Alerts ignoriert wurden und die Belastung im On-call zunahm.

Zentrale Erkenntnis: Zu viele Alerts degradieren zu einem Messenger-Health-Checker und beeinträchtigen die Sichtbarkeit des Systems. Als zentrale Kennzahl zur Reduzierung von Alerts wurde vorgeschlagen, mit Slack-Emojis (👀, ✅) die „Alert-Reaktionsrate“ zu messen.

Lösungsprozess:

Alerts, deren ursprüngliche Konfigurationsabsicht nicht mehr zur aktuellen Umgebung passte (z. B. nicht passende Schwellwerte für die Erhöhung von EBS-Volumes), wurden angepasst oder gelöscht.

Bedeutungslose Alerts, bei denen die Absicht früherer Bearbeiter nicht nachvollziehbar war, wurden konsequent entfernt.

Zusätzlicher Erfolg: Nachdem das Alert-Rauschen beseitigt war, wurde entdeckt, dass die hohe iowait auf einem bestimmten Server durch eine im Verhältnis zur tatsächlichen Workload zu groß konfigurierte ZFS recordsize verursacht wurde, und dies wurde normalisiert.

Ergebnis: 95,7 % weniger Warning-Alerts (10.553 pro Monat → 453). Mehr als 70 % weniger kritische Telefonbenachrichtigungen in der Nacht und an Feiertagen. Schlafmangel im On-call wurde behoben und die tatsächliche Systemverfügbarkeit und -sichtbarkeit wurden verbessert.

[darjeeling]

Für Logs, Metriken und Alarme braucht es eine Praxis regelmäßiger Anpassungen.

[roxie]

Der Nickname kam mir irgendwie bekannt vor — das ist wohl die Person, die früher schon einen unterhaltsamen Beitrag über die Ausgabe von cron geschrieben hat. Diesen Artikel habe ich auch gerne gelesen :D

[computerphilosopher]

Danke, es freut mich, dass Sie den Artikel mit Interesse gelesen haben.