Alerts和通知：PagerDuty, Opsgenie

Alerts和通知： PagerDuty, Opsgenie

1）為什麼需要一個單獨的Alert平臺

目標是立即向合適的人/團隊發出相關信號，並啟動事件過程：承認（ack），升級，溝通，驗屍。PagerDuty和Opsgenie給出：

按服務/標記/環境路由。
升級和時間表（職責，追隨太陽）。
重復數據消除/事件相關性。
安靜的窗戶（維護/freeze）和薄荷規則。
與監控，CI/CD和ChatOps集成。

支持：SLO閾值→ alert →人/自動機→ runbook →回滾/假→驗屍。

2）信號模型和嚴重性（severity）

建議的量表：

critical （page）-SLO違規行為/現金路徑錯誤（存款/退款）,可用性下降,burn-rate。
高度（page/tiket）是沒有明顯的SLO擊穿的顯著降解。
medium （tiket）-容量、後退降解、後退。
low （inform）-趨勢,警告。

規則：頁面僅通過SLO或顯式業務觸發。

3）路由架構

1.源（Prometheus/Alertmanager，Grafana，雲監視，專有的webhooks）。

2.Шлюз (PagerDuty/Opsgenie service/integration).

3.策略：按標簽（'service'，'env'，'region'），severity，payload的路線。
4.升級：服務級別的順序（L1→L2→menedzher）。

5.通訊： ChatOps頻道,狀態頁面,郵件.

關鍵標簽示例（標準化）

「service」，「env」，「region」，「version」，「runbook」，「release_id」，「route」，「tenant」（如果B2V/多重特南特）。

4）呼叫和升級時間表

Schedules: primary/secondary, роли (SRE, DBRE, Sec).

Rotations：白天/夜間，追隨太陽，周末。
Overrides：休假/生病。
升級：ack-taymaut 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密鑰：使用穩定的指紋（例如,service+route+code）。
分組：「group_by」通過服務/環境,以便5xx級聯不會產生數十頁。
Mutes/安靜的窗口：在遷移/發布/負載測試期間。
原因是：如果「api-gateway@prod」的P1事件已經發生，請抑制子P2/P3。

反模式：CPU/Memory上的頁面沒有確認對SLO的影響。

7）與發布和自動操作的聯系

在金絲雀除塵器中，PagerDuty/Opsgenie從CI/CD → pause/rollback（Argo Rollouts/Helm）中的SLO門→ webhook獲得警報。
Alert包含："release_id"，"image。標題,鏈接到管線和回滾步驟運行手冊。

註釋中的鏈接示例runbook


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

8） ChatOps和通信

在Slack/Teams中自動創建事件通道，綁定到tiket。

Slash-команды: `ack`, `assign @user`, `status set`, `postmortem start`.

狀態頁面：P1/P2時自動更新。

9）事件生命周期（最低）

1.觸發器（來自SLO/傳感器的警報器）。

2.Page (primary on-call).

3.Ack（確認，TTA）。
4.Communicate（頻道/狀態）。
5.Mitigate（rollback/feature-flag/隔離）。

6.Resolve (TTR).

7.Postmortem（時間線，原因，行動，課程，任務所有者）。

Role-kit: IC (incident commander), Ops lead, Comms, Scribe.

10）有用的payload字段（normalize）

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 Alerting-更容易用於行車記錄儀/業務指標。
OpenTelemetry/SpanMetrics是路由上的後端/錯誤。
K8s事件-群集事故（控制平面,PDB違規）。
DB/隊列-lag/locks/replication。
應用的Webhooks是域信號（PSP錯誤，指紋激增）。

12）政策與合規性

RBAC用於創建/更改策略，時間表，mutes。
審計：誰承認/任命/更改了狀態，時間表。
PII最小化為payloads（ID ticket代替用戶電子郵件/電話）。
DR計劃：在PagerDuty/Opsgenie （fallback頻道）不可用時會做什麼。

13）實踐示例（PagerDuty vs Opsgenie）

一個機會	PagerDuty	Opsgenie
升級/日程安排	成熟、靈活	成熟、靈活
事件角色/模板	強大的事件工作流	Incident Templates/Stakeholders
自動頻道/通用	良好的集成	Deep Slack/MS團隊
定價/許可證	通常更昂貴，很多地獄	通常在開始時便宜
按標簽進行路由	強大（服務目錄）	強大（路由規則）
兩個平臺都關閉了95％的相同腳本；按成本、UX和堆棧集成進行選擇。

14）安靜的窗戶和霜凍

Freeze：禁止在計劃發布窗口中分頁,只剩下P1。
標記為：「env=stage」，「region=dr」，「service=batch」。
時間靜音：在數據庫遷移/負載測試時-具有明確的所有者。

15）效率度量（SRE/DORA for alerts）

MTTA/MTTR（命令/服務/輪班部分）。
具有運行簿的Alert的百分比（目標≥ 95％）。
SLO的頁值份額（目標≥ 90％）。
Ratio有用/嘈雜（目標≥ 3：1）。
%自動輔助功能（pause/rollback via webhook）-生長。
Burn-down postmortem action items 14/30天。

16）反模式

通過「鐵」（CPU，磁盤）分頁而不會影響用戶。
沒有「grupp_by」 → 「storm」 alerts。
沒有安靜的窗口-版本將所有內容塗成紅色。
沒有「服務/env/runbook」的payloads-無法路由/操作。
沒有單一的severity量表和規則（每個來源都是以自己的方式）。
沒有人提出的「永恒」警告（警報職責）。

17）實施清單（0-45天）

0-10天

調和severity量表並標準化標簽/註釋。
在PagerDuty/Opsgenie中創建服務,自定義schedules和基本升級。
綁定Alertmanager/Grafana，包括「group_by」和dedup。

11-25天

鍵入SLO-alerta（多窗口燃燒）,添加鏈接運行手冊。
自定義ChatOps： autocanals、ack/assign命令。
在發布/遷移中啟用安靜的窗口。

26-45天

集成加那利群島的自動pause/rollback（webhooks）。
引入MTTA/MTTR報告和allert衛生（噪音清潔）。
標準化驗後和控制行動項目。

18）現成的嗅探

Grafana Alerting → 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" }
]
}

🚨 Check Alert的Webhook → Argo Rollouts pause

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）結論

Alert的強環路是+學科的過程：SLO為中心的分層，可讀的路由和升級，單個標簽和payloads，安靜的窗口，ChatOps和自動動作（pause/rollback）。在預算和UX上選擇PagerDuty或Opsgenie，但要遵守相同的噪音、職責和責任規則--那麼佩奇將是罕見、準確和有用的，事件是短暫和可管理的。

Alerts和通知：PagerDuty, Opsgenie

Opsgenie (webhook)

註釋中的鏈接示例runbook

11-25天

26-45天

Opsgenie-路由規則（偽）

與我們聯繫

快速聯繫

影片即將更新

我們目前正忙於各項專案