9.6 カオスエンジニアリングとレジリエンステスト

概要と動機

カオスエンジニアリングとは、本番の乱れた条件に耐えるシステムの能力への確信を築くために、システムに対して実験を行う、規律ある実践です。名前は無謀に聞こえ、それが最初に捨てるべき思い込みです。カオスエンジニアリングは、無作為に物を壊して何かを学ぶことを願うものではありません。その逆です。ユーザーより先に弱点を発見するために、現実的な失敗を注入する、管理された仮説駆動の方法です。システムが失敗に直面することはすでに知っています。本物のシステムはすべてそうだからです。唯一の問いは、ロールバックを用意した火曜日の午後にそれらの失敗に出会うのか、何が起きているのかわからないまま、最も忙しい時間帯の午前3時に出会うのかです。

大きなチームにとって、これが重要なのは、複雑さが、誰かが点検によって推論できる範囲を超えて育ったからです。現代のサービスは、数十から数百のコンポーネントの網で、それぞれが独自のタイムアウト、リトライ、キャッシュ、失敗の様式を持ち、それらの間の相互作用は、どんなアーキテクチャ図も予測しない創発的な挙動を生みます。コードをレビューし、箱を描いても、遅い依存関係が、3ホップ先のサービスを落とすリトライの嵐を引き起こすことに不意を突かれえます。カオスエンジニアリングは、それらの相互作用を経験的に探る方法なので、レジリエンスは、想定するものではなく、検証したものになります。

企業と政府の文脈は、賭け金を、そしてますます義務づけを引き上げます。金融規制当局は今や、企業が深刻だがありそうなシナリオに対する運用のレジリエンスをテストし、中断を通じて重要なサービスを動かし続けられることを証明するよう期待します。政府機関は、不可欠な公共サービスが停止、災害、サイバー攻撃を生き延びるよう、運用継続の演習を行います。どちらの世界でも、「持ちこたえると思う」は、監査人や市民への受け入れられる答えではありません。カオスエンジニアリングは証拠を与えます。この章は、サイトリライアビリティエンジニアリング(9.1章)と3.5章のレジリエンスのパターンの上に築かれ、インシデント管理(9.3章)と災害復旧(9.5章)に密接につながります。

主要原則

混沌を作るのではなく、確信を築く。 目標は、見世物ではなく検証されたレジリエンスです。すべての実験は、ストレス下でのシステムの挙動についての特定の問いに答えます。
まず定常状態を定義する。 「健全」が何かの明確で測定可能な定義がなければ、問題を検知できません。
仮説を立てる。 障害を注入する前に、何が起こると予期するかを述べます。驚きは発見で、驚きがないこともまた発見です。
影響範囲を最小化して封じ込める。 小さく始め、本物のユーザーを守り、確信が育つにつれてのみ範囲を広げます。
注意深く、本番を優先する。 失敗は、本物のトラフィック、本物のデータ、本物の規模のもとで異なって振る舞います。そこでテストする権利を勝ち取ります。
継続的な検証に向けて自動化する。 一度直した弱点は退行しえます。継続的にテストされるレジリエンスは、真実であり続けます。
失敗は教師であって、判決ではない。 発見はシステムを改善します。実験を行った人を責める理由には決してなりません。

推奨事項

一つの障害を注入する前に、前提条件を確立する

カオスエンジニアリングは、成熟したシステムにとっては力の倍増装置で、未成熟なシステムにとっては負債です。始める前に、三つのものが整っている必要があります。第一に、オブザーバビリティ、つまり外側からシステムが何をしているかを見せるメトリクス、ログ、トレース。観察できない実験からは何も学べないからです。第二に、成功した実験と有害な実験をリアルタイムで見分けられるよう、サービスレベル目標、あるいは健全な定常状態の同等の定義(9.1章)。第三に、実験が本物のユーザーを脅かしたとき、数秒でそれを止めて通常のサービスを回復できるよう、速く信頼できるロールバックあるいは中止の経路。システムを測定し、健全な状態を定義し、崖っぷちから引き戻せないなら、まだカオス実験を行わないでください。まずそれらの能力を築きます。それらはどのみち元を取ります。

定常状態を定義し、本物の仮説を立てる

