هشدارها و اطلاعیه ها: PagerDuty، Opsgenie

هشدارها و اطلاعیه ها: PagerDuty، Opsgenie

1) چرا یک پلت فرم جداگانه از هشدار

• مسیریابی توسط خدمات/برچسب ها/محیط ها.
• تشدید و برنامه (در وظیفه، به دنبال خورشید).
• تقسیم بندی رویداد/همبستگی.
• پنجره های آرام (نگهداری/انجماد) و قوانین موسیقی.
• ادغام با نظارت، CI/CD و ChatOps.

پشتیبانی: SLO آستانه → هشدار → شخص/ماشین → runbook → rollback/fix → postmortem.

2) مدل سیگنال و شدت

• بحرانی (صفحه) - خطای نقض SLO/مسیر پول (سپرده/برداشت)، افت در دسترس بودن، نرخ سوزاندن.
• بالا (صفحه/بلیط) - تخریب قابل توجهی بدون شکست SLO آشکار است.
• متوسط (بلیط) - ظرفیت، تخریب پشت، retray.
• پایین (اطلاع رسانی) - روند، هشدارها.

قانون: صفحه توسط SLO یا فقط ماشه کسب و کار صریح.

3) معماری مسیریابی

1. منبع (Prometheus/Alertmanager، Grafana، نظارت بر ابر، وب سایت های خود).
2. Шлюз (خدمات PagerDuty/Opsgenie/ادغام).
3. سیاست ها: مسیرهای برچسب ها («سرویس»، «env»، «منطقه»)، شدت، بارگیری.
4. تشدید: توالی سطوح وظیفه (L1 → L2 → menedzher).
5. ارتباطات: ChatOps کانال, صفحات وضعیت, پستها.

نمونه ای از برچسب های کلیدی (استاندارد)

«سرویس»، «env»، «منطقه»، «نسخه»، «runbook»، «release _ id»، «مسیر»، «مستاجر» (اگر B2B/چند مستاجر).

4) برنامه های تماس و تشدید

برنامه: اولیه/ثانویه، роли (SRE، DBRE، ثانیه).
چرخش: روز/شب، پیگیری خورشید، آخر هفته.

بایگانی برچسب: مرخصی/بیماری

تشدید: ack-timeout 5-10 دقیقه → لایه بعدی. با ساعات کار - به بخش مشخصات ؛ خارج - پلت فرم در تماس.

نکته: مراحل کوتاه تشدید را در شب (خستگی کمتر) و طولانی تر در طول روز (زمینه وجود دارد) نگه دارید.

5) ادغام با Alertmanager (الگوی پایه)

yaml receivers:
- name: pagerduty pagerduty_configs:
- routing_key: ${PAGERDUTY_ROUTING_KEY}
severity: '{{ if eq. Labels. severity "critical" }}critical{{ else }}error{{ end }}'
class: '{{.Labels. service }}'
component: '{{.Labels. env }}'
group: '{{.Labels. region }}'
description: '{{.Annotations. summary }}'
details:
service: '{{.Labels. service }}'
env: '{{.Labels. env }}'
runbook: '{{.Annotations. runbook }}'
release: '{{.Annotations. release }}'
route:
receiver: pagerduty group_by: ["service","env","region"]
group_wait: 30s group_interval: 5m repeat_interval: 2h

Opsgenie (webhook)

yaml receivers:
- name: opsgenie opsgenie_configs:
- api_key: ${OPSGENIE_API_KEY}
responders:
- name: "SRE Primary"
type: team priority: '{{ if eq. Labels. severity "critical" }}P1{{ else }}P3{{ end }}'
details:
trace: '{{.Labels. trace_id }}'
runbook: '{{.Annotations. runbook }}'

6) سر و صدا، مرده و همبستگی

