実環境の分散システムが、適応的に異常を学習していくために、Chao Engineeringにおける意図的に異常を発生させる「実験」プロセスの結果を異常の教師データあるいは報酬としてみなし、教師あり機械学習または強化学習のアプローチをとる。または、制御工学における制御モデルのパラメータを推定するシステム同定のプロセスに「実験」の結果を利用する。 [Chaos EngineeringとSRE](https://www.notion.so/Chaos-Engineering-SRE-0bfc9918d9f94305bfc15aec76cff31d) により、SREが導入されていれば、Chaos Engineeringは実践しやすい状況になるため、本番環境で実験するというのは荒唐無稽な話ではなくなっている。 --- IPSJ-ONE 2017での分散システムを自然のように人間にとっては理解できないものとしてみなし、実験によって、システムの特徴をあぶり出し、自律的に学習していくというコンセプトが元になっている。 [高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017 - ゆううきブログ](https://blog.yuuk.io/entry/ipsjone2017) 「観測と実験」というキーワードのもとに「Experimentable Infrastructure」という名前付けをした。 [https://speakerdeck.com/yuukit/the-concept-of-hatena-system](https://speakerdeck.com/yuukit/the-concept-of-hatena-system) [ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会 - ゆううきブログ](https://blog.yuuk.io/entry/2017/the-concept-of-autonomous-web-system) > 分散システムの自動実験の概念としてNetflixが提唱するChaos Engineering[cha17]があります。 Chaos Engineeringは、本番環境にて故意に異常を起こす逆転の発想です。 例えば、サーバダウンなどわざと異常を起こすことで、システムが異常に耐えられるのかをテストし続けます。 Chaos Engineering自体は、先に述べたように制御モデルのパラメータ推定についての言及はありませんが、ビジョンの構想に大きく影響を受けました。*17 しかし、一般に言われていることは、本番環境で異常を起こしたり、限界まで負荷をかけるのは不安であるということです。 実際、書籍「Chaos Engineering」[cas17]では、監視の環境整備、異常時の挙動の仮説構築、実験環境での手動テスト、ロールバックなどの基盤を整えた上で十分自信をもった状態で望むようにと書かれています。 したがって、実験そのものは自動化されていても、まだまだそれに至るまでに人間による判断を多く必要とするようです。 ここで、クラウドやコンテナ技術など限りなく本番に近い環境をオンデマンドに構築する技術が発達してきていることを思い出します。 自分の考えでは、実験環境を高速に作成することで安全に実験を自動化する技術を突き詰め、効率的にデータを取得し、パラメータを決定するというアプローチを考えています。*18