# Trade-Offs Under Pressure - Chapter 6: Analysis > 前: [[@2015__MSc__Trade-Offs Under Pressure - Chapter 5 Results]] | 次: [[@2015__MSc__Trade-Offs Under Pressure - Chapter 7 Discussion]] | 全体: [[Trade-Offs Under Pressure]] ## 要約 第6章は、第5章で提示したコーディング済みデータ(IRCトランスクリプト・非言語行動・インタビュー)を解釈し、本論文の中心的主張である4つのヒューリスティックを定式化する章である。構成は(1)参加の水準、(2)協調エピソードにおいて発見された3つのテーマ、(3)同定されたヒューリスティックの使用と異常対応パターン(ヒューリスティック1〜4を個別に論じる)、(4)アブダクション推論による解釈、の順である。第5章が「何が観察されたか」という生データの提示にとどめたのに対し、本章は観察をヒューリスティックという分析カテゴリへ定式化し、各ヒューリスティックの根拠(インタビュー引用・トランスクリプトの発言頻度・組織のツール機能・アンケート結果)を積み上げる。 ## 参加の水準 [[Etsy]]の#warroomチャンネルにおけるIRC対話のうち、約52%はProdEng2とProdEng3の2名によるものであり、残りを他の参加者が占めた(Figure 8を参照。第5章に既出)。ProdEng1-3は、対象となった機能(サインイン済みホームページ)とグレースフルデグラデーション制御を設計したチームに最も精通しており、この関与水準の高さは意外ではないと著者は述べる。 ## 協調エピソードにおける発見 5つの協調エピソード(第5章)を分析した結果、3つのテーマが浮かび上がった。 **a. 対応としてのグレースフルデグラデーション制御。** ほぼすべての活動は、即座の完全復旧を目指すのではなく、劣化の望ましくない影響を軽減し、サイトの機能を安定化させることに向けられていた。 - エピソード1の活動は、ホームページを完全に劣化した状態(3.5秒を超えるとフェイルセーフとして表示される汎用の「trending items」表示)から、より軽度な劣化状態(サイドバーを除く個人化コンテンツを復元)へ引き上げることに向けられた。 - エピソード2の活動は、「featured shop」モジュールを除いてサイドバーを再有効化することでより軽度な状態へ引き上げようとしたが、当該ショップに問題がないと判明したため中止された。 - エピソード3の活動は、「more on the blog」モジュールを除いてサイドバーを再有効化することでより軽度な状態へ引き上げようとしたが、停滞・中止された。 - エピソード4の活動は、著者自身が所有するショップを参照していたために問題視されたブログ記事のunpublishに向けられた。 - エピソード5の活動は、サイドバーをオフからオンへ(「more on the blog」モジュールを除いて)引き上げることに向けられた。 より劣化した状態からより軽度な状態への遷移というこの焦点は、エピソード2中の対話に明示的に表れている。 > [01:31:46 PM] <InfraEng4> i guess i'm asking if we need to do root cause determination right this very instant > > [01:32:16 PM] <ProdEng3> InfraEng4: not really but it'd be good to be in a less-degraded state if possible インタビューでも同じ視点が裏づけられた。ProdEng2は「サイトが落ちていて、エラーページが出ていて、劣化がある状況では、まず可能な限り速やかに、より劣化していない状態へ引き上げ、その後さかのぼって、なぜ劣化させたのかを追及する」ことが本能であると述べ、ProdEng3も「休暇シーズンであり、この時点での目標は製品を可能な限り100%に近い状態にすることだった」と述べた。 **b. 変更に対する仲間の支持(Peer Support)。** 本番システムへの変更提案がなされる際、エンジニアはほぼ例外なく、行動を取るか否かについて仲間の合意(peer consensus)に依拠し、変更の詳細について議論した。エピソード2では変更を進めないという明示的なフィードバックがあり、エピソード3ではフィードバックの不在によって提案された変更が進まなかった。 **c. デプロイ前に自動テストの完了を待たない。** エピソード中2回、エンジニアに対して自動テストの完了を待たずにデプロイするよう提案がなされた。 ## 同定されたヒューリスティックの使用と異常対応パターン 本研究の中心的発見は、**エンジニアは障害対応において単一の規定された手順への依存ではなく、文脈依存的なヒューリスティックを用いる**ことである。本事例では4つのヒューリスティックが同定された。最初の3つは診断を中心とする。 1. **ヒューリスティック1**: 診断探索の範囲を暗黙裏に絞り込む試みとして、まずシステムへの直近の変更との相関を探す。 2. **ヒューリスティック2**: 相関する変更が見つからない場合、診断探索空間を潜在的なシグナル全般へ広げる。 3. **ヒューリスティック3**: 相関する変更が見つからない場合、2つの主要な診断方向がある。(a) 想起される特定の過去の診断を、類似する信号・症状のマッチングによって確認/棄却する。(b) 想起される一般的で直近の診断を、類似する信号・症状のマッチングによって確認/棄却する。 4つ目は協調を中心とする。 4. **ヒューリスティック4**: 障害シナリオにおいて、コードの変更に対する確信を得る手段として、自動テストなど他の手続きよりも同僚によるレビューを用いる。 ### ヒューリスティック1 ── 「直前に何を変更したか」 本論文の最も意外な発見の一つは、最も頻用されていたルール・オブ・サムが、IRCチャンネルの対話上では最も明示的でなかったという点である。参加者全員が、障害や劣化の発生を認識した(アラート・自身の観察・他者からの通知いずれの経路であれ)直後、診断データを収集する前に、まずアプリケーションに変更が加えられたかを確認することを本能とすると証言した。ほとんどの場合、これは次の問いへの回答として現れる。 > "Does this line-up with a deploy?" しかしIRCトランスクリプト中でデプロイとの相関に言及した箇所はわずか2回であった(障害発生から約12分後の「doesnt line up with any push」、約30分後の「it doesnt seem to be, no」)。インタビューでは複数の参加者がこの重要性を敷衍した。InfraEng3は「たぶん何かおかしくなったら最初か2番目にすることだ」、ProdEng1は「(確認すべき事項のリストの)上位、ほぼ1位だ」と述べた。ProdEng2は変更を「ソフトウェア工学における障害・エラーの最大の原因の一つ」と表現し、ProdEng1は「普段は問題ないのに誰かが何かを変更した途端に壊れる」と述べた。InfraEng3は理由として「コード変更には可視性があり、追跡しやすい(tractable)と感じる」ことを挙げ、また「静止しているシステムは壊れない」とも述べた。InfraEng5は「コード変更は最も頻繁で最も可視性の高い、最も変動の大きい種類の変更であり、導入されるエントロピー量も多い」と述べ、InfraEng4は「我々は正常状態が稼働中であることを前提にしており、その状態から外れたときは何かが起きて別の挙動を導入したと仮定する」と説明した。 Etsyのダッシュボード設計には、この暗黙のヒューリスティックを支える具体的な機能(社内呼称「tooling」)、すなわちコード変更が行われた時点を時系列グラフ上に縦線で示す「deploy lines(デプロイ線)」が存在した。 **Figure 17: デプロイ線を重ねたエラー時系列プロット** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch06-fig17-deploy-lines-error-timeseries.png]] (Figure 17. PHP警告数の時系列プロット(オレンジ線)に、3回のコードデプロイの発生時刻を示す赤い縦線を重ねた典型例。デプロイ線と警告数の急増・急減が視覚的に相関するかどうかを即座に判定できる。) インタビューではこの機能の効果が具体的に語られた。InfraEng5は「#warroomの開始時点で、あるいはどの障害・異常でも、まず相関を探す……ツールには大きな縦線があり『このイベントがこの時刻に起きた』と示され、その後のトレンドを容易にその瞬間と相関づけられる」「その種の変更への内省を大きく最適化してきた」「縦線とトレンドがあれば、線に戻ってリンクをクリックし、差分の形で何が変わったかを見られる」と述べ、ProdEng2は「グラフがスパイクしたりホッケースティック状になったとき、その底に線があるか。あれば何が変わったか見る」と述べた。トランスクリプトの証言に加え、参加者がブラウザで開いたダッシュボードはすべてデプロイ線が有効な状態であった(InfraEng1のみ、診断上デプロイが関与しないと明確になった13:25時点でAPIコンポーネント性能ダッシュボードのデプロイ線を無効化し、分析が容易になったと報告した)。 ### ヒューリスティック2 ── 探索を広げる時 コードの変更との明確な相関が見当たらないと判明した際の参加者の反応を尋ねたところ、その後の診断方向は著しく不確実になったことが示された。ProdEng1は「わからない、何もないところから始めることになる」、InfraEng3は「それが怖くなる瞬間だ……『何が悪いか見当もつかない』へ変わる」、InfraEng2は「コード変更でないと分かった時点で、あらゆる可能性が開かれる」とそれぞれ述べた。ProdEng2はこの過程を「幅優先探索(breadth first search)」と自己記述し、InfraEng1がサイドバーを発見した時点で全員が「幅優先から深さ優先に切り替え」、行き詰まると「幅優先に戻った」と説明した。 ### ヒューリスティック3 ── 収束的探索 ヒューリスティック1が不発に終わり「あらゆる可能性が開かれた」と判明した後、本研究では2つの主要なパターンが観察された。(a) 想起される特定の過去の診断を、類似する信号・症状のマッチングによって確認/棄却する。(b) 想起される一般的で直近の診断を、類似する信号・症状のマッチングによって確認/棄却する。 **#3a**: InfraEng2による凍結ショップ仮説の生成過程(「did some shops get frozen?」)は、それ以前のトランスクリプト上の観察やダッシュボード・本番サイトへのアクセスと結びつかない形で唐突に現れた。InfraEng2はその起源をこう説明した。「これまで4〜5回はこの現象を見てきた……大きなエラーが出て多くの人が調べ、最終的に特定のリスティングやショップのリスティングに絞られると分かる」「何が今起きていることに似ているか、を考えていた」。過去の類似事例の診断難易度についても、「非常に高かった。今回見ている症状と同じパターンだったが、一次的に利用できるデータで判明する手がかりがなかった」と回想した。InfraEng2はその後もこの仮説を継続的に検証する行動を取り、「Right - I'm kinda fixated at this point, I think. (laughs)」と自身の固着(fixation)を認めた。CDN仮説・Wordpress仮説もこれと同じテーマを共有する。すなわちコード変更が除外され探索空間の拡張が必要になった時点で、有望な次の一手は記憶に格納された観察とのマッチングであるという点である。ProdEng2は「見覚えのある症状を見ると、すぐに過去に問題を起こしたものを確認する」と要約した。プロセストレースからは、想起される事象の基準が、驚きをもたらしたか診断が困難だったと記憶されている事象であるという強い推論が得られる。 **#3b**: サイドバー・ショップデータ取得・特定のブログ記事へと診断が絞り込まれた後も、障害機構そのもの(なぜそれが起きたか)の完全な理解は残されていた。ブログ記事がunpublishされる前、InfraEng1は「varnish was queuing us?」という仮説を発した。この時点でこの仮説を裏づける観察はダッシュボードのアクセスログにも見当たらず、トランスクリプト中にVarnishやキューイングへの先行言及もなかった。InfraEng1はこの起源について、「タイムアウトを見た瞬間、『これはあのキューイング問題か』と思った」と回想した。過去のVarnishキャッシュ問題は「その時は新しかったのでパターンを認識できておらず、非常に難しかった……その週に3回、少しずつ異なる予期しない形で同じ問題に遭遇した」ため診断が困難であったと述べた。パイロットインタビューの冒頭で、事象の日付と簡単な説明のみを与えられたInfraEng1は、「これはvarnishが複数の統合クエリリクエストをキャッシュしてキューイングする件に関連していると思う」と障害機構を特定して事象を言い当てた。 このヒューリスティックにおける仮説生成は、Woods & Hollnagel (2006, p.77)の次の指摘と整合する。 > "Performance at diagnostic reasoning depends on the ability to generate multiple plausible alternative hypotheses that might account for the findings to be explained. Observing anomaly response in action reveals that people do not call to mind all plausible alternatives at once. Rather, context, new evidence, and the response of the monitored process to interventions all serve as cues that suggest new possible explanations." ### ヒューリスティック4 ── 自動テストの完了待ちについて 協調エピソードの同定過程で、対応中にコード変更をデプロイするエンジニアが自動テストの完了を待つべき局面において、他のエンジニアが「待たずに進めるべき(push on through)」という意見を複数回述べたことが目を引いた。通常運用における自動テストの役割(想定外の箇所へ変更が悪影響を与えないという確信をデプロイ担当者に与えること)を踏まえると、障害対応中に既存の障害を複雑化・追加しうる変更をデプロイすることは直感に反する逆説である。時間切迫感の知覚により、エンジニアは問題をより速く解決・封じ込めるためにテスト完了を待たないことを選好するのではないか、という問いから、Etsyの全エンジニアを対象とする簡易アンケートが実施された。質問は次の2件である。 1. 障害・劣化シナリオ中に何かをデプロイする前、テストの完了を待つべきか進めるべきか他者に確認するか(yes/no) 2. 障害・劣化シナリオ中にCONFIGデプロイを行う際、1(自動テスト完了を絶対に待たず、デプロイ前のコード変更への確信は他者からのフィードバックに依拠する)から5(時間切迫にかかわらず常にテスト完了を待つ)の5段階でどこに位置するか 質問1の結果は29名がYes、3名がNo(n=32)であった。質問2の結果はFigure 18に示される。 **Figure 18: アンケート結果(自動テストの完了待ちについて)** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch06-fig18-survey-wait-for-tests-results.png]] (Figure 18. n=32の回答分布。1(絶対に待たない)が1名、2が12名、3が9名、4が5名、5(常に待つ)が3名であり、回答の大多数が「待たない」寄りに偏っている。) 回答者の1名は追加の説明として、判断に影響する要因は「変更の範囲」と「障害の範囲」であり、パッチではなくリバートを推す場合はテストが通る確信が高い(そのコードは既に本番で稼働していたため)一方、新規パッチはリスクが高いためテスト完了を待つ可能性が高いと述べた。この文脈とアンケート結果は、自動テストの完了を待たずに(少なくともCONFIG変更については)同僚レビューへ確信を依拠するというルール・オブ・サムが、本事例に限定されない、より広く見られる傾向であることを裏づける。この発見はHollnagelの「Work-Related ETTO Rules」(Hollnagel, 2009)の例、すなわち「it has been checked earlier by someone else」(コード変更の正しさは同僚レビューによって既に検証済みという意味)や「(doing it) this way is much quicker」(テスト完了を待たないことで時間の節約になるという意味)とよく整合する。 ## アブダクション推論による解釈 同定されたヒューリスティックを踏まえると、診断活動はアブダクション(仮説形成推論)を主たる推論様式として用いていることを示すという解釈が成り立つ。Woodsの枠組み(Woods, 1995a)を用いると、プロセストレースを通じてエンジニアが行った観察をD、事象中に生成された仮説(CDN、ネットワーク、Wordpress、データベーススキーマ変更、凍結ショップ等)をHとして次のように整理できる。 - ステップ1: D = 観察・所与・事実の集合 - ステップ2: H はDを説明する。すなわちHが真であればDを説明できる - ステップ3: Dを H ほどよく説明する他の利用可能な仮説はない - 結論: したがってHはおそらく真である 生成された各仮説(Figure 16、第5章)について、参加者へのインタビューはこの推論様式と過程を裏づける。 ## 考察・限界 本章は分析の中心を成すが、著者自身の解釈が色濃く反映される章でもある。第一に、ヒューリスティック1(相関確認)は全参加者が「最初に取る行動」と証言する一方、トランスクリプト上の直接言及はわずか2回にとどまる。著者はこの乖離を「暗黙性の強さ」の証拠として解釈しているが、乖離自体は「証言バイアス(想起時の後付け合理化)」あるいは「デプロイ線という既存ツールにより確認行為自体が発話を要さない自動化された作業になっていたこと」のいずれによっても説明可能であり、本章はこれらの対立仮説を明示的に比較検討していない。第二に、ヒューリスティック4を裏づけるアンケート(n=32)は「デプロイ前に確認を取るか」という行動傾向を問うものであり、Hollnagelの ETTO ルールへの整合づけは著者による事後的な解釈であって、回答者自身がETTOという枠組みを念頭に置いて回答したわけではない。第三に、アブダクション推論による解釈は、5つの仮説がいずれも(a)過去の類似事例、または(b)直近の事例との類似性マッチングから生成されたという第5章のデータに基づいているが、これらの仮説がアブダクションの妥当性基準(ステップ3「他の仮説がDをHほどよく説明しない」)を実際に満たしていたかどうかは、本章では検証されていない。すなわち本章は「エンジニアがアブダクション的に推論しているように見える」という記述的解釈にとどまり、その推論が規範的に妥当であったかどうかへは踏み込んでいない。 ## 関連 - [[Etsy]] — 本事象の当事者組織 - [[John Allspaw]] — 本論文の著者 - [[診断ヒューリスティック]] — 本章で定式化される4つのヒューリスティックそのものを扱う概念ページ - [[@2015__MSc__Trade-Offs Under Pressure - Chapter 5 Results]] — 本章が解釈する生データ(協調エピソード・仮説生成)を提示する章 - [[@2015__MSc__Trade-Offs Under Pressure - Chapter 7 Discussion]] — 本章の分析結果を踏まえた考察を行う章 - [[Trade-Offs Under Pressure]] — 本論文のハブページ ## 出典 - `.raw/theses/msc-allspaw-2015-tradeoffs-under-pressure/chapters/ch-06.txt`(PDF p52-62)