第5回 Chaos Engieering 読書会@リモートのログ

development javaeestudy chaosengineering

learning.oreilly.com

javaee-study.connpass.com

引き続き Discord によるオンライン開催。

合計 300 ページくらいのところを毎回 30 ページくらい進んでるので、全部で 10 回くらいになるのかなぁ。

次回は 9/12(土曜日)で、Part III Human Factors の 10 Humanistic Chaos から。

javaee-study.connpass.com

対象

  • 8 Capital Oneの採用とカオスエンジニアリングの進化
    • Capital Oneのケーススタディ
    • 実験の設計で気をつけること
    • ツーリング
    • Team Structure
    • Evangelism
    • Conclusion
  • Part III Human Factors（第三部 ヒューマンファクター）
  • 9 Creating Foresight
    • 9.1 Chaos Engineering and Resilience
    • 9.2 Steps of the Chaos Engineering Cycle
    • 9.3 Tool Support for Chaos Experiment Design
    • 9.4 Effectively Partnering Internally
    • 9.5 Conclusion

トピック

ディスカッション

8. Capital Oneの採用とカオスエンジニアリングの進化

銀行は、この証跡を収集し適切な当局に提出するために、必要なガバナンスプロセスとツールを導入している。そのプロセスには法的な意味合いがあり、カオスエンジニアリングのような試みやツールの影響を受けてはならない。

とても大変そう。

Capital Oneのケーススタディ

  • 実験をするのは非本番環境で、実験の結果を反映したものだけが本番環境に反映されている
  • 実験の価値はサポート問い合わせに伴う稼働など具体的な数値に換算している
  • アラートを受け取るということはフェールオーバーやオートスケールできていないことを意味しているため実験は失敗になる
  • SOX 法に準拠したデプロイメントパイプラインは、人間が介入せずにリリースすることが承認されている

  • Blind Resiliency Testing is 何

    • おそらく社内用語

  • 金融系の規制には本番環境とそれ以外の環境は物理的に分離しないといけない、とかそういうのを聞いたことがある

  • 医療システムだとどうなんだろう？
    • オンライン診療とかはできそう
    • 電子カルテ連携とかはダメそう(むしろ政治的にダメそう)
  • 電力系は規制が厳しいことで有名

  • イスラエルのスタートアップには軍隊経験者が多い（体感）

  • カオス実験ができるかどうかは、実験によりどんな影響があるかどうかにかかってるような気がする

実験の設計で気をつけること

  • リスクスコアって誰がどう決めるんだろう

  • なんか基準があるのかな

  • できるだけリスクを回避しようとする雰囲気

  • 学習よりも大事にしていることがあるのかな

ツーリング

カオスエンジニアリングのための適切なツールを選択することが重要であり、それはあなたの会社のビジネスと運用上の目的と一致している。ツールを導入した後は、そのツールを適切なチーム構成でサポートすることが、実践の採用と成功のために重要になる。

Team Structure

大企業ではどんなにチームの繋がりが良くても、今日のソフトウェア・エンジニアリング・スキルセットの革新的な性質のために同じ問題を複数のチームが同時に解決することになり、結果としてツールの拡散が起こりコストと管理上の問題を招いてしまう。

Evangelism

  • ボトムアップで議論が広まる様子が想像できないので見てみたい
  • 立ち上げの最小単位ってなんだろう
    • 1人 SRE が始める、ていうシナリオがありがち

Conclusion

結局のところ、ツールと実践はエンジニアが最善を尽くせるようにするためのものであり、その逆ではない。

信頼性を追求するための活動が、カオスエンジニアリングのプラクティスとうまく適合している様子だった。

Part III. Human Factors（第三部 ヒューマンファクター）

  • 9 Creating Foresight の紹介
  • 10 Humanistic Chaos の紹介
  • 11 People in the Loop の紹介
  • 12 Experiment Selection Problem (and a Solution) の紹介
  • 前のパートより抽象度が高くなりそう

9. Creating Foresight

カオスエンジニアリングには、信頼性をテストするためのプラットフォームを構築したり、Game Daysを実行したりする以外にも、重要なコンポーネントがあります。個々にとってシステムがどのように構造化されているかに関する懸念、アイデア、メンタルモデルを理解し、技術的・人間的な回復力について組織がどこに秀でているかを学ぶことは、コードによって自動化することはできないことである。

カオスエンジニアリングはただのツールという理解が先立ってしまうけど、人間を成長させる特性を自動化することはできないんだよと。

我々の業界で慢性的に投資が不足しているカオスエンジニアリングの段階は，前段階と後段階です。

カオス実験の準備と後始末に投資が少ない。人間にフォーカスすることが多いため、自動化できないからだ。

重要なことは、サイクルの各段階で、成功を最大化するためには、異なるスキルセットと異なるタイプの役割が必要であるということです。これらの要素を最も効果的にするために、これらのスキルセットと考え方（どちらもトレーニングと支援が可能）について学習します。

