# ドリルダウン分析 ## 定義 ドリルダウン分析は、高いレベルで問題を解析するところから始め、関係のなさそうな領域を捨てて焦点を絞り込み、根本原因を見つけるためにソフトウェアスタック(必要ならハードウェアまで)を深く掘り下げていく観察型メソドロジである。3段階からなる。(1) モニタリング: 時系列的に高レベルの統計量を全社規模で記録し、問題の検出やアラートに使う(SNMP や指標エクスポータが典型的な実装)。(2) 特定: サーバーを直接対象に CPU・ディスク・メモリ等のコンポーネントを vmstat(8)・iostat(1)・mpstat(1) や GUI ダッシュボードでチェックし、疑わしい領域を絞り込む。(3) 分析: トレーシングやプロファイリングをベースとしたツール(strace(1)、perf(1)、BCC、bpftrace、Ftrace 等)で疑わしい領域をさらに精査し、必要ならカスタムツールやソースコード確認まで踏み込む。Netflix クラウドでの実装例では、Atlas(モニタリング)→ perfdash/Netflix Vector(特定、USE メソッド指標を使用)→ FlameCommander とコマンドラインツール(分析)という3段階が対応する。補助メソドロジとして、なぜなぜ分析(Five Whys)があり、「なぜか」を5回(またはそれ以上)繰り返して根本原因まで掘り下げる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.12) ## 横断的知見 - **2章の3段階モデル(モニタリング→特定→分析)は、16章の実際の障害調査では「60秒チェックリスト→USEメソッド→PMC/ソフトウェアイベント/トレーシング」という具体的なツール連鎖として現れる**: 16章では、`uptime`・`mpstat`等による60秒チェックリストとUSEメソッドの適用が2章の「特定」段階に相当し(vmstat(8)・iostat(1)・mpstat(1)というまさに2章が挙げる典型ツールが使われている)、続くPMC・`perf stat`・BCC(`cpudist(8)`)による深掘りが「分析」段階に相当する。ただし16章では「モニタリング」段階(全社規模の時系列記録によるアラート)への言及はなく、調査は最初から特定・分析の2段階に絞られている。これは、16章の事案がすでに人手で報告された既知の問題(パフォーマンス向上が「うますぎる」という報告)であり、モニタリングによる検出を経て持ち込まれたものだったためと考えられる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.12, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.2-16.1.7) - **16章は「関係のなさそうな領域を捨てて焦点を絞り込む」というドリルダウン分析の定義どおりの手順を具体的に示す**: [[USE メソッド]]でCPUに絞り込んだ後、iostat(1)・sar(1)でディスクI/O・ネットワークI/Oがボトルネックでないことを確認して除外し、CPU一本に絞ってPMC以降の深掘りに進んでいる。この「除外による絞り込み」は2章の定義が抽象的に述べる「関係のなさそうな領域を捨てる」を、実際にどのツール(iostat・sar)でどう確認するかまで具体化した実例になっている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.12, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.3) ## 未解決の問い - ドリルダウン分析の3段階(モニタリング→特定→分析)は、[[根本原因分析]]の一般的な枠組みとどのように対応・分岐するか。とりわけ分散システムにおける根本原因分析研究では、単一ホストを前提とするこの3段階モデルがどこまで通用するか。 - なぜなぜ分析(Five Whys)は各ステップでの「なぜか」の答えが一意に定まらない(複数の並行原因がある)場合にどう扱うべきか。本章はこの分岐の扱いに触れていない。 - 16章のように「モニタリング」段階を経ずに特定・分析だけで進む調査は、3段階モデル全体のうちどの割合を占めるのか。モニタリング段階を省略できる条件(既知の問題報告がある場合等)を一般化できるか、他章のケーススタディ ingest で確認したい。 ## 関連 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] — ドリルダウン分析となぜなぜ分析の原典解説(§2.5.12)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] — 60秒チェックリスト→USEメソッド→PMC/トレーシングという具体的なドリルダウンの実務適用例(§16.1.2-16.1.7)。 - [[根本原因分析]] — 関連する一般的な障害調査の枠組み。 - [[Netflix]] — Atlas/perfdash/FlameCommander によるドリルダウン分析の実装例。 - [[USE メソッド]] — 16章のドリルダウンで「特定」段階に使われるメソドロジ。 ## 出典 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.12 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.2-16.1.7(ドリルダウン分析の実務適用例)