جلوگیری از افزایش بیش از حد هشدارها
1) مشکل و هدف
خستگی هشدار زمانی اتفاق می افتد که سیستم اعلان های بی ربط یا غیر قابل اجرا را ارسال می کند. خط پایین نادیده گرفتن صفحات، رشد MTTA/MTTR و پرش از حوادث واقعی است.
هدف: برای ایجاد سیگنال های نادر، معنی دار و اجرایی با اتصال آنها به SLO ها و playbooks.
2) طبقه بندی سیگنال (کانال = عواقب)
صفحه (P0/P1) - بیدار شدن از خواب یک فرد ؛ فقط زمانی که اقدام دستی در حال حاضر مورد نیاز است و یک runbook وجود دارد.
بلیط (P2) - کار آسنکرون در ساعت/روز ؛ از خواب بیدار نمی شود، بلکه توسط SLA ردیابی می شود.
Dash-only (P3) - مشاهده/روند بدون اقدامات فعال ؛ سر و صدا ایجاد نمی کند.
Sentry Silent - معیارها/حسابرسی در پس زمینه (برای RCA/پس از مرگ).
قانون: سیگنال یک گام پایین تر است - هنوز ثابت نشده است که نیاز به بالاتر است.
3) طراحی هشدار «صحیح»
هر هشدار باید:- هدف/فرضیه (آنچه ما محافظت می کنیم: SLO، امنیت، پول، انطباق).
- شرایط ماشه (آستانه، پنجره، حد نصاب منبع).
- Runbook/Playbook (شناسه گام کوتاه + لینک).
- مالک (تیم/گروه نقش).
- معیارهای تکمیل (زمانی که برای بستن، خودکار قطعنامه).
- کلاس آسیب پذیری (تاثیر کاربر/پلت فرم/امنیت/هزینه).
4) نظارت SLO گرا
SLI/SLO → سیگنال های اصلی: در دسترس بودن، تاخیر، موفقیت عملیات تجاری.
هشدار نرخ سوختگی: دو پنجره (کوتاه + بلند)، به عنوان مثال:- کوتاه: 5٪ از بودجه در 1 ساعت → صفحه.
- طولانی: 2٪ از بودجه در 6 ساعت → بلیط.
- کوهورت: هشدارها بر اساس منطقه/ارائه دهنده/بخش VIP - هشدارهای جهانی کاذب کمتر.
5) تکنیک های کاهش سر و صدا
1. پروب های Quorum: تنها در صورتی که منابع مستقل ≥2 (مناطق مختلف/ارائه دهندگان) مشکل را تایید کنند.
2. Deduplication - کلید های جمع آوری: سرویس + منطقه + کد.
3. هیسترزیس/مدت زمان: «در منطقه قرمز ≥ N دقیقه» برای فیلتر کردن خوشه.
4. محدودیت نرخ: بیش از X هشدار/ساعت/خدمات ؛ اگر بیش از حد باشد، یک صفحه + خلاصه.
5. خودکار چرت زدن/سرکوب هوشمند: هشدار تکراری در پنجره T → ترجمه به بلیط تا ریشه حذف شده است.
6. همبستگی رویداد: یک «هشدار استاد» به جای ده ها تن از علائم (به عنوان مثال «DB در دسترس نیست» مسدود کردن 5xx از microservices).
7. پنجره های تعمیر و نگهداری: کار برنامه ریزی شده به طور خودکار سیگنال های مورد انتظار را سرکوب می کند.
8. ناهنجاری + guardrails: ناهنجاری - فقط به عنوان بلیط، اگر هیچ تایید توسط سیگنال SLO وجود دارد.
6) مسیریابی و اولویت ها
اولویت ها: P0 (صفحه، 15 دقیقه به روز رسانی)، P1 (صفحه، 30 دقیقه)، P2 (بلیط، 4-8 ساعت)، P3 (مشاهده).
مسیریابی توسط برچسب ها: service/env/region/tenant → مربوط به تماس.
تشدید زمان: بدون ACK در 5 دقیقه → P2 → مدیر وظیفه/IC.
ساعات آرام: ساعات شب برای غیر بحرانی ؛ صفحه برای P2/P3 مجاز نیست.
سیاست خستگی: اگر مهندس دارای> N صفحه/تغییر - توزیع مجدد به P2، تشدید آلودگی سیگنال.
7) کیفیت هشدارها: ترتیبات
قابلیت اجرا ≥ 80٪: اکثریت قریب به اتفاق صفحات منجر به عمل runbook می شود.
مثبت کاذب ≤ 5٪ برای سیگنال های صفحه.
Time-to-Fix-Alert ≤ 7 روز - هشدار معیوب باید اصلاح شود/حذف شود.
مالکیت 100٪ - هر هشدار دارای یک مالک و یک مخزن با تعریف آن است.
8) هشدار به عنوان چرخه عمر کد
1. ایجاد روابط عمومی (شرح هدف، شرایط، دفتر اجرا، مالک، طرح آزمون).
2. Sandbox/Shadow: هشدار سایه می نویسد به چت/ورود به سیستم، اما صفحه نیست.
3. Canary: مخاطب محدود در تماس، اندازه گیری FP/TP.
4. تولید: گنجاندن با نرخ محدود + مشاهده 2-4 هفته.
5. بررسی هفتگی: معیارهای کیفیت، ویرایش/برداشت.
6. Deprecate: اگر سیگنال یک مورد بالاتر را تکرار کند یا عملی نباشد.
9) معیارهای بلوغ (نمایش در داشبورد)
زمان مناسب برای تنظیم هشدار
هشدارها در هر ساعت تماس (متوسط/95 درصد).
٪ عملی (مراحل تکمیل شده) و میزان مثبت کاذب وجود دارد.
MTTA/MTTR در اطراف صفحات و صفحه → نرخ بلیط (نباید بالا باشد).
سخنرانان برتر (خدمات/قوانینی که ≥20٪ سر و صدا ایجاد می کنند).
پوشش نرخ سوختگی: سهم خدمات با هشدارهای SLO در دو پنجره.
10) چک لیست «بهداشت هشدار»
- هشدار به SLO/SLI یا کسب و کار/امنیت گره خورده است.
- یک runbook و مالک وجود دارد ؛ تماس و کانال اتاق جنگ مشخص شده است.
- دو پنجره (کوتاه/بلند) و حد نصاب منابع پیکربندی شده است.
- Dedup، rate-limit، auto-resolve و auto-snooze گنجانده شده است.
- نگهداری و سرکوب ویندوز برای انتشار/مهاجرت مشخص شده است.
- سایه/قناری گذشت ؛ اندازه گیری FP/TP
- گزارش معیارهای کیفیت هشدار شامل.
11) قالب های کوچک
مشخصات هشدار (ایده YAML)
yaml id: payments-slo-burn severity: P1 owner: team-payments@sre purpose: "Защитить SLO успеха платежей"
signal:
type: burn_rate sli: payment_success_ratio windows:
short: {duration: 1h, threshold: 5%}
long: {duration: 6h, threshold: 2%}
confirmations:
quorum:
- synthetic_probe: eu,us
- rum: conversion_funnel routing:
page: oncall-payments escalate_after: 5m controls:
dedup_key: "service=payments,region={{region}}"
rate_limit: "1/10m"
auto_snooze_after: "3 pages/1h"
runbook: "rb://payments/slo-burn"
maintenance:
suppress_when: [ "release:payments", "db_migration" ]
متن به روز رسانی استاندارد (برای کاهش سر و صدا)
Импакт: падение success_ratio платежей в EU (-3.2% к SLO, 20 мин).
Диагностика: подтвержден кворумом (EU+US синтетика), RUM — рост отказов на 2 шаге.
Действия: переключили 30% трафика на PSP-B, включили degrade-UX, след. апдейт 20:30.
12) فرآیندها: هفتگی «بررسی هشدار»
دستور کار (30-45 دقیقه):1. برترین گویندگان → ویرایش/حذف.
2. FP/TP در صفحه سیگنال → تنظیم آستانه/پنجره/حد نصاب.
3. متقاضیان برای downgrade (صفحه → بلیط) و بالعکس.
4. وضعیت Time-to-Fix-Alert - تاخیرها به صاحبان خدمات تشدید می شود.
5. بررسی پوشش با هشدارهای SLO و حضور کتابهای اجرا.
13) پیوند به انتشار و عملیات
حاشیه نویسی انتشار به طور خودکار اضافه کردن سرکوب موقت.
پنجره ها را تغییر دهید: در 30 دقیقه اول پس از انتشار - فقط سیگنال های SLO.
Playbooks شامل یک گام هشدار غیر کلیدی پایین/سرکوب برای تمرکز بر روی ریشه است.
14) ایمنی و انطباق
سیگنال های امنیتی (هک/نشت/دسترسی غیر طبیعی) - کانال های جداگانه، بدون ساعت آرام.
گزارش حسابرسی از تمام سرکوب ها/پنجره های آرام: چه کسی، چه زمانی، چرا، مهلت.
الزام غیر قابل تغییر برای هشدارهای بحرانی (امضای رویداد).
15) ضد الگوهای
«هر گراف = هشدار» → بهمن.
آستانه «! = 0 خطا» در فروش.
یک کاوش/یک منطقه به عنوان منبع حقیقت.
صفحه بدون کتاب اجرا/مالک.
«سرکوب موقت» دائمی بدون هیچ اصطلاح.
هشدارهای معیوب «بعداً آن را برطرف کنید» - سالها جمع می شوند.
مخلوط کردن سر و صدای آزاد با حوادث تولید.
16) نقشه راه پیاده سازی (4-6 هفته)
1. موجودی: تمام هشدارها را بارگیری کنید، صاحبان و کانال ها را پایین بیاورید.
2. هسته SLO: قوانین نرخ سوختگی را با دو پنجره برای خدمات بحرانی معرفی کنید.
3. کنترل نویز: quorum، deadup و rate-limit را فعال کنید، یک بررسی هفتگی را شروع کنید.
4. پوشش Runbook: نزدیک 100٪ از سیگنال های صفحه با playbooks.
5. سیاست Fatig: محدودیت صفحه/تغییر، ساعات آرام، توزیع مجدد بار.
6. اتوماسیون: هشدار به عنوان کد، سایه/قناری، گزارش در معیارهای کیفیت.
17) خط پایین
سکوت فقدان نظارت نیست، بلکه سیگنال های به خوبی طراحی شده در ارتباط با SLO و فرایندها است. Quorum، دو پنجره، dedup و مسیریابی دقیق، هشدارها را به نادر، دقیق و اجرایی تبدیل می کنند. تیم در خواب است، کاربران خوشحال هستند، حوادث تحت کنترل هستند.