今年初め、第４回の"Chaos Community Day"が、ニューヨーク市のWork-Bench(訳註:ソフトウェア会社の名称)で開催された。当日の重要ポイントは次のようなものだ — カオスエンジニアリングのトピックは他の分野に大きく依存しており、ソフトウェアエンジニアはここから多くのことを学ぶことができる。システム内のレジリエンスの確立には、メンタルモデルの理解と交換が不可欠だ。可観測性(observability)は、カオス試験を行う上での前提条件である。"ゲームデー"は、非緊急のシナリオ下でエンジニアが障害処理を実践できる、価値のあるアプローチだ。
Chaos Community Dayの主催者でVericaのCEOである、Netflixカオスチームの元エンジニアリングマネージャのCasey Rosenthal氏による歓迎の挨拶に続いて、当日最初の講演者であるNora Jones氏が、"Chaos Engineering Traps"について話した。Slackでカオスエンジニアリングとヒューマンファクタの責任者を務めるJones氏の講演は、カオスエンジニアリングのコンセプトとアイデアは、レジリエンスエンジニアリングや、航空などの業界、外科医学、法執行など、さまざまなソースから導き出されたものだ、という話題から始まった。この点について、ソフトウェアエンジニアは十分に議論しておらず、結果として学際的な学習の機会を逃している、と氏は主張する。
QCon LondonでJohn Allspaw氏が発表した考え方を反映して、氏は、構築するシステムに関するメンタルモデルを交換することが非常に重要である、と述べた。カオスエンジニアリングは全社的な取り組みでもあるので、安全性を事前に考慮し、コミュニケーションを取る必要がある。
カオスエンジニアリングのフェーズはすべてが重要であり、同等の配慮が必要です。例えば開始フェーズでは、メンタルモデルの交換が可能であり、相互のモデル間にあるギャップの特定を始めることができます。
Jones氏は、発見した脆弱性の数でカオスエンジニアリングの成功を評価したり、発見した問題はすべて解決しなければならないと考たりするような、誤った考えをもたらす一連のトラップを紹介した上で、"ゲームデーやサンドボックス環境での試験を超越しなければ、真のカオスエンジニアリングではない"点を指摘した。講演の最後に説明した、"カオスエンジニアリングを行う上で、規範となる公式は存在しない"という３番目のトラップは、氏が最も重要だと考えるものだ。興味のある読者は、Jones氏の主催するInfoQ Chaos Engineering emagで詳細を学ぶとよいだろう。
続いて講演した、AuxonのCEOであるNathan Aschbacher氏は、これまで十分に理解されていた機械システム -- 航空機のような -- に、それをコントロールするソフトウェア層が追加されたことによって、結果的に複雑なシステムが構成され、故障モードの理解が非常に難しくなっている点を警告した。氏は、"カオスエンジニアリングは未知の未知(unknown unknowns)を表面化させるものだ"と主張する一方で、システムを理解するためには、その第一原理から始めるべきだと警告し、"既知の既知(known knowns)から理解を始めることのメリット"は自明だ、と述べている。
続いて登壇した、honeycombの共同創立者兼CTOのCharity Majors氏の講演は、カオスエンジニアリングが"実際には、製品テストに関する新たなマーケティング用語に過ぎない"、という話題から始まった。分散システムの時代において、我々にとってのソフトウェア開発ライフサイクルとは"アップグレードのためのもの"に他ならない、と主張するMajors氏は、カオスエンジニアリングは非常に有益ではあるが、実稼働前のテストにも時間を割くべきだ、と論じた。その上で氏は、１日を通じて議論されたコア思想を繰り返し、チーム内でメンタルモデルを共有することは、ソフトウェア開発の成功に不可欠である、と指摘した。
国内電力網のような、分散システムについて検討する必要があります。そのようなシステムは、モジュール化されていなくてはなりません。システム全体の正確なモデルを頭の中に保持する方法は、他にはないのです。
カオスエンジニアリングにはいくつかの前提条件がある、と言うMajors氏は、基本レベルでのシステムの理解、観察する能力などを、その例としてあげた。"観測性がなければ、カオスエンジニアリングはあり得ません。ただ混乱するだけです。"Tammy Butow氏は以前、QCon Londonで、同じようにカオスエンジニアリングの前提条件について論じている。
午後の講演では、Capital Oneでソフトウェアエンジニアリングのシニアマネージャを務めるDeepak Srinivasan氏が、カオスエンジニアリングを探求し、よりレジリエントなシステムの構築を求めた、氏らのチームの道程について紹介した。氏はその道程における、3つの重要なステージについて検討した。まず最初に、組織と関連するシステムの現在の位置を理解する("オペレーティングポイント"）。問題解決の平均時間を短縮するための設計を行う(下図を参照)。失敗に関するコミュニケーションを改善し、トランスペアレンシとアカウンタビリティを向上し、仮定にチャレンジすることにより、ヒューマンオペレーションを改善する。
続いて、GoogleのPadma Gopalan氏が、Google内のチームが復旧トレーニング(DiRT)において障害を発生させる方法についての洞察を提供した。氏の講演は、DiRTの概念とカオスエンジニアリングが多くの類似点を共有しており、同じアイデアから同じ時期に出現したものであることの説明から始まった。GoogleのエンジニアがDiRTセッションを実施する理由は、緊急事態に遭遇する前に、管理されたシナリオ下で障害の軽減および対応プロセスをテスト可能であるからだ、とGopalan氏は述べた上で、次のようないくつかのDiRTシナリオを公開した。
Gopalan氏はさらに、Google社内で使用されているDiRTの自動化ツールである"Catzilla"についても説明した(下図を参照)。
さらに氏は、実稼働環境でのテストを実施する前に、テストの明確な目標を設定し、障害注入シナリオの信頼性を徐々に高める必要がある、と述べた。"1パーセントの障害から始めて、5パーセントへ ... あるいは開発環境から始めて、ステージング、そしてプロダクションへ"。サービスレベル目標(SLO)をサポートするためには、カスタマエクスペリエンスを重視し、顧客が直面する問題を検出して低減し、ロールバックが迅速に機能することを保証する必要がある。
当日の多くの講演者に賛同する形で、Gopalan氏は、カオスエンジニアリングは組織全体の活動に他ならないものであり、実験の計画と時間、緩和戦略に関する十分なコミュニケーションが不可欠だ、と訴えた。