سیستم هشدار و اطلاع رسانی

1) نقش و اهداف

سیستم سیگنال «ارسال پیام» نیست، بلکه یک مدار تصمیم گیری است: انحراف در زمان را برجسته می کند، اقدامات را ارائه می دهد و تعادل بین به موقع و سکوت را حفظ می کند.

• کاهش MTTD/MTTR از طریق اولویت بندی و روشن playbooks.
• کاهش خستگی هشدار از طریق لغو سر و صدا.
• اقدامات را به طور مستقیم از اطلاع رسانی (ack، snooze، runbook، auto-action) انجام دهید.
• حریم خصوصی و رضایت (opt-in/opt-out, log storage) را رعایت کنید.

2) طبقه بندی رویدادها و سطوح

2. 1 انواع رویداد

معیارها/ناهنجاری ها (SRE، محصول، مالی).
قوانین کسب و کار (محدودیت ها، تقلب، KYC، پرداخت).
سیستم (استقرار، تخریب، مجوز).
کاربر (محرک های رفتاری، RG/بازی مسئول).

2. 2 سطح شدت

بحرانی - پاسخ فوری، خطر از دست دادن/ایمنی.
بالا - زوال قابل توجهی از KPI/SLO.
متوسط - اقدام مورد نیاز در ساعات کاری.
کم/اطلاعات - مشاهده/زمینه، خودکار convolution به هضم.

2. 3 اولویت

«تأثیر × فوریت» matrix → P1..P4. لینک به کانال ها و واکنش های SLA.

3) معماری و موضوعات

Producers of signals → Sheena of events → Normalization (enrich, dedup) → the Correlation → Corrected (policy engine) → Routing → the Center of preferences → Logs/analytics.

• Enricher: اضافه می کند مستاجر، نقش، منطقه، لینک playbook.
• رویدادهای تکرارشونده گروه ددوپر با کلید.
• Correlator: سیگنال های مرتبط را به یک حادثه متصل می کند.
• موتور سیاست: قوانین YAML/DSL، ساعات آرام، تشدید.
• تحویل: در برنامه، ایمیل، فشار، SMS، webhook، ادغام چت.

4) قوانین و سیاست ها (مثال YAML)

yaml policies:
- id: p_sre_critical match: { domain: "infra", severity: "critical" }
route:
primary: { channel: "pager", targets: ["oncall_sre"] }
fallback: { channel: "sms", delay: "2m" }
suppress:
flapping: {window: "10m," threshold: 5} # suppressing frequent twitching duplicates: {key: ["service, ""cluster,"" error _ code"], ttl: "15m"}
escalate:
after: "10m"
to: ["sre_manager"]
auto_assign: true
- id: p_product_medium match: { domain: "product", severity: "medium", kpi: "conversion" }
route:
primary: { channel: "inapp", audience: "product_owners" }
digest:
window: "1h"
max_items: 10 quiet_hours:
tz: "Europe/Kyiv"
ranges: ["22: 00-07: 00"] # only P1 digests/pager at this time

5) تقسیم بندی، همبستگی، سرکوب فلاپ

Dedup: شناسه گروه 'dedup _ key = هش (سرویس' متریک 'کم نور) ؛ پنجره TTL ≥ Flapping

همبستگی: ترکیب سیگنال های مرتبط با توپولوژی (servis → zavisimost)، زمان (± N min) و زمینه (انتشار، حادثه).
Flapping: آستانه «N حوادث در هر دقیقه M» → یک سیگنال «flapping تشخیص داده شده» با پیشنهاد برای افزایش هیسترزیس یا سرکوب.

6) مسیریابی و RACI

مسئول: چه کسی اولین اعلان/کشیدن را دریافت می کند.
پاسخگو: چه کسی پس از SLA تشدید می شود.
مشورت: چه کسی به ذکر است در موضوع/چت کانال.
مطلع: چه کسی هضم/نتایج را ترک خواهد کرد.
با نقش و زمینه (مستاجر، منطقه، جریان محصول) اختصاص دهید.

7) کانال های تحویل و تفاوت های ظریف

Retrai: 5xx/429/timeout → عقب نشینی + لرزش ؛ احترام «تلاش دوباره». Idempotence: «X-Notification-Id» در وب سایت ها.

8) مرکز ترجیحات

انتخاب کردن در/انتخاب کردن بر اساس نوع رویداد، سطح، کانال.
ساعتهای آرام، چرت زدن دستی برای 15/30/60 دقیقه.
آستانه/حساسیت (به عنوان مثال ≥ 3 σ ناهنجاری).
زبان/محل، فرمت زمان/ارز.
اتصال نقش: ایستگاه از پیش تنظیم برای SRE/محصول/امور مالی.
شفافیت: نشان می دهد که چرا کاربر سیگنال را دریافت کرده است (پیوند به قانون).

