『Chaos Engineering』読書メモ

Going Big

p.xxi 当時の構成：動画再生のコントロールプレーンはAWS上にデプロイ、ストリーミング部分はプライベートネットワーク
p.xxi リージョン障害をシミュレーションする：Chaos Kong
p.xxii リージョンのフェイルオーバには最速でも50分かかり、手動操作も必要だった：新しいプロジェクトができ、6分で切り替えられるように^[1]。

Formalizing the Discipline

p.xxii 2015年前半Netflixにカオスエンジニアリングチームができる
p.xxiii カオスエンジニアリングの定義：カオスエンジニアリングは分散システム上の実験のトレーニングであり、本番の荒れた状況に耐えるシステムに自信を得るためのもの
p.xxiii 自信が不要な場合はカオスエンジニアリングをやる必要はない
p.xxiii カオスエンジニアリングはカオスを作り出すのではなく、システムに内在するカオスを可視化する
p.xxiii 5つの高度な原則

• 安定状態をもとに仮説を構築する
• 現実世界のイベントに変化を与える
• 本番環境で実験する
• 実験を自動化し継続的に実施する
• 影響範囲を最小化する

Community Is Born

p.xxiii Netflixはシニアエンジニアしか採用しないが、カオスエンジニアリングは発明されたばかりなのでジュニアエンジニアすら社外にいない
p.xxiii Casey Rosenthalはコミュニティを作りエバンジェリスト活動を行なった：Chaos Community Day