すべての実験は、正常が測定可能な言葉でどう見えるかを書き出すことから始まります。リクエスト成功率が99.9パーセント超、チェックアウトのレイテンシが95パーセンタイルで400ミリ秒未満、キューの深さが閾値未満。これがあなたの定常状態の定義で、内部の配管ではなく、ユーザーに見えるヘルスを反映すべきです。それから、仮説を平易な言葉で述べます。「レコメンデーションのサービスに300ミリ秒のレイテンシを加えても、ページがレコメンデーションを任意として扱い200ミリ秒でタイムアウトするので、商品ページはレイテンシバジェット内で描画され続ける」。これで反証可能な主張ができました。実験を走らせると、二つの良いことのどちらかが起こります。システムが予測通りに振る舞い、確信が勝ち取られるか、そうならず、エンジニアが見守る中、自分たちの条件で、安く本物の弱点を見つけるか。

恣意的ではなく現実的な障害を注入する

導入する障害は、システムが実際に経験する失敗を映すべきです。フォールトインジェクション、つまりシステムの反応を試すための意図的なエラーの導入は、本物の本番インシデントから引いたメニューを与えます。遅い依存関係や飽和したネットワークリンクをシミュレートするために、レイテンシを注入します。失敗する下流のサービスをシミュレートするために、HTTP 500や接続拒否を返すエラーを注入します。圧力のもとでシステムがどう縮退するかを見るために、CPU、メモリ、ディスク、ファイル記述子を消費して、リソース枯渇を注入します。データベース、キャッシュ、キュー、サードパーティのAPI全体を到達不能にして、依存関係の失敗を注入します。コンポーネントが別々のマシンで動き、信頼できないネットワークを介して通信する分散システムでは、これらが本物の停止を支配する失敗です。実際に物を壊すのは、きれいなクラッシュではなく、レイテンシと部分的な失敗なので、実験を散らかった中間に重みづけてください。

レジリエンスの仕組みが実際に働くことを検証する

ここが、カオスエンジニアリングが価値を発揮する所です。システムは、あなたを守るはずの仕組みで満ちています。呼び出し側が永遠に待つのを止めるタイムアウト、一時的な揺らぎを取り繕うリトライ、失敗する依存関係を叩き続けるのをやめるサーキットブレーカー、主系が死んだときにスタンバイへ切り替えるフェイルオーバー。3.5章で扱うこれらのパターンが、封じ込められた問題と連鎖する停止の違いです。問題は、それらが存在するための条件のもとでめったにテストされないことです。呼び出し側自身の期限が2秒のときに30秒に設定されたタイムアウトは、何もしません。バックオフのないリトライは、一つの苦しむサービスを雷鳴の群れに変えます。一度も演習されていないサーキットブレーカーは、誤設定で決して作動しない、あるいはしょっちゅう作動するかもしれません。カオス実験は、それが守る障害が実際に到来したとき、これらのそれぞれが設計通りに振る舞うことを確認する方法です。テストされていない安全の仕組みはすべて、実験が別のことを証明するまで壊れていると想定してください。

自動化の前にゲームデーから始める

障害を継続的に注入する自動化されたプラットフォームから始めないでください。ゲームデーから始めます。チームが集まり、シナリオを選び、管理された環境で障害を注入し、一緒に見守る、予定された実地の演習。それ以前に、システムに触れずにホワイトボードでシナリオを話し合う机上演習が、ほとんどリスクなしに、ランブック、アラート、所有の隙間を表面化させます。ゲームデーは入り口です。仮説を立て、影響範囲を封じ込め、ストレス下でシステムを読む筋肉を育て、本番で実験を走らせることを許されるために必要な、リーダーシップと隣接するチームとの信頼を築きます。また、本物のインシデント(9.3章)の間にオンコールのエンジニアが使うのと同じ技能なので、インシデント対応を直接強めます。最初のゲームデーはステージングで、次に静かな時間帯の本番で小さな影響範囲で行い、それから広げます。

影響範囲を意図して封じ込める

