カオスエンジニアリング ―回復力のあるシステムの実践

11章ループの中の人々

John Allspaw

ソフトウェアシステムに対する実験が、その振る舞いをより深く理解する上で有益であるという考え方は、設計段階であらかじめシステムの振る舞いを規定しきるのは不可能だと暗に認めることでもあります。現代の多くのソフトウェアエンジニアは、このことを理解しています。

ソフトウェアを書くことと、それがどのように機能する（あるいは機能しなくなる）かを理解することは、まったく異なるものです。

システムの振る舞いに関する理解を深めて維持することは、それらに対する「メンタルモデル」†1を見直し、再調整する人々の能力にかかっています。本番環境のシステムにおける実験のプロセスは、インシデント後の分析と並行した再調整、つまり「メンタルモデルの更新」を行うための意義ある機会だと捉えられます。

本書の大半は、カオスエンジニアリングの「how」の部分に対するアプローチやニュアンス、詳細、そして視点について書かれています。本書の存在そのものや、現在のソフトウェアエンジニアリングと運用に関する対話におけるカオスエンジニアリングの話題は刺激的で、今後も発展が期待されます。カオスエンジニアリングによって、より洗練され、成熟した方法で自信をつけることが可能だという考え方がもたらされたのです。

ソフトウェアの世界で期待されるように、カオスエンジニアリングの文脈でいっそうの自動化を進める方法については、次々と新しいアイディアや議論が生まれています。「自動化」の構築が本質的にソフトウェアエンジニアの存在理由だと考えれば、この傾向は理解できるものです。しかしこの流れの中では、自動化された動作の不確かさに対する自信をつけるために存在するプロセスに対し、さらなる自動化を導入することになる皮肉に気づかないことがあります。 ...