• 2015年：サンフランシスコ、40名(Netflix, Google, Amazon, MS, Facebook, NewRelic, PagerDuty, etc)
• 2016年：シアトル、60名(GitHub, O'Reilly, SendGrid, Uber, Visa, etc)
• 2017年：サンフランシスコ、150名
• 2017年のAWS re:Invent：参加者4万名、ストリーミング参加者2万名

Example 3: Holiday Code Freeze

p.11 水平、垂直にスケーリングし、50%オーバープロビジョニングされたサービスがあった
p.11 ブラックフライデーから元日までがNetflixのサービスのピーク：通常のデプロイによるバグ混入を避けるべくコードフリーズ期間とされた
p.11 デプロイが行われなくなった結果、2週間でインスタンスが次々と再起動：数時間かけて全インスタンスが再起動した結果、処理できないリクエストが多数
p.12 外部ライブラリによるメモリリークが原因：垂直スケールされた結果メモリが枯渇するまで2週間かかった。コードフリーズ前は頻繁にデプロイされ再起動していたので発覚せず
p.12 やはり、誰が悪いわけでもないし、予測もできなかった

Confronting Complexity

p.13 複雑さには2種類ある：偶発的複雑さと本質的複雑さ

偶発的複雑さ

p.13 利用できるリソースは限られ、優先順位づけが難しい：無限の時間はないので、妥協が生まれる
p.14 偶発的複雑さを減らす持続的な方法は知られていない：新しいソフトウェアを作り偶発的複雑さを削減しようとするが、新しい形で偶発的複雑さを生むだけ
p.14 組織は機能追加のためにコードを書く：しかしコードを書くことによって偶発的複雑さが増加していく

本質的複雑さ

p.14 追加された機能がものごとをさらに複雑にする
p.16 新しい機能や可用性、安全性をソフトウェアに追加するということは複雑さを追加するということに他ならない
p.16 ソフトウェアを発展させるには複雑さは避けられない

複雑さを受け入れる

p.16 まず、複雑さを避けるのではなく受け入れよう：ソフトウェアは改善しており、複雑さの増加は悪いことではない
p.16 複雑さに対処する方法を学ぼう：第2章のツールやプラクティスが参考になる

ソフトウェアの場合

p.22 ひとは一般的に機能をたくさん欲しがる：ソフトウェアの状態を簡素化することはできない
p.22 多くのソフトウェア企業がリモートな組織構造を採用し、人間の関係性に対する統制を緩めている
p.22 有意義に環境を変えられるようなソフトウェア企業はほとんどない
p.22 可逆性：これこそがソフトウェアが輝く場所だ
p.23 プロセスベースで可逆性を改善する方法：XP、アジャイル
p.23 設計の面での可逆性の改善：VCS、ブルーグリーンデプロイ、カナリアリリース、フィーチャーフラグ、CI/CD
p.23 カオスエンジニアリングの実験によって、可逆性にとって逆効果となるシステムの特性が明らかになる
p.23 カオスエンジニアリングはエンジニアが可逆性のために最適化するポイントを指し示す

全体的な視点

p.23 他のプラクティスとカオスエンジニアリングが異なる点：その全体性にある
p.23 システム全体の安全性、回復性を高めることにつながる
p.23 複雑さとうまくやっていくためのプラクティス：複雑さと戦うプラクティスではない

本番環境で実験を行う

p.32 ステージング環境で実験をしても、ステージング環境に対する自信が高まるだけ：最も進んだカオスエンジニアリングは本番環境で行う
p.32 重要なのは、カオスエンジニアリングは複雑なシステムに内在するカオスを明らかにするのであって、カオスを引き起こすわけではない
p.32 望ましくない結果を引き起こすことがわかっている実験はやる必要がない
p.32 ステージング環境からはじめて、徐々に本番環境へ移していくのがよい

継続的に実験するために自動化する

p.32 より多くの実験を行うためには自動化によるスケールが不可欠
p.32 継続的に我々の想定が正しいことを検証しつづけることが重要
p.33 自動化のメリットデメリットについてはChapter 11、12を参照

影響範囲を最小化する

p.33 仮説が正しくなかった場合でも本番環境における顧客への影響を最小化する形で実験すべき

ユーザー体験にフォーカスする
p.34 カオスエンジニアリングのビジネス価値は本番環境の問題点を見つけ出すこと
p.34 ユーザー体験に影響するような変数に着目すべきである
p.34 APIのコントラクト違反などは開発プロセスで見つけるべき問題：既知の特性はテストによって対処すべき

The Future of "The Principles"

p.35 初期に金融業界などではカオスエンジニアリングは上手くいかないと反発
p.35 とはいえ障害ゼロではない：カオスエンジニアリングで先手を打ち、リスクを理解し、大惨事を予防できる
p.35 医療業界からも反発：しかし西洋の医療システムは臨床試験というカオスエンジニアリングに基づくもの
p.35 戦略的にカオスエンジニアリングを実施し、他の分野での教訓を我々の業界に生かす

Diasterpiece Theater

Goals

p.42 開発環境が本番環境とどれだけ一致しているかという点に細心の注意を払う：開発環境でシステム障害を実践できることが重要
p.42 調査対象：可用性、正確性、可制御性、可観測性、セキュリティ
p.43 組織の成長とシステムの成長が個々人のシステムの理解度を下げる：定期的な検証が重要
p.43 開発環境と本番環境の等価性を高め、信頼性の改善を促進し、システムの障害耐性を実演するもの

Anti-Goals

p.43 エラーバジェットは守る：重大かつ長期間の顧客影響を受け入れるものではない
p.43 データは失わない：データの喪失が発生しないように計画し準備する
p.43 計画する：探索的に行うものではない

The Process

p.44 Diasterpiece Theaterの演習は思いつき、心配事から始まる

準備

1. 障害を起こすサーバーあるいはサービスを決め、障害のシミュレーション方法を決める
2. 開発環境と本番環境を比較する
3. 障害を検知するであろうアラート、ダッシュボード、ログ、メトリクスを特定する
4. 冗長性や自動復旧、障害対応手順を確認する
5. オンコール担当など関係者をイベントに招待する

p.44 準備には1時間ほどあれば十分
p.44 プロセスを停止したり、インスタンスを停止したり、iptablesでネットワーク障害をシミュレートしたり
p.45 仮説を裏付けるためのログやメトリクスが不可欠

演習

p.46 議事担当を指名しよう
p.46 予定外のことが起きたら中止しよう：また別の日にやればよい

1. 全員に確認したうえで、可能ならWeb会議を録画しておく

2. 計画をレビューし、必要なら修正する

3. チャットで開発環境での演習開始を宣言する

4. 開発環境で障害を発生させる

5. アラートを受け取り、ダッシュボート・ログ・メトリクスを調査する

6. 自動復旧の実行を確認する

7. 必要なら障害対応手順に従う

8. 本番環境でも実行するかどうかを決める

9. チャットで本番環境での演習開始を宣言する

10. 本番環境で障害を発生させる

11. アラートを受け取り、ダッシュボート・ログ・メトリクスを調査する

12. 自動復旧の実行を確認する

13. 必要なら障害対応手順に従う

14. チャットで完了を報告する

15. 感想戦をする

16. 録画していた場合は公開する

p.47 開発環境で自動復旧がうまくいかなかったら、本番環境ではやらないほうがよい
p.47 顧客にとってわかりやすい障害、長期間におよぶ障害の場合も、やめた方がよいだろう
p.47 本番で障害を発生させるときの感情を記録しておこう：リスクがどこにあるのか分かるかも

感想戦

• 障害を検知し復旧するまでどれくらいかかった？
• ユーザーが気が付いたか？どうやってそれを知ることができる？どうやったら気づかれない？
• コンピューターがやるべきなのに、人間がやったことは？
• 我々は何に気が付いていなかった？
• ダッシュボードやドキュメントの誤りはなかったか？
• より頻繁に訓練すべき内容は？
• これが予期せず発生したらオンコールのエンジニア はどうすべきか？

p.49 共有ドキュメントやSlackのチャンネルに答えを集める
p.50 みんなの理解を改善するチャンス

プロセスの進化

p.50 最初はインシデント対応の補足やインシデント対応の練習の場だった
p.50 人間の介入が必要な計画は立てないようにしていたが、実際には必要な場合もあった
p.50 感想戦や要約、推奨事項、録画などは教育目的で導入された
p.50 リモートの参加者がいる場合は、画面共有とビデオのバランスが難しい

マネジメントの協力

p.51 CTOやVPoEを引き入れるには語りが重要
p.51 この演習が学びを最大化し、顧客への影響を最小化あるいは排除するよう入念に計画されていることを強調しよう

結果

p.51 計画通り進み、自信が深まった演習もある：他方で、深刻な脆弱性が明らかになり、顧客に影響する前に修正できた問題もある

キャッシュ不整合

p.51 Memcachedのインスタンスの自動入れ替えの演習
p.52 計画段階で、入れ替えアルゴリズムの問題に気づき、開発環境で問題を確認できた
p.52 演習時には手動で問題に対応し、演習後に問題を修正し再度テストした

何度も繰り返す

p.52 AWS上でのネットワーク分離のテストを計画
p.52 初回は、オーバーレイネットワークが転送中のデータの暗号化をしていたためネットワークを分離できずに終わった
p.52 2回目は、うまくいったが本番環境では実行できなかった：Consulがネットワーク分離にうまく対応してしまったため
p.52 3回目はiptablesを用いてネットワークを分離：Consulがインスタンスを入れ替えることに成功し、APIがその間の負荷に耐えることができた

不可能な結果

p.52 Slackのインシデント対応中に設定変更をしようとしたが動作せず
p.53 設定変更結果をSlackにポストしようとしてタイムアウトになっていたため
p.53 タイムアウトやリトライポリシーを監査し、数多くの改善を重ねた

結論

p.53 Disasterpiece Theaterは、本番システムの耐障害性をテストするための明確なプロセスを与えてくれた

3. People Outage

p.63 重要な内部システムで障害が発生したが、シニア開発者が会議中で捕まらない場合
p.63 宝くじ係数、あるいはバス係数
p.63 技術的専門知識だけでなく、リーダーシップやビジネス面での決定権も単一障害点となる

4. Release and Rollback

p.64 本番環境のリリースに問題があり、オンコール担当にアラートが飛ぶ場合
p.64 本番環境を変更しないというアプローチにもリスクがある：最終的に失敗することが多い
p.64 ロールバックのための手順は十分にドキュメント化され訓練されるべき：アプリのリリースだけでなく、設定変更も同様

5. Incident management proceduers

p.64 重要な内部サービスのエラー率が100%になり、デバッグ、他チームとの連絡が必要な場合
p.65 明確なインシデント対応手順や役割を定めておくことで対応者のリソースを効果的に活用できる

6. Datacenter operations

p.65 データセンターで水害が発生した場合
p.65 データセンターの災害訓練は、1つのラックの電源をオフにするだけのシンプルなものから、施設全体を補助電源に切り替える複雑なものまである
p.65 データセンター内外の関係者が、非常時の手続きについて熟知し、どうコミュニケーションをとるか知っておくべし

7. Capacity Management

p.65 あるリージョンで計算資源の予期せぬ喪失が発生した場合
p.65 可用性と冗長性のバランスが難しい：ともすれば過剰に用意された資源は無駄になる
p.66 非常事態には別リージョンに切り替えられるか？

8. Business continuity plans

p.66 メインオフィスの所在地で自然災害が発生し、サテライトオフィスで影響調査、事業継続を行う場合
p.66 災害時でも経営層の決定は必要になる：承認フロー、緊急経費の承認、広報、法務etc
p.66 BCPを用意しておくだけではダメ：従業員が理解し、緊急時に実践できるか

9. Data Integrity

p.66 データが破損し、最新のバックアップからリストアが必要な場合
p.66 バックアップはリストアをテストしてはじめて意味がある
p.66 リストア後バックアップが正しく動いているとどのように確かめる？
p.66 バックアップのプロセスが停止したら、いつ気づける？
p.67 アプリケーションの堅牢性も重要：内部サービスでもfuzz testをすべき
p.67 データストアのレプリケーションの遅延もテストする

10. Networks

p.67 リージョン障害でネットワークの大部分が喪失した場合
p.67 ネットワーク障害は、個人のデスクトップレベルから、建物レベル、データセンターレベルまで様々なテストが必要

11. Monitoring and alerting

p.68 障害が発生してもアラートが飛ばない場合
p.68 定期的に監視とアラートのテストをする

12. Telecommunications and IT systems

p.68 会社のWeb会議システムが1日の大半使えない場合
p.68 代替手段が用意され、実際の利用の前にテストされているか？

13. Medical and security emergencies

p.68 入りづらい場所やセキュリティ制限のある場所で骨折した場合
p.68 地球上で絶対に安全な場所というのは存在しない：事前に対応をリハーサルしておくべし

14. Reboot everything

p.68 脆弱性対応のため全システムを再起動しなくてはならない場合
p.68 各サービスのコールド・リスタート方法を知っておくべき

How to Test

p.69 DiRTの専門家に頻繁に相談し、テストに付加価値を設けよう：既に分かっている障害を再測定するのは時間と労力の無駄
p.69 何をテストするのか明確にしよう：オンコール担当の対応？システム自体の自動復旧？サービス利用者の設定？
p.69 テスト対象となる仮説は一度に一つまで：ただし、障害を複数同時に発生させることもある
p.69 オンコール担当エンジニアにDiRTが行われていることを知らせておこう
p.70 テスト時には社内イベントを考慮しよう：長期休暇やスポーツイベントなどは避けるべき（その場合のテストがしたいのでなければ）

Gathering Results

p.71 SREのpostmortem同様、軽量な分析ドキュメントをDiRT後に作成する
p.71 テストへの参加除外を希望するサービス利用者については、参加できない理由を文書で説明させ、次回はその原因を取り除いて参加してもらうようにする

Scope of Tests at Google

p.71 Googleのシステムは巨大すぎて人間がすべて理解するのは困難：DiRTが助けになる
p.72 ときどきGoogleのチームは意図的にあるリージョンのSLOを限界まで下げて一定期間運用する
p.72 設計レビューではチェックしきれない依存関係の問題を明らかにするため（依存関係はサービスの発展に伴い増加していくので）
p.72 サービス利用者が単体でテストできるよう、クライアントライブラリにレイテンシ発生の仕組みを実装しておく

p.73 Googleの大規模なテストの例

• あるリージョンのログストレージサービスを一時的に無効化し利用者の設定を確かめる
• グローバルなロックサービスを時々ダウンさせる
• RPCサービスに対するファズテスト
• 建物全体のネットワーク分離テスト
• ソースコード管理システムへのシステム用アカウントのアクセスを数時間停止

p.73 災害テストを自動化：コマンドラインツールで実行できるように

p.74 Borgの事例：タスクの強制終了SLOに基づき、一部のタスクをわざとダウンさせる。利用者が自分でテストできるようにしている。

Conclusion

p.75 複雑さは時間と共に成長する：これを拒否するのではなく、受け入れる必要がある
p.75 定期的に、定式化された災害テストを注意深く行うことで、統制のとれたやりかたでシステムを試すことができる

【発生可能性】
p.83 定期的には発生しないので、優先度の下がるイベント：例、セキュリティ脆弱性
p.83 発生した場合には他のものより優先度を上げて対応する必要がある

Explore Dependencies

p.84 依存関係についても、同じようなイベントを考えてみよう
p.84 依存関係にあるサービスが相互的に依存しあっている場合、被害が複合的に拡大する可能性がある
p.84 そうした可能性は予測不可能であるが、カオスエンジニアリングによって明らかにすることができる

Degree of Variation

p.84 カオスエンジニアリングによって実際のシステムの動きや依存関係のつながりが明らかになる
p.84 近年のマイクロサービスアーキテクチャの隆盛により、システムの全体像は人間が理解するには複雑すぎるものとなった
p.85 レビューだけでは見つけられない未知のつながり、依存関係が、カオスエンジニアリングによって明らかとなる

Varying Failures

p.85 変化させる部位を1カ所に留めることで結果が理解しやすくなる：他方で、より広い範囲を変化させることで、複雑なシステムの動きを理解する助けとなる
p.85 アプリケーションレイヤーでネットワーク障害を模倣することはできる：しかし、実際に起きるのはネットワークケーブルが抜けて複数のコンポーネントに障害がおこり、混合的な障害となる
p.85 こうした混合的な障害はシステムにより大きな被害をもたらすが、実際のシステムの相互関係をはるかに理解させてくれる
p.85 さらに、複合的な障害ははるかに危険である：実験の影響範囲が上流・下流のシステムへの急速に拡大していくため。
p.86 障害復旧訓練は自動化が難しいが、重要である：ときにインシデント以上に復旧の失敗によってさらなる被害が発生することもある

Combining Variation and Prioritization

p.86 複合的な障害が発生した場合に何が起きるか？どのような障害に対応できるか？直近の脅威は何か？を考えて優先順位をつける

Expanding Variation to Dependencies

p.87 動いているシステム全体を対象にする：依存関係も全て含める
p.87 SLAの変化：通常のSLAを超えている場合、SLAをやや上回る場合、SLAぎりぎりの場合、SLAを下回る場合
p.87 それぞれの依存関係が上記の組み合わせで変動させてみる：システムの動作についてより学び、将来驚くことは少なくなるだろう

Deploying Experiments at Scale

p.87 発展的原則にあるとおり、小さく始めて影響範囲を最小化すべき
p.88 どのような実験をしようとしているのか理解することが重要：モニタリングとトレーシングの仕組みが不可欠
p.88 障害を起こしているシステムを理解する＋システム全体の状態を理解する：障害が予定の範囲を超えて複合的になっていないか？
p.88 カオスエンジニアリング自体がシステムであり、調査対象のシステムと同じ問題や障害を抱える可能性があることを忘れないこと

結論

p.89 短い期間で定期的に実験を繰り返すことで、上達できる：毎週起きるイベントから実験しよう
p.89 毎月起きるイベントは毎週実験を、毎週起きるイベントは毎日実験をしよう：失敗しても6日間の猶予がある
p.89 3ヶ月毎に自サービスにとっての大きな問題が何かを考え、復旧計画をたて、その問題に今日取り組もう：トラフィックのスパイク、DoS、かなり古いバージョンのクライアントを利用している顧客、などなど。

p.97 オープンソースのRest.li（LinkedIn製）

Failure Modes

p.97 SREが日常的に出会う障害に絞って障害をテスト
p.97 3種類の障害：エラー、遅延、タイムアウト
p.97 エラー：モックしてRestliResponseExceptionをスローする
p.98 遅延：任意の時間遅延させることが可能
p.98 タイムアウト：UX改善のためにチューニングが必要
p.98 LinkedOutにより本番障害を正確にシミュレーションできるようになった

Using LiX to Target Experiments

p.98 LiX：タイムアウトや遅延などの障害発生のターゲットを指定できるUI、緊急停止ボタンも備える
p.99 利用には注意が必要：設定ミスが本物の障害になりうる
p.100 障害発生対象ユーザーを拡大する設定変更時には、Waterbearチームとの協力が不可欠

Browser Extension for Rapid Experimentation

p.101 LiXはA/Bテストのようなものでサクッとテストするにはプロセスが重い
p.101 Rest.liの内部コンポーネントのInvocation Contextを利用して、ブラウザ拡張からクッキー経由で障害を発生させる対象マイクロサービスを指定できるように
p.103 対象ユーザーは自分自身だけ：影響範囲が最小化されている

Automated Experimentation

p.104 テスト対象URLが決まると、障害発生対象サービスが選択され、Seleniumワーカー群＋上記ブラウザ拡張で自動テスト実行
p.104 結果のレポートとスクリーンショットが提供される
p.104 日次、週次、月次で実行し、リグレッションに気付けるように
p.104 リリース時の自動実行もロードマップにはある

Conclusion

p.105 実験を停止するか、影響ユーザーを制限するような防御手段を適切に備えるべし
p.106 小さな範囲で検証できたら、大規模に検証を行うことも重要

Transition to Chaos Engineering

p.109 2018年ごろはChaos experimentsと呼ばれていた
p.109 オンコールの減少が一つのサクセスメトリクスになる：金銭的価値に変換しやすい
p.109 開発者にとっても、オンコールの減少っはこの実験を優先的に取り組む動機となった

Chaos Experiments in CI/CD

p.110 Capital Oneのコアシステムの基本的要求：回復力のある、スケーラブルで、可用性のあるシステム
p.110 自信を得るためにカオスエンジニアリングを採用
p.110 まずはありうる障害ポイントをデザインの深い分析から探る
p.110 CI/CDに組み込んでインフラを早期にテスト
p.110 パフォーマンステストの一部にも組み込む：ピーク時の負荷での堅牢性を確かめる
p.110 顧客が指針：顧客体験のためにシステムを良くするためにあらゆる決定を行う

Things to Watch Out for While Designing the Experiment

p.111 Chaos experimentsの設計は機能開発以上に時間もリソースも必要
p.111 初期に以下を理解しドキュメント化するべし

• 期待される動作についての明確なドキュメント
• 起こりうる障害
• 実行中のトランザクションへの影響
• インフラとアプリのモニタリング
• 検証しようとしている障害点のクリティカル度合い
• それぞれの実験のリスクスコア

p.111 実験中もイベントの監査ログをきちんと維持することが重要

Tooling

p.112 カオスエンジニアリングは繰り返し、スケールして実行してこそメリットがある
p.112 Capital Oneは独自のカオスエンジニアリングのツールを実装：サードパーティツールでは要求を満たさなかったため
p.113 実験データが社外ネットワークに出る心配がないのもメリット

Team Structure

p.113 小さなチームだけでこうしたツールを作ろうとするのが一般的だが問題も多い：工数不足、ドメイン知識不足
p.113 サイバーセキュリティ、コンプライアンス、監査、監視など関係者と安定した関係性を築くのが重要
p.114 アプリケーションチームからもエンジニアに参加してもらい、カオスエンジニアリングプラットフォームを使ってもらおう
p.114 アプリチームが加わることで、各アプリチームの要望が1カ所に集まるので、別のツールが乱立する心配もない

Evangelism

p.114 カオスエンジニアリングは草の根的なレベルでは興味を持たれている：大規模で継続的な活動にするには、明確な戦略、プロセスを簡略化するためのツール、エンジニアとビジネスとコンプライアンスの各チームでサクセスストーリーを共有するプラットフォームの3つが不可欠

Conclusion

p.115 信頼性の高いシステムを構築するには信頼性を検証するためのプラクティスが必要：それがカオスエンジニアリングの役割

Discuss Scope

p.127 実験対象を選んだら、スコープを議論して参加者全員のメンタルモデルをそろえよう
p.127 そのための質問

• システムの通常の動作/良い動作をどう定義する？
• 全員がその理由を理解しているか？どうしてそれがわかる？
• 過去の経験に由来する実験か？
• 何が起きるかわからないから実験するのか？
• この障害の期待結果は何か？個々のコンポーネント、システム全体ではどうか？
• 悪い状態であるとどうやって知るのか？最重要メトリクスは？どうやって監視する？
• 影響範囲を限定する方法は？
• この実験のビジネス上の価値は何か？

Hypothesize

p.128 自分たちの仮説を明確にしておこう

• 安定状態を明文化する
• 安定状態からどのように逸脱するはずか？
• ユーザー体験はどうなる？
• 依存関係のサービスへの影響は？

p.128 文書化したものを、全ステークホルダーと共有しておくべし
p.129 実験で問題が見つかったら、終わってから次のことを質問しよう

• 学んだことは何か？
• 学んだ情報をどのように活かす？
• 実験前や実験中にいなかった人物が、その人の専門知識を理由に後から呼ばれた？
• 期待と異なる結果になったのはどの部分？
• 次の実験で考えるべきことは？
• これらの学びを組織に広めるにはどうする？

Conclusion

p.130 ファシリテータが議論を導くための質問例を集めた：隠れた専門知識を発見し共有するための手助け
p.130 最大の価値は、システムに関するメンタルモデルを改良する手助けとなること

Engineering Adaptive Capacity

p.135 安全に対する2つの価値観

• 古い価値観：人間はプロセス、標準化などでコントロールすべき問題点。安全性はマイナスがないことで主に評価。
• 新しい価値観：人間を利用すべき解決策ととらえ、安全性をポジティブな能力の存在によって評価する。

Spotting Weak Signals

p.135 通常時と障害の間に注目すると、弱いシグナルが重要：システムにおける新しい活動だが、ほとんど気づくことができない
p.135 即座に問題となるわけではないが、閾値を超えると障害となる
p.136 弱いシグナルを理解するには、安定状態を理解する必要がある
p.136 例）エンジニアの疲労がたまっていたら、あまり効率的でなくなるし、重大なミスを犯すかもしれない
p.136 「〜さんに話す必要がある」というのはフラグ：システムが閾値を超えそうだというシグナル（〜さんが転職したらどうなる？）

Failure and Success, Two Sides of the Same Coin

p.136 かつての成功は突如として障害に陥ることがある
p.136 境界線をより明確にする必要がある

Putting the Principles into Practice

p.137 人間のシステムの中のカオスをどのように探したらよいだろうか？
p.137 カオスエンジニアリングのコア原則のうち3つに着目する

1. システムの安定状態に関する仮説を立てる
2. 変更する変数を定義する
3. 結果を観察する

Build a Hypothesis

p.137 人間のシステムは、コンピューターシステムと違い、入出力が不明瞭で、フィードバック間隔が短く、可視性も著しく異なる
p.137 従って、質的な分析がより重要となる
p.137 最初の仮説を探す際は、組織の境界、限度に着目しよう：SPOF、コミュニケーションのボトルネック、仕事がたまる場所はどこだろうか？

Vary Real-World Events

p.138 実際に変更を加えてみると、3つのパターンにであう

1. ハードリミットを超える場合：重要な仕事が即座にとりこぼされて放置される
2. キャパシティ限界ギリギリの場合：この変更を継続することはできない、状況が悪化したらもとに戻す必要がある
3. 変化が見られない場合：仮説が間違っていたか、観察すべきポイントを間違えているか、安定状態に関する重要な理解が欠けている可能性がある

Minimize the Blast Radius

p.138 障害が連鎖的に大きくなることは避けねばならない
p.139 筆者の会社の場合、スポーツイベントに関係しており、季節性が高い：オフシーズンに実験をするなどの配慮
p.139 実験参加者全員がロールバック手段を理解し、いつでも実行できるようにすべき

Case Study 1: Gaming Your Game Days

p.139 インシデントは事前に計画していない学習イベント
p.139 計画したイベントとしてのGame Days：安全に学べる
p.140 インシデント対応はチームスポーツ：十分な練習なしには上達しない
p.140 専門家/適切なメンバーが参加できないとどうなるか、という仮説
p.141 何度かチーム全員でゲーム（インシデント対応演習）をやり、SPOFとなる専門家なしでやる回を設ける
p.141 どういった知識を共有すればチームがよくなるかが見えてくる
p.141 チームのシステム的な弱さが明らかになる：この弱点は常に変わり続けるので対策に終わりがない

Communication: The network latency of any organization

p.142 チームや部署の境界を超えるコミュニケーションがうまくいかない
p.142 メールが見落とされたりして、相手が怒ってしまう
p.142 一対一のやりとりはこうした問題を起こしがちだが、定期的にコミュニケーションが取れていればかなり効率的なスタイルである：ではどうすればよいか？

Case Study 2: Connection the Dots

p.142 ネットワークを拡大する
p.142 ダンバー数：人間が安定的な社会関係を維持できるとされる人数の認知的な上限は150人くらい
p.143 Etsyのブートキャンプ：新入社員がチームに配属される前に他のチームで短期間仕事をすることで、コミュニケーショチャンネルを増やす
p.143 では定期的に別のチームで仕事をしてみてはどうだろうか？
p.143 Opsチームでローテーションプログラムを開始：プロダクトチームの開発者がOpsチームにきて１スプリント過ごす
p.143 プロダクトチームにも運用経験者を増やしていく
p.144 反対に、Opsチームからプロダクトチームにエンジニアを派遣する実験も
p.144 Opsチームで運用の改善が進むなど良い結果が得られた

Leadership is an Emergent Property of the System

p.145 リーダーシップ：境界づけられたコンテキストにおける意思決定

Case Study 3: Changing a Basic Assumption

p.146 アーキテクチャに関する問い（正しいデータベースを選んだだろうか？など）と同じように、あなたの組織の根本的な部分について問いをたてているか？
p.146 働きたいと思える場所をつくれば、ひとびとはもっと生産的で幸せになれる
p.147 カイゼンへの情熱やふりかえりによる学びが有効だが、銀の弾丸ではない
p.148 「何かやってみたい」と宣言するのが成功につながる

Safely Organizing the Chaos

p.148 組織の3つの状態：病的、官僚的、生産的
p.148 病的な組織では新奇性はつぶされ、官僚的組織では新奇性は問題をひきおこし、生産的な組織では新奇性が実施される

All You Need Is Altitude and a Direction

p.149 航空機産業における実験の余白は高度：地面にぶつかっていなければまだ時間がある、動いている場合にかぎるが。
p.149 エンジニアが忙しくなり余白が消えた結果、実験は終わりを迎えた

Close the Loops

p.149 カオスエンジニアリングの原則に言う「安定状態を理解する」ということは、フィードバックループが重要である
p.149 安定状態にどう動くかを知るためのフィードバックがある、ということ
p.149 人間のシステムでも同じ：関わった人にインタビューをして、状況の質的分析が必要
p.149 関わった人が価値を感じていれば、正しい方向に進めていることになる

If You're Not Failing, You're Not Learning

p.150 失敗するということがまさに学んでいるということ：調整して、動き続けよう

But what about automation and getting people "out of the loop"

p.155 カオスエンジニアリングのどの部分を自動化できるか？安定状態を定義する部分？仮説を立てる部分？変数を導入する部分？仮説を反証する部分？
p.155 これらを考える前に、人間と機械の機能配分について考えよう

Functional Allocation, or Humans-Are-Better-At/Machines-Are-Better-At (HABA/MABA)

p.155 どのような機能、タスク、仕事を人間に、機械にそれぞれ割り当てるべきだろうか？
p.156 1951年の研究（Fitts List）では、検知・知覚・判断などは人間、スピード・パワー・計算などは機械の仕事とされた

The Substitution Myth

p.157 近年の研究では、そのようにタスクを分割して割り当てられるという考え方は問題があるとされている
p.157 コンピュータの強みを活用することは、人間の弱点を置き換えることにはならない：しばしば予期せぬ形で、人間の新しい強みと弱みを生み出している
p.157 現実の複雑なシステムでは、タスクや活動は相互に結びつき依存しているから。
p.157 カオスエンジニアリングの自動化においても、こうした考えは当てはまるだろうか？次の章では実験の選択は自動化できると提唱されている
p.158 自動化そのものが新しいチャレンジを生み出す：無料でできるわけではない
p.158 運用担当者を排除しようとする自動化の設計担当は、自動化できないタスクを運用担当者に押し付けることになる

Conclusion

p.159 ソフトウェアは人間にとって重要なので、実験を通じて、ソフトウェアシステムに自信を持つことは意味がある
p.159 人間は責任をもつことができるが、ソフトウェアはそうではない：カオスエンジニアリングを通じて、複雑なシステムを設計し運用する責任を手助けすることができる

p.162 今のところ解法は2つ

Random Search

p.162 Chaos Monkeyのようにランダムに探索する

• 実装しやすい
• ドメイン知識が不要

p.163 分散システムではあまりうまくいかない：組み合わせが多すぎる

The Age of Experts

p.163 システムの専門家のドメイン知識を活用する
p.163 過去の実験の結果をもとに新しい仮説を立て、徐々に洗練していく
p.164 問題はその専門家をどのように採用し訓練するか

The role of the Expert

p.164 専門家のもう一つの役割：どの実験を行わないかを決定する
p.164 例）バグが起きる/起きないとわかっているなら実験する必要がない
p.165 専門家の重要な仕事：どういう順番で実験を行うかを決定すること
p.165 めったに発生しないイベントよりも発生可能性の高いイベントに関連する実験をすべき

The communicability of Human Intuition

p.166 自動化と人間の専門知識のバランスをどうとるか
p.166 そもそも人間固有の得意なこととは？：おそらく、ゼロからのex nihilo創造
p.166 残念ながら人間は直感を他人に説明するのが下手くそ
p.167 説明ができるなら、その論理をプログラムに変換して意思決定を自動化できる

Observability: The Opportunity

p.168 カオスエンジニアリングの実践には、障害を注入する仕組みだけでなく、観測のための仕組みにも投資が必要
p.168 分散トレーシング各種：Dapper、Zipkin、Salp、Jaeger
p.168 こうしたトレーシングは、何が問題だったのかを分析するために利用されたり、全体を可視化するために利用されるが、それは表面的な利用にすぎない
p.168 まずは安定状態がどのようなものか理解し、問題を定式化するのに利用する
p.169 正しい実験を選択するためには、システム全体の理解、とくに対応可能に設計された障害に対してどのように対応しているかを理解することが必要

Observability for Intuition Engineering

p.169 観測の仕組みは、フォレンジックだけでなく、専門家がシステム全体を理解しモデル化する上で重要
p.169 専門家の仕事は直感を育て活用すること

Lineage-driven fault injection

p.169 LDFI：Lineage-driven fault injection
p.169 実験の選択を自動化し、SRE専門家の役割を担う
p.169 LDFIのキー概念：冗長性と共通性
p.170 障害のおきそうな場所の情報をランクづけして実験の優先順位づけに活用する

Conclusion

p.171 直感の自動化が必要：カオスエンジニアリング実験の選択における専門家の役割をコンピュータに担わせるべき

Kirkpatrick Model

p.176 ROI評価のためのカークパトリックモデル: 4段階

• レベル1：Reaction
• レベル2：Learning
• レベル3：Transfer
• レベル4：Results

p.176 カオスエンジニアリングはある種の教育的行為

Level 1: Reaction

p.176 参加者の反応をアンケート、インタビュー、非公式の会話などで評価する
p.177 否定的な回答があれば、カオスエンジニアリングプログラムがうまくいっていない可能性がある

Level 2: Learning

p.177 参加者が何かを学んだということを示す
p.177 学んだこと、発見を書き記す

Level 3: Transfer

p.177 カオスエンジニアリングプログラムで学んだことを実践に移す：情報を行動に変換する
p.177 運用担当、エンジニア、マネージャー、その他のステークホルダーの行動は変わったか？

• 脆弱性を修正した？
• 運用戦略を変更した？
• より強固なシステムを構築した？
• より多くのリソースを割り当てたか？

Level 4: Results

p.178 特定の効果をビジネスの成果と結びつけるのは容易ではない

Alternative ROI Example

p.179 NetflixのChAPをカークパトリックモデルで分析するとレベル2
p.179 エンジニアの行動が変わっていればレベル3、否定された仮説から学んだ教訓がビジネス目標に貢献していればレベル4

Collateral ROI

p.179 カオスエンジニアリングから学んだ教訓は演習の主要目標からは独立している
p.180 演習に関連システムのステークホルダーが集まってくることで2つの副次的効果
p.180 起こりうるシナリオが観念化される：ある人にとっての当たり前の結果は別の人にとってそうではない
p.180 会ったことがないステークホルダーとの出会い：実際のインシデント対応時によりうまくチームが機能するようになる
p.180 人間は習慣の生き物なので、オンコールの準備をするのに演習は最適

Conclusion

p.181 カオスエンジニアリングのROIを示すのは容易ではない
p.181 カークパトリックモデルの4段階が重要

Open Science; Open Source

p.185 カオスエンジニアリングはその真価を発揮するために、オープンである必要がある
p.185 実験に対するオープンさ：チームや部署、組織を超えて、公に実験結果を共有できるか
p.186 6原則：Open Educational Resource, Open Access, Open Peer Review, Open Methodology, Open Source, Openn Data

Open Chaos Experiments

p.186 実験の構成要素：説明、対象システム、安定状態に関する仮説、実験手段、検査、復旧手段
p.188 安定状態仮説は二度使われる：実験開始前と、実験開始後

Experiment Findings, Shareable Results

p.188 実験結果を共有できない場合、共同作業は妨げられてしまう
p.188 実験遂行のシンプルな記録であっても、オープンな共同作業に貢献する

Conclusion

p.188 カオスエンジニアリングには参加者全員が対象システムの弱点の証跡を浮かび上がらせる自由が必要
p.188 そのためのオープンなツール、基準：オープンサイエンスのガイ絵が役に立つ

How Much of the Organization Participates in Chaos Engineering

p.193 組織の協力はコミットメントに、コミットメントはリソース配分に表れる
p.193 カオスエンジニアリングチームへのリソース配分＝組織による事前のインシデント対策優先姿勢、高いレベルでのカオスエンジニアリング採用度合いを示す
p.193 DevOpsと似ている：専門のチームが運用改善に特に貢献するが、組織全体が責任を持つ

Prerequisites

p.194 カオスエンジニアリングを採用しようとする組織への最初の質問：デグレード状態にあるかどうか判断できるか
p.194 カオスエンジニアリングの結果が関係者を驚かせる場合、敵対関係を生み出してしまう：関係者に何をどこまで実行していて、予想結果が何であるか周知することが非常に重要
p.194 望まれない結果を生むことがわかっている場合も実験をすべきではない：カオスエンジニアリングをする前に、分かっている問題を修正しよう
p.194 実験の結果得られた問題点を修正しよう：でなければただのカオスエンジニアリングはノイズに過ぎない

Obstacles to Adoption

p.195 障害やセキュリティインシデントがあるからカオスエンジニアリングをしないというのは非合理的である
p.195 選択肢は2つ：反応的に対処するか、事前に対処するか
p.195 カオスエンジニアリングは後者、統制されていなかったリスクを統制下に置こうとするとりくみ
p.195 カオスエンジニアリングは必ずしも本番環境で実施する必要はない

Sophistication

p.196 洗練度合い：助言をするだけ〜ツール提供、の間のどのあたりか
p.196 Netflixではツールの製品化に注力：Advanced principlesにおける実験の自動化

p.197 洗練度合いは主に次のようになる

1. Game Days
2. フォールトインジェクション相談
3. ツールの自立的利用
4. 実験プラットフォーム
5. プラットフォームの自動化

p.197 Game Days：とにかく集まってやってみる
p.197 フォールトインジェクション相談：ツールの使い方の指導が必要なチームがほとんど
p.198 ツールの自立的利用：専門チームの助けがいらなくなる
p.198 実験プラットフォーム：本番環境でも実験ができるような仕組みができる
p.199 プラットフォームの自動化：実験の優先順位付けも含めてコード化、自動化

p.199 実験の優先順位付のアルゴリズムにとって重要なこと：どのように優先順位が決定されたか利用者に理解させる
p.200 アルゴリズムが考慮すべきこと：実験を適切に設計するために、ある機能・システムが失敗しても安全かどうか
p.200 フォールバックがない機能、システムは安全ではない
p.200 カオス・バジェット：KPIと連動させ、どこまで実験を許容するかの目安とする
p.201 実験の発展：インフラ->アプリ->ビジネスロジック
p.201 ツールの洗練と、カオスエンジニアリングの組織内での採用拡大の間でバランスを取る必要がある
p.202 カオスエンジニアリング：ソフトウェア業界における可用性と安全性を改善するための最良の事前対策

ChAP: Running Experiments

p.210 ChAPはインスタンスを2つ追加する：1つはコントロールグループ、1つが実験対象
p.210 それぞれについてKPIを測定する（NetflixではSPS）
p.210 実験は通常45分程度（最低でも20分）
p.210 実験結果は担当チームに通知され、何が問題だったか、どう対処するかを考えるのはチームの責務

The Advanced Principles in ChAP

p.210 ChAPは第3章の発展的原則を適用している
p.210 安定状態に関する仮説：Netflixでは安定状態を秒間視聴開始数のKPIを使ってモデル化している
p.210 現実世界のイベントを変数化する：レイテンシーを使ってモデル化
p.211 本番環境での実験：Netflixの本番分散システムは巨大で変化が速く、正確なステージング環境を用意できない
p.211 自動化し継続的に：MonocleとChAPで人間の介入が不要
p.211 影響範囲を最小化：新しいインスタンスを追加して実験を行うため、並行して複数の実験が可能

ChAP as Continuous Verification

p.211 ChAPは営業時間中に継続的に、自動的に実行され、少しの変更でCI/CDパイプラインでも利用可能

CV Coming Soon to a System Near You

p.211 CVの将来の主な利用シーン：パフォーマンステスト、データ、正確性
p.212 インフラ、アプリ、ビジネスの3つのレイヤー間それぞれでの一貫性がないことが問題を引き起こす
p.213 ビジネスロジックが最も検証しづらい：不確実な環境によって変化しうるため、インフラやアプリとのミスマッチは不可避

FMEA and Chaos Engineering

p.219 FMEAの手法が効果的だったとしたら、カオスエンジニアリングにどのような価値があるか？：FMEAでの想定が適切か否かをカオスエンジニアリングの実験で検証できる
p.219 複雑なソフトウェアと複雑なハードウェアの相互作用により超複雑なシステムが生まれる：特に完全に自動化されていて、人間が排除されている場合

Software in Cyber-Physical Systems

p.220 ソフトウェアは再利用され、毎回同じ動作をするが、ハードウェアはそうではない
p.220 とはいえ、ネットワークインターフェースの設定ミスなどによりハードウェア故障に似たソフトウェアの挙動も生まれる
p.220 FMEAを実行する場合、複数の故障が同時に起こることは通常想定しない
p.220 FMEAはあくまでより良い理解（完璧な理解ではない）を得るためのフレームワーク

Chaos Engineering as a Step Beyond FMEA

p.221 FMEAとカオスエンジニアリングの関係

• スコープと機能の定義＝＝安定状態の仮説
• 問題の起きそうなことをブレスト＝＝現実世界のイベントを変化させる
• 深刻度、発生可能性をスコアづけ＝＝影響範囲を最小化する

p.222 暗黙的に、システムのある部分は決定論的で、別の部分はそうでないとバイアスを持ちがち
p.222 しかし、絶対的に正しいと信じている事柄について、まだ見ぬ不確実さがないか探索するところから始めるべき
p.222 知っていると思われていることでも、検証されていなければ、「知らないと知らないこと」と同じである
p.222 奇妙なことに、信頼できると思っているシステムのある部分で問題が起きると、巨大なリスクとなる^[1]：反対に信頼されていない部分が最も頑健となる
p.223 ソフトウェアシステムでは大抵結果整合性が受け入れられるが、CPSでは受け入れられない：リトライしている間に火に包まれたり水に沈んだりしてしまう
p.223 電気技師は、非常に信頼できるローカルクロックを構築するのがうまい：だが、それに信頼を置きすぎる
p.223 分散システムのエンジニアは、時計をそもそも信頼していない：システムが小さい時にはクロックが信頼できたが、巨大化するにつれて信頼できなくなった
p.224 本書の読者でカオスエンジニアリングのプラクティスを実践するポイントを探している人がいたら、タイミングの問題から始めてみてはどうか
p.224 特に、CPSではタイミングが生死を分ける

Probe Effect

p.224 あるシステムで障害を起こそうとしたり計測しようとしたりするのは無料ではできない：探査装置の存在そのものが計測に影響を与える
p.224 カオスエンジニアリングでも同様：システムのレイヤーや抽象化が増えるほど、こうしたプローブ効果が起こる

Addressing the Probe Effect

p.225 システムが限界で動作するにつれ、プローブ効果は重大な問題となる（タイミングやCPUキャッシュなど）
p.225 正確性と引き換えに利便性を手に入れることもできる
p.226 最も簡単な方法は常に観測装置をデプロイして非観測時も負荷をかけること

Conclusion

p.226 機械の場合、材料特性という概念がある：表面張力や引火点など
p.226 NoraやHeatherの発表はそれぞれのコンテキスト特有の価値をもつ：今日のソフトウェアを理解するということは、それだけコンテキストに依存している
p.227 有限要素法のように、カオスエンジニアリングがソフトウェアをモデル化し、「材料特性」のようなものを見つけてくれるだろう
p.227 そうすれば、ソフトウェアのインシデントは運用の問題から初期の設計時の考慮事項となるだろう

Applying Chaos Engineering

p.240 以下のアプローチでカオスエンジニアリングを適用

• 安定状態を測定可能なアウトプットとして定義する
• 安定状態に基づき仮説を立てる
• 現実世界を反映した変数を導入する
• 安定状態からの逸脱を検知し仮説を反証する

Our Way of Embracing Chaos

p.240 安定状態としてはよくQPS、レイテンシ（P99/P95）、CPU、メモリを利用する
p.240 仮説1：TiKV（TiDBのストレージレイヤ）を孤立させるとQPSが低下し、すぐに復旧されるはず
p.240 仮説2：TiKVのセグメンテーション単位を増やしてもCPUとメモリは通常を維持するはず

Fault Injection

p.241 障害を発生させるとき、重要なのはシステムを他から孤立させ、影響範囲を最小化すること
p.241 アプリ、CPU/メモリ、ネットワーク、ファイルシステムについて障害を注入する

Fault Injection in Applications

p.241 プロセスを停止/中断して耐障害性をテストする

Fault Injection in CPU and Memory

p.242 CPUとメモリは密接に関連しており、パフォーマンスに直接影響するので同じカテゴリでテストする
p.242 while (true) {} のループでCPUを消費してテストする/cgroupコマンドを利用する

Fault Injection in the Network

p.242 分散DBのTiDBにとってネットワークとファイルシステムの方が重要度が高い
p.242 ネットワーク分離については３パターンある：全く疎通できない、間接的に疎通可能、一方通行で疎通可能
p.243 レイテンシを増加させたりするために、tcコマンドを利用してテスト

Fault Injection in the Filesystem

p.243 ファイルシステムがクラッシュするとデータの一貫性が失われる
p.243 直接ファイルシステムで障害を模倣するのは難しいため、Fuseを利用してディレクトリをマウントする
p.244 特定のファイルパスに対してのみ障害を発生させるようなルールを設定可能

Detecting Failures

p.244 仮説を立てて障害を注入するのは、システムの複雑さ予測不可能さを理解するプロセスの始まりにすぎない
p.244 自動的に障害を検知できる必要がある、特に本番環境で
p.244 Prometheusなどのアラートシステムを使うと簡単
p.244 もう一つ、過去のデータから学習するという方法もある

Automating Chaos

p.245 機能追加するごとに、複雑なカオスエンジニアリングの手順が必要：手動ではスケールしないので自動化必須

Automated Experimentation Platform: Schrodinger

p.246 K8sベースの自動カオスエンジニアリングプラットフォーム：シュレディンガー
p.246 物理マシーンにクリーンな環境を構築するというカオスエンジニアリングの大きなペインポイントを解消

Shrodinger Workflow

p.247 テストケースを用意して、テスト対象のクラスタの設定を書き込む
p.247 数クリックで自動的に実行可能、24時間365日実験可能

Conclusion

p.247 さらなる段階として、カーネルレベルでの障害注入や、シュレディンガーに機械学習を利用して過去ログから効率的な障害を探すことを検討中

A Modern Approach to Security

Human Factors and Failure

p.250 Sydney Dekker「根本原因と呼んでいるものは、単に思考停止した場所のことだ」
p.251 障害のたったひとつの根本原因はない：成功の根本原因がひとつでないのとおなじ
p.251 根本原因分析の手法は、不要な非難を押し付けることになり、究極的には組織に恐怖の文化を広めてしまう
p.251 従って、伝統的な根本原因分析は、障害時に何が起きたか、何が結果に影響したかをより深く理解する機会を逸していることになる

Remove the Low-Hanging Fuit

p.252 狙われるのは準備不足の、無自覚な人間＝簡単な攻撃対象
p.252 犯罪者や悪意ある攻撃が原因とされるデータ流出も、きちんと対策されていればそんな結果にならなかったはず
p.252 障害は我々のシステムとそのセキュリティの通常動作なのだ：成功動作は日々危険にさらされている

Feedback Loops

p.253 これまでのセキュリティに対するアプローチは、主に予防的で、ある時点（のソフトウェアの状態？）に依存していた
p.253 つまり、モダンなプロダクトのデリバリを成功に導いた、高速で反復的なフィードバックループが欠けているのだ
p.253 Stitch Fix前CEO, NetflixのセキュリティエンジニアCharles Nwatu「セキュリティを改善するには、何をうまくやれているか評価し、より少なくより上手なやり方を学ぶことが重要だ」
p.253 セキュリティの問題を発見するよくあるパターンは、実際にセキュリティインシデントが発生したとき：それでは遅すぎる
p.254 フィードバックループを生み出すには、可観測性が不可欠
p.254 実験によって新しい知見を得ることで、フィードバックループが完成し学び続けられる

Security Chaos Engineering and Current Methods

p.254 SCEは現代のセキュリティ手法（レッドチーム・エクササイズやパープルチーム・エクササイズ）の不足部分を補う
p.254 レッドチームやパープルチームはSCEと組み合わさることでより客観的で事前的な（proactive）フィードバックループとなる

Problems with Red Teaming

p.255 多くのレポートが提出されるが、実行可能なアクションを示すことは稀である
p.255 システム的にありがちな脆弱性でなく悪意ある攻撃者に注目しがち
p.255 レッドチームは相手のブルーチームを負かすことに主眼を置いている：共通の理解を得ることは目的でない（そもそもブルーチームは予防的な対策がちゃんと動作したかどうかに着目している）

Problems with Purple Teaming

p.255 パープルチーム・エクササイズは非常に多くのリソースを投下する必要がある：つまりテストできるアプリケーションが少なく、実施頻度も少ない（月一回か年一回）
p.255 過去の所見を再適用してリグレッション分析を行うような仕組みがない

Benefits of Security Chaos Engineering

p.256 システム全体にフォーカスしている、セキュリティ問題を事前に特定できる
p.256 複雑なアタックチェーンではなく、シンプルで独立したコントロール可能な実験である
p.256 共同の学びのための実験である：実際のインシデントの現場は、理想的な学びの環境ではない（主眼がビジネスの継続性にあり、学びは二の次）

p.256 ソフトウェアエンジニアのチームは1日に複数のプロダクトアップデートを提供している：システムが根本的に変わりうるこの状況では、Red/Purpleチーム演習の成果の重要性は低くなりがち
p.256 SCEはこうした変化に追随可能

Security Game Days

p.257 Game Day演習の目的：統制下にある環境で障害を起こして、以下の点を明らかにすること

• 自分達のツール、技術、プロセスがどれだけ効果的に障害を検知できたか
• どのツールが障害を検知するためのデータ、理解を提供したか
• データは問題を特定するのにどれだけ有効だったか
• システムは意図した通りに対応したか

p.257 将来の障害を予測することはできない：予測できない状況にどれだけうまく対応できるか理解を深めることはできる

Example Security Chaos Engineering Tool: ChaoSlingr

https://github.com/Optum/ChaoSlingr

The Story of ChaoSlingr

p.258 テスト仕様が決まると、自動的にテストが実行され、レポートや通知が生成される
p.259 緊急停止機能も備えている
p.259 主にAWS上で動作

Conclusion

p.260 伝統的なセキュリティテスト手法は未だ有効ではあるものの、DevOpsモデル、特に継続的デプロイで変化し続ける環境では不十分である
p.260 SCEはよりよい理解のためのフィードバックループを作り、未知の事柄を明らかにし、攻撃対象領域を制限する