最も重要な唯一の安全の実践は、すべての実験の潜在的な害を限ることです。何かを教えられる最小の範囲から始めます。一つのインスタンス、トラフィックの1パーセント、一つの重要でない依存関係、一つのアベイラビリティゾーン。開始前に中止の条件を定義し、定常状態の指標に配線し、実験を止めることを、見ている誰もが起動できる単一の行動にします。驚きが誰も見ていないインシデントになる夜間ではなく、チームが警戒して配置されている営業時間中の実行を好みます。小さな実験がきれいに走り、確信が本当に高まったときにだけ、影響範囲を広げます。封じ込めの規律が、カオスエンジニアリングと、自分で起こした停止を分けるものです。

継続的で自動化されたレジリエンスの検証に向けて育てる

時折のゲームデーは弱点を見つけますが、システムは毎日変わり、前四半期の修正は静かに退行しえます。成熟した最終状態は継続的な検証です。パイプラインあるいはスケジュールで自動的に走る、選り抜かれたレジリエンス実験の集合で、タイムアウト、リトライの方針、フェイルオーバーの経路の退行が、次の本物の停止の間ではなく、数日以内に捉えられます。NetflixのChaos Monkeyのようなツールがその評判を勝ち取ったのはここで、本番のインスタンスを無作為に終了させて、エンジニアにインスタンスの喪失に耐えるサービスを築かせます。手作業の実行からすでに理解し信頼している実験だけを自動化してください。未成熟なシステムの上の継続的なカオスは、確信ではなくインシデントを生む方法です。

実験を災害復旧とインシデントの学びにつなげる

カオスエンジニアリングは単独では存在しません。リージョン全体の喪失、データベースのフェイルオーバー、バックアップからの復元のような、より大きくまれなシナリオは、災害復旧のテスト(9.5章)に属し、ゲームデーはしばしば、それらの計画をテストされない文書として腐らせる代わりに、演習する最良の手段です。反対側では、弱点を表面化させたすべての実験が、本物のインシデント(9.3章)と同じ学びのループに供給されるべきです。責めない書き出し、追跡される修正、修正が保たれることを確認する後続の実験。カオスの発見、災害復旧の訓練、インシデントの振り返りがすべて、レジリエンスの仕事の一つの積み残しに流れ込めば、散在する一回限りの演習ではなく、複合する見返りが得られます。

トレードオフ: 長所と短所

決定	長所	短所
本番でのテスト	本物のトラフィック、データ、規模。発見は真実	封じ込めが失敗するとユーザーへのリスク。成熟が必要
ステージングのみでのテスト	安全、低い賭け金、始めやすい	現実の挙動を見逃す。誤った確信
手作業のゲームデー	技能と信頼を築く。低いツールコスト	頻度が低い。発見が気づかれず退行しうる
継続的で自動化されたカオス	退行を速く捉える。スケールする	まず成熟したツールとオブザーバビリティが必要
広い影響範囲	大きな構造的な弱点を明らかにする	高リスク。間違いがインシデントになる
狭い影響範囲	安全で制御可能	サービス横断の創発的な失敗を見逃しうる

中心的な緊張は、現実性と安全性の間にあります。最も欲しい発見は本番から来ます。そこだけが、システムが本物のトラフィック、本物のデータ、本物の規模に直面する場所だからですが、本番はまさに、失敗した実験がユーザーに害を与える場所でもあります。解決は、片側を選ぶことではありません。徐々に本番へ向かう権利を勝ち取ることです。前提条件を証明し、ステージングでリハーサルし、それから生きた指標に配線された中止の条件を伴って、小さくよく封じ込められた実験を本番で行い、証拠が蓄積されたときにだけ範囲を広げます。もう一つの繰り返される緊張、手作業対自動化も、時間とともに同じように解決します。理解と信頼を築くために手作業で始め、それから頼りにするようになった実験を自動化して、一度検証したレジリエンスが検証されたままであるようにします。

チームで議論すべき問い

