O'Reillyの新しいレポート "Chaos Engineering Observability: Bringing Chaos Experiments into System Observability"では，筆者のRuss Miles氏が，可観測性とカオスエンジニアリングは"密接に関連している"と考える理由が論じられている。エンジニアがカオス試験を実施する場合には，試験の対象とする下位システムに関して多くの問いかけをする必要が生じるはずだ，と氏は主張する。このためには，実行中のシステムを監視し，理解できることが重要な前提条件となる。そこで，このレポートでは，試験の実施と合わせて，メトリクスの収集やログ，トレースに関する指針も簡潔に示されている。
ChaosIQ.ioのCEOであるMiles氏は，32ページからなるこのレポート執筆時にはHumioのチームで開発作業に従事していたため，同チームも執筆を支援している。取り上げられている話題は，試験の進行状況を通知する手段としてのカオスエンジニアリング信号，試験をコントロールするために関連するイベントに対処する方法，カオス試験の記録と効果的な集中型ログソリューションの必要性，"何が起きたか，どのような順序か，すべての事象の起因となったのは何か，といった重要な答をまとめる"ためのOpen Tracingデータの出力，といったものだ。
InfoQは，Humioのチームが同社のログ管理プラットフォームで実践する開発作業とカオスエンジニアリングとの関係をどのように見ているのかを理解するために，同社CEOのGeeta Schmidt氏に話を聞いた。
カオスエンジニアリングは、開発者やセキュリティチーム、運用管理者が、失敗や脅威の注入という形で意図的かつ慎重に試験を行うことによって、システムの理解を向上し、再調整し、前進することを可能にします。システムに対する理解度の向上は、顧客とユーザのよりよいエクスペリエンスや，ビジネス成果の向上にもつながります。
"Principles of Chaos"の"chaos in practice"セクションを改めて見ると，最初のステップとして，"通常の振る舞いを示すシステムの測定可能なアウトプットとして，’定常状態(steady state)'を定義することから始めよ"，と述べられている。ここからShumidt氏は，カオス試験を始めるにおいては，"システムの正常時を確認し，試験を実施することでその正常状態からどれほど逸脱するかを検出する"ために，システムを監視する能力を開発することが重要なのだ，と主張する。その上で氏が強調するのは，Humioの顧客と作業した時に，カスタマイズ可能で粒度が細かく，ほぼリアルタイムなメトリクスとログが，試験の影響をよりよく理解することにつながる，という知見を得たことだ。
関連するものとして，GremlinのプリンシパルSREであるTammy Butow氏は，昨年のQCon Londonでプレゼンテーションを行い，効果的なカオスエンジニアリングプラクティスの実践を行うための大きな前提条件として，極めて厳格なインシデント管理，モニタリング，ダウンタイムの影響を測定する能力，の3つを主張した。Netflixがスポンサとなり，Casey Rosenthal，Lorin Hochstein，Aaron Blohowiak，Nora Jones，Ali Basiri各氏によって執筆され，当初はO'Reillyから公開されたオジリナルの"Chaos Engineering"レポートでは，このトピックの広範なオーバービューを紹介するだけでなく，試験時に監視すべきメトリクスを識別することの重要性についても議論されている。
Michael Kehoe氏とAaron Rinehart氏もまた，障害注入試験を観測し，管理された試験結果から新たな洞察を得ることの必要性について，Nora Jones氏をゲストエディタとして迎えて先日公開されたInfoQ Chaos EngineeringEマガジンに寄せた"LinkedIn's Waterbear: Influencing resilient applications"と"Using Chaos Engineering to Secure Distributed Systems"という記事の中で，それぞれ論じている。Adaptive Capacity Labsの共同創設者であるJohn Allspaw氏は，"可観測性"という用語が当初の意味(実証的調査に裏付けらていること)から離れたものになっている点を指摘し，関連する人的要素の重要性を無視してはならない，と警告している。
InfoQは先日，そのMiles氏と席を共にして，カオスエンジニアリングと可観測性の話題に関して議論をした。
InfoQ: Russさん，こんにちは。今日は時間を頂いて，ありがとうございます。カオスエンジニアリングや可観測性に不慣れなチームは，まず何から始めるべきでしょうか？
Russ Miles: 最初に必要なのはカオスの原則(Principles of Chaos)でしょう。
次にChaos Toolkitを入手し，オンラインチュートリアルをいくつか試して，自分自身でカオス試験をいくつか作ってみることをお勧めします。すぐに自身のシステムの可観測性に疑問を持つようになるでしょう。そうなれば，"Distributed Systems Observability"や"Chaos Engineering"といった書籍が次のステップになります。
そして最後に、参加することによって無償で記録を比較したり，多くのアドバイスを受けることのできる，素晴らしいコミュニティもいくつかあります。Google Groupsのカオスに関するコミュニティや，SlackにはGremlinによるChaos Engineering Communityがあります。Chaos ToolkitやPlatformを使っているのであれば，私たちのチームやコミュニティのSlackもあります。
カオスエンジニアリングは，システムに信頼と信用を構築することを目指す，エキサイティングな旅です。カオスエンジニアリングを，より堅牢でレジリエントな，そして最終的には信頼性と安全性を備えたシステムの構築を支援する重要な思想であり規律である，と考えている私たち全員が，あなたがカオスエンジニアリングを導入し，継続していく手助けをする手段として，これらのコミュニティが存在するのです。
InfoQ: カオス試験を実施する前に，システムの可観測性が重要である理由は何でしょうか？
Miles: 今の質問の中で，キーワードは"前に"です。カオスエンジニアリングに着手するかどうかとは関係なく，システムが良好な可観測性を備えるのは非常に望ましいことですから，正確には前提条件ではないのですが，
カオスエンジニアリングと可観測性という２つのアプローチの組み合わせは，極めて良好に機能するのです。
カオスエンジニアリングを実施する前から，システムがある程度の可観測性を備えているケースもあります。カオスエンジニアリング試験で何らかの逸脱が明らかになり，システムの弱点を診断する必要が生じた場合には，これが非常に役に立ちます。一方で，カオスエンジニアリング試験を開始したことが"強制力"になって，それまでなかったシステムの可観測性改善の必要性がクローズアップされる場合もあります。
このような理由から，私たちの経験では，優れた可観測性はカオス試験の重要な前提条件ではないのです。カオスエンジニアリングを考える場合には特にシステムの可観測性の欠如が顕著に現れる，ということなのです。この2つの技術は，時間とともに相互に発展し，互いに強化し合うようになることでしょう。
興味深いのは，これはカオスエンジニアリングが，他の非機能的ないし運用中心のシステムを改善する，優れた"強制力"となる理由でもある，という点です。カオスエンジニアリングはこのように，忘れられがちな，あるいは後回しにされがちな懸念を眼前に突き付けることが少なくありません。運用システムに責任や関係を持たない人たちにまで，このような課題を強く意識させ，それによって対応する堅牢性や回復機能を設計し，システムに実装することを可能にするのです。
一言で言うならば，カオスエンジニアリングは，すべての人々をより運用状況に敏感なシステムオーナにするものであって，それゆえにシステムの可観測性は，大きなメリットを即時に得られる機能のひとつなのです。
InfoQ: カオスエンジニアリングを行う上で，何か特別な課題というものはあるのでしょうか？カオスエンジニアリング自体の理解と観測を可能にする上で，それはどの程度重要なのでしょう？
Miles: カオスエンジニアリングが組織内で失敗する理由はたくさんあります。思想に対する理解不足から，対立的な関係で他のチームを混乱に陥れようとするカオスエンジニアまで，さまざまです。カオスエンジニアリングを不適切に行えば，その規律が拒絶されることにもなりかねません。
ChaosIQチームでは，組織内のすべての人たちが，最終的にはカオスエンジニアリングを実践し始めると考えています。カオスエンジニアリングは選ばれた一部の人々のテクニックではありません。ミッションクリティカルなビジネス・システムを所有するすべての人にとって有用な考え方であり，規律なのです。これは当然，中小規模の組織においても，大規模なカオスエンジニアリングの課題があるという意味でもあります。そして，規模が大きくなるほど，カオスエンジニアリングアプローチの失敗する確率も高くなるのです。
カオスエンジニアリングが失敗する可能性のひとつは，カオスエンジニアリングがサプライズとして実施される時です。これはあらゆる規模の導入で見られます。これはつまり，試験を実施したことで誰かが驚いたとすれば，それはすべての人々にとって気まずいものであるため，そのような試験は二度と行いたくないという要求につながる場合が多い，ということなのです。
組織全体のゲームデーなどの一環として，カオス試験そのものでチームを驚かせてみるのも効果的です。人々やプラクティスやプロセスの弱点を探る目的で，不穏な事態にチームがどう対応するかを確かめるため，適用される条件の正確な内容を同僚に告げない場合もあります。このような条件はサプライズであるとも言えるでしょう。ただし，ゲームデー自体はサプライズではありません。これは重要なポイントです。
サプライズではないカオス試験の実施にも，これとは別の意義があります。カオス試験の実施によって影響を受ける可能性のある人はすべて，そのカオス試験がいつ，何に対して，さらに理想的には，何のために実施されるのか，知ることができるべきだからです。
Chaos Toolkitとプラットフォームの試験形式，プラグイン可能なカオスエンジニアリング可観測性ツールを組み合わせることで，このようなチーム間および組織レベルの可視化が可能になり，カオスがサプライズになる危険性と，その時点で起こり得る不適切な対応を回避することができます。
そのためには，多くの点において，チームの規模やカオスエンジニアリング能力に関係なく，カオス試験の実施をシステム全体の可観測性の枠に含めることが，このような落とし穴を避けるためには不可欠なのです。カオスエンジニアリング試験はシステムの一部でもあるので，運用中のシステムの他の側面と同じように，その活動について知ってもらい，目に見えるものにすることが，広く受け入れられるために重要なことです。
今回紹介したMiles氏の新しいレポート"Chaos Engineering Observability: Bringing Chaos Experiments into System Observability"は，HumioのWebサイトでダウンロード公開されている。参照には登録が必要だ。