SREノススメ　其の７

# 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の目標は「**静かで意味あるアラート環境を作ること**」

---

## 🚀 実践アクション

1. 全アラートをリストアップし、対応履歴がないものを洗い出す
2. SLO/SLAと紐づかないメトリクス通知を削除または変更
3. アラート → Runbook → Slack/PagerDuty連携の一貫したフローを整備

---
# 第11章：オンコール対応（On-Call Responsibilities）

## 🔰 はじめに

オンコール（On-Call）は、SRE活動の中でも特に**人に負荷が集中しやすい**領域です。  
Googleでは、オンコール対応は「犠牲的奉仕」ではなく「**信頼性を支える文化の一部**」と捉えています。

本章では、持続可能なオンコール体制を作るための設計・運用・改善サイクルの重要性が詳述されています。

---

## 💤 オンコールがつらくなる原因

| 原因 | 説明 |
|------|------|
| アラート疲れ | 毎晩意味のないアラートで呼び出される |
| 属人化 | 対応できる人が限られていて、対応負担が一部に集中 |
| Runbook未整備 | 手順がないため、その場で手探り調査が必要 |
| 不公平なローテーション | 一部メンバーに夜間・週末が集中 |
| エスカレーション不備 | 担当がいないときのルールが不明確 |

これらが慢性化すると、オンコールは「信頼性を守る行動」ではなく「**不満の温床**」となります。

---

## ✅ 持続可能なオンコール体制を作る7原則

1. **アラート量の最適化**  
   → 本当に対応が必要なものだけが鳴るよう設計する（SLO違反ベース）

2. **自動対応の導入**  
   → 例：CPU使用率高騰 → 自動スケーリング or 再起動

3. **Runbookと必ず連携**  
   → 通知から1クリックで「対応方法」が確認できる設計

4. **カバレッジの見える化**  
   → 誰が・いつ・何時間アラートを受けたかを可視化して公平性を保つ

5. **オンコールレビュー文化**  
   → 毎月「今月のアラートは正しかったか？改善点は？」をレビューする

6. **エスカレーションポリシーの整備**  
   → 時間帯・重大度に応じて段階的に通知先を変える

7. **心理的安全性の確保**  
   → 対応に失敗しても責めない。むしろ改善に繋げる文化を育てる

---

## 🧠 GoogleのSREでの実践

- オンコール履歴（呼び出し時間・対応時間・SLO達成率）をBigQueryで可視化
- アラートの50%以上が無対応だった場合、その通知ルールは削除検討
- トイル化した手順（毎回再起動など）は週次で自動化チケット化
- 「睡眠を妨げないオンコール」を設計方針の1つとして明言

---

## 📊 オンコール運用のKPI指標

| 指標 | 意味・活用法 |
|------|--------------|
| アラート件数（週次・月次） | 通知数の多さ＝仕組みの悪さの指標 |
| MTTA / MTTR | 平均検知時間・平均復旧時間（速度と対応力のバランス） |
| Sleep Disruption Rate | 深夜0時〜6時のアラート割合（持続可能性の判断） |
| Escalation Rate | 一次対応で完了しない割合（Runbook整備・教育の指標） |

---

## 🛠 オンコール疲れを軽減する実装戦略

- **夜間アラートのフィルタリング**：深夜帯の通知はSLO直結・緊急度P1のみに限定
- **自動診断Botの導入**：障害原因の候補や過去チケットをSlack通知に添付
- **Postmortem作成の標準化**：毎回ではなく、重大障害のみテンプレに基づき記録

---

## 📘 オンコール文化と心理的安全性

Googleでは、オンコールの目的は「人間の責任を問う」ことではなく「**仕組みの改善ポイントを見つけること**」にあります。

- オンコールで失敗したら、責めるのではなく仕組みのどこが悪かったかを振り返る
- 定期的に「オンコールのやりたくなさ」が上がってきたら、真っ先に仕組みを疑う
- オンコールの質＝チーム文化の質

---

## 📌 まとめ

- オンコールは“緊急時の保険”ではなく“信頼性運用の最前線”
- 「つらいオンコール」はシステム設計と文化の失敗
- SREの目標は、「**必要最小限の呼び出しで最大限の信頼性を守る**」こと

---

## 🚀 次にやること

1. 過去3ヶ月分のオンコール通知ログを分析
2. 「誰が」「何件」「どんな内容」で呼ばれているかを可視化
3. 自動化できる対応を整理し、Runbookを整備
4. オンコール担当同士で月1レビューを導入

---