# Trade-Offs Under Pressure - Chapter 5: Results > 前: [[@2015__MSc__Trade-Offs Under Pressure - Chapter 4 Event Description]] | 次: [[@2015__MSc__Trade-Offs Under Pressure - Chapter 6 Analysis]] | 全体: [[Trade-Offs Under Pressure]] ## 要約 第5章は、第4章で記述した[[Etsy]]の障害対応事象について、IRCトランスクリプト・非言語行動データ・インタビューを組み合わせたプロセストレーシングの結果を提示する章である。#warroomで応答した20名のエンジニアのうち、発話量が多く診断・対応活動に有意な影響を与えたと判断された8名を分析対象とする。本章は(1)発話を分類する初期コーディングスキーマの成立過程、(2)事象全体のタイムライン概観、(3)5つの協調エピソードの詳細なコーディングと可視化、(4)診断活動における仮説生成の様式と5つの主要仮説の起源、(5)擾乱管理活動、という順で構成される。分析・解釈そのものは第6章(Analysis)に譲り、本章はコーディングされたデータと、それを裏づけるインタビュー引用を提示することに徹する。 ## コーディングスキーマ: Listening To The World IRCトランスクリプトの初期コーディングは、発話をカテゴリへ分類するために行われた。この「第1サイクル」コーディング(Saldaña, 2009)は探索的な性質を持ち、結果のコードはAppendix Aに示される([[@2015__MSc__Trade-Offs Under Pressure - Appendix A Initial coding schema]])。 初期コーディングスキーマは、パイロットインタビュー(InfraEng1が対象)における焦点の当て方を提供した。パイロットインタビューの文字起こし後、コーディングスキーマは批判的な岐路(critical junctures)と不確実性のエピソードを中心とするより絞り込まれた焦点へと変換された。このスキーマは、残りの参加者へのインタビューにおいて、事象の合図つき想起(cued recall)からどのような暗黙知やヒューリスティックが引き出せるかを探る質問を準備するために用いられた。 ## タイムライン全体像とマップ トランスクリプトデータから活動のエピソードが構成され、インタビューを通じて妥当性が検証された。同定されたエピソードは以下の3カテゴリに分かれる。 - **協調的活動(coordinative activities)**: 複数のエンジニアが成果を生み出すために作業を支援・順序づけする活動 - **診断的活動(diagnostic activity)**: 仮説生成と観察の中継を含む活動 - **擾乱管理活動(disturbance management activities)**: 事象への対応状態が議論・要求される活動 ヒューリスティックの同定は主に診断的活動と協調的活動に焦点を当てた。理由は2点である。(a) 研究の範囲を制御するため、利用可能なデータ量を削減する必要があったこと。(b) 初期コーディングにより、両領域が参加者の不確実性への対処を含むことが示され、これらの領域に焦点を当てることでヒューリスティックが見つかる可能性が高まると判断されたこと。 #warroom IRCチャンネルにおける参加者の発話のタイムラインビューがFigure 8に示される。 **Figure 8: IRC発話のタイムラインビュー(参加者別)** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig8-irc-utterance-timeline-by-participant.png]] (Figure 8. #warroomチャンネルにおける各参加者の発話を時系列上にプロットしたもの。参加者ごとに色分けされ、発話密度が高い時間帯(事象初期)とまばらな時間帯が視覚的に識別できる。) 非言語的な行動データは事象の概観タイムラインに重ね合わせられた。個々の参加者について、これには「診断的活動」「行動を取る」の上位コードが付いたIRCトランスクリプトからのコード化発話に加え、以下が含まれる場合があった: (a) ダッシュボードへのアクセス、(b) 職員名簿へのアクセス、(c) 変更が行われている間のPrincess環境(検証・準備環境)へのリクエスト、(d) 本番サイト(https://www.etsy.com)へのリクエスト。個々のトレースはAppendix Cに示される(本 wiki には未取り込み)。 事象中に参加者が本番サイトへ行ったリクエストに加え、各参加者のサインイン済みホームページへのアクセスについてもデータが収集された(Figure 9)。 **Figure 9: サインイン済みホームページを更新する参加者** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig9-signed-in-homepage-refresh-counts.png]] (Figure 9. 13時前後から14時40分頃までの間、各参加者(ProdEng1-3・InfraEng1-5)がサインイン済みホームページへ行ったリクエスト数を1分単位の棒グラフで示す。ProdEng1が13:25頃に4回、ProdEng3が14:05頃に3回など、変更のデプロイ直後に確認のためのリロードが集中する様子が読み取れる。) 事象で識別された5つの協調エピソードはいずれも、劣化機構への露出を抑える、または正常機能を回復するために本番システムへの変更を行うことを目指すものであった。診断的活動と行動・対応(action taking/response)によってグループ化された全発話のタイムラインマップがFigure 10に、5つの協調エピソードとともに示される。 **Figure 10: 診断・対応・協調エピソードを伴う事象のタイムライン** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig10-event-timeline-diagnostic-response-coordination.png]] (Figure 10. 13:06:44から14:30:00までの事象全体を、上段「診断的活動」・下段「行動を取る/対応」の2レーンで示すタイムライン。下段には5つの協調エピソード(緑色の枠)が重ねて示され、「HOLDがプッシュキューに設定される」(約13:19)・「ProdEng2がホームページサイドバーモジュールを無効化する」(約13:20)・「ProdEng1がブログを無効化した状態でサイドバーを再有効化する」(約14:03)・「HOLDがプッシュキューから解除される」(約14:10)という4つの節目が注釈される。) ## 協調エピソード 5つのエピソードが事象における協調的活動として同定され、それぞれ劣化機構への露出を抑える、または正常機能を回復するために本番システムへの変更を目指すものであった。 ### エピソード1 13:19:10、InfraEng1とInfraEng2がホームページサイドバー機能が観測中の挙動に何らか関与するエラーをログに残していることを発見したのを受け、ProdEng2はホームページのサイドバーを「オフにする」、あるいはホームページコードの実行からスキップするべきだと提案した。 #warroomトランスクリプト上、このエピソードは3つの異なるコードでコーディングされた。 - **行動提案/フィードバック要求**: 例「should I shut that off?」(ホームページのサイドバー部分を指す) - **行動・成果物へのフィードバック**: 例「lgtm」(looks good to me、デプロイ予定の設定変更を指す) - **行動状態の主張**: 例「going to prod」(本番システムへの変更のデプロイ行為を指す) 協調エピソード1の全コーディング詳細はAppendix Bに記載される([[@2015__MSc__Trade-Offs Under Pressure - Appendix B Coordinative Episodes Coding Schema]])。上記コーディングを伴うエピソードの事象タイムライン上の視覚的表現がFigure 11に示される。 **Figure 11: 協調エピソード1** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig11-coordination-episode-1.png]] (Figure 11. 13:06:44-13:45:00の範囲で「診断的活動」「行動を取る/対応」の2レーンを示し、「行動を取る/対応」レーンのうち「ProdEng2がホームページサイドバーモジュールをオフにする」を含む区間を拡大し、「行動提案/フィードバック要求」(青)・「行動・成果物へのフィードバック」(緑)・「行動状態の主張」(橙)の3コードの発生順序を示す。) ### エピソード2 13:24:44、ProdEng1は「something wrong with the featured shop?」と仮説を立てた。featured shopはホームページサイドバーのもう一つのモジュールであり(Figure 5に示される)、具体的には編集部門が選定したEtsyショップオーナーのプロフィールを内容とするブログ記事である。ProdEng2はサイドバーを再有効化しつつfeatured shop部分のみをオフにすることを提案し、フィードバックを求めた。 この提案について尋ねられたProdEng2は、featured shopモジュールをオフにすることが、それを問題の一部として関与づける実りある方法であったと述べた。 > "I think at this point, we had gotten ... <InfraEng2> had uncovered a really, really good clue. We had successfully verified it was the sidebar. Not just in theory, not just from evidence, but we shut the sidebar off and the errors go down. Now I was in, and I think ProdEng3 was also in agreement with the mode of, 'Let's get hardcore evidence that it's the featured shop.' We know it's something in the sidebar, let's turn the sidebar back on, sans the featured shop and see if these error come back, right?' That's the easiest way for us to verify whether or not it's the featured shop." ProdEng2が設定変更へのフィードバックを求めた後、InfraEng1は次のように尋ねた。 > [01:30:31 PM] <InfraEng1> <ProdEng3>, <ProdEng2>, can we hold on that? この時点でProdEng2は変更を今デプロイしないという保留要求を了承し、変更に関するエピソードは一時的に棚上げされた。上記コーディングを伴うエピソードの視覚的表現はFigure 12に示される。 **Figure 12: 協調エピソード2** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig12-coordination-episode-2.png]] (Figure 12. エピソード1と同じタイムラインレイアウトで、「行動を取る/対応」レーンの2つの区間を拡大し、「行動提案/フィードバック要求」(青)と「行動・成果物へのフィードバック」(緑)は複数観測されるが、「行動状態の主張」(橙)は0件であることを示す。提案が保留され実際のデプロイに至らなかったことに対応する。) ### エピソード2と3の間 13:32:24、InfraEng2はIRC上で観察を中継した。 > [01:32:24 PM] <InfraEng2> here's the shop error: > [01:32:25 PM] <InfraEng2> InfraEng2@InfraEng2:~/development/Etsyweb$ curl http://server:port/v3/public/shops/12345678/cards > [01:32:25 PM] <InfraEng2> {"error": "Shop 12345678 does not exist"} 続けてInfraEng2は次のように尋ねた。 > [01:32:51 PM] <InfraEng2> so why are we loading that shop? ProdEng3とInfraEng5はともに、当該ショップの詳細を調べた結果、それがEtsy従業員が所有するショップであり、社内ディレクトリの当該従業員のスタッフページにリンクしていることを発見したと返答した。ProdEng3はまた、そのショップが現在closed状態としてマークされていることも指摘した。 ### エピソード3 13:36:04、ProdEng1は、InfraEng2が発見した「closed」でエラーを返しているショップが、「featured shop」の投稿ではなく、ブログの「more from the blog」モジュールに表示される直近のブログ記事であるという観察を行い、当該ブログ記事へのリンクを投稿した。 ProdEng2は再びサイドバーを再有効化しfeatured shopをオフにすることを提案したが、ProdEng3はオフにすべきは「more from the blog」モジュールであり「featured shop」モジュールではないと応答した。ProdEng2はこの提案を了承し、その対応方針で進める設定変更へのフィードバックを求めた。 エピソード3の視覚的表現はFigure 13に示される。 **Figure 13: 協調エピソード3** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig13-coordination-episode-3.png]] (Figure 13. エピソード1・2と同じレイアウトで、「行動を取る/対応」レーン中の3つの区間を拡大し、うち1つを「行動提案/フィードバック要求」3件・「行動・成果物へのフィードバック」2件として詳細化する。) チームからProdEng2の提案した変更へのフィードバックはなく、代わりに編集チームおよびブログ記事の著者への連絡についての対話が続いた。InfraEng4は次のように述べた。 > [01:39:04 PM] <InfraEng4> i feel like we're still unclear on what we're fixing > [01:39:12 PM] <InfraEng4> the blog or the featured shop? 意図されていた対応方針(サイドバーを再有効化しつつ「more from the blog」モジュールをオフにする)は、それ以上進行しなかった。 ### エピソード4 ブログ記事が特定された後、ブログインフラを管理するチームのメンバーが#warroomへの参加を要請された。そのメンバーは当該ブログ記事のunpublishを申し出て、対応チームのメンバーから同意が得られた。 その後、当該記事が実際にunpublishされ、キャッシュされたバージョンもパージされたことが確認された。エピソード4の視覚的表現はFigure 14に示される。 **Figure 14: 協調エピソード4** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig14-coordination-episode-4.png]] (Figure 14. エピソード1-3と同じレイアウトで、「行動を取る/対応」レーン中の4つの区間のうち末尾を拡大し、「行動状態の主張」(橙)2件・「行動・成果物へのフィードバック」(緑)1件・「行動提案/フィードバック要求」(青)複数件という構成を示す。) ### エピソード5 該当ブログ記事がunpublishされた後、13:49:07、ProdEng1によって再度、サイドバーを再有効化し「more from the blog」モジュールをオフにするという提案がなされた。ProdEng2がこの設定変更を準備する間、エンジニアたちは、closed状態のショップがなぜ観測している影響を生じさせるのかについて仮説立てを続けた。 エピソード5の視覚的表現はFigure 15に示される。 **Figure 15: 協調エピソード5** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig15-coordination-episode-5.png]] (Figure 15. 13:06:44から14:30:00までの事象全体を、他の4エピソードと同じ「ProdEng2がホームページサイドバーモジュールをオフにする」の節目とともに示し、末尾に14:03頃の「ProdEng1がブログを無効化した状態でサイドバーを再有効化する」・14:10頃の「HOLDがプッシュキューから解除される」という2つの節目を追加した全体図。「行動を取る/対応」レーン末尾の拡大部は「行動状態の主張」(橙)2件・「行動・成果物へのフィードバック」(緑)複数件・「行動提案/フィードバック要求」(青)複数件を示す。) ## 診断と仮説生成 事象の展開に伴い、#sysopsと#warroom両方のトランスクリプトから、エンジニアが仮説を生成し、それを他者と共有し、検証・テストする努力をしていたことが示された。 診断における仮説生成は複数の様式で現れ、それがIRCトランスクリプトのコーディングに反映された。第1の最も直接的な様式は、単純に述べられた仮説である。例:「I wonder if Wordpress is dying?」。第2の様式は、特定のトピックに向けられた質問によって示される仮説生成である。例:「Did we just turn off a CDN or make F5 changes?」。これは候補仮説を構築するためのデータ探索とみなせる。第3に、他のチームメンバーへの観察の中継も、仮説生成の強い推論として分類された。例:「InfraEng2: this shows the same problem with GetShopCards <URL link to log search>」。観察の中継と仮説の質問・陳述の両方が診断的活動としてコーディングされた。診断的活動がどのように識別・コーディングされたかの例はAppendix Aに示される。 仮説生成と主要な観察の視覚的表現がFigure 16に示される。 **Figure 16: 仮説の診断マップ** ![[_attachments/msc-allspaw-2015-tradeoffs-under-pressure/ch05-fig16-diagnostic-map-of-hypotheses.png]] (Figure 16. 13:06:44-14:30:00のタイムライン上に、発話者(PE1-3・IE1-3・IE5)ごとの仮説陳述(四角)と重要な中継観察(丸)を配置した図。CDN/ロードバランサ変更・ネットワーク変更・Wordpress障害・ホームページサイドバーのエラー・400応答コード・凍結ショップ・featured shop・staff shop・データベーススキーマ変更・PublicShops_GetShopCards APIメソッド・「Shop 1234567 does not exist」・Varnishのキューイング/非キャッシュといった仮説・観察が時系列に並び、複数の仮説が並行して生成・破棄されていく過程を示す。) ### 仮説生成とその起源 Figure 16に示されるように、事象の展開に伴い多数の仮説がIRCトランスクリプト上で生成・共有された。一部の仮説は陳述された後に何らかの形で反証されたが、他の仮説は実りある探索方向であることが判明し、他のエンジニアを探索へと導いた。 **仮説1: CDNまたはロードバランサの変更** 13:13:28、ProdEng3は#sysopsチャンネルで尋ねた。 > [01:13:28 PM] <ProdEng3> did we just turn off a CDN? > [01:13:34 PM] <ProdEng3> or make f5 changes? 得られた回答は、F5(サーバロードバランシング機器)の変更もCDNのオフもなかった、というものであった。13:15:20、InfraEng2は障害対応中のエンジニアに#warroomチャンネルへの参加を促し、InfraEng5もCDNのオン/オフ状態についての情報を求めた。 > [01:17:54 PM] <InfraEng5> <CDN vendor> has been off for a while now, right? that didn't just happen? この質問に至った経緯を尋ねられたProdEng3とInfraEng5はともに、この障害の初期シグナルが類似した過去の障害を想起させたと述べた。 > "This matched a pattern that we saw earlier. By earlier, I mean many months earlier. When we turn off the CDN that was doing response buffering. I'm sorry, it was doing post-buffering." (ProdEng3) > > "We've seen patterns in the past where we turned off one CDN that was fronting the API and it changes the profile of the request rate to the API… so if we see a increase in request for second to the API cluster can be an indication that we turned off the CDN." (InfraEng2) F5ロードバランサの診断方向についても、ProdEng3はネットワークに関する作業についての最近の言及を見た記憶があると述べており、他の参加者からもCDNの状態が妥当な診断方向であったことについて全員一致の同意が得られた。 **仮説2: ネットワークの変更** #warroomでこの発言に至った経緯を尋ねられたInfraEng3は次のように述べた。 > [01:18:01 PM] < InfraEng3 >: and #netops says no network changes InfraEng3は、CDNとロードバランサについての先行する質問を見ており、ネットワークの変更を検討したと述べた。 > "Probably what happened is I saw ProdEng3 speculating and I went to go find answers." > > "Yeah, yeah. So the first two questions were about CDNs, and I found the answer to that. So when InfraEng5 brought it up later, I hadn't had that answer." (InfraEng3) **仮説3: 外部ホストのブログ** Etsyのブログコンテンツはサードパーティのwordpressホストでホストされており、ホームページには「featured shop」と「more from the blog」というブログにリンクする2つの主要モジュールが含まれる。いずれもEtsyのインフラの外部でホストされているブログにリンクする。 01:19:24、ProdEng3は尋ねた。 > [01:19:24 PM] < ProdEng3>: I wonder if wordpress is dying この仮説の起源を尋ねられたProdEng3は次のように述べた。 > "The blog is, it's an endpoint that had caused us trouble in the past because it has been slow in the past. The sidebar prominently has blog posts in it." 他の参加者もWordpressが妥当な診断方向であったと考えており、その理由として (1) 過去に問題を起こしたことがある、(2) Etsyのスタッフの制御・可視性の外にある、という2点を挙げた。 > "I think at this point, if I recall, we were all having a hard time finding graphs that were moving the way we wanted them to, to validate assumptions. If WordPress was having issues, we can't graph it, it's outside of our control." (ProdEng2) > > "Historically we've had problems with the blog not loading and causing problems like this. My hypothesis would have been that it was the blog." (ProdEng1) **仮説4: 凍結ショップ(Frozen Shop)** 01:19:49、InfraEng2は#warroomチャンネルで尋ねた。 > [01:19:49 PM] < InfraEng2 >: did some shops get frozen? ショップは、支払いの延滞や不正の疑いといった特定のシナリオにおいて、EtsyのMember Supportチームによって「凍結(frozen)」(停止)される。これは通常、Member Supportとの連絡を通じてステータスが解消されるまでの一時的な状態として意図されている。 チャンネルでこの質問に至った経緯を尋ねられたInfraEng2は次のように述べた。 > "Something that is not specific to the API that we've seen before is that we see this sudden increase in errors where if Trust and Safety closed a the shop or a series of shops that have a lot of listings that have external links to them, we suddenly see a spike of errors ... but Trust and Safety has just made a data change, which then means that the app behaves differently." トランスクリプト中で他のエンジニアはこの仮説に到達していない。インタビューでは多くの参加者がInfraEng2がこの仮説に至った経緯を理解できると回答した一方、当時この診断方向を理解していたとは記憶していないと回答した。 **仮説5: データベーススキーマの変更** 01:28:12、InfraEng3はデータベースに関わる診断方向について情報を求めた。 > [01:28:12 PM] < InfraEng3>: are we doing a schema change right now? データベーススキーマの変更とは、本番データベース構造への変更である。通常、スキーマ変更は本番サービスに問題を生じさせない。全データについて2台のミラーリングされたデータベースが存在し、相互にデータを複製しているためである。スキーマ変更はペアの一方に対して、それが本番から外されている間に行われ、その後もう一方のサーバを変更するために本番へ復帰させる。 この質問に至った経緯を尋ねられたInfraEng3は次のように答えた。 > "You know that feeling when you have seen a problem recently, so it's like primed in your head as a possible problem? This was because maybe like a weekend or two before this was the weekend we had the weird materials pinning problem on <database> that we later discovered was a problem with like all of <database>." > > "And I think my weirdo theory here was something like if there was somehow replication broke for the featured shop, and it only existed on the side that was out for schema change and we featured it." ## 擾乱管理と対応状態の追跡 トランスクリプトとインタビューの双方に、擾乱管理活動(disturbance management activity)の兆候が見られた。この種の活動は、診断的活動や対応の行動計画立案とは異なる。Woods(1995a)は擾乱管理を、動的プロセスアプリケーションにおける障害管理の中で生じる「状況評価と対応管理(対応選択・適応的計画立案・計画生成)との間の相互作用」を指すものとして記述している(p.74)。 このタイプの活動の例として、InfraEng4による以下の一連の発話が挙げられる。 > [01:30:33 PM] < InfraEng4> is there a rush to get this deployed today? should we slow down? > [01:32:27 PM] < InfraEng4>: what is our current state? > [01:34:10 PM] < InfraEng4>: wasn't the sidebar not loading before? trying to understand what the toggle of the flag did > [01:39:04 PM] < InfraEng4>: i feel like we're still unclear on what we're fixing > [01:39:12 PM] < InfraEng4>: the blog or the featured shop? > [01:53:26 PM] < InfraEng4>: have we communicated to the employee in question? > [01:58:24 PM] < InfraEng4>: ProdEng2: if there are still this many questions, i'd prefer we skip the blog post for now until we know why it's killing us 対応のペースと診断についての懸念が、この状態要求・対応管理活動の重要な駆動要因であったように見える。InfraEng4は次のように報告した。 > "In general, I think the most difficult thing is the stress that is involved in diagnosing and it gets in your way, I think. I think a lot of my line of questioning was along the theme that slow is fast in these situations. We don't want to be reacting too quickly without understanding where we at. We don't want to be jerking back and forth between up and down, and up and down. It's not a time to really shotgun a solution in just terms of, 'let's try everything and see if it works.' > > "I think the biggest part is slowing down and buying us enough time so that we can get deeper into the problem, and actually figure it out. Had <engineer> pushed their solution too early, we might have not gotten any insight. What would the game been there?" ## 考察・限界 本章は分析(第6章)に先立つ生データの提示に徹しており、著者自身による解釈上の主張は最小限にとどめられている。ただし、いくつかの限界が本章の記述からも読み取れる。第一に、分析対象は#warroomで発話量の多かった8名に限定されており、残る12名の発話は「有意な影響を与えなかった」と著者が判断した基準で除外されている。この判断基準そのものは本章では詳述されない。第二に、仮説4(凍結ショップ)はInfraEng2のみが到達し、他のエンジニアには共有された理解として広がらなかったことが明示されており、仮説生成が必ずしも協調的な収束に至るとは限らないことを示す一次データである。第三に、擾乱管理活動はInfraEng4という単一の参加者の発話に集中しており、この活動類型が他の事象・他の参加者に一般化できるかは、単一事例研究の範囲では判定できない。 ## 関連 - [[Etsy]] — 本事象の当事者組織 - [[John Allspaw]] — 本論文の著者。プロセストレーシングとインタビューを実施した研究者 - [[診断ヒューリスティック]] — 本章の仮説生成データが、後の第6章で定式化される診断ヒューリスティックの経験的基盤となる - [[Joint Activity]] — 協調エピソードの3コードスキーム(提案→フィードバック→行動状態の主張)はJoint Activityの相互予測可能性・方向付け可能性が実際の発話としてどう現れるかを示す - [[Common Grounding]] — 擾乱管理活動(状態の問い直し)は対応状態についての共通基盤を維持する具体的な発話実践として読める - [[@2015__MSc__Trade-Offs Under Pressure - Chapter 4 Event Description]] — 本章が分析するタイムラインの元になる事象記述 - [[@2015__MSc__Trade-Offs Under Pressure - Chapter 6 Analysis]] — 本章のデータをもとにヒューリスティックの使用パターンを分析する章 - [[@2015__MSc__Trade-Offs Under Pressure - Appendix A Initial coding schema]] — 本章冒頭の初期コーディングスキーマの詳細 - [[@2015__MSc__Trade-Offs Under Pressure - Appendix B Coordinative Episodes Coding Schema]] — 協調エピソードの全コーディング詳細 - [[Trade-Offs Under Pressure]] — 本論文のハブページ ## 出典 - `.raw/theses/msc-allspaw-2015-tradeoffs-under-pressure/chapters/ch-05.txt`(PDF p37-51)