ストーリー
佐
佐藤CTO
根本原因がわかった。次は同じことを二度と起こさない仕組みを作る番だ
佐
佐藤CTO
“気をつける”は対策ではない。システムで防ぐ仕組みを作るんだ
アクションアイテムの分類
優先度マトリクス
| 優先度 | 基準 | 期限 | 例 |
|---|---|---|---|
| P0 | 同じ障害が今すぐ再発しうる | 1週間 | 緊急パッチ、設定修正 |
| P1 | 類似の障害リスクが高い | 1ヶ月 | 監視追加、テスト強化 |
| P2 | 長期的な改善 | 四半期 | アーキテクチャ改善、自動化 |
| P3 | あると良い改善 | バックログ | ドキュメント整備、ツール改善 |
良いアクションアイテムの特徴
| 特徴 | 良い例 | 悪い例 |
|---|---|---|
| 具体的 | DB接続数の監視アラートを追加する | 監視を強化する |
| 測定可能 | 負荷テストにDB接続数チェックを追加 | テストを改善する |
| 担当明確 | SREチーム田中が実施 | 誰かがやる |
| 期限あり | 2月28日までに完了 | なるべく早く |
| 自動化志向 | CI/CDにDB接続数チェックを組み込む | 次回から気をつける |
再発防止の4つのレベル
Level 4: 発生不可能にする（設計で排除）
└─ 例: N+1クエリを型レベルで防止するORM制約
Level 3: 自動検知・自動修復する
└─ 例: DB接続数超過時に自動スケール
Level 2: 自動検知・手動修復する
└─ 例: DB接続数のアラート + ランブック
Level 1: 手動検知・手動修復する
└─ 例: 定期的なメトリクスレビュー目標: できるだけ高いレベルの対策を実施する
エラーバジェットポリシーとの連携
エラーバジェット消費時のアクション
| エラーバジェット残量 | アクション |
|---|---|
| 75%以上 | 通常の開発速度 |
| 50-75% | 信頼性改善タスクの優先度を上げる |
| 25-50% | 新機能開発を50%に制限、信頼性改善に注力 |
| 25%未満 | 新機能開発を停止、信頼性改善のみ |
| 枯渇 | 全チームで信頼性改善に集中 |
アクションアイテムの追跡
追跡テンプレート
| ID | タイトル | 優先度 | 担当 | 期限 | ステータス |
|---|---|---|---|---|---|
| AI-001 | DB接続数の監視アラート追加 | P0 | SRE田中 | 2/21 | 完了 |
| AI-002 | 負荷テストにDB接続チェック追加 | P1 | QA鈴木 | 3/14 | 進行中 |
| AI-003 | N+1検出のlintルール追加 | P1 | Dev佐々木 | 3/14 | 未着手 |
| AI-004 | コネクションプール自動スケール | P2 | SRE高橋 | 4/30 | 未着手 |
レビューサイクル
| 頻度 | 内容 |
|---|---|
| 週次 | P0/P1アクションアイテムの進捗確認 |
| 月次 | 全アクションアイテムのレビュー |
| 四半期 | 再発防止策の有効性評価 |
まとめ
| ポイント | 内容 |
|---|---|
| アクションアイテム | 具体的・測定可能・担当明確・期限付き |
| 4レベル | 「発生不可能にする」を最上位目標とする |
| エラーバジェット | 残量に応じて開発と信頼性のバランスを調整 |
| 追跡 | 定期レビューで完了まで追跡する |
次のステップへ
次は演習でインシデント対応を実践します。
推定読了時間: 20分