Alerting - On-Call, PagerDuty, Escalation Policies
שבוע אחד ב-2021, ה-on-call engineer של חברת SaaS ישראלית קיבל 340 PagerDuty alerts. הוא ישן 4 שעות בלילה. ב-retrospective הוא אמר: "כבר לא קוראים לalerts בתשומת לב. כשה-phone מרעיש, אנחנו מסתכלים ואם זה לא נראה חמור - dismiss ומחזירים לישון."
בשבוע הזה, incident אמיתי שגרם ל-customers לאבד data עבר 47 דקות בלי תגובה. כי ה-alert שלו נראה בדיוק כמו עוד noise.
Alert fatigue הוא אחת הבעיות הכי קשות ב-SRE. הפתרון הוא לא לקבל יותר alerts - אלא פחות, ועם precision גבוה יותר.
ב-GitLab.com, ב-31 בינואר 2017, database administrator בטעות מחק 300GB מdata production במהלך maintenance. ה-incident, שהפך לאחד מה-postmortems הגלויים ביותר בhistory, חשף עובדה מדאיגה: ה-alerting system שלהם לא detect את אובדן הdata בזמן סביר. MTTD: 18 דקות. במהלך 18 הדקות האלה, users ניסו לכתוב לDB ולא ידעו שהנתונים לא נשמרים.
הbug לא היה בalert logic - היה ב-alert configuration. ה-threshold לreplication lag alert היה 5 דקות - אבל ה-alert ל-"replication stopped completely" לא היה קיים. כי מישהו הניח שreplication lag הוא ה-edge case הרע ביותר. הם לא thought of the case שבו replication פשוט לא קיים יותר.
בpostmortem הם כתבו: "we need alerts not just for when things are slow, but for when they are absent." זה עיקרון שחוזר בכל מקרה של alert gap: לא רק "threshold exceeded" אלא "expected signal missing."