アラート

アラート設計、オンコール、インシデント対応

アラートは問題を検知して通知する仕組み。良いアラートは「アクショナブル」であり、受け取った人が何をすべきか明確です。過剰なアラートはアラート疲れを招きます。

良いアラートの条件

アクショナブル

アラートを受けたら何かアクションが必要。「見るだけ」のアラートは削除。

緊急性が明確

今すぐ対応が必要か、翌営業日でよいか。深夜に起こす価値があるか。

コンテキストが豊富

何が起きているか、どこで、いつから。 Runbookへのリンク。

ノイズが少ない

一時的なスパイクで発報しない。適切な閾値と期間の設定。

アラートの種類

Critical（緊急）

サービス停止、データ損失の危険。即座に対応が必要。 24時間365日、オンコール担当者に通知。

例: サービスダウン、エラー率90%超、ディスク99%

Warning（警告）

問題が発生しているが、サービスは稼働中。営業時間内に対応。Slackチャンネル通知。

例: レイテンシ増加、エラー率上昇、ディスク80%

Info（情報）

参考情報。ダッシュボードに表示、通知は不要。トレンド分析、キャパシティプランニング用。

例: デプロイ完了、スケールアウト実行

アラート設計のポイント

症状ベース vs 原因ベース

症状ベース（推奨）
「エラー率が5%を超えた」
ユーザー影響に直結。

原因ベース
「CPU使用率が90%」
原因だが、影響がないことも。

閾値と期間

• 一瞬のスパイクで発報しない（for: 5m など）
• 閾値は実績に基づいて設定
• 定期的に閾値を見直し

Prometheus アラートルール例

yaml

1 groups:
2   - name: service-alerts
3     rules:
4       # エラー率アラート（症状ベース）
5       - alert: HighErrorRate
6         expr: |
7           sum(rate(http_requests_total{status=~"5.."}[5m]))
8           / sum(rate(http_requests_total[5m])) > 0.05
9         for: 5m
10         labels:
11           severity: critical
12         annotations:
13           summary: "High error rate detected"
14           description: "Error rate is {{ $value | humanizePercentage }}"
15           runbook_url: "https://wiki.example.com/runbooks/high-error-rate"
16 
17       # レイテンシアラート
18       - alert: HighLatency
19         expr: |
20           histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1
21         for: 10m
22         labels:
23           severity: warning
24         annotations:
25           summary: "P95 latency exceeds 1 second"

オンコール運用

オンコールとは

24時間365日、緊急アラートに対応できる体制。ローテーションで担当者を決め、アラートがあれば対応する。

ツール

• PagerDuty: オンコール管理の定番
• OpsGenie: Atlassian製
• VictorOps: Splunk製

エスカレーションポリシー

1次対応者 → 5分応答なし → 2次対応者 → 10分応答なし → マネージャー

ローテーション

週単位でローテーション。休日や長期休暇を考慮。バーンアウト防止のため負担を分散。

インシデント対応フロー

検知

アラート発報

→

トリアージ

影響範囲確認

→

対応

復旧作業

→

復旧

正常確認

→

振り返り

ポストモーテム

Incident Commander（IC）

インシデント対応の指揮者。状況把握、タスク割り当て、コミュニケーション管理。

コミュニケーション

専用チャンネル（#incident-YYYYMMDD）で情報集約。ステークホルダーへの定期アップデート。

Runbook

アラートごとの対応手順書。初動対応、確認事項、エスカレーション基準。

ポストモーテム（振り返り）

インシデント後の振り返り。ブレームレス（個人を責めない）文化で、システム改善に焦点を当てる。

ポストモーテムの構成

1. 概要: 何が起きたか、影響範囲、タイムライン
2. 根本原因: なぜ起きたか（5 Whys分析）
3. 対応: 何をしたか、うまくいったこと/いかなかったこと
4. アクションアイテム: 再発防止策、担当者、期限
5. 教訓: 学んだこと、改善点

アラート疲れ対策

アラート疲れ: アラートが多すぎて無視されるようになる状態。本当に重要なアラートを見逃す原因。

定期的なアラートレビュー

発報したがアクション不要だったアラートを削除/調整

アラートの集約

類似アラートをグループ化。100件のアラートより1件のサマリ。

自動修復（Self-healing）

可能なら自動で復旧。人間はエスカレーション時のみ対応。

SLOベースアラート

エラーバジェット消費率でアラート。ユーザー影響に直結。

通知チャンネル設計

重要度	チャンネル	例
Critical	電話、SMS、PagerDuty	サービスダウン
Warning	Slack（メンション）、メール	エラー率上昇
Info	Slack（通常）、ダッシュボード	デプロイ完了

1	groups:
2	- name: service-alerts
3	rules:
4	# エラー率アラート（症状ベース）
5	- alert: HighErrorRate
6	expr: \|
7	sum(rate(http_requests_total{status=~"5.."}[5m]))
8	/ sum(rate(http_requests_total[5m])) > 0.05
9	for: 5m
10	labels:
11	severity: critical
12	annotations:
13	summary: "High error rate detected"
14	description: "Error rate is {{ $value \| humanizePercentage }}"
15	runbook_url: "https://wiki.example.com/runbooks/high-error-rate"
16
17	# レイテンシアラート
18	- alert: HighLatency
19	expr: \|
20	histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m])) > 1
21	for: 10m
22	labels:
23	severity: warning
24	annotations:
25	summary: "P95 latency exceeds 1 second"