私たちは本当にカオス実験を行う準備ができていますか。そしてどうやってそれを知りますか。 洗練されて聞こえるので障害を注入し始めたくなりますが、観察できず、明確な健全性の定義も速いロールバックもないシステムへのカオスエンジニアリングは、自分で起こす停止にすぎません。この議論に誠実な証拠を持ち込んでください。リクエスト成功率とレイテンシをリアルタイムで見られるか、定常状態について合意された定義があるか、数秒で実験を中止して回復できるか。大きなチームでは、答えはしばしばサービスごとに異なるので、有用な成果は、サービスが実験の対象になる前に越えなければならない準備の基準です。規制対象の設定では、その準備の基準が、監査人に示せる統制を兼ねます。誠実な答えが、準備ができていないということなら、今四半期にできる最も価値あるカオスの仕事は、準備を整えるオブザーバビリティとロールバックの能力を築くことです。
私たちの影響範囲の方針は何で、実験を止める権限を持つのは誰ですか。 すべてのカオス実験は本物のユーザーに何らかのリスクを持ち、価値ある発見と自分で起こしたインシデントの違いは、どれだけ厳密に封じ込めたかです。具体的な限界を話し合ってください。トラフィックのどの割合か、いくつのインスタンスか、どの環境か、一日のどの時間か、どの指標の閾値が実行を自動的に中止するか。誰が各実験を見ていて、誰が単一の行動のキルスイッチを持つかを事前に決めてください。誰も素早く止められない実験は、封じ込められていないからです。大きな組織では、この方針が、多くのチームが、どれも偶然に共有の依存関係を落とさずに実験できるようにするものです。答えは書き出され、影響を受けうるサービスのチームと合意され、本番で何かを走らせる前提条件として扱われるべきです。
どのレジリエンスの仕組みが私たちを守ると信じていて、実際にテストしたことがありますか。 ほとんどのシステムは、それらが存在する失敗のもとで演習されないまま、一度設定されたタイムアウト、リトライ、サーキットブレーカー、キャッシュ、フェイルオーバーの経路で満ちています。頼りにしている仕組みの一覧を作り、それぞれについて、本物の注入された障害のもとで動作が最後に検証されたのはいつかを尋ねてください。相反する考慮は時間です。各仕組みの検証にはエンジニアリングの労力がかかり、機能の期限は常にあります。その反論に対する反証を持ち込んでください。つまり、動作するサーキットブレーカーや正しいタイムアウトが封じ込めたはずの過去の停止のコストです。答えは、安心させる想定された保護の一覧を、失敗が最も痛手となる仕組みから始める、優先順位づけられた実験の積み残しに変えるべきです。
ステージングではなく本番で実験を行う前に何が真でなければならず、今日その権利を勝ち取ったサービスはどれですか。 最も欲しい発見は本番から来ます。そこだけがシステムが本物のトラフィック、データ、規模に出会う場所だからですが、本番は失敗した実験が実際のユーザーに害を与える唯一の場所でもあります。大きなチームでは、誠実な現実は、サービスごとに準備の水準が異なることなので、「本番のカオスはなし」という一律のルールは最良の学びを無駄にし、一律の「あり」は自分で起こす停止を招きます。サービスごとの証拠を持ち込んでください。そのオブザーバビリティの質、定常状態が定義されてアラート可能か、ロールバックの速さ、それを昇格させることを正当化するきれいなステージングの実験の実績。企業と政府の設定では、本番のゲートを、誰が昇格を承認し、どの中止の条件が生きた指標に配線されているかを名指しする、文書化された統制に結びつけ、監査人が、本物のユーザーで即興するチームではなく、意図された証拠のある決定を見られるようにしてください。
カオス実験が弱点を表面化させたとき、その発見はどこへ行き、手つかずで腐るのをどう防ぎますか。 弱点を発見するが決して直さないプログラムは、プログラムがないより悪いです。労力を燃やし、信頼を侵食し、実験は劇場だと人々に教えるからです。相反する圧力は常に機能のロードマップです。レジリエンスの修正は、それが防いだはずの停止が実際に来るまで、次のリリースほど緊急には感じられません。レジリエンスの積み残しの現在の状態を議論に持ち込んでください。いくつのカオスの発見が未解決か、最古のものはどれだけ古いか、実験、災害復旧の訓練、インシデントの振り返りからの発見が一つの共有のキューに流れるか、チーム間に散らばるか。誰が各修正を所有し、誰が修正が保たれることを確認する後続の実験を行うかに合意してください。大きなあるいは規制対象の組織では、積み残しを固定の周期でレビューし、機能よりレジリエンスの修正を優先する権限を持つ場を名指ししてください。閉じる責任を誰も負わない発見は、取り除いたのではなく、文書化しただけのリスクだからです。
実験のどれかを継続的な検証に自動化する準備はできていますか。そして具体的にどれですか。 時折のゲームデーは弱点を見つけますが、システムは毎日変わり、前四半期の修正は静かに退行しうるので、成熟した最終状態は、自動的に走って数日以内に退行を捉える、選り抜かれた実験の集合です。危険は、早すぎる自動化です。弱いオブザーバビリティの未成熟なシステムに重ねた継続的なカオスは、洞察より速くインシデントを生みます。完全に信頼できるほど手作業で十分な回数走らせた実験の一覧、それらを無人で統治する影響範囲の制御と中止の条件、誰も見ていない午前3時に自動実行がうまく行かなくなるのを捉える監視を持ち込んでください。大きな企業あるいは公的機関では、無人の障害注入が招く追加の精査を量ってください。変更管理の承認、各自動実行が残さなければならない監査証跡、本物のインシデントと重なった予定された実験への明確な説明責任。すでに理解している実験だけを自動化し、残りは同じ信頼を勝ち取るまで手作業のままにしてください。

