# パフォーマンスのアンチメソドロジ ## 定義 パフォーマンスのアンチメソドロジ(anti-methodology)は、まともなメソドロジの欠如を指し示す3つの典型パターンとして本書で紹介される。(1) 街灯のアンチメソッド: よく知っている可観測性ツールやたまたま見つけたツールで明らかな問題が現れるかをチェックするだけの分析。酔っぱらいが鍵を落とした場所ではなく街灯の下(明るいから)を探すという逸話(街灯効果、streetlight effect)に由来し、意味があるからではなく読み方を知っているからという理由だけで top(1) を見る行為がこれに当たる。多くのタイプの問題を見過ごし、決定的な問題かどうかを定量化できない。(2) ランダム変更アンチメソッド: どこに問題があるか適当に推測し、消えるまで適当に変更を加える実験的アンチメソッド。パラメータをある方向に変え、逆方向にも変え、良い方を残すという手順を繰り返すが、非常に時間がかかる上、後年のバグフィックス等で無意味になる理解不能なチューニングを残すリスクがある。(3) 誰か他人のせいにするアンチメソッド: 自分の管掌外のコンポーネントに問題があるという仮説を、データなしに立てて他チームに丸投げする。「たぶんネットワークだ」という発言に象徴され、仮説を裏付けるデータの欠如で見分けられる。犠牲にならないためには、告発者にツール実行のスクリーンショットと解釈根拠、セカンドオピニオンを要求するとよい。3つに共通するのは、いずれも仮説を裏付けるデータの収集を欠く点である。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.1-2.5.3) 12章は、ベンチマーキングの文脈における独立したアンチメソドロジとして「パッシブベンチマーキング」を挙げる。ベンチマーク実行を開始したら完了するまで何も考えないミサイルの自動追尾のような fire-and-forget な手法で、「ツールを選ぶ→オプションを指定して実行する→結果からスライドデッキを作る→管理職に渡す」という手順で行われる。アクティブベンチマーキング(実行中に可観測性ツールで分析する手法)との対比で定義される点で、街灯のアンチメソッド等の3パターンと同じく「体系的な分析データの収集を欠く」という共通構造を持つ。パッシブベンチマーキングは簡単に実行できるが、ベンチマークソフトウェアのバグ・制約(シングルスレッド実行等)・無関係コンポーネントによる制約・構成による制約・反復不能な摂動・まったく誤ったターゲットのベンチマーキングのいずれかによって、誤った結果になりやすい。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.3.1) ## 横断的知見 - 2章の3アンチメソッド(街灯・ランダム変更・誰か他人のせい)と12章のパッシブベンチマーキングは、いずれも「実行中または分析中に体系的なデータ収集を行わない」という共通構造を持つ姉妹パターンである。ただし適用場面が異なり、2章の3つは本番環境での障害調査(観察対象は既存の問題)に、12章のパッシブベンチマーキングは制御されたテスト実行(観察対象は自ら発生させた負荷)に対応する。アンチメソドロジという分類は、対象が診断かベンチマークかを問わず「体系性の欠如」という一点で貫かれている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.1-2.5.3, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.3.1) - 2章はアンチメソッドへの対抗策として個別の心構え(告発者へのスクリーンショット要求等)を示すにとどまるが、12章はパッシブベンチマーキングに対する代替として「アクティブベンチマーキング」という名前付きの体系的メソドロジを提示し、bonnie++のケーススタディで具体的な分析手順(iostat→bpftrace→cachestat→vfs_write引数のヒストグラム化)まで踏み込んでいる。アンチメソドロジの克服が、2章では姿勢の問題として、12章ではツールチェーンを伴う手順として記述されている違いがある。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.1-2.5.3, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.3.1, §12.3.2.1) ## 未解決の問い - 街灯のアンチメソッドとツールメソッド(§2.5.8、利用可能なツールから指標をリストアップする体系的アプローチ)は、いずれも既知のツールに依存する点で類似している。両者を区別する境界(体系性の有無以外)は実務上どこにあるか。 - 「誰か他人のせいにするアンチメソッド」への対抗策(スクリーンショット・セカンドオピニオンの要求)は、組織文化や心理的安全性に強く依存すると考えられるが、本章はその組織的前提条件に触れていない。 - パッシブベンチマーキングは2章の3アンチメソッドと同型の構造(体系的分析の欠如)を持つが、本書はこれを2章の3分類には含めず12章で独立に再定義している。両者を統一的な「アンチメソドロジ」の下位分類として体系化するなら、境界基準(対象が障害調査かベンチマークか、以外の基準)は何になるか。 ## 関連 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] — 3つのアンチメソッドの原典解説(§2.5.1-2.5.3)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] — パッシブベンチマーキングの原典解説(§12.3.1)。 - [[USE メソッド]] — アンチメソッドの不完全さを補う体系的な代替メソドロジ。 - [[ベンチマーキング]] — パッシブベンチマーキング/アクティブベンチマーキングを含む、ベンチマーク実行メソドロジ全般の集約概念。 ## 出典 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.1-2.5.3 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.3.1(パッシブベンチマーキング)