LESSON 25分

ストーリー

佐
佐藤CTO
インシデントを解決しただけでは50点だ。なぜ起きたかを理解してこそ100点になる
佐
佐藤CTO
重要なのは人を責めないこと。システムと仕組みの問題を見つけることだ

ブレイムレスカルチャー

原則

原則説明
人ではなくシステムに着目「誰がミスしたか」ではなく「なぜシステムがミスを許したか」
心理的安全性の確保正直に報告しても罰せられない環境
学習の最大化「犯人探し」より「学びの最大化」を目的とする
改善への投資分析結果を仕組みの改善に繋げる

RCA手法

1. 5 Whys（なぜなぜ分析）

graph TD
    P["問題: 本番サービスが30分停止した"]
    W1["Why 1: デプロイ後にDBコネクションエラーが大量発生"]
    W2["Why 2: コネクションプールの上限を超えた"]
    W3["Why 3: 新機能が大量のDBクエリを発行していた"]
    W4["Why 4: 負荷テストでDB接続数を計測していなかった"]
    W5["Why 5: 負荷テストのチェックリストにDB接続数がなかった"]
    RC["根本原因: 負荷テストのチェック項目にDB接続数が含まれていない<br/>対策: チェックリストにDB接続数メトリクスを追加"]

    P --> W1 --> W2 --> W3 --> W4 --> W5 --> RC

    style RC fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px

2. フィッシュボーン図（特性要因図）

graph LR
    P["人<br/>・スキル不足<br/>・引き継ぎ不足"] --> F["本番障害"]
    PR["プロセス<br/>・レビュー手順の不備<br/>・テスト項目の漏れ"] --> F
    E["環境<br/>・本番と差異<br/>・リソース不足"] --> F
    T["ツール<br/>・監視の不備<br/>・アラート設定漏れ"] --> F
    D["設計<br/>・単一障害点<br/>・スケール限界"] --> F

    style F fill:#ffebee,stroke:#c62828,stroke-width:2px

3. タイムライン分析

時刻イベントカテゴリ
13
デプロイ開始変更
13
デプロイ完了変更
14
エラー率上昇開始症状
14
アラート発報検知
14
IC任命対応
14
DB接続エラーを特定発見
14
ロールバック実施対応
14
エラー率正常化回復

気づき: デプロイ完了からアラート発報まで15分のギャップ → 検知の遅延が改善ポイント

4. 障害ツリー分析（FTA）

graph TD
    TOP["サービス停止"]
    DB["DB障害"]
    NET["ネットワーク障害"]
    CONN["接続枯渇"]
    QUERY["クエリ遅延"]
    DISK["ディスクフル"]
    POOL["コネクションプール不足"]
    N1["N+1クエリ問題"]

    TOP --> DB
    TOP --> NET
    DB --> CONN
    DB --> QUERY
    DB --> DISK
    CONN --> POOL
    POOL --> N1

    style TOP fill:#ffebee,stroke:#c62828,stroke-width:2px

寄与要因の特定

直接原因 vs 寄与要因

種類説明例
直接原因障害を直接引き起こした事象N+1クエリによるDB接続枯渇
寄与要因障害を可能にした/悪化させた条件負荷テスト不足、監視の不備
根本原因改善すれば再発を防げる最も根本的な要因テストプロセスの不備

まとめ

ポイント内容
ブレイムレス人ではなくシステム・仕組みに着目する
5 Whys「なぜ」を繰り返して根本原因に到達
フィッシュボーン多面的に原因を分類・整理する
タイムライン時系列で事象を整理し、ギャップを発見する

次のステップへ

次は再発防止策の策定方法を学びます。

推定読了時間: 25分