アラートと通知：PagerDuty、 Opsgenie

アラートと通知： PagerDuty、 Opsgenie

1）アラートの別のプラットフォームがなぜ

• サービス/タグ/環境によるルーティング。
• エスカレーションとスケジュール（勤務中、フォローザサン）。
• イベント重複除外/相関。
• 静かなウィンドウ（メンテナンス/フリーズ）と音楽のルール。
• モニタリング、CI/CD、 ChatOpsとの統合。

サポート：SLOしきい値→alert→person/machine→runbook→rollback/fix→postmortem。

2）信号モデルおよび重症度

• critical （page）-SLO違反/マネーパスエラー（デポジット/出金）、ドロップ・イン・アベイラビリティ、バーンレート。
• 高い（ページ/チケット）-明らかなSLOの故障なしで大幅な劣化。
• ミディアム（チケット）-容量、背面の劣化、リトレイ。
• 低（通知）-トレンド、警告。

ルール：SLOによるページまたは明示的なビジネストリガーのみ。

3）ルーティングアーキテクチャ

1.ソース（Prometheus/Alertmanager、 Grafana、クラウドモニタリング、独自のWebhook）。
2.Шлюз （PagerDuty/Opsgenieサービス/統合）。
3.ポリシー：タグによるルート（'service'、 'env'、 'region'）、重大度、ペイロード。
4.エスカレーション：デューティレベルのシーケンス（L1→L2→menedzher）。
5.コミュニケーション：ChatOpsチャンネル、ステータスページ、郵送。

キータグの例（標準化）

'service'、 'env'、 'region'、 'version'、 'runbook'、 'release_id'、 'route'、 'tenant' （B2B/マルチテナントの場合）。

4）オンコールおよびエスカレーションのスケジュール

スケジュール：primary/secondary （SRE、 DBRE、 Sec）。
ローテーション：昼/夜、太陽、週末。
オーバーライド：残す/病気。
エスカレーション：ack-timeout 5-10 min→next layer。労働時間によって-プロフィール部門に；外部-通話プラットフォーム。

ヒント：夜間に短いエスカレーションステップを保ちます（疲労が少なくなります）、日中に長い（文脈があります）。

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 key：安定した指紋を使用します（例：service+route+code）。
5xxカスケードが数十ページを生成しないように、サービス/環境による'group_by'をグループ化します。
Mutes/quietウィンドウ：マイグレーション/リリース/ロードテスト中。
理由のための抑制：'api-gateway@prod'のP1インシデントがすでにある場合は、子P2/P3を抑制します。

アンチパターン：SLOへの影響が確認されていないCPU/メモリによるページ。

7）リリースおよび自動操作との接続

カナリアうつ病では、PagerDuty/OpsgenieはCI/CD→pause/rollback （Argo Rollouts/Helm）のSLOゲート→webhookからアラートを受信します。
アラートには、'release_id'、 'imageが含まれます。tag'、パイプラインとロールバックのrunbookへの参照。

注釈のrunbookリンクの例

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

8） ChatOpsとコミュニケーション

Slack/Teamsでインシデントチャンネルを自動作成し、チケットにリンクします。
Slash-Knowledge： 'ack'、 'assign@user'、 'status set'、 'postmortem start'。
ステータスページ-P1/P2で自動的に更新されます。

9）インシデントライフサイクル（最小）

1.トリガー（SLO/センサーからのアラート）。
2.ページ（プライマリ・オン・コール）。
3.Ack（確認、TTA）。
4.通信（チャンネル/ステータス）。
5.軽減（ロールバック/フィーチャーフラグ/アイソレーション）。
6.解決（TTR）。
7.死後（タイムライン、理由、アクション、レッスン、タスクの所有者）。

ロールキット：IC（インシデントコマンダー）、Ops lead、 Comms、 Scribe。

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/キュー-遅延/ロック/レプリケーション。
アプリケーションWebhook-ドメイン信号（PSPエラー、詐欺サージ）。

12）方針とコンプライアンス

ポリシー、スケジュール、mutasを作成/変更するRBAC。
監査：ステータス、タイムスタンプを認識/任命/変更した人。
ペイロードの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日以内にBurn-down postmortemアクション項目。

16）アンチパターン

ユーザーに影響を与えることなく、ハードウェア（CPU、ディスク）によるページ。
アラートの'group_by'→「storm」がない。
静かな窓はありません-すべてを赤く塗ります。
'service/env/runbook'なしのペイロード-ルーティング/実行できません。
単一の重大度スケールとルールはありません（各ソースは異なります）。
「永遠の」警告は、誰も（警報債務）を修復することはありません。

17）実装チェックリスト（0-45日）

0-10日

重要度の尺度を調整し、タグ/注釈を標準化します。
PagerDuty/Opsgenieでサービスを作成し、スケジュールと基本的なエスカレーションを設定します。
Alertmanager/Grafanaをバインドし、'group_by'とデッドアップを有効にします。

11-25日

SLOアラート（マルチウィンドウバーン）を入力し、リンクランブックを追加します。
ChatOpsの設定：自動チャンネル、ack/assignコマンド。
リリース/マイグレーションで静かなウィンドウを有効にします。

26-45日

カナリア（webhook）の自動一時停止/ロールバックを統合します。
MTTA/MTTRレポートとアラート衛生（ノイズクリーニング）を入力します。
Postmortemを標準化し、アクションアイテムを制御します。

18）準備ができたスニペット

Grafanaアラート→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ロールアウト一時停止

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と自動アクション（一時停止/ロールバック）。予算とUXでPagerDutyまたはOpsgenieを選択しますが、ノイズ、義務、責任の同じルールに固執すると、ページはまれで正確で有用であり、インシデントは短くて管理可能になります。