セクター別の視点

スタートアップ。 速度と生存が支配的なので、カオスのプラットフォームには何も使わないでください。実際にあなたを殺す一つの依存関係、通常は決済、認証、主要なデータストアの失敗に対して、ステージングで90分のゲームデーを一度行います。粗いプロキシや殺したプロセスで障害を注入し、何が壊れるかを見て、欠けたタイムアウトやフォールバックを直し、先へ進みます。要点は、人員を置けない規律を築くことではなく、顧客がそうする前に、自分で起こす明らかな停止を安く捉えることです。

小規模事業者。 信頼性の専門家はおらず予算も厳しいので、レジリエンステストを、人員を置くプログラムではなく、定期的で意図した演習として扱ってください。専用のプラットフォームを買うのではなく、クラウドプロバイダーやマネージドなツールがすでに含む障害注入の機能に頼り、顧客が気づく少数の依存関係に実験を集中させます。保険として枠づけてください。バックアップが復元できてチェックアウトがグレースフルに縮退することを確認する一日の午後は、そうでないことを証明する停止よりはるかに安いのです。

大企業。 問題は、規模での共有の依存関係に対して多くのチームを調整することなので、本番で走らせる前にすべてのチームが越えなければならない準備の基準、影響範囲の方針、中止条件の配線を標準化してください。カオスの発見、災害復旧の訓練、インシデントの振り返りを、明確な所有を伴う一つのレジリエンスの積み残しに流し、四半期ごとのゲームデーと選り抜かれた自動実験の集合で、運用のレジリエンスの期待を証拠で満たします。誰が共有のサービスに影響を与えてよいかを統治し、どの単一のチームの実験も、他が依存するインフラストラクチャを落とさないようにします。

政府。 調達規則、透明性、公的な説明責任が仕事を形づくります。運用継続の義務づけはしばしばどのみち定期的な演習を要求するので、誰も開かないバインダーではなく、本物の発見を生む生きたゲームデーとして行い、すべての実験、その影響範囲、結果の監査証跡を保ちます。障害注入のツールを調達する場合は、セキュリティとデータ取り扱いの規則に収まることを要求し、市民向けサービスでの本番の実験は、厳密に封じ込められた承認済みの窓のために取っておきます。カオスのプログラムが生む証拠は、まさに監督機関や監査人が見ることを期待するものです。

事例

スタートアップ。 15人のスタートアップは、少数のサービスでウェブアプリを動かし、サードパーティの決済APIに依存します。誰もカオスのプラットフォームの時間はないので、チームはステージングで90分のゲームデーを行います。仮説を立てます。決済APIがエラーを返し始めたら、チェックアウトは、クラッシュせずに、明確なリトライのメッセージを示して注文をキューに入れるはずだ。単純なプロキシで500応答を注入し、クライアントの呼び出しにタイムアウトがないためフロントエンドが無期限にハングすることを発見します。タイムアウトと親切なフォールバックを加え、修正を確認するために実験を再実行し、共有のドキュメントに二段落のメモを書きます。総コストは、午後一回と、顧客が当たる前に捉えた一つの非常に現実的なバグです。