人間にフォーカスする部分は自動化できないけど、スキルとして学ぶことはできる。

  • メンタルモデル is 何
    • 人間が理解している（仮定している）システムの振る舞いや内部構造

9.1 Chaos Engineering and Resilience

カオスエンジニアリングは脆弱性を発見したり、表面化させたりすることではない。

勘違いしないでね。

予期しないシステムの結果が発生した場合のレジリエンスの文化を構築することです

障害により発生した影響を事実として受け止め、それを活かしていく考え方ということかな。

9.2 Steps of the Chaos Engineering Cycle

大規模な停止が発生したのは、これらの期待の不一致と、固有の仮定について議論する機会がなかったことが原因の一部でした。サービス・ディスカバリー・インフラストラクチャがどのように機能しているかについて、二人が個別に持っていた文脈を考慮すると、両者の仮定は完全に妥当なものでした。ジョシーとマテオはサポートについて明確にこのような会話をしたことはありませんでした。当たり前のことを誰が議論するでしょうか？実際のところ、事件が発生するまではできないのです。

ポテンヒットになってしまいますよと。

実際には、インシデントが起きた時よりも、このような違いについて話し合う方が、よりオープンになることに気づくでしょう。インシデントが発生していないため、結果として、誇張されない心理的な安全の要素があるからです。安全な設定でこれを実験したことを知っていれば、システムの動作に対する恥や不安感が取り除かれます。そして、この感情的な基盤によって、誰が何をして誰がトラブルに巻き込まれるかということに気を取られることなく、私たちは学ぶことに集中することができるのです。

問題が起きてから対応を考えるとどうしても責任の押し付け合いや感情的な摩擦が生じてしまう。 シミュレーションならそうはならずに、理性的な議論ができるだろう。

  • メンタルモデル is 何
    • 人間が理解している（仮定している）システムの振る舞いや内部構造
  • 人によってシステムの捉え方が違うけどどちらが正解でどちらが不正解というものではないので、お互いのメンタルモデルを理解しておくと役に立つよ、みたいな話

9.3 Tool Support for Chaos Experiment Design

  • "API - baseline" と "API - canary" を分けてるのはなんでだろう
    • 実験結果の有意性を判断するには通常のトラフィックの 2% あればよいと判断した
    • フォールトを注入する実験群と、注入しない対照群を用意する必要がある
    • 前者が "API - canary" 後者が "API - baseline"
  • ChAP を開発することはできたけどそれが本当によかったことなのか、という考察
  • 業務を理解している担当者に実験してもらうのは難しいので、理解が浅くても意味のある実験をできそうなアルゴリズムを考案するほうがいいのかな、みたいな前向きな話
  • ツールを作るだけでなく対話が必要でした、という話じゃないかと

9.4 Effectively Partnering Internally

全ての関係者のメンタルモデルのギャップこそが、真の問題がどこにあるかを明らかにするので、訓練された面接担当者は、全関係者のそれぞれのストーリーを収集することが重要だとよく理解しています。カオス実験を知らせるためにも、認知面接が使えます。

問題の出所を検討するには、メンタルモデルの違いを明らかにするのが良い。それを効果的に行えるのが認知面接という手法。

  • プラクティカルな例がまとまっててよい

  • カオスエンジニアリングの Game Day の様子が見たいなぁ

  • カオス実験をする前に仮説として具体的な状況を想像できるようでないといけない感じする

  • 仮説を立てるのが大事なのであって、分からないこと自体は仕方ない、という理解でいいのかなぁ

    • メンタルモデルの違いを発見できるとかそういう効能があるよね、みたいな

  • ブラストラディウス・爆風半径 is 何

    • 障害の影響範囲のこと

  • ストレージサイズ的な意味でメトリクス貯めるのしんどくない ?

    • (無邪気に収集してるとメトリクス監視システムが破綻しそう)
    • 残したい期間に応じてストレージサービスを使い分ける感じ
    • サービスによってダッシュボードの作りやすさが違ってくる

9.5 Conclusion

これらの議論のポイントは、エキスパートのチームがシステムのコンポーネントに関する隠された専門知識を見つけて共有できるようにすることです

カオス実験の専門家ではなく、業務の専門家がカオス実験から学ぶことが大事。

チームは最終的に、効率化された実験計画とその結果としてのメンタルモデルの比較から、より多くを学びます。

プロセスやツールを自動化することで、人間の理解つまりメンタルモデルの相違を明らかにすることへ集中し、学んでいける。

  • ダッシュボードを作る単位は ?

    • 普通はサービス単位に用意しつつ、カオス実験用に複数のサービスを集約したダッシュボードを用意するとか

  • Mackrel のメトリクスチャートにはコメントつけて GitHub の Issue とかにリンクできてよさそうだった

    • 出典がわからず･･･

参考情報

いろいろ並べたけど全部は読めてない。