Notification Routing, Dedupe و Escalation

1. مسئله واقعی: هر Signal نباید به هر Channel برود

اگر هر event به ایمیل، چت و pager فرستاده شود، یک مشکل واحد می‌تواند ده‌ها notification بسازد، چند نفر هم‌زمان واکنش نشان دهند و در نهایت معلوم نباشد چه کسی مالک کار است. هدف این درس «فرستادن پیام بیشتر» نیست؛ هدف ساخت یک Notification Routing, Dedupe & Escalation Matrix v1 است که تصمیم delivery را از وضعیت واقعی condition جدا نگه دارد.

2. مرز درس و Artifact مالک

هر ردیف Matrix باید signal_id، notification_key، group_key، severity/urgency/actionability، owner، route، mute/inhibit، delivery result، acknowledgment، resolution، escalation stage، deadline، retry budget، suppression reason و terminal state را ثبت کند. Obligation Lifecycle متعلق به PLN-005 است و Executive Docket متعلق به PLN-007؛ این درس آن outcomeها را جذب نمی‌کند.

3. Condition، Notification و Delivery سه چیز متفاوت‌اند

condition همان وضعیت زیربنایی است؛ notification تصمیمی برای جلب توجه است؛ delivery_attempt فقط تلاش یک کانال برای رساندن پیام است. موفقیت SMTP یا chat API اثبات نمی‌کند که owner پیام را دیده، acknowledgment داده یا مشکل را حل کرده است. این جداسازی پایه‌ی تمام escalationهای قابل حسابرسی است.

4. Notification Key باید از Condition پایدار مشتق شود

سه adapter ممکن است همان condition را با سه signal_id مختلف تولید کنند. اگر notification key از channel یا message id ساخته شود، dedupe شکست می‌خورد. Key باید از هویت owned condition و ابعاد پایدار آن مشتق شود؛ channel فقط بخشی از delivery policy است، نه identity اصلی.

5. Grouping و Deduplication قبل از Fan-out

Prometheus Alertmanager به‌صورت رسمی grouping، deduplication و routing را برای کاهش notificationهای تکراری پشتیبانی می‌کند. در این درس از آن به‌عنوان مرز عملی استفاده می‌کنیم، نه تعریف MAKNOW. اگر سه signal مربوط به یک condition باشند، Matrix باید آن‌ها را در یک group نگه دارد و تعداد duplicateهای suppressed را ثبت کند.

6. Route با Actionability، Urgency و Owner تعیین می‌شود

Severity بالا به‌تنهایی به معنی page نیست. ابتدا بپرس: آیا اقدام انسانی مشخصی وجود دارد؟ owner مشخص است؟ window اقدام کوتاه است؟ Google SRE تأکید می‌کند alert خوب timely و actionable است و alert غیرقابل‌اقدام noise می‌سازد. بنابراین route باید به evidence عملیاتی متصل باشد، نه فقط label «critical».

7. Group Wait، Group Interval و Repeat Interval چه می‌آموزند

Alertmanager برای grouped notificationها زمان‌های group_wait، group_interval و repeat_interval دارد. نکته آموزشی این نیست که همین مقادیر را کپی کنیم؛ نکته این است که ارسال اولیه، افزودن signalهای جدید و تکرار reminder سه timer متفاوت‌اند. Escalation policy باید این تفاوت را صریح نگه دارد.

8. Mute با Inhibition فرق دارد

Mute یعنی در یک window یا policy مشخص notification ارسال نشود. Inhibition یعنی وجود یک source condition مرتبط باعث شود target notification سرکوب شود؛ مثلاً وقتی outage والد فعال است، alertهای فرزند که فقط symptom همان outage هستند page جدا نسازند. Suppression باید دلیل قابل مشاهده داشته باشد و condition را «resolved» نکند.

9. Delivery Success هرگز Ack نیست

ممکن است ایمیل DELIVERED باشد اما owner acknowledgment نداده باشد. Matrix باید delivery_result و acknowledged_at را مستقل ثبت کند. تا وقتی Ack یا Resolution وجود ندارد، workflow بسته نشده است. همین Failure Probe جلوی یک خطای رایج را می‌گیرد: transport success به‌جای business state.

10. Escalation فقط با Deadline و Retry Budget محدود

اگر acknowledged_at خالی بماند و deadline برسد، route می‌تواند به backup owner یا channel دیگری escalate شود؛ اما retry باید محدود باشد. retry_budget، escalation_stage و terminal state مانع loop بی‌نهایت می‌شوند. وقتی بودجه تمام شود، نتیجه باید صریحاً BLOCKED/REVIEW_REQUIRED یا terminal failure باشد، نه تکرار بی‌پایان.

11. Resolution مسیر Escalation را می‌بندد

اگر condition قبل از deadline بعدی واقعاً resolved شود، notification جدید نباید صرفاً چون timer فعال بوده ارسال شود. Resolution باید از evidence owned condition بیاید، نه از delivery. Matrix باید terminal state را RESOLVED ثبت کند و pending escalation را لغو کند.

12. Worked Example: سه Signal، دو Channel، یک Condition

یک obligation overdue سه signal در ده دقیقه می‌سازد. همه یک notification_key و group_key دارند؛ پس فقط یک notification group داریم. ایمیل می‌رسد، chat fail می‌شود و Ack هنوز نداریم. اگر parent incident معتبر هم فعال باشد، inhibition می‌تواند page فرزند را suppress کند. اگر inhibition وجود نداشته باشد، تا deadline در WAIT_ACK می‌مانیم و فقط بعد از deadline به stage بعد escalate می‌کنیم.

13. Stateهای خروجی را با هم قاطی نکن

DELIVER یعنی policy اجازه ارسال دارد. WAIT_ACK یعنی delivery ممکن است انجام شده باشد اما acknowledgment هنوز نرسیده. ESCALATE فقط بعد از trigger محدود و معتبر است. SUPPRESS به‌خاطر mute/inhibit/dedupe است و resolution نیست. DEFER_TO_DOCKET برای مورد کم‌فوریتی است که page نمی‌خواهد. REVIEW_REQUIRED برای evidence ناقص است و RESOLVED فقط وقتی condition واقعاً بسته شده باشد.

14. Failure Probeهای قطعی

چهار shortcut باید fail شوند: (۱) یک condition از سه channel adapter و سه page مستقل؛ (۲) delivery موفق بدون acknowledgment و ثبت اشتباه RESOLVED؛ (۳) parent incident معتبر ولی نادیده‌گرفتن inhibition؛ (۴) condition قبل از escalation بعدی resolved شده اما timer هنوز page می‌فرستد. هرکدام باید در Matrix reason و state قابل حسابرسی داشته باشد.

15. Transfer: Reminder کم‌فوریت باید Docket بسازد، نه Page

در Transfer همان separation را نگه دار اما context را عوض کن: یک opportunity reminder کم‌فوریت و actionable داریم. notification_key همچنان از condition می‌آید، delivery/ack/resolution مستقل می‌مانند، اما route باید DEFER_TO_DOCKET باشد. baseline را کپی نکن؛ urgency و route را از evidence جدید دوباره محاسبه کن.