大企業。 世界的な銀行は、深刻だがありそうなシナリオに対する運用のレジリエンスを規制当局に示さなければなりません。その信頼性チームは、四半期ごとのゲームデーに加えて、本番での自動実験の集合を運営します。一つのシナリオは、低トラフィックの窓の間に、主要な取引データベースをスタンバイにフェイルオーバーさせ、厳密に封じ込められた影響範囲と、取引成功率に結びついた中止の条件を伴います。最初の実行で、下流の突き合わせサービスにバックオフのないリトライの方針があり、負荷の急上昇を生んで、災害復旧計画(9.5章)の復旧時間目標をはるかに超えて復旧を遅らせることが明らかになります。発見はインシデントの振り返りと同じ積み残しに入り、リトライの方針は指数バックオフで直され、後続の実験が、フェイルオーバーが今や目標内に完了することを確認します。演習全体が規制当局への証拠になります。

政府。 市民向けの給付ポータルを運営する国の機関は、中断を通じて運用の継続を維持することを求められています。継続計画を誰も開かないバインダーとして扱うのではなく、機関は年次の継続演習を生きたゲームデーとして行います。チームは主要なデータセンターの喪失をシミュレートして副サイトへのフェイルオーバーを歩き、それとは別に、ポータルがグレースフルに縮退するかを見るために、本人確認の依存関係にレイテンシを注入します。テストされていない監視の隙間のために、オンコールのチームが本人確認のサービスの低下に気づかず、アラートが遅れて発火したことを学びます。機関はオブザーバビリティの隙間を閉じ、ランブックを更新し、来年も同じ演習を予定し、コンプライアンスの要件を、重要な公共サービスの本物のテストされたレジリエンスに変えます。

ビジネスケース: 動機、ROI、TCO

カオスエンジニアリングの見返りは、起こらなかった停止から来ます。大きなサービスの単一の大きな停止は、失われた収益、規制上のペナルティ、是正の労力、サービスが回復した後も長く残る評判の毀損で、数万から数百万のコストがかかりえます。カオス実験は、それらの予測できない高価な驚きを、エンジニアが見守りロールバックを用意して、自分の予定で直せる、安く予定された発見に変えます。管理されたゲームデーの間に壊れたタイムアウトを見つけるのは、午後一回のコストです。本物のインシデントの間に見つけるのは、停止、総出の大慌て、ユーザーの信頼のコストです。算術は、大差でゲームデーに有利です。

総所有コストは、前提条件が整えば控えめです。カオスエンジニアリングは、どのみち必要なオブザーバビリティ、アラート、ロールバックの投資を再利用するからです。誠実なコストは、実験を行うエンジニアリングの時間、障害を注入し影響範囲を封じ込めるいくらかのツール、そして意図して失敗を導入することにリーダーシップを慣れさせる文化的な仕事です。最後のものが本物の障壁で、それを抜ける道は、ステージングで始め、お金やリスクに対応する発見を示し、少数の封じ込められた本番の実験に信頼を築かせることです。リーダーシップに論拠を示すには、カオスエンジニアリングを、測定できる保険として枠づけてください。最近のインシデントのコストを示し、レジリエンスの実験がそのどれを捉えたはずかを示し、小さく始め、自らを証明するにつれてのみ広がるプログラムを提案します。規制対象と公共部門の設定では、コンプライアンスの角度を加えてください。運用のレジリエンスのテストと継続の演習はますます期待されており、カオスのプログラムは、その期待を書類ではなく証拠で満たす方法だからです。

アンチパターンと落とし穴

オブザーバビリティのないカオス。 見えないシステムに障害を注入することは、手順が増えただけの推測であること。害を与え、何も学べない。
定常状態の定義がない。 健全さについて合意された尺度がなければ、実験が問題を明らかにしたのか、引き起こしたのか見分けられないこと。
仮説がない。 無作為に物を壊すことはカオスエンジニアリングではなく、発見のない、格好をつけた名前の破壊行為であること。
封じ込められない影響範囲。 小さく安全な実験を飛ばして本番全体の失敗に直行すると、テストが自分で起こす停止になること。
中止の経路がない。 即座に止められない実験は実験ではなく、引き金を待つインシデントであること。
早すぎる自動化。 未成熟なシステムの上の継続的なカオスは、洞察より速くインシデントを生むこと。
どこにも行かない発見。 弱点を発見して決して直さないことは、演習を無駄にし、プログラム全体への信頼を侵食すること。
悪い実験の後の非難。 本物の欠陥を表面化させた実験を行ったエンジニアを罰することは、誰も次を行わないことを保証すること。