9) طراحی محتوا: ساختار پیام

[P1] [PSP _ TR] افزایش شارپ در شکست 3DS (+ 12٪).

زمینه: دوره، بخش/منطقه آسیب دیده، منبع داده.
دلیل/فرضیه: «مرتبط با انتشار PSP_X 18:20 UTC».
SLA/مهلت: «تشدید در 10 دقیقه».
CTA: "playbook Open"، "فعال کردن برگشت PSP_Y،" Ack (30 دقیقه) ".
پیوندها: نمودار، موضوع حادثه، معیارها، کتاب اجرا.
فراداده: «trace _ id»، «incident _ id»، «dedup _ key».

تن: حقایق، بدون دراماتیک ؛ اعداد و واحدها از اختصارات بدون رمزگشایی اجتناب می کنند.
محلی سازی: متغیرها → متغیرهایی، ترجمه ها در منابع ذخیره می شوند ؛ اعداد/تاریخ - توسط محلی.

10) اقدامات از اطلاعیه ها (قابل اجرا)

Ack/Snooze با پارامترهای زمان.
اختصاص/دعوت به موضوع حادثه.
مراحل راه حل Runbook-Open با تکمیل خودکار متن.
یک کلیک اصلاح (که در آن امن): سوئیچ مسیر، بالا بردن حد، راه اندازی مجدد کار (با تایید و ممیزی).
بلیط (Jira/GitHub) را با فیلدهای تکمیل خودکار ایجاد کنید.

11) کیفیت سیگنال: معیارها و اهداف

دقت ≥ 80٪ برای P1/P2.
یادآوری (نسبت حوادث شناسایی شده در میان تمام حوادث) 70٪ ≥.
سر و صدا: متوسط سیگنال/ساعت در هر کاربر (سقف هدف).
Ack-time p50/p95، میزان تشدید، میزان چرت زدن (به عنوان یک نشانگر نویز).
MTTD/MTTA/MTTR (از نظر دامنه ها و کانال ها).
سکوت اما باید هشدار (شکاف به دلیل قوانین) یک داشبورد جداگانه است.

12) کنترل نویز: تکنیک ها

هیسترزیس و پنجره های کشویی برای آستانه.
ضد aliasing (EWMA) قبل از تشخیص.
جمع آوری: به جای 30 عدد کوچک - یک دسته/هضم با همکاران برتر.
محدودیت های زمینه: حداکثر N اطلاعیه/ساعت/کانال/کاربر.
بازخورد خودکار: اگر کاربر کلیک کند Snooze برای 3 × در یک ردیف → پیشنهاد افزایش آستانه/تغییر کانال.

13) امنیت، حریم خصوصی، انطباق

امضای HMAC برای وب سایت ها، چرخش اسرار، «X-Key-Id».
RBAC/ABAC: دید سیگنال توسط نقش/مستاجر.
به حداقل رساندن PII، ماسک در سیاهههای مربوط، اقدامات حسابرسی (ack/assign/runbook).
رضایت و دلایل اطلاع رسانی (قانون/سیاست) - در payload.
نگهداری/TTL سیاهههای مربوط اطلاع رسانی، حقوقی نگه در حوادث.

14) طرح ها و بارهای

رویداد (داخلی)

json
{
"id": "sig_01HX",
"domain": "payments",
"severity": "high",
"priority": "P2",
"title": "The 3DS failure graph has grown to 8. 2% (+3. 1 pp), "
"occurred_at": "2025-11-03T17:55:00Z",
"context": { "psp": "PSP_X", "country": "TR", "release_id": "rel_241103_1820" },
"metrics": { "baseline": 5. 1, "current": 8. 2, "delta_pp": 3. 1 },
"dedup_key": "payments    PSP_X    TR    3DS_FAILURE",
"runbook": "rbk_psp_3ds_spike",
"slo": { "ack_deadline_sec": 600 }
}

اطلاع رسانی (کانال آگنوستیک)

json
{
"notification_id": "ntf_91ab",
"signal_id": "sig_01HX",
"targets": ["oncall_payments"],
"channels": ["inapp","slack","webhook"],
"cta": [
{"id": "ack," "label": "Confirm (30 min)," "payload": {"ttl ":" 30m"}},
{"id": "runbook," "label": "Open playbook," "payload": {"id ": "rbk _ psp _ 3ds _ spike"}},
{"id": "fallback," "label": "Enable fallback, PSP_Y" "confirm": true}
],
"hmac": "sha256=AbCd..."
}

15) الگوهای UX در محصول

