Enginnering事情がまとめられた本を読了したので内容の概要と感想を記載しておきます。Enginneringは下記の3Partで構成されています。「個々の要素は合理的な動作をしていても全体としては望ましくない動作をすることがある」(ブルウィップ効果)という問題点を持つ分散システム(Microservice)の回復性を検証するために、意図的に障害を作り出して注入する試験を実施する作業のことということかなと理解しました。Stateは変化しない、という仮説を検証するということになるのかなと。Stateというのが重要な概念のようでした。これは許容できる通常動作を定義したもので、例えば人間で言うところの体温のような指標ということです。マシンリソース等の指標ではなくビジネス指標であることが望ましい模様。指標として用いるかの基準としては「顧客を失うかどうか」という点で判断する必要があります。second)という指標を用いているようです。リアルタイム性が重要で、理由としてはスパンが広すぎると今日の状態が健全なのかどうかの判断が出来ないから、ということ。「ビジネスメトリクスを収集できない場合はより相関が強いと思われるシステムメトリクスを見る」という記載もあるので、ひとまずはSLOとして設定しているシステムメトリクスから始めてもいいのかも知れないと思いました。Learning機能のようなものが必要かも知れないです。最終Partでは下記のような具体的な実施の流れが記載されていました。指標となる値が悪化したときに即座に中断できる準備もしておく組織に通知するカオス実験の実施や実施の目的を連絡しておく回数を重ねるごとに通知する必要がなくなっていく実験を実行する結果を分析する期待通りの動作をしたか確認する実験の結果をすべての関連チームにフィードバックして、チームがあらゆる弱点を軽減できるようにする範囲を広げる自動化するツール等で自動で定期的に実行するように設定する「事前にテスト環境での試験も実施する」というところは重要な気がしました。当たり前ではあるけど、テスト環境の試験では不十分だから実施するのであって、テスト環境の試験でわかるものは事前に潰しておくべきだなと。あと、被害を最小限に食い止めるためにも自動化は必須だなと感じました。Stateを監視して、値が正常範囲を外れたらすぐ切り戻す、というのを自動化しておけば、そんなに怖くないのかも。Spinnakerとかちゃんと使えるようになりたいな......。まとめただ上辺だけ真似しても怪我して終わりそうだなという印象を受けました。(チェルノブイリ原発事故も冷却剤ポンプのための冗長電源を検証しているときに起きたというから恐ろしい...)ただ古典的なシステムテストでは対応しきれないほど複雑な分散システムを扱うようなケースは今後どんどん増えていくと思うので、必須になってくるのかなとも思いました。メモ参加したので酔った頭でメモ。tshohe1はてなブログをはじめよう!tshoheさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。