成熟度モデル

レベル1: 開始: レジリエンスはテストされず、想定されています。失敗は、本物のインシデントの間に本番で発見されます。ゲームデーも障害注入もなく、しばしば健全さが何かの明確な定義もありません。チームは、停止を一つずつ通じて、つらい方法で弱点を学びます。
レベル2: 発展: チームは、通常ステージングで、定義されたシナリオと仮説を伴う時折のゲームデーを行います。定常状態は少数の主要なサービスで定義され、基本的なオブザーバビリティが存在します。発見は捉えられ、一部は直されますが、実践はチーム間で一貫せず、確立された方法ではなく個々の推進者に依存します。
レベル3: 標準化: カオス実験は、徹底される影響範囲の方針、中止の条件、サービスが本番で実験する前に越えなければならない準備の基準を伴う、文書化された組織全体の実践です。実験は管理された条件のもとで本番で走り、発見は、インシデントの振り返りと災害復旧の訓練と並んで、共有のレジリエンスの積み残しに流れ、レジリエンスの仕組みは想定されるのではなく検証されます。すべてのチームが同じ手引きに従います。
レベル4: 管理: プログラムが、ベースラインに対するデータで測定され制御されます。レジリエンスのカバレッジ(どの重要なサービスとどの仕組み、たとえばタイムアウト、リトライ、サーキットブレーカー、フェイルオーバーが、本物の注入された障害のもとで、どれくらい最近検証されたか)、実験が発見を表面化させる率、レジリエンスの発見を閉じるまでの平均時間、以前に検証された仕組みが退行する頻度を追跡します。これらの指標は固定の周期でレビューされ、本番への昇格は意見ではなく証拠でゲートされ、実験は、まだ検証されていない仕組みの測定されたリスクで優先順位づけられます。
レベル5: オーケストレーション: 選り抜かれた実験の集合が継続的かつ自動的に走り、数日以内に退行を捉え、プログラムはシステムとそのリスクの状況が変わるにつれて適応します。カオスエンジニアリングは、デリバリーのパイプライン、インシデントの学び、災害復旧のテストと組織全体で統合されているので、新しいサービスは既定でレジリエンスの検証を引き継ぎます。レジリエンスは継続的に検証されるシステムの性質であり、リーダーシップは、プログラムを特別な取り組みではなく、証拠で洗練される標準のリスク管理として扱います。

議論のためのアイデア

あなたの組織のどのサービスが、最初に本番でカオス実験を行う権利を勝ち取るかをどう決め、そうなる前に何が真でなければなりませんか。
カオス実験が深刻な弱点を表面化させたとき、誰が修正を所有し、その発見が積み残しで手つかずのまま座るのをどう防ぎますか。
あなたの文脈で、カオス実験、災害復旧の訓練、ゲームデーの間の線はどこにあり、その区別は、それらを計画する方法にとって重要ですか。
本番に意図して障害を注入することが、本物の停止を待つ現状よりも安全だと、懐疑的な経営幹部をどう説得しますか。
来月チームが行える、最小で最も価値のある最初の実験は何で、それを行うのを何が妨げますか。
レジリエンステストは、継続の義務づけを持つ市民向けの公共サービスと、小さなユーザー基盤を持つ内部の企業ツールで、どう異なるべきですか。

要点

カオスエンジニアリングは、無作為な破壊ではなく、レジリエンスへの確信を築くための、規律ある仮説駆動の実験です。
一つの障害を注入する前に、オブザーバビリティ、定常状態の定義、速いロールバックを確立します。
現実的な障害(レイテンシ、エラー、リソース枯渇、依存関係の失敗)を注入し、タイムアウト、リトライ、サーキットブレーカー、フェイルオーバーが実際に働くことの検証に使います。
机上演習とゲームデーから始め、影響範囲を意図して封じ込め、本番と自動化に向かう権利を勝ち取ります。
発見が一つのレジリエンスの積み残しに複合するよう、実験を災害復旧のテスト(9.5章)とインシデントの学び(9.3章)につなげます。
発見を責めずに扱って直します。教訓が対処されない実験は、実験がないよりも悪いです。

参考文献とさらなる読み物

Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
Principles of Chaos Engineering, principlesofchaos.org