インシデント対応の現実
深夜3時にPagerDutyのアラートが鳴る。寝ぼけ眼でSlackを開き、ダッシュボードを確認し、原因を特定し、修正を適用する。この一連の作業にかかる時間は平均45分——しかしその80%は「状況把握」と「定型的な対応手順の実行」だ。
KGAではクライアント10社以上のインシデント対応体制を構築してきた。その経験から断言できるのは、インシデント対応の大部分は自動化可能だということだ。完全な自動化ではない。判断が必要な部分は人間が行う。しかし情報収集、初期診断、定型対応は確実に自動化できる。
PagerDutyを中心としたインシデント管理
KGAの標準構成: アラートソースはDatadog（インフラ/APMメトリクス）、Sentry（アプリケーションエラー）、CloudWatch（AWSリソース）をPagerDuty Event APIv2に集約。エスカレーションはLevel 1（即時→当番SRE）、Level 2（10分後→SREリーダー）、Level 3（30分後→VP of Engineering）。Level 1応答率97%（SLA目標95%）。
アラート品質管理が最重要だ。対応不要アラートが月間10%を超えたらルールを見直す。ノイズ率を月次追跡し、現在は対応不要率5.2%まで改善した。
Slack Botによる自動診断
インシデント発生時、KGA開発のSlack Bot「Watchdog」が30秒以内に以下を自動実行する。Datadogからエラー率・レイテンシ・リソース使用率のグラフを投稿。GitHub APIから直近1時間のデプロイ履歴と変更サマリーを取得。CloudWatch Logs Insightsでエラーログ上位5件を抽出。過去のインシデントDBから類似事象と対応手順を提示。
これによりSREのダッシュボード巡回時間を平均15分削減している。
自動ランブックとAuto-remediation
ランブックはAWS Systems Manager Automation Documentで実装。YAMLで定義し、条件分岐、承認ステップ、ロールバック手順を含む。「Podのメモリ不足」ランブック: 対象Pod特定（自動）→ メモリ確認（自動）→ Pod再起動（承認後自動）→ メモリリミット引き上げ提案（自動、適用は承認後）→ 再発監視設定（自動）。
承認はSlackボタンUIで、スマートフォンからも可能。実績: 全インシデントの38%がランブック全自動実行で解決、27%が承認1回の半自動で解決、手動介入は35%に削減。
Auto-remediationパターン: ディスク85%超過→自動ログローテーション+一時ファイル削除。SSL証明書→30日前に自動更新。Pod OOMKill→自動再起動+メモリリミット1.5倍調整。鉄則は「安全性の証明」。データベース操作や顧客データに影響する処理は絶対に対象にしない。
ポストモーテム文化
KGAのポストモーテムテンプレート: インシデント概要、タイムライン、根本原因分析（5 Whys）、対策（短期・中期・長期）、教訓。最重要原則は「blame-free」。「なぜ○○さんがミスをしたか」ではなく「なぜシステムがそのミスを許容したか」を問う。
全ポストモーテムを社内Wikiに公開し、月1回の読書会で過去のインシデントから学ぶ。この文化的投資がMTTRを1年間で65%改善した最大の要因だ。