今の会社の同僚、というかチームメイトが訳を手掛けた「カオスエンジニアリング」、これを頂戴してから実に4ヶ月弱、先日ようやく読み終わりました...。。遅読にも程がある。
こちら来ました、ご恵贈いただきました！！ありがとうございます、ちょっとスピードは遅めかもなんですが読みます！！！ pic.twitter.com/GBxvw9gVjV
— a-know | Daisuke Inoue (@a_know) June 10, 2022
この本を読むまでは、「カオスエンジニアリング」という言葉だけは知っていて、......と思っていたけど、実際に読んでみて、「自分は何も知らなかったんや...」ということに気が付きました。本当によかった。
カオスエンジニアリング、僕が盛大に勘違いしていたこととして「”カオス” をいかにもたらすかというエンジニアリング」かと思ってたのだけど、そうじゃ（それだけじゃ）なくて、「複雑なシステムが内在するカオスを表出させるため」のもの、ってことなんだよなー。
— a-know | Daisuke Inoue (@a_know) June 29, 2022
上記のツイートのほかにも、この本を読んでいると、「カオスエンジニアリング」に対するいろんな表現が思い浮かんだ。
- 「可用性に影響する問題のつらさ」を、エンジニア一人ひとりの目の前に突きつけてくれる技術
- 「いつ起こるかわからないが、いつ起こってもおかしくはない」事象をコントローラブルにするために不可欠なもの
- 一定以上複雑なものを複雑なもののままにしておきながら、起きる事象に対して適切に対処するための技術？
- 「システムやサービスが価値を届け続けることに寄り添う技術」ともいえるかも...。
もちろん、この本の中にも、「カオスエンジニアリング」についてのいろんな角度からの記述がある。
カオスエンジニアリングは、システムに内在するカオスを表面化させる行為（P.7）カオス実験は脆さを表面化させ、効率性への最適化を緩めるか、 可逆性の方へ最適化を進めるかして、脆い箇所が実際に壊れたときにシステムの残りの部分が状況に応じて対処できるようにするものです。 カオスエンジニアリングは投光照明のように、ソフトウェアエンジニアが可逆性を最適化できる箇所を見つけられるように照らし出します。(P.37-38)システム的な弱点を発見するために行う実験の円滑化（P.39）カオスエンジニアリングは、モノがどのように動くかではなく、動くかどうか自体に関心を寄せます。（P.41）カオスエンジニアリングと抗脆弱性の重要かつ決定的な違いは、カオスエンジニアリングは人間の運用者たちがより回復力を持つチームになれるよう、すでにシステムに内在しているカオスに関する教育を行うことです。（P.43）カオスエンジニアリングが複雑なシステムに内在するカオスを表出させるためにあり、カオスを引き起こすのが目的ではない（P.46）カオスエンジニアリングとは、システムから予想外の結果が得られることを前提に、回復力（レジリエンス）のあるカルチャーを作り上げる取り組み（P.134）カオスエンジニアリングは人々に対し、自分たちのシステムに関する示唆を与えるため、教育的な取り組みだと考えることができます（P.190）
実は、というか、僕らは普段から大なり小なり、「カオス」を想定してはいるんですよねきっと。けど、きっと、目の前にある実際の「カオス」はその想定を遥かに超えていることが多くて、でも、それを正確に行うことは「できない」。それもまた、カオスエンジニアリングの必要性の根拠の一つになっているんだと思う。
カオスエンジニアリングが組織に対してもたらす恩恵として解釈できる点の1つは、安全性に対する直感をエンジニアが備えていないとき、それを養う一助となることです。実験によってもたらされた経験的な証拠は、エンジニアの直感に訴えます。(P.34)
でもなんか、カオスエンジニアリングに頼ることは「複雑性に対する理解を諦める」ような感じもしてしまったりして。...こんなことを思えるのは、僕は「そこそこのカオス」にしか触れずに済んできたから、なのかもしれないｗ 「理解できるはず、という自惚れを捨てよ」ということだろう。（実際、本書の中にも 総じてシステムが複雑になればなるほど、その全体像の把握が不可能になっていくのを認めることの重要性 （P.282）とある。はい。）
「カオスエンジニアリング」について誤解していたことのもう一つに、「自分に最も遠いもののうちの一つだと思っていたこと」もあるなーと。でもむしろ、 カオスエンジニアリングは最も手がつけやすく、効果的な方法 (P.30) で、本質的には身近なものなのかもしれないな、と。これはちょっと拡大解釈かもだけど、例えば「敢えて自分を不安定な環境におく」みたいなのも、結構近いところはあるのでは？とか。
「おもしろっ」ってなったところがいくつかあって、例えば「カオスエンジニアリングは "実験" なのか "テスト" なのか」という観点についてこの一冊の本の中でも異なる見解が見られたりするところとか、「宝くじ要因」（とある従業員が宝くじによって巨万の富を得てしまい、退職してしまう、という「カオス」）までもが考慮されてたりするところとか。あとあと、第10章を書いている Andy の "システムオタク" っぷりと、そんな Andy が "人" で構成されるシステムであるところの "組織" へのカオスエンジニアリングの適用についてあるところとか！
読んでいて気になったところもいくつか。単に見落としてるだけかもなんだけど、「カオスのカバレッジ」というか、「カオス度合い」というか、「カオスが足りてなくて、カオスエンジニアリングしきれてなくて漏れたりしていないか？」みたいなところとか。そう考えると、「どれだけ満遍なく "カオス" を注入できたか？」という管理が必要そうだなー、"カオスのための秩序" みたいなのが必要になりそうだなーとか思って、ふふってなったりもした。
そのほか、文章としてはうまくまとめられそうにないんだけどグッときたポイントが多くてもったいなかった（？）ので、そちらを箇条書きで。
- P.124 の「8.1.3 CI/CD におけるカオス実験」はとても興味深かった。「信頼性のテスト」を目的としてCI/CD の一部にカオス実験を組み込んでいるとのこと。まさしくカオスエンジニアリングが「テスト」として扱われてるんだなぁ、と。
- P.126 の、カオスエンジニアリングを構成する3つの運用ステップはすべて手動でうまく行える必要があるものの、カオスエンジニアリングの真価はこれを大規模に繰り返し行えたときに発揮される、というのはなるほど。
- P.133
インシデントになる前に問題を見つけることに最適化しすぎると、システムに対するメンタルモデルを再構成するというカオスエンジニアリングの主要なゴールから得られるものが少なくなってしまいますこれあるよね。プログラムで動くシステムに限らず。 - P.149
下手に明示的にマップされたシステムほど信頼性の低いシステムはありません痛快だな - P.197 のあたり、カオスエンジニアリングが注入するものが "カオス" であるからこそ、ことさら "オープンネス" が必要とされる、というのもなるほどだなぁ
- P.225
本番環境で実験する、これを実現できるようになるために頑張る、それを標榜するだけでも、きっとずいぶん違うよな〜〜 - P.236
不思議なパラドックス信頼性が高いと信じたシステムの部分であるほど、誤動作の発生時には凄まじいリスクをもたらす力となり、逆に信用されていない部分が最も堅牢になってしまうのです。わかる〜〜〜〜〜（わかる） - P.281
カオスエンジニアリングを始めようと思えば始められる状況になりつつある中で大事なのが、何を目的としてカオスエンジニアリングを行うのかを考え直すことそうだなと思ったし、「どのようなことを目的として据えられるのか」を教えてくれるのがまさに本書だなと。
自分はここ数年、「カスタマーサクセス」という "人（顧客）" を相手にした仕事に従事してるのだけど、この本を読んでいて何度となく、自分の今の仕事との関連性を見出してしまったんですよね。例えば、13章を読みながら以下のようなツイートを思わずしてしまったりとか。
カオスエンジニアリングしかり、プロアクティブな取り組みというのは往々にして「そのビジネス的価値をどう示すか」が課題になるのかねぇ
— a-know | Daisuke Inoue (@a_know) September 20, 2022
高度に発達したシステムの異常は神の怒りと見分けがつかない......、、お客様は神様です......、、ムニャムニャ。
もとい、ここらへんについては、同僚（おなじくカスタマーサクセス関連職）がこの本を訳しながらどういうふうに感じていたのか、ぜひ議論してみたいところ。
てなかんじで（？）、「カオスエンジニアリング」について僕自身がそもそも大きな誤解をしていたことも相まって、きっと自分じゃなかなか選ばなかったであろう本なので、この本に出会わせてくれた同僚に心から感謝！です。きっとこれからも多くのいろいろな「カオス」と付き合っていくことになるだろうから、「どうしたらいいんやこのカオス！」ってなったときには、またこの本に立ち戻りたいなと思いました。
