DevOps の可観測性（Observability）入門 — ログ・メトリクス・トレースで「なぜ壊れたか」に答える
DevOps を推進する立場になると、障害対応の「速さ」と「再発防止」を両立させる仕組みが避けて通れません。その中核にあるのが **可観測性（Observability）**です。
本記事では、監視（Monitoring）との違いを起点に、ログ / メトリクス / トレースをどう使い分け、どう相関させると「なぜ壊れたか」に近づけるのかを、リーダー層の意思決定に繋がる形で整理します。
1. 可観測性とは何か：モニタリングとの違いは「未知への問い」
モニタリング（監視）は、ざっくり言うと「想定した異常を見張る」行為です。CPU 使用率の閾値、エラー率、ディスク逼迫など、既知の失敗モードを検知する設計になりがちです。
一方、可観測性は「システムの外から得られるデータで、内部状態を推測して問い詰められる」性質です。ポイントは 未知の失敗モードに対して、探索的に「何が起きたか」「なぜ起きたか」を辿れること。言い換えると、アラートの有無ではなく **探索可能性（explorability）**が価値の中心にあります。
実務への影響
- 監視だけだと「鳴ったアラートに対応する運用」になり、想定外の壊れ方（依存先の遅延、部分的障害、デグレ、設定ドリフト）で手が止まりやすい。
- 可観測性を設計すると、障害時の会話が「誰が知ってる？」から「データ上、どこまで言える？」に変わり、属人性が下がる。
筆者の評価・意見（ポジティブ/ネガティブ）
- ポジティブ：可観測性は、障害対応を「勇者待ち」から「仕組み」に変える投資です。特に分散システムでは、これがないと原因究明が運任せになります。
- ネガティブ：「可観測性＝ツール導入」と誤解されるリスクが高い。実際の難所は、どこに何を計装し、どう相関させるかというデータ設計です。ツールはその後です。
背景分析・今後の展望（なぜ起きているか）
マイクロサービス化・クラウド化で、障害原因が「単一サーバの異常」から「サービス間の連鎖」「依存先のボトルネック」「非同期処理の詰まり」に移りました。
この世界では、閾値監視だけでは “起点” は掴めても “因果” が辿れません。結果として、ログ・メトリクス・トレースを相関して探索する可観測性が重要になっています。
2. 三本柱：ログ / メトリクス / トレースは「得意分野」が違う
可観測性は三本柱で語られます。大事なのは「どれかを選ぶ」ではなく、相互参照できる状態にすることです。
それぞれ何に向くか
- ログ（Logs）：事後の証拠、詳細、例外スタック、監査。
- 向く：局所原因の確定、バグの特定、リクエスト単位の事実確認
- 弱い：全体傾向の把握（量が多いほど厳しい）
- メトリクス（Metrics）：数値化された時系列。傾向、異常、SLO 計測、容量計画。
- 向く：全体状況の把握、SLO の計算、アラートの起点
- 弱い：原因の確定（「何が悪いか」は見えても「なぜ」は不足）
- トレース（Traces）：分散トランザクションの呼び出し連鎖。遅延や失敗の起点。
- 向く：分散依存のボトルネック探索、影響範囲把握
- 弱い：各地点の詳細な証拠（結局ログに戻ることが多い）
「検知→探索→確証→復旧」の流れ（メトリクス→トレース→ログ）
以下の図は、障害対応で三本柱がどう連携すると強いかを示します。
この図から読み取ってほしい点は次の3つです。
- メトリクスは「異常の入口」、トレースは「経路」、ログは「証拠」になりやすい。
- TraceID などで相関できると、行ったり来たりが高速化する。
- 速さは個人の勘ではなく、データの繋がりで作れる。
実務への影響
- リーダーが最初に問うべきは「ログ/メトリクス/トレースがあるか」より、同じ相関IDで横断できるかです。ここが繋がっていないと、三本柱が揃っていても探索が遅い。
- 「収集の標準化（どのエージェント/収集器に寄せるか）」は、将来のツール選択や移行コストに効きます。近年は OpenTelemetry を軸にした“配線”が業界標準に寄っており、ベンダーロックイン回避の説明もしやすくなっています。
筆者の評価・意見
- ポジティブ：三本柱の相互参照は、障害対応の会話を「推測」から「検証」に変えます。これは MTTR を削る最短距離になりがちです。
- ネガティブ：データを集めるほどコストが増え、収集器設定も複雑化します。結果として「設定変更が怖い」状態になることがあります。可観測性のパイプライン自体を変更管理（レビュー・テスト）する発想が必要です。
3. なぜ DevOps で効くか：MTTR と DORA Four Keys に直結する
DevOps の文脈で可観測性が効く理由は明快で、障害対応の探索が速くなるほど 復旧が速くなるからです。DORA Four Keys で言えば、特に次の2つと接続します。
- サービス復旧時間（Time to restore service）：障害発生から復旧までの時間
- 変更障害率（Change fail rate）：変更が障害やロールバックにつながる割合
実務への影響
- 復旧時間短縮：メトリクスで異常を掴み、トレースで影響範囲と経路を絞り、ログで確証を取れると、「切り分け会議」の時間が縮みます。
- 変更障害率の改善：原因が特定できるほど、再発防止が“精神論”になりにくい。どの変更がどの経路に影響したかを追えると、リリース判断も合理化しやすい。
筆者の評価・意見
- ポジティブ：可観測性投資は「運用の趣味」ではなく、DORA 指標の改善に繋がるため、経営・マネジメントとの合意形成がしやすい。
- ネガティブ：可観測性だけ導入しても、インシデント運用（優先度、切り戻し基準、ポストモーテム）が弱いと、ダッシュボードが増えるだけで復旧が速くならない。仕組み（データ）と運用（意思決定）をセットで設計する必要があります。
比較：伝統的な監視中心 vs 可観測性中心
- 監視中心：閾値アラート→手順書→復旧（原因は後追いになりやすい）
- 可観測性中心：SLO 逸脱や異常→探索→原因→復旧→恒久対策（探索が前提）
「どちらが上」ではなく、監視は入口として重要です。ただし分散化した今の現場では、入口だけでは足りず、探索能力の整備が差になります。
4. SLI / SLO / エラーバジェット：SRE と繋がる“意思決定の言語”
可観測性はデータの話に見えますが、リーダー層にとって重要なのは 意思決定です。そこで SRE の枠組み（SLI/SLO/エラーバジェット）が効きます。
- SLI（Service Level Indicator）：ユーザー体験を表す測定値（例：成功率、レイテンシ）
- SLO（Service Level Objective）：その目標値（例：成功率 99.9%）
- エラーバジェット：SLO を満たさなかった“許容枠”。信頼性と開発速度のトレードオフを扱う道具
実務への影響
- SLO は「監視項目」ではなく、プロダクトと運用が合意した守るべき体験です。合意があると、障害時の優先順位が揃います。
- エラーバジェットは「守れなかった時に何を止めるか」を決める仕組みになり得ます。たとえばバジェット消費が大きい期間は、機能開発より信頼性改善を優先する、といった判断が可能です。
エラーバジェットを使った分岐（開発速度と信頼性の調停）
観察ポイントは2つです。
- SLO は「守る」だけでなく、守れないときの行動（ポリシー）まで含めて初めて機能する。
- 可観測性の三本柱は、このループを回すための“計測と探索”の土台です。
筆者の評価・意見
- ポジティブ：SLO/エラーバジェットを入れると、「緊急だから全部止める」か「納期だから全部進める」かの二択から抜けられます。判断をデータと合意に寄せられる。
- ネガティブ：形だけ導入すると形骸化します。ユーザー価値とズレた SLI、達成不能な SLO、バジェット消費時に何もしない運用——このいずれかが起きると、SLO は単なる報告資料になります。
5. リーダー層が押さえる導入の勘所（概念レベル）
ハンズオンやツール設定の前に、推進担当として合意を取りにいく論点をまとめます。
「未知に答える」ことを目的に置く
監視項目の追加ではなく、障害時に「次の問い」を進められるデータ設計に投資する。相関（TraceID 等）を最優先する
ログ・メトリクス・トレースが別々にあっても、繋がらないと復旧は速くならない。DORA と接続して説明する
可観測性は「サービス復旧時間」「変更障害率」を改善する施策として語れる。投資対効果の説明が通りやすい。SLO を“運用の契約”として置く
SLO は計測の話で終わらない。エラーバジェット消費時の判断（変更を絞る、恒久対策を優先）まで含めて設計する。
まとめ：可観測性は「障害対応の会話」を変える
- 監視は既知の異常検知、可観測性は未知の原因探索に強い。違いは探索可能性にある。
- 三本柱は役割が違い、価値は相互参照（メトリクス→トレース→ログ）で最大化する。
- DevOps では MTTR 短縮に直結し、DORA の「サービス復旧時間」「変更障害率」と繋げて語れる。
- SLI/SLO/エラーバジェットは、信頼性と変更速度のトレードオフを意思決定に落とす枠組みで、可観測性のデータがその土台になる。
次回（シリーズ第6回）では、DevSecOps などセキュリティ領域と DevOps の接続を扱うと、推進の全体像がより立体的になります。