Chaos Engineeringの8つの罠

動機

2019年4月から新卒入社してSREとして働いている私は、今期の目標の一つに「Chaos Engineeringの本質的理解とOSS貢献」があります。

今回はフィードで流れてきた「Chaos Engineering Traps」という記事が素晴らしく良かったので日本語訳して、価値提供を少しできたらいいなと思って書いてます。

対象記事はこちらです。

medium.com

筆者について

Nora Jones

twitter.com

https://www.linkedin.com/in/norajones1

Chaos Engineeringの前駆者であるNetflexやJet.comを経て、Slackへジョインし、Chaos Engineeringに関わる業務をしています。

Netflix時代にもChaos Engineeringにコミットをしています。

[https://qconsf.com/sf2017/system/files/presentation-slides/designing_services_for_resilience_testing-qcon_sf_2017.pdf]

対象記事

以下の記事を対象にしています。

記事の内容

2019年3月28日にNora JonesがChaos Communityにて」カオスエンジニアリングの罠」(Chaos Engineering Traps)という題目で発表したものを記事化したものです。

このコミュニティ自体はNora氏によると、Youtubeをはじめとする、媒体にはアップされてないみたいです。

Nora氏の動機

以前のJohan Bergströmの「障害調査の3つの罠」(“Three traps in accident investigation”)にインスパイアされて、今回の記事を作成したみたいです。

改めてChaos Engineeringとは

Chaos Engineeringの体系的な理解は、以前のChaosKubeの記事で説明してるので説明はしません。気になる方は以下の記事をご覧ください。

www.1915keke.com

Chaos Engineeringとは幾つもの業界から知見とアイデアを参照していて、例えば信頼性工学、学習科学、認知システム工学など多岐に渡ります。

ケーススタディ

本記事で軽く説明されているケーススタディを紹介します。

もっとも有名なカオス的な実験である最初の有人宇宙飛行計画であるアポロ1号を対象にしています。アポロ1号とは、アメリカの人類初の初めての月面着陸であるアポロ計画のミッションです。

ja.wikipedia.org

発射リハーサルは1967年2月21日に、アポロのクルーと一緒に命令とサービスモジュールのテストのため計画されていました。

コマンドモジュールから発火して、３人のクルーが犠牲となりました。出火の原因は、初期型アポロ司令船の設計および構造における広範囲な致命的な欠陥に起因するものであるとされました。

ドアのハッチが本来ならフライト中の安全を守るものなのだが、出火のときには開かなかった。ロケットは当初、完全に燃料を積んでいたわけではないので、テストは行われていなかったのである。

私達エンジニアは直接的には全員が人命を扱っているわけではありませんが、それでもビジネスには必ず直結していると思います。障害は、たくさんの理由で不利益になり得るので、だからこそChaos Engineeringが必要であり、それをもって、私達の障害に対する行動に対して自信を持つことができます。

NASAの実際の調査のドキュメントはこちらのリンクからご覧になれます。

Chaos Engineeringの8つの罠

ここから本題です。記事で紹介されている実際の8つの罠について見ていきましょう。

罠1. 脆弱性を見つけた数によってChaos Engineeringの成功を計測できる

Chaos Engineering自体の「費用対効果」として計測するには、見つけた脆弱性を一つの指標として使うことは、とてもありふれていて、自然な方法でしょう。

しかし Robert L Wears博士のThe Error of Counting Errorsの論文からわかるように、数を数えただけではChaos Engineeringが成功しているとは限らないのです。

この論文中の一つの格言に

Errorは怠惰の計測していて、リスクではない

とあります。組織として脆弱性の数をOKRとして定義しているなら、間違いになります。また、このようなご認識はChaos Engineeringの本当の効果を得られづらくなります。

How to Lie With Statistics

この本では、統計の解釈を誤ると、結論をミスリードしながらも、実際にはよいパフォーマンスをだしていると信じさせることを実証しています。

Chaos Engineeringとは脆弱性を見つけるツールのようなものではなくて、私達が見つける脆弱性を通して信頼性を求める旅へ出かける背中を押すようなものです。

ここでトップハイライトされている一文があるので紹介します。

信頼性とは、変更や障害へ対応し、重要な機能を維持するためのシステムの機能である

ここでシステムは「人」も含めての意味です。障害に対して、どのようなことをしたらいいのかを知ることはChaos Engineeringの一つです。

信頼性工学のファンデーションはこちらにあるので、興味がある人は参照するのが良いかもしれません。

www.resilience-engineering-association.org

罠2. サービスに関わるすべての人が実験や準備に参加する必要はない

例えば、時間節約のために、Chaos Engineeringのための準備でチームの2/11のエンジニアだけが会議に参加していたが、それが問題を引き起こした実例があるそうです。

実験下のシステムに対して、多様なメンタルモデルを議論することは大事でしょう。

罠3. Chaos Engineeringを実行するには規範的なルールがある

これは、誰もが否定するでしょう。規範的なルールはChaos Engineeringには存在しません。

罠4. Chaosエンジニアはルール制定者であるべきだ

Chaos Engineeringの結果を知って、ルールを制定することがゴールではありません。成功の一部は、関係を構築して、システムのトレードオフ、専門的な知識をどのように進歩させるか、作るかに対して理解することです。

脆弱性があるから修正を要求するのではなくて、なんでそのようなことになるのかという文脈をサービスオーナーに提供することが大事です。

修正のバックログを追加するのではなくて、サービスオーナーにトレードオフを理解してもらってどのように対処するかを自律的に判断してもらうのが賢いでしょう。

罠4.5: 脆弱性を修正するべきだ。そしてできるならば自動化するべきだ

著者がNetflixにいるときに「Monocule」という、Chaos 実験がされる可能性のあるサービスや依存関係に設定を提供するツールを開発していたそうです。

ゴールとはサービスオーナーにサービスの重要な情報を提供することで、RPCタイムアウトが低すぎるなど一見、すぐにはわからないような知見を提供していました。

しかし、以下のようなフィードバックがサービスオーナーからあったそうです。

間違っているということを知れたなら、なぜ「正しい状態」にしてくれるように自動的にPull requestを出してくれないのか

実際にはタイムアウトを代表するように、それらは人間の専門知識が必要であり、人間が判断する必要があります。つまり「何がいい」、「何がもっといい」というような概念は、自動化はしづらいく、UXに対しての自動化は多くの考慮が必要です。

また、重要なインサイトとして、結果的に自動で直してそれがエラーになった場合に、どのように修正をするべきか誰が知っているのでしょうか。

繰り返しにはなりますが、修正のバックログを追加するのではなくて、サービスオーナーにトレードオフを理解してもらってどのように対処するかを自律的に判断してもらうのが賢いでしょう。

罠5. サンドボックス環境から実験を発展させないと「真の」Chaos Engineeringではない

非Production環境でChaos実験をすることは、重要なだけでなくて、プロダクション環境で実験をする前や、実験をベストプラクティスに基づいて実験をするときに必要です。

著者は強く、サンドボックス環境で実験を練習してみてほしいとのことです。

また、自動化の観点で自動化によるプロセスを実行より、実験を自動化するプロセスのほうが学びがあるということです。

罠6. Chaos Engineeringの最も重要なパートは、実験を実行することである

実験を作成して、学んだことを共有することはChaos Engineeringを行った最も価値のある報酬になります。

黄金率としては「実験の前、実験中、実験の後はどれも平等に、かつそれぞれ固有の注目があるべき」とのことです。

障害は、誰かの「どのようにシステムが動いてほしい」といったような精神的なモデルを見直す機会です。

チームごとによっても違う可能性は高いです。つまり、chaos実験をデザインして、ファシリテートをするような人はサービス外部の人であることが望ましいです。

これを更に合わせてChaos Engineeringとは、複数のチームからいくつかの人が、システムに対して議論して、実験をデザイン、実行することが最も価値のあるリターンを生みます。

罠7. 安全は後から心配して、まずはカオスな状態を生むのが大事である

アポロ1号のハッチドアが内圧によって開かなかったのは、本来ハッチドアとは安全を守るものであることを考えれば皮肉です。

これらは一般的でなくて、「脆弱性防御」という名前がつけています。

重要なのは、脆弱性をテストするために防御をを理解することが重要です。

防御の脆弱性はとても見抜くのが難しいです。Chaos Engineeringとは、防御の脆弱性を見つけることに約立ちます。

カオス自体は簡単ですが、安全性は難しいです。

失敗させることは簡単ですが、それから「反応をする」ということは難しいのです。ここでいう反応とは、システム的なものだけではなくて、例えばダッシュボードの可視化性、ログのチェックなども含まれます。

罠8. chaos実験はシステムの理解がなくても実行をすることができる

これは暗闇の中で的に発砲している状態と何も変わりありません。トレース、障害パターンなどを知る必要があります。

罠8.5. 定常状態の定義は少しくらいゆるくても良い

Chaos Engineeringとは、定常状態を定義するところから始まります。

満たすべき要件が揺れているようでは、正しい実験はできません。

まとめ

Chaos Engineeringに対する有用な知見がシェアされていたので、すぐにこの記事に取り掛かりました。

SREとして価値を伝えていく、とどけていく理念の先には、Chaos Engineeringが通過点としてあると思います。そして、今回は非常に良い機会になりました。

最後までありがとうございました！