# 9章 先見性を生み出す

>この章は、8章までのツールの自動化を覆す「カオスエンジニアリングにおける自動化の皮肉(Ironies of Automation)」について触れ、事前処理(実験準備)、カオス実験中、事後処理(実験後)におけるファシリテーターの役割と実験を行う体制、事前処理・事後処理で質問すべき事項などがを説明しています
>自動化するのは、あくまでその過程でシステムの特性、動きを把握するプロセスで得られる知見を得るの手段であり、
>自動化の仕組みを共有できれば、自動化は数週間で止める。何か起きた時にどのように対処すればよいか、をチームで理解を深めるのが目的である。

回復力のある組織は、顧客のビジネスが幸せになる信頼性や回復力を実現する方法を見つけたり思い描いたりする機会を、
* 過去の成功を自信の理由づけに使わない
* 物事が起きてからそれが予測可能だったと考える傾向に惑わされない
* 人間が無自覚のうちに持っている、思い込みや価値観を見直す

などの観点で

* 過去の成功を深く考え、裏に潜むリスクを見付け出す
* システムがどのように成功し、どのように失敗するか

などのメンタルモデルを再構成する機会と捉えている。

> 本書では、「物事が起きてからそれが予測可能だったと考える傾向」を[後知恵バイアス](https://ja.wikipedia.org/wiki/後知恵バイアス)と表記している。「だから言ったのに！」とか「後の祭り」などの言葉は結果論からの批判であり、これらも後知恵バイアスと呼ばれている。

組織が技術的あるいは人的な回復力に優れているのはどの分野かを学んだりするのは、コードによって自動化はできない。本稼働環境のイベントをシミュレート行い、アーキテクチャとプロセスのパフォーマンスをテストすることで、
* 個別のシステムがどのように構成されているか、改善できる箇所を把握できる
* 組織がイベントに対応することを経験することで、アイディア出しや無自覚に思っている価値観や思い込みを排除する(本章では[ゲームデー](https://https://d1.awsstatic.com/International/ja_JP/Whitepapers/AWS_Well-Architected_Framework_2018_JA_final.pdf#page=8)と表現)。

これによりカオスエンジニアリングの鍵となるコンポーネントが見えてくる。

> 本書では、「人間が無自覚のうちに持っている価値観、思い込み」を[メンタルモデル](https://sevendex.com/post/322/)と表記している。「障害が心配だから可用性テストをしよう」というのは、過去の失敗の経験や印象的な出来事などの潜在意識から引き起こされる顕在意識とも言えます。この潜在意識を引き出し、理解することが目的意識や行動に繋がるものと考えます。以下の図の見えているもの「顕在意識」よりも、「見えていないもの」潜在意識を引き出すことが重要視されています
> 

この章では、カオスエンジニアリングの各ステージで長きにわたって投資されてこなかったのは事前準備と事後処理のフェーズに関して、カオスエンジニアリングを専門知識を抽出する方法(重要な問いかけ)として取り上げています。

事前準備と事後処理のフェーズは、特定の一人がファシリテーターとして準備を行なうことが多い。
このファシリテーターは、
* 実験の前にチームが何をするのか
* システムが何たるか
* システムがどのように動くか

などをチームに教える役目を持っている。この時に、インシデントになる前に問題を見つけることを最適化しすぎると、何かを失敗させたり、壊したりする方法にだけ大きな注意が払われ、事前準備や学んだ成果の普及から得られる価値を見逃してしまう。
最大限の成功を得るためには、各フェーズ(事前準備、事後処理)において、異なるスキルセットと異なるロールが必要であることを留意するのが大事です。これらを最も有効に活かすためのスキルセットとマインドセットについて本章で検討していく。

## 9.1 カオスエンジニアリングとレジリエンス

カオスエンジニアリングは、
* 何かを壊す
* 問題を止める
* 脆弱性を見つけたりする

ためにツールを活用することではありません。

カオスエンジニアリングとは、システムから予想外の結果が得られることを前提に、回復力のあるカルチャーを作り上げる取り組みである。
このゴールを達成するのにツールが手助けになるなら、素晴らしいことであるが、それは目的に対する手段の1つでしかありません。

> レジリエンスエンジニアリングとは、さまざまな状況において人間や組織が効果的かつ安全に対応できる前向きな能力が何かを特定し、それを広げる取り組みです。レジリエンスとは、問題を減らすことではありません。
> [Sindney Dekker](https://www.amazon.co.jp/Foundations-Safety-Science-Understanding-Accidents-ebook/dp/B07QL9YH3M)

## 9.2 カオスエンジニアリングサイクルとその各ステップ

この項では、カオスエンジリアリングの3つのフェーズ
1. 事前準備
2. 実施中
3. 事後処理

に焦点を当てる。事前準備と事後処理のフェーズは、実施中フェーズと同じくらい、あるいはより多く洞察に富んだデータや、調べるべき分野がある。
事前準備のフェーズにはゴールが2つある
1. システムに対する異なるメンタルモデルを質問を元にしてチームメイト間で議論する。
2. 障害を起こしてみる前に、構造化されその場かぎりでない形で障害をデザインする方法の根底にあるべき戦略を改善すること

### 9.2.1 実験をデザインする

> すべてのメンタルモデルは間違っている。しかし、いくらかは役に立つ
> [George Box](https://www.sciencedirect.com/science/article/pii/B9780124381506500182)

インシデントは、システムがどのように動くかに対するある人のメンタルモデルが、他の人のメンタルモデルとどのように違うのかを、じっくり観察する機会です。
インシデントがこのような機会になるのは、システムがどのように動き、どのようにリスクに対処するかに対する私たちの思い込みを一定のレベルで裏切ってくれるタイミングだからです。
2人のメンタルモデル
* ジョシー
* サービスディカバリのインフラに100%の稼働率を期待している
* 長らくサービスディスカバリのインフラを使ってきており、気に入っていた
* 重要なキーバリューペアを保存し、必要な時に素早く変更する仕組みを作るのに、手間と時間を省け、問題が起きるまでは求めることが実現できていた
* マテオ
* サービスディスカバリを設計したマテオは、このインフラの利用者には稼働率が100%であると**期待している人**などいないと思っている
* サービス側でリトライやフォールバックが設定されていると思い込んでいる

> [サービスディスカバリ](https://ja.wikipedia.org/wiki/サービスディスカバリ)は、サービスのインスタンスがもつネットワーク上の位置を決定することである

大規模なシステム停止が発生した。2人の期待のズレと、元々の思い込みについて議論する機会がなかったことが原因になった。それぞれの思い込みは立場から全く合理的であり、サポートについて明確に議論することがなかった。障害が起きるまでは明確な議論をしようと思う人はいないでしょう。
カオス実験は、システムの部分Xが故障した時に何が起こるかについてのメンタルモデルと思い込みが、他のチームメイトのメンタルモデルと思い込みと違うことを確認する機会である。
カオス実験では実際の障害は発生していないので、心理的安全性が感じられるという、見逃せない一面がある。安全な環境で実験していると認識することで、結果として起こるシステムの振る舞いに対する恥ずかしさや不安感を減らせます。このような心理的な基盤を持つことで、障害が原因で誰が厄介毎に巻き込まれるのかという心配を持たずに、誰もが学習に集中できる。

## 9.3 カオス実験のデザインをサポートするツール

2017年Netflixでは、ChAPと呼ばれるツールを作っていた。デプロイパイプラインにユーザが指定したサービスを問い合わせ実験クラスタと、コントロールクラスタを起動し、それぞれのクラスタに少量のトラフィックをルーティングする。指定された故障注入シナリオが実験クラスタに適用され、その実験の結果が作成者に報告される。

ChAPは、アプリケーションが共通のJavaライブラリを使用しており、特定の呼び出しは失敗するというメタデータをリクエストに付与していたことをうまく利用していた。

>以下の文章は書籍ではなく[Netflixの論文](https://arxiv.org/pdf/1905.04648.pdf)から作成しています

Netflixは、通信事業者のような可用性は要求されていないが(稼働率99.99%)、それでも可用性はビジネスにとって重要であり、もし顧客がサービスの中断を経験すれば、サブスクリプションをキャンセルする可能性を危惧していた。
Netfilixはエンドユーザの視点(PC、スマホ、ゲーム機　etc..の様々なデバイス)から見ると単一のサービスである。内部的にはマイクロサービスアーキテクチャを用いて実装されており、RPC(Remote Procedure Call)により相互通信をしている。
以下の図はNetflixのマイクロサービスアーキテクチャを可視化したもので、各ノードは1つのサービスを構成するサーバ群となっており、トラフィックは左から右へと流れる。
サービスは異なるチームが所有し、各チームは他のチームと調整する必要はなく、独立してサービスをデプロイすることができる。マイクロサービスアーキテクチャは、障害領域を小さくすることで可用性を高めることができる
Netflixがレジリエンスを実現するために採用している戦略は、タイムアウト、再試行、フォールバックの3つである。
すべてのRPCはタイムアウトで構成されている。RPCがタイムアウトする理由には、呼び出された特定のサーバの問題(例：サーバーが過負荷)やネットワーキングインフラの問題など様々な問題がある。
NetflixではJavaベースのHystrix(ラテン語：ヒュストリクス)ライブラリを使用しており、フォールバックとサーキットブレイカーパターンを実装している。

>[サーキット ブレーカー パターン](https://learn.microsoft.com/ja-jp/azure/architecture/patterns/circuit-breaker)の目的は、再試行パターンとは異なります。 再試行パターンでは、アプリケーションが成功を見込んで操作を再試行することができます。 サーキット ブレーカー パターンは、失敗する可能性がある操作をアプリケーションが実行しないようにします。 アプリケーションは、サーキット ブレーカーによって操作を呼び出す再試行パターンを使用することで、これら 2 つのパターンを組み合わせることができます。 ただし、再試行ロジックは、サーキット ブレーカーによって返されるすべての例外から大きな影響を受け、エラーが一時的なものではないことが示されると、再試行回数を破棄します。

Hystrixライブラリには、コマンドという概念があ理、Hystrixのコマンドは潜在的に失敗する可能性のあるロジックのラッパーです。Hystrixの一般的な使用例は、RPCクライアントの呼び出しをラップすることです。Hystrixコマンドは、タイムアウトやエラー処理用のフォールバックをサポートするように設定できる。Hystrixコマンドはマルチスレッドで、デフォルトでは10個のスレッドを持つスレッドプールに関連づけられる。
タイムアウトとフォールバックに関する課題の1つは、これらの動作がハッピーパスほど頻繁に実行されず、期待通りに動作するという確信が持てないということです。これがChAPの開発における重要な動機の1つであった。

ChAPの実験のほとんどは、サービスの1つが劣化した場合に、システム全体が健全性を保てるかどうかを評価することに重点をおいている。注目する2つの障害モードは、サービスが遅くなる（応答レイテンシーの増加）、またはサービスが完全に失敗する（エラーを返す）ということでした。
サービスレベルの故障の見方は、多くの異なるタイプの故障を、サービスの速度低下やエラーの発生としてモデル化できるため有用である。
欠陥のあるコードの展開は、エラーを返すサービスとしてモデル化でき、多くの形式のリソース枯渇（例：CPU、スレッド、メモリ、ネットワーク帯域幅）は、サービスの速度低下としてモデル化できる。
フォルトの注入は、RPCで通常、着信するリクエストに、コールを失敗させるべきことを示すメタデータをアノテーションすることで行われる。

例えば「ロードオブザリング」を45分まで見た後、Netflixアプリを終了し、再び戻った場合、動画のどの位置から視聴を続ければ良いかを把握するのが「bookmarks」の役割となる
「bookmarks」はユーザにとっては付加価値のあるサービスですが、システム全体の機能にとって不可欠なものではない。仮に「bookmarks」に障害が発生しても、ユーザはサービスを利用し、動画を視聴することは可能という仮説を立てた。
この仮説を検証するために、一部のユーザに対して意図的に「bookmarks」を停止させる実験を行い、そのユーザが正常に動画配信を行える事を確認します。
この実験で影響を与えるユーザはアクティブユーザの1%をランダムに選択し、さらにユーザの1%は実験ユーザとは別のベースラインクラスタにルーティングする。


Netflixにおいては、ある箇所で安全に障害を起こす方法を設計するのに時間を費やすことで、そのシステムの特定の箇所に深い専門知識がなくても、システムがどのように接続されているのかについての知識が溜まり初めていく。
この知識をカオス実験を作り設計していくためだけではなく、ツールを最大限に活用する方法をチームに教えることに利用することを考えていた。ツールをどのように使い、どのようにサービスが故障するかという観点で徹底的に質問をしていたが、チームが自らの意志で実験を行なっていないことに疑問を持ち始めた。
ChAPのUIの一部に、以前の実験を確認し、いつ実行されたか、どのくらいかかったか、何が失敗したか、誰が実行したかというRunsというページを作り、疑問が正しかったことがわかった。
実験を実行していたのはほとんどの場合がカオスエンジニアだった。
本番環境で問題を引き起こす可能性があることに神経質になっており、安心してツールを使えるようにするため、カオスエンジニアたちがチームに安全な実験ができるように手助けを行った。
しかし、フルタイムのほとんどの時間をプログラミングしている事を期待されているカオスエンジニアたちにとってはかなりの負担となる仕事になっていた。
この問題を解決するため、自動的に実験を作成して実行すれば良いと考えた。
これを実現すべく、意味のある実験を作成するためにシステムの様々な場所に提供できるアルゴリズムを開発する必要があった。
サービスにとってカオス実験を安全に実行できるといはどういうことなのか、実験の優先順位の付け方、実験を作成するのに必要な情報の見つけ方といった様々な情報を集めた。
Netflix内での専門家に対するインタビューの結果から、サービスに含まれるコールが実験を実行するのに安全かそうでないかを判断するには、次の情報が必要である。

* タイムアウト
* リトライ
* コールにフォールバックがあるかどうか
* 通常時にトラフィックを処理している割合

これにより、カオス実験を行うチームの多くはユーザのところへ行って話をする必要があるとわかった。
必要な情報を集める最適な方法は、サービスオーナー達とパートナーを組み、彼らの視点とそれぞれのメンタルモデルを理解することが必要になる。

## 9.4 組織内で効果的にパートナリングする

航空、医薬品、海運におけるインシデントの調査の手法では、インシデントの途中あるいはインシデントに至る過程で何が起きたとチームメンバーは考えているのか、その詳細を抽出するため、認知面接(cognitive interviews)を行う第三者(ファシリテータ)を参加させる。
本当の問題がどこにあるかはメンバー達のメンタルモデルの違いが教えてくれる。認知面接は、カオス実験を特徴づけるのにも利用できる。
それぞれのチームメンバーのメンタルモデルを収集して仮説を構築するのは（少なくともカオス実験をデザインするフェーズにおいて）重要なことである。
この仮説は、ファシリテータが考えたものではなく、ファシリテータがグループ方式でチームメンバー達にインタビューを行い、システム自体とシステムが故障した時に起こることの理解について、各メンバーに発言の機会を与える。
グループ方式が重要なのは、各チームから複数の人が1部屋に集まり、システムに対する期待値を議論する時に、カオスエンジニアリングから最も大きな価値が得られる。

### 9.4.1 運用手順を理解する

ファシリテータは、「このシステムにおけるどんな振る舞いややりとりが気になりますか？」といった質問を投げかけることによって、参加者のグループをガイドし、議論の種をまく。
反発が起きないようなら、この質問はまずチーム内でも比較的社歴の短い人に問いかけ、その後、より社歴の長い人（あるいは特定の領域でより専門の人）に問いかける。
「専門家がその専門領域で非常に高いスキルを持つと、その専門知識を認識したりどのくらい深いのか判断できなくなってしまう」という「Law of Fluency(流暢の法則)」がある。
専門知識が、仕事にかけられた労力を隠してしまうため、カオス実験に備えて運用手順を理解しようとするファシリテータとしての役割は、隠されてしまっている労力を明らかにし、最終的にはそれを広めていくことです。
社歴の短い人に最初に問いかける理由としては、システムに対して新鮮な視点や、わかりやすい後知恵バイアスを持っているためである。

> 認知心理学者のGary Kleinは、比較的社歴の短い社員と、経歴の長い社員の違いとして、「社歴の短い社員はシステムが動いていた時ではなく、システムが正常に動かなくなった時を想像できる」としている
> [Seeing the invisible: perceptual-cognitive aspects of expertise](https://cmapspublic3.ihmc.us/rid=1G9NSY15K-N7MJMZ-LC5/SeeingTheInvisible.pdf)

ファシリテータは、チームメンバーが共有している描写に基づいて、システムに対する理解を描き出さなければなりません。
それに加え、興味を持っている振る舞いや相互作用がチームメンバーごとにどのように違うのか捉える必要があります。単に違いだけではなく、専門知識も捉え、チームメンバーは質問に対してそれぞれ違った答えを持っているはずなので、実験の学習機会として扱う。

* 下流のサービスで気になるところはありますか？
* 担当サービスで問題が発生した時、上流のサービスでは何が起きますか？
* 今、担当するサービスで問題が発生したら、何が起きますか？
* フォールバック先（またそれに類するもの）は準備されているますか？
* フォールバック先は何をしますか？
* フォールバック先はサービスの振る舞いをどのように変えますか？
* フォールバック先はどのようにユーザエクスペリエンスを変える可能性がありますか？
* システムに対する直近の変更（あなたのサービスでも、その上流または下流のサービスでも）で、新たな脆弱性をもたらし得るものはありますか？
* それらの変更について最もよく知っているのは誰でしょうか？
* サービスのさまざまな設定パラメータに関してどのくらい自信を持っていますか？具体的には、設定されているタイムアウトやリトライなどシステムにハードコードされた値が及ぼす影響を理解していますか？
* システムに対する日々のオペレーションで一番怖いのは何ですか？
* システムについてチームメイトはどんなことを知っているはずだと思っていますか？

自信の有無は、自分のメンタルモデルに不確実性があること、あるいはオペレーションの手順に自信がないことを表しています。
実験のデザインに関わった全員がこれらの質問に関して合意形成ができたら、実験のスコープの議論に移れる。質問の答えによっては、このセクションを飛ばすという判断をするのも全く問題なく、実際に飛ばすことも多いはず。

### 9.4.2 スコープを議論する

実験のスコープを議論し、皆んなのメンタルモデルを調整する必要がある。これらの質問に対する回答はそれぞれ違うものになるが、それは問題にはなりません。

* 「正常な」あるいは「よい」オペレーションをどのように定義しますか？
* 実験のスコープ（どこに障害を注入するか）をどのように定めますか？
* そのスコープに決めた理由は何ですか？
* ここにいる全員がその理由を理解していますか？またはそれをどうやって確認しますか？
* これは恐怖心が元になった実験ですか？
* この実験をするのは、過去に痛い目にあったからですか？もしそうなら、ポストモーテムやインシデントに関する会話へリンクをつける
* この実験をするのは、Xで障害発生した時に**何が起こるのか**の理由が欠けているからですか？（その障害はほとんど発生する可能性がなく、何が起こるかわからないのでしょうか？）
* その障害が起きた時に何が起きると期待されていますか？（明確に表現すること）
* 各コンポーネントからは何が起こると予想されていますか？
* システム全体では何が起こると予想されていますか？
* システムが問題のある状態であることをどのように知りますか？
* この実験の間、どれが計測すべき最も重要なメトリクスですか？
* これらの質問をするときは、HollnagelとWoodsの「可観測性とは、**プロセスに対する見方を提供し**、利用可能なデータから意味を抽出するために必要な仕事に注意を向けるためのフィードバックである」という言葉をよく考える。
* どのようにシステムを**観測**していますか？
* **どのように**影響範囲を限定していますか？
* この実験から認識される（サービスチームに対する）ビジネス上の知覚価値は何ですか？それ以外の部署に対する価値は**何**ですか？

### 9.4.3 仮説を立てる

実験に関する仮説を練り、より明確に表現するための時間を取る。

システムの部分Xが故障したら、Yが発生し、影響はZになる。

* 定常状態(steady state)とはどのような状態かを書き出しましょう
* 定常状態からの逸脱から予想されることは何ですか？（これは、監視すべきだと判断した全てのメトリクスについて行う）
* 次に、ユーザエクスペリエンスから予想されることを書き出しましょう
* 続いて、下流のサービスへの影響について予想されることを書き出しましょう。
* 最後に、全てのステークホルダーとそのドキュメントを共有しましょう

:::info
*役割を決める*

ゲームデー形式の実験を行おうとしているなら、参加する人を特定し、実験における彼らの役割を明確にしましょう。自動化された実験に対しては全ての役割を割り当てる必要はない。影響範囲を限定したり自動で障害を作り出すような自動化をまだしていない段階なら、実験の準備のたびに次のような役割が必要になるはずです。

* デザイナあるいはファシリテータ（議論をリードする人）
* 指揮官（命令を実行する人）
* スクライブ（何が起きているのか、Slackなどコミュニケーションツールにメモを記録する人）
* 監視員（グループ内で、関係するグラフを注視し共有する人）
* 通信員（アラートを受け取るチャンネルに目を配り、現在のオンコール担当が実行中の実験に気がついているか、何が予想される影響か理解しているか確認する人）

実験のデザインや実行に関わったそれ以外の人達と、実験の中での彼らの役割もリストアップしておきましょう

:::

全ての質問に対する答えが出揃い、役割が準備されたら、デザイナーあるいはファシリテータはグループ全体に対し、実験への見解とミーティングで何を議論し何を学んだかを共有しなくてはなりません。
この時、使用した方法と注意すべき範囲が明確に記述された使いやすいフォーマットにする必要がある。

* 実験前
* 定常状態に対する理解や思い込みのずれについて、質問を通じてどのように知りますか？
* このような認識のずれは何に由来するもので、どのような意味がありますか？「正常な」あるいは「よい」オペレーションをどう定義しますか？
* システムのこの部分に実験を行うことをの知覚価値は何ですか？
* 視覚的に表現したり、システムがどのように動くかはっきりした仮説を元にしたりといった方法で、各人のメンタルモデルを整理された状態で書き出すように促すには、どのようにしますか？
* 実施中の状態に至るため、自動化する決断が必要なものがあるはずです。何を自動化すべきかどのように決めますか？
* どの程度のスケールでなら実験を安全に実行できるかどのように判断しますか？
* 回復力を実験するプラットフォームの有効性を計測するのに使うべき、あるいは使うべきでないものは何ですか？
* ノイズをシグナルから分離したり、エラーがカオス実験の結果によるものなのかそうでないかを判断したりするにはどうしますか？
* 実験後：実験により問題が見つかったら、事後に以下のような質問を問いかける
* 何を学びましたか？
* 理解を再構築し繰り返すために、学んだ情報をどのように活用しますか？
* 実験を行う前、チームはどのようにして実験の実行に自信を持ちましたか？
* 実験の中で何が明らかになるか、チームはメンバー同士でどのようにコミュニケーションを取りましたか？
* 特別な専門知識が必要になったため、実験のデザインや実行時に参加していなかった誰かを呼んだり連絡を取る必要がありましたか？
* 実験の途中で（実験への関係の有無を問わず）障害が発生しましたか？
* 実験の結果がどうだったのか分類を始めるにはどうしますか？
* 実験のどの部分が予想と違う動きになりましたか？
* 学んだことあるいはまだ理解していないことを考慮すると、次のサイクルではどんな実験をすべきですか？
* 組織内の全員が確認でき、最後まで読めるように実験からの学びを広めるにはどうしますか？
* 時間が経過しても別々の実験にまたがるテーマを理解できるようにするにはどうしますか？また、これらのテーマをインシデントや組織が経験した予期しないことに関連づけるにはどうしますか？

## 9.5 まとめ

リストアップした質問は、ファシリテータが議論をガイドするために利用できるツールです。しかし、この議論のポイントは、専門家チームがシステムのコンポーネントについて隠れた専門知識を見つけ出してそれを共有するのを手伝うことです。ファシリテーターは専門知識を明らかにするためにそこにいるのであって、自分の専門知識を見せるためにいるのではない。実験が予期しないような何かを見つける場になるような、最高な仮説を立てるためにあるのです。
カオス実験の事前準備と事後処理のフェーズに関わる基本理念の全ては、**本番環境での実験を自動化しようとし、ユーザ側の「面倒なこと」を減らそうとする**経験から来たものです。
カオス実験で得られた最大の価値は、人々がシステムに対するメンタルモデルを改善し、磨きをかける手伝いをしたということです。
自動化を行なっても、数週間動かしたのち、最終的には自動化を止めます。それは価値の多くを自動化そのものではなく、ダッシュボードと、実験を自動化するそのプロセスから得ているからです。
この経験全体から、ファシリテーション、認知面接、専門知識を広めることは、組織内でカオスエンジニアリングを成功させるために非常に重要である。自動化の仕組みを開発する手法とその結果を共有したことで、システムがどのように動き、どのように故障するのかについてメンバーそれぞれの理解を深めることができる。