صندوق های پستی: بحرانی/بالا/زبانه های دیگر، مدالها مقدار.
خوراک حادثه: سیگنال های مرتبط، جدول زمانی اقدامات، «آنچه انجام شد».
فیلترها: نقش، دامنه، منطقه، زمان، «فقط بدون پاسخ».
اقدامات سریع در لیست (ack/snooze/assign).
توضیح دهید: «چرا شما آن را ببینید» (قانون، آستانه، داده ها).
هضم: صبح/شب، محلی توسط TZ.

16) طرح تست

واحد: کلید های dedup، هیسترزیس، فلپینگ، سریال سازی محموله ها.
یکپارچه سازی: مسیریابی، ساعات آرام، افزایش، بازپرداخت کانال ها.
E2E: سناریو P1 از ناهنجاری به بسته شدن بلیط ؛ P2 در ساعت های آرام → هضم.
هرج و مرج: از دست دادن لینک (SMTP/SMS)، تاخیر، بهمن سیگنال، ساعت skew.
A11y/i18n: صفحه نمایش خوان، صفحه کلید ack/snooze، محلی سازی اعداد/تاریخ.

17) داشبورد با کیفیت

دقت/فراخوانی توسط دامنه.
زمان Ack p50/p95 و سهم به موقع تایید شده است.
سر و صدا در هر کاربر/ساعت و قوانین سر و صدا بالا.

افزایش نرخ و «افزایش کاذب»

سرکوب در مقابل تحویل (چقدر سرکوب/هضم شده است).
بازخورد کاربر :/پیام ها، نظرات در مورد سر و صدا.

18) چک لیست

طراحی سایت

• طبقه بندی رویداد و سطوح سازگار هستند
• ساعت های آرام/سیاست های تشدید شرح داده شده است
• تقسیم/همبستگی/فلپینگ پیکربندی شده است
• کانال ها، Retras، وب هوک Idempotency
• مرکز اولویت (انتخاب کردن در/از, چرت زدن)
• قالب های محتوا و محلی سازی
• کتاب های بازی و اقدامات یک کلیک (حسابرسی شده)
• معیارهای کیفیت و داشبورد

عملیات

• فصلنامه بهینه سازی آستانه
• قوانین A/B (آستانه، پنجره ها، هضم)
• به طور منظم «سر و صدای بالا» و بررسی CAPA
• چرخش مخفی کانال (HMAC، SMTP، SMS)
• تست روزهای بازی برنامه ریزی شده

19) برنامه پیاده سازی (3 تکرار)

تکرار 1 - پایه (2-3 هفته)

طبقه بندی، شدت/اولویت، مرکز اولویت (در برنامه + ایمیل).
Dedup، همبستگی کلید/زمان ساده، ساعت آرام.
قالب های پیام, playbooks, ACK/چرت زدن/اختصاص.

تکرار 2 - قابلیت اطمینان و کاهش نویز (3-4 هفته)

Flapping/hysteresis، هضم، ادغام چت و webhooks (HMACs، retrays).
تشدید با توجه به SLA، داشبورد کیفیت (دقت/فراخوان، سر و صدا).
اصلاح با یک کلیک (با تایید و ممیزی).

تکرار 3 - بهینه سازی و مقیاس (مداوم)

همبستگی با توپولوژی/انتشار، پیشنهادات خودکار آستانه.
قوانین A/B، پیش بینی «زمانی که آستانه کار خواهد کرد».
بررسی سر و صدا و روزهای بازی منظم.

20) مینی سوالات متداول

چگونه با خستگی مفرط مقابله کنیم ؟

Dedup، همبستگی، هیسترزیس، هضم و مراکز ترجیحی + سر و صدای منظم و بررسی آستانه A/B.

آیا ML برای ناهنجاری ها مورد نیاز است ؟

مفید است، اما با قوانین قطعی و آستانه قابل توضیح شروع کنید. ML مانند یک افزودنی است، همیشه با توضیح.

چرا کاربران ایمیل های «اضافی» دریافت می کنند ؟

بررسی قوانین مسابقات، ساعات آرام، «چرا تحویل» ممیزی، تنظیم کانال/ساعت محدودیت و هضم.

مجموع

یک سیستم سیگنال قوی فیلتر هوشمند و اولویت بندی صحیح + اقدامات یک کلیک است. طبقه بندی و سیاست های رسمی، پیاده سازی dedup/همبستگی/هیسترزیس، کنترل کاربران (تنظیمات، چرت زدن)، ارائه تحویل قابل اعتماد و شفافیت "چرا من آن را کردم. سپس سیگنال ها به یک ابزار کنترل تبدیل می شوند، نه یک منبع سر و صدا.