SRE本 第9章〜第11章 詳細まとめ【シンプルさ・アラート設計・オンコール対応】
🔰 はじめに
本記事では、SRE本の第9章「シンプルさ」、第10章「実践的なアラート」、第11章「オンコール対応」の内容を、より深く実務的な視点で解説・補足しています。
これら3章は「設計」「検出」「対応」というSRE活動の核心的な領域をカバーしています。単にツールを導入するだけではなく、設計思想・文化・プロセス改善の重要性に焦点を当てているのが特徴です。
第9章：シンプルさ（Simplicity）
🧱 複雑さがもたらすリスク
GoogleのSREは、複雑さを「運用コストの最大化装置」と見なしています。
複雑なシステムは以下のような課題を生みます：
- 障害発生時のトラブルシュート時間が延びる
- 担当者の属人化が進み、オンボーディングが困難になる
- 変更やリファクタリングの際に手が出せなくなる
- テストや監視のカバレッジが不足しやすくなる
「複雑さは障害そのものではないが、すべての障害を悪化させるブースターである」とGoogleは述べています。
🤔 なぜ複雑になってしまうのか？
- 新しい要件に次々対応した「足し算型開発」
- 機能ごとに設計者が異なり一貫性が失われる
- 「過去にうまくいった設計を再利用しすぎる」ことによるスパゲッティ化
- インフラ層での過剰な抽象化や自作フレームワークの濫用
✅ シンプル設計のための4つの視点
| 原則 | 具体例 |
|---|---|
| 理解可能性 | コンポーネント図1枚で全体の挙動が把握できるか |
| 再現性 | 再デプロイ・障害再現が容易にできるか |
| 観測性 | 内部状態や障害兆候がすぐ見えるか |
| 変更容易性 | 修正に自信が持てる構造か、テスト可能か |
🛠 シンプル化の戦略
- 責任境界を分割する（APIゲートウェイ／バックエンドの明示的分離など）
- 「削る」設計：今すぐ必要ない機能は後回しに
- プロダクトの縮小設計（Scope Limiting）
- オンボーディングテスト：新人が設計図を理解できるかを評価基準とする
📌 シンプルな設計がもたらす恩恵
- チーム間の引き継ぎが容易になり、サポート負担が減る
- システム理解にかかる時間が短縮され、新規採用者の戦力化が早まる
- 障害検知や対応の速度が向上し、MTTRが短縮
- 将来のスケーリングやリプレースに柔軟に対応できる
第10章：実践的なアラート（Practical Alerting）
🚨 なぜアラートが壊れるのか？
現場でよく見られるアラートに関する問題は次のようなものです：
- CPU使用率やメモリ消費など「インフラメトリクスの閾値超過」のみを基準としたアラート
- アクションに繋がらない通知ばかりで、チームが“アラート疲れ”を起こしている
- アラートにRunbookがリンクされておらず、都度調査や問い合わせが発生する
- 結果として、「アラートが鳴っても無視される」状態に陥る
組織的に「重要なアラートが無視される文化」が醸成されてしまうと、最終的にはSLO違反・ユーザー離脱という実害に繋がります。
✅ アラート設計の原則（Google流）
GoogleのSREチームでは、次の4つの観点をもとにアラート設計を見直します：
1. アクション可能性
- アラートを受け取った人が「今すぐに何をすべきか」が明確であること
- 逆に、即時対応が不要な通知はレポート化またはダッシュボードに移動
2. ユーザー影響の重視（SLOベース）
- 「CPU使用率 > 80%」ではなく、「p99のレイテンシがユーザーに影響している」などSLOに紐づけたメトリクス
- SLI（Service Level Indicator）と連携させ、顧客体験に直結するアラートのみを発火させる
3. 優先度（Severity）分類
- 通知を Warning（様子見） と Critical（即対応） に分類し、担当者の負担を最小化
- PagerDuty などのオンコールルーティングにも反映
4. ノイズの最小化
- 同じ障害で5つも10もの通知が鳴らないように、アラートの抑制（サプレッション）や結合を設計
- 例：単一Pod障害はスルーだが、特定割合を超えるとアラート化
🛠 アラート改善のステップ
| ステップ | 内容 |
|---|---|
| アラート棚卸し | 全通知ルールをリストアップし、対応されていないものを除去 |
| Runbook連携 | 通知メッセージに「対応手順」またはURLを必ず添付 |
| チューニングサイクル導入 | 月次レビューで通知数・対応履歴を分析し、削除・修正を継続 |
| チーム責任の明確化 | アラートごとに「メトリクスオーナー」を定義 |
🔧 実例：良いアラートと悪いアラート
| 項目 | 良いアラート | 悪いアラート |
|---|---|---|
| 内容 | 「p99レイテンシが5分以上SLO超過」 | 「CPUが85%超過」 |
| アクション性 | 再起動 or スケールアウトなどの判断が可能 | 原因不明、手動調査が必要 |
| Runbook | 再現手順・影響範囲・対応フロー記載 | 何をすべきか記載なし |
| 通知先 | SREチーム + Slack + PagerDuty | 全体通知、誰も対応しない |
📊 アラートメトリクスとダッシュボードの使い分け
- アラート：即時対応が必要なもの
- ダッシュボード：傾向や分析用（例：リリース影響チェック）
- レポート：SLO違反率や週次対応件数の定期報告用
🤖 ツールのベストプラクティス
| ツール | 機能 | 備考 |
|---|---|---|
| Prometheus | メトリクス収集とルール設計 | カスタムルールが柔軟 |
| Alertmanager | 通知のルーティング・抑制 | SlackやPagerDutyと連携 |
| Grafana | ダッシュボード可視化 | アラート状況のトレンド分析にも |
| PagerDuty | オンコール管理 | Escalation Policyと統合 |
| Runbook（Google Docs等） | 手順書管理 | 通知テンプレートにリンク推奨 |
📌 まとめ
- アラートは「誰に」「どのように」「何をさせたいのか」が明確でなければ意味がない
- 通知しすぎるシステムは“壊れたアラート文化”を招く
- SREの目標は「静かで意味あるアラート環境を作ること」
🚀 実践アクション
- 全アラートをリストアップし、対応履歴がないものを洗い出す
- SLO/SLAと紐づかないメトリクス通知を削除または変更
- アラート → Runbook → Slack/PagerDuty連携の一貫したフローを整備
第11章：オンコール対応（On-Call Responsibilities）
🔰 はじめに
オンコール（On-Call）は、SRE活動の中でも特に人に負荷が集中しやすい領域です。
Googleでは、オンコール対応は「犠牲的奉仕」ではなく「信頼性を支える文化の一部」と捉えています。
本章では、持続可能なオンコール体制を作るための設計・運用・改善サイクルの重要性が詳述されています。
💤 オンコールがつらくなる原因
| 原因 | 説明 |
|---|---|
| アラート疲れ | 毎晩意味のないアラートで呼び出される |
| 属人化 | 対応できる人が限られていて、対応負担が一部に集中 |
| Runbook未整備 | 手順がないため、その場で手探り調査が必要 |
| 不公平なローテーション | 一部メンバーに夜間・週末が集中 |
| エスカレーション不備 | 担当がいないときのルールが不明確 |
これらが慢性化すると、オンコールは「信頼性を守る行動」ではなく「不満の温床」となります。
✅ 持続可能なオンコール体制を作る7原則
-
アラート量の最適化
→ 本当に対応が必要なものだけが鳴るよう設計する（SLO違反ベース） -
自動対応の導入
→ 例：CPU使用率高騰 → 自動スケーリング or 再起動 -
Runbookと必ず連携
→ 通知から1クリックで「対応方法」が確認できる設計 -
カバレッジの見える化
→ 誰が・いつ・何時間アラートを受けたかを可視化して公平性を保つ -
オンコールレビュー文化
→ 毎月「今月のアラートは正しかったか？改善点は？」をレビューする -
エスカレーションポリシーの整備
→ 時間帯・重大度に応じて段階的に通知先を変える -
心理的安全性の確保
→ 対応に失敗しても責めない。むしろ改善に繋げる文化を育てる
🧠 GoogleのSREでの実践
- オンコール履歴（呼び出し時間・対応時間・SLO達成率）をBigQueryで可視化
- アラートの50%以上が無対応だった場合、その通知ルールは削除検討
- トイル化した手順（毎回再起動など）は週次で自動化チケット化
- 「睡眠を妨げないオンコール」を設計方針の1つとして明言
📊 オンコール運用のKPI指標
| 指標 | 意味・活用法 |
|---|---|
| アラート件数（週次・月次） | 通知数の多さ＝仕組みの悪さの指標 |
| MTTA / MTTR | 平均検知時間・平均復旧時間（速度と対応力のバランス） |
| Sleep Disruption Rate | 深夜0時〜6時のアラート割合（持続可能性の判断） |
| Escalation Rate | 一次対応で完了しない割合（Runbook整備・教育の指標） |
🛠 オンコール疲れを軽減する実装戦略
- 夜間アラートのフィルタリング：深夜帯の通知はSLO直結・緊急度P1のみに限定
- 自動診断Botの導入：障害原因の候補や過去チケットをSlack通知に添付
- Postmortem作成の標準化：毎回ではなく、重大障害のみテンプレに基づき記録
📘 オンコール文化と心理的安全性
Googleでは、オンコールの目的は「人間の責任を問う」ことではなく「仕組みの改善ポイントを見つけること」にあります。
- オンコールで失敗したら、責めるのではなく仕組みのどこが悪かったかを振り返る
- 定期的に「オンコールのやりたくなさ」が上がってきたら、真っ先に仕組みを疑う
- オンコールの質＝チーム文化の質
📌 まとめ
- オンコールは“緊急時の保険”ではなく“信頼性運用の最前線”
- 「つらいオンコール」はシステム設計と文化の失敗
- SREの目標は、「必要最小限の呼び出しで最大限の信頼性を守る」こと
🚀 次にやること
- 過去3ヶ月分のオンコール通知ログを分析
- 「誰が」「何件」「どんな内容」で呼ばれているかを可視化
- 自動化できる対応を整理し、Runbookを整備
- オンコール担当同士で月1レビューを導入