کلید Dedup: از یک اثر انگشت پایدار (به عنوان مثال، سرویس + مسیر + کد) استفاده کنید.
گروه بندی: 'group _ by' توسط سرویس/محیط زیست به طوری که آبشار 5xx ده ها صفحه را ایجاد نمی کند.
پنجره های خاموش/آرام: در طول مهاجرت/انتشار/آزمایش بار.
سرکوب به یک دلیل: اگر در حال حاضر یک حادثه P1 برای api-gateway @ prod وجود دارد، P2/P3 کودک را سرکوب کنید.

ضد الگو: صفحه توسط CPU/حافظه بدون اثر تایید شده در SLO.

7) ارتباط با انتشار و اقدامات خودکار

با افسردگی قناری، PagerDuty/Opsgenie یک هشدار از دروازه SLO → webhook در CI/CD → مکث/بازگشت (Argo Rollouts/Helm) دریافت می کند.
هشدار شامل 'release _ id', 'image. برچسب '، اشاره به خط لوله و rollback runbook.

نمونه ای از لینک runbook در حاشیه نویسی

runbook: https://runbooks. company/rollback/api-gateway#canary

8) ChatOps و ارتباطات

خودکار ایجاد یک کانال حادثه در Slack/Teams، اتصال به یک بلیط.
اسلش- команды: «ack»، «assign @user»، «status set»، «postmortem start».
صفحه وضعیت - به روز رسانی به طور خودکار بر روی P1/P2.

9) چرخه عمر حادثه (حداقل)

1. ماشه (هشدار از SLO/سنسور).
2. صفحه (اولیه در تماس).
3. ACK (تایید، TTA).
4. ارتباط (کانال/وضعیت).
5. کاهش (بازگشت/ویژگی پرچم/انزوا).

6. راه حل (TTR)

7. Postmortem (جدول زمانی، دلایل، اقدامات، درس ها، صاحب وظیفه).

نقش کیت: IC (فرمانده حادثه)، عملیات سرب، ارتباطات، کاتب.

10) زمینه های بارگیری (عادی سازی)

json
{
"service": "payments-api",
"env": "prod",
"region": "eu-central-1",
"severity": "critical",
"event_class": "slo_burn",
"summary": "Withdraw 5xx > 0. 5% for 10m",
"runbook": "https://runbooks/payments/withdraw-5xx",
"release_id": "rel-2025-11-03-14-20",
"image": "ghcr. io/org/payments:1. 14. 2",
"trace_id": "8a4f0c2e9b1f42d7",
"annotations": { "canary": "25%" }
}

11) ادغام منابع سیگنال

Prometheus/Alertmanager منبع اصلی SLO/RED است.
هشدار Grafana برای داشبورد/معیارهای کسب و کار آسان تر است.
OpenTelemetry/SpanMetrics - تاخیر/خطا در مسیر.
رویدادهای K8s - شکست خوشه ای (کنترل هواپیما، نقض PDB).
DB/صف - تاخیر/قفل/تکرار.
وب سایت های کاربردی - سیگنال های دامنه (خطای PSP، افزایش تقلب).

12) سیاست ها و انطباق

RBAC برای ایجاد/تغییر سیاست ها، برنامه ها، mutas.
حسابرسی: که به رسمیت شناخته شده/منصوب/تغییر وضعیت، timestamps.
به حداقل رساندن PII در بارهای (ID بلیط به جای ایمیل/تلفن کاربر).
DR-plan: چه کاری باید انجام دهیم وقتی PagerDuty/Opsgenie در دسترس نیست (کانال برگشت).

13) مطالعات موردی (PagerDuty در مقابل Opsgenie)

14) پنجره های آرام و یخبندان

انجماد: ممنوعیت صفحه بندی در پنجره های آزاد برنامه ریزی شده، تنها P1 را ترک می کند.
حفظ برچسب: 'env = stage', 'region = dr', 'service = batch'.
بی صدا موقت: هنگام انتقال پایگاه های داده/تست بار - با مالک صریح.

15) معیارهای عملکرد (SRE/DORA برای هشدار)

MTTA/MTTR (توسط تیم/خدمات/شیفت شکسته).
٪ هشدارها با runbook (≥ هدف 95٪).
سهم هشدارهای صفحه توسط SLO (≥ هدف 90٪).
نسبت مفید/پر سر و صدا (≥ هدف 3:1).
٪ از اقدامات خودکار (مکث/بازگشت از طریق webhook) - رشد کنید.
آیتم های عمل پس از مرگ را در 14/30 روز بسوزانید.

16) ضد الگوهای

صفحه توسط سخت افزار (CPU، دیسک) بدون تاثیر بر کاربر.
عدم وجود «group _ by» → «storm» of alerts.
هیچ پنجره آرامی وجود ندارد - همه چیز را قرمز رنگ کنید.
بارهای بارگیری شده بدون «service/env/runbook» - قابل مسیریابی/اقدام نیستند.
مقیاس شدت و قوانین واحدی وجود ندارد (هر منبع متفاوت است).
هشدار «ابدی» که هیچ کس تعمیر (هشدار بدهی).

17) چک لیست پیاده سازی (0-45 روز)

0-10 روز

تراز شدت مقیاس و استاندارد برچسب ها/حاشیه نویسی.
ایجاد خدمات در PagerDuty/Opsgenie، پیکربندی برنامه ها و افزایش پایه.
Bind Alertmanager/Grafana، گروه _ by و مرده را فعال کنید.

11-25 روز

هشدارهای SLO را وارد کنید (سوزاندن چند پنجره)، یک runbook پیوند اضافه کنید.
پیکربندی ChatOps: کانال های خودکار، دستورات ack/assign.
فعال کردن پنجرههای آرام در releases/migrations.

26-45 روز

ادغام مکث خودکار/بازگشت برای canary ها (webhooks).
گزارش MTTA/MTTR و بهداشت هشدار (تمیز کردن سر و صدا) را وارد کنید.
استاندارد سازی پس از مرگ و کنترل بر موارد عمل.

18) قطعه های آماده

هشدار گرافانا → PagerDuty (نقشه برداری بدن JSON)

json
{
"routing_key": "${PAGERDUTY_ROUTING_KEY}",
"event_action": "trigger",
"payload": {
"summary": "{{.RuleName }}: {{ index. Labels \"service\" }}",
"severity": "{{ if eq (index. Labels \"severity\") \"critical\" }}critical{{ else }}error{{ end }}",
"source": "grafana",
"component": "{{ index. Labels \"env\" }}",
"group": "{{ index. Labels \"region\" }}"
},
"links": [
{ "href": "{{.DashboardURL }}", "text": "Dashboard" },
{ "href": "{{ index. Labels \"runbook\" }}", "text": "Runbook" }
]
}

Webhook از هشدار → مکث Argo Rollouts

bash curl -X POST "$ARGO_API/rollouts/pause" \
-H "Authorization: Bearer $TOKEN" \
-d '{"name":"api-gateway","namespace":"prod"}'

Opsgenie - قانون مسیریابی (شبه)

yaml if:
tags: ["service:payments","env:prod"]
severity: ["P1","P2"]
then:
route_to: "SRE-Payments"
notify: ["Primary OnCall","Secondary"]

19) نتیجه گیری

یک کانتور قوی از هشدارها یک فرآیند + نظم و انضباط است: طبقه بندی SLO گرا، مسیریابی صالح و تشدید، برچسب ها و بارهای یکنواخت، پنجره های آرام، ChatOps و اقدامات خودکار (مکث/بازگشت). PagerDuty یا Opsgenie را در بودجه و UX انتخاب کنید، اما به همان قوانین سر و صدا، وظیفه و مسئولیت بچسبید - سپس صفحه نادر، دقیق و مفید خواهد بود و حوادث کوتاه و قابل کنترل خواهند بود.