Closed59

『Chaos Engineering』読書メモ

Introduction: Birth of Chaos

Management Principles as Code

p.xvii 物語はNetflixで始まった:このプラクティスにビジネス価値を見出した
p.xviii 2008年からクラウドへの移行を始めたNetflix:クラウド上の水平スケールしたコンポーネントが、巨大なデータベースのような垂直スケールした単一障害点を減らしてくれるはず、という想定
p.xviii 当時のクラウドインスタンスは警告もなく消失:安いハードウェア上で動く小さなマシンにはよくあること
p.xix Netflixのプラクティス

  • 経験豊富なシニアエンジニアのみを採用
  • 全エンジニアに仕事上の完全な自由を与えた
  • 仕事のやり方を信頼して任せた
  • マネジメント層はエンジニア解くべき問題を伝えるだけ
  • チームは同じ方向を向いているが、結合はゆるやか:同じ問題に取り組むが、解決方法は異なる

Chaos Monkey Is Born

p.xix Chaos Monkey:毎日、クラスタからランダムにインスタンスを選び業務時間中に停止する
p.xx 毎日起きるので、この問題を解決しない限り本来の仕事ができない:重要なのは素早く解決し結果を出すこと
p.xx 2012年のクリスマスイブにAWSのELBで障害発生:Netflixユーザーもストリーミング再生できなくなった
p.xxi Chaos Monkeyはインスタンスレベルの問題は解決できていたが、より大きなスケールではどうすべきだろうか?

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万名
脚注
  1. Project Nimble ↩︎

Chapter 1: Encountering Complex Systems

p.1 驚きが複雑系の自然な性質である:複雑な分散ソフトウェアシステムは、非線形で、予測不可能で、望ましくない結果をもたらす
p.1 複雑さをシステムから取り除き、望ましくない動作をシステムから取り除くことができるだろうか(いやできない)

Contemplating Complexity

単純なシステム 複雑なシステム
線形 非線形
予測可能な出力 予測不可能な動き
理解可能 完全なメンタルモデルの構築は不可能

p.3 複雑なシステムの増加にともない、伝統的なソフトウェアアーキテクトの役割はあまり重要でなくなりつつある
p.3 複雑なシステムでは、設計と実装を分けるような官僚的役割分担は非生産的である

Encountering Complexity

Example 1: ビジネスロジックとアプリロジックの不一致

p.4 データストレージサービスQはRedisとCassandraを利用している
p.4 ある日Redisが落ち、Cassandraのプロビジョニングが不十分であったためCassandraへのリクエストもタイムアウトしてしまう
p.5 Qはサービス利用者である別のサービスPに404レスポンスを返すが、サービスPの実装が不十分でクラッシュしてしまう
p.5 それぞれが合理的なデザインの決定をしている:誰も悪くない
p.5 コンポーネントの相互作用を1人の人間が理解するのはキャパシティを超えているので、チーム間で想定にギャップが生じるのは避けられない

Example 2: エンドユーザー由来のリトライ連打

p.6 Wifiの調子が悪く、1人のエンドユーザーが100回リトライ:Wifi再接続時に、サービス側に同時に届く
p.7 ストレージフリートの1ノードにリクエストが集中し、キャッシュからデータを返し始める: CPU使用率やディスクI/Oが低下したため、スケーリングポリシーに従いノードが削除される:100リクエスト目がエラーを返したため、エンドユーザーがリトライを連打...
p.9 最終的にはリトライのリクエストがストレージフリートへのタイムアウトにより前段のサービスに滞留しスレッドプールが溢れ、システム全体がクラッシュ
p.9 graceful degradationも採用されていた:誰も悪いわけではない。もちろん、後知恵でシステムを改善することはできるが、予測できなくて当然。

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章のツールやプラクティスが参考になる

Chapter 2: Navigating Complex Systems

Dynamic Safety Model

p.17 3つの要素のバランスが重要:経済的側面、仕事の負荷、安全性

経済的側面

p.18 エンジニアは暗黙的に個人の、チームの、リソースのコストを理解している
p.18 無駄に100万個のインスタンスを起動したりはしない

仕事の負荷

p.18 個人がさばける仕事には限界がある:チームにも1スプリントでデリバリーできる機能数には限界がある

安全性

p.19 安全性:システムの可用性であり、サイバー攻撃に対する安全性
p.19 エンジニアは経済的側面や仕事の負荷は直感的に理解しているが、安全性はそうではない
p.19 経済的側面や仕事の負荷に最適化するほど、安全性から離れてしまう
p.19 カオスエンジニアリングがエンジニアの安全性に対する感覚を養う

Economic Pillars of Complexity

p.20 成功するには複雑さを増すしかない
p.20 4つのポイント:状態、関係性、環境、可逆性

Ford社の事例

p.21 状態(変数)を減らす:T型のみを生産、色は黒
p.21 製造工程における関係性を減らす:小さなタスクに分割し、チーム間のコミュニケーション不要に(ベルトコンベア方式)
p.21 環境を変える:自動車に関する特許を有する企業連合ALAMに反訴して勝利、特許料不要に
p.22 自動車は非常に複雑で、可逆性については当時コントロールしきれなかった

ソフトウェアの場合

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 複雑さとうまくやっていくためのプラクティス:複雑さと戦うプラクティスではない

Chapter 3: Overview of Principles

カオスエンジニアリングとは何か

p.25 「全体的な弱点を明らかにするための実験を促進すること」

  1. 安定状態の定義づけから始める
  2. この安定状態が対照群でも実験群でも継続すると仮説を立てる
  3. 現実世界のイベントを反映した変数を注入する
  4. 対照群と実験群を比較し仮説を反証する

実験かテストか

p.26 カオスエンジニアリングは実験の一形態であって、テストではない
p.26 どちらも品質保証のために行われるのは共通している
p.26 テスティングは厳密に言えば、新しい知識を生み出さない:テストはシステムの既知の特性に関する宣言
p.26 他方、実験は新しい知識を生み出す:まず仮説があり、否定されなければその仮説に自信が持てる。否定されれば、新しいことを学んだことになる。
p.26 テストをいくら実施しても実験から得られる知見には敵わない
p.26 一方で、新しい知見が得られてからそれをテストに書き起こすことは可能

確認か検証か(Verification Versus Validation)

p.27 カオスエンジニアリングは検証validationよりも確認verificationを強く好む
p.27 確認verification:複雑なシステム境界のアウトプットを分析するプロセス
p.27 検証validation:複雑なシステムの部分部分を分析し、相互作用を理解するプロセス
p.27 カオスエンジニアリングにとって重要なのは、システムが動くかどうか:どのように動くかは重要ではない
p.28 大抵のビジネスにおいても、システムのアウトプットのほうが、システムの実装詳細よりはるかに重要である

カオスエンジニアリングとは何でないか

システムを破壊する

p.28 カオスエンジニアリングはむしろ本番環境を修復する
p.28 カオスエンジニアリングは複雑なシステムの可用性と安全性を先回りして改善するプラクティス
p.28 SREは先回りもするし、対処的にもシステムを改善する点が異なる

Antifragility[1]

p.28 カオスエンジニアリングはAntifragilityの一種ではない
p.28 Antifragility:複雑なシステムがランダムなストレス(カオス)にさらされて強化されること
p.29 カオスエンジニアリングは複雑なシステムに既に内在するカオスを知らせてくれる
p.29 カオスエンジニアリングの基礎には経験主義があるが、Antifragilityにはそれがない

進化版の原則

p.29 カオスエンジニアリングは経験主義に基づき、テストより実験を好み、検証より確認を好む
p.29 進化版の原則

  1. 安定状態について仮説を立てる
  2. 現実世界のイベントを変数にする
  3. 本番環境で実験をする
  4. 継続的に実施するために実験を自動化する
  5. 影響範囲を最小化する

安定状態について仮説を立てる

p.30 可用性の実験時の仮説:○○な状況でも、ユーザーは快適に利用できる
p.30 安全性の実験時の仮説:○○な状況では、セキュリティチームに通知が飛ぶ
p.30 プロダクトのコードではなく、全体的なアウトプットが重要
p.30 カオスエンジニアリングはビジネス上の優先度、KPIと強く結びついている

現実世界のイベントを変数にする

p.30 当たり前のようにも見えるが、以下の理由で重要

  • 学習価値のあるものよりも、実行しやすい変数が選ばれがちであるから
  • エンジニアは自信の経験に基づき変数をえらびがちだから(ユーザーのの経験は無視されがち)

p.31 インスタンス停止、CPU高止まり、メモリ枯渇、ディスク枯渇、ネットワーク停止などはどれも同じ結果になるので、全ての実験をやる必要はない
p.31 分散システムにおいては、HTTPのレイテンシーやステータスコードを変更することで実験が可能
p.31 ただし、実際にっはサイドカーやネットワークルールの修正、クライアントライブラリの利用、サービスメッシュやロードバランサなど、かなりのエンジニアリングコストの投資が必要になる

脚注
  1. 2012年ごろにNassim Talebによって提唱された概念。https://en.wikipedia.org/wiki/Antifragility ↩︎

本番環境で実験を行う

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 戦略的にカオスエンジニアリングを実施し、他の分野での教訓を我々の業界に生かす

Chapter 4: Slack's Diasterpiece Theater

p.39 複雑なシステムであろうと、昔ながらのシステムであろうと、カオスは訪れる:リライトする時間はない
p.39 カオスエンジニアリングをそのまま昔ながらのシステムに適用しても状況は悪化するだけ
p.39 統制下で障害を発生させ、ソフトウェアの問題点を理解し、改善するプロセス
p.39 多数のエンジニアチームのロードマップにも影響する

カオスを組み込む

p.40 システムをフォールトトレラントにするツールや技術は、システムをモダンにし、クラウドネイティブにし、可用性を高めるツールや技術と同じ

古いシステムに共通のデザインパターン

p.40 古いシステム:同じコンピューターが長い時間動作しづつける前提
p.40 フェイルオーバー:非常に稀と考えられドキュメントも自動化もトレーニングも十分でない
p.40 バックアップとリストアも同様
p.40 モノリス:改造が困難で影響範囲が絞りづらい

新しいシステムに共通のデザインパターン

p.41 最近のシステム:個々のコンピューターは頻繁に入れ替わる前提
p.41 ヘルスチェックが重要な役割をもつ:インスタンスを入れ替えることでフォールトトレラントが可能に
p.41 バックアップやリストアも頻繁にテストする

基本的なフォールトトレランス

p.41 カオスエンジニアリングの実験は開発環境、ステージング環境に加えて本番環境でも行うべき
p.41 ただし顧客への影響はないと自信を持つ必要がある
p.41 古いシステムの場合はキャパシティに余剰を持たせ、インスタンスの入れかえ自動化に取り組むべき
p.42 データを保存するシステムの場合、フェイルオーバーを自動化する
p.42 机上の演習では不十分:本番環境で失敗してこそ真の自信に繋がる

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は、本番システムの耐障害性をテストするための明確なプロセスを与えてくれた

Chapter 5: Google DiRT: Disaster Recovery Testing

p.55 期待は戦略ではない:期待した内容と現実が一致しないリスクは常に存在する
p.55 SREチームが2006年にDiRTプログラムを開始
p.56 積極的に、定期的に、システムと自分たち自身をテストする
p.57 ものごとは失敗するものと考え、それを念頭において設計し、継続的にその設計が有効であることを検証すべし

Life of a DiRT Test

p.57 自動化されていないDiRTテストはテスト計画のドキュメントから始まる
p.57 少なくともチーム外のエンジニア2人のレビューを受ける:詳細を質問し、ロールバック手順などを明確にする
p.58 レビュアーの承認後、予定がとられ、実行される:実行後、結果を端的に振り返る
p.58 計画書も振り返りのドキュメントも構造化されており、プログラムで処理しアーカイブ化される

実行時のルール

p.58 過去の経験、失敗を反映した、よりスムーズなテストのためのガイドライン

1. DiRTテストはSLOに違反してはならない

p.58 絶対に外部ユーザーに影響を与えてはいけない、というわけではない
p.58 SLOに違反しない範囲なら良い
p.59 可能な限り統制下でのカオスを好む
p.59 インフラや内部サービスはSLO通りに動いていても、内部の利用者はSLOに違反しがち:実際に保証されているものよりも高い耐障害性を期待してしまうことが多い
p.59 必要な場合には、内部の利用者のセーフリスト(除外リスト)を作って、DiRTテストによる影響を与えないようにする

2. 本番のアラートがDiRTのアラートより常に優先される

p.59 DiRT演習中に本番の障害が発生した場合は、演習を中止し本番障害に集中すべき
p.59 本番障害よりもDiRT障害の方が影響がでかい場合、ルール1に違反している
p.60 どんなに小さな本番障害でもスムーズな調査のためにDiRTを中止する:たとえDiRT開始前の障害であっても同様。

3. 透明性をもってDiRTを実行する

p.60 DiRTのアラートが演習の一環であることを明示すべし
p.60 メールの件名や本文のはじめに「DiRT DiRT DiRT」とつけておく
p.60 テストに変わったテーマを設ける:ゾンビによる攻撃、AIウィルス、エイリアンの侵略など
p.60 テーマがあることで楽しいし、演習か本番障害かを区別しやすくなる

4. コストを最小化し、価値を最大化する

p.60 不安定だと誰もが思っているシステムの場合、そもそもDiRT以前に改善が必要:すでに災害はそこにあるのだから
p.60 DiRTはシステムを壊すものではない:未知の障害を明らかにすることに価値がある

5. DiRTテストを実際の障害のように扱う

p.61 演習だからといって見逃すのではなく、定められた通りにエスカレーションを行う
p.61 演習の影響範囲を知るための重要な情報収集の一環であり、予想されていなかったシステム間のつながりを明らかにしてくれる

テスト対象

p.61 最近の障害があるならば、とても良い参考材料になる:同じ障害を発生させてみよう
p.61 以下のような質問からはじめよう

  • 1箇所にしかないデータやサービスはあるか?
  • 1箇所にいる人やベンダーに頼っているプロセスはないか?
  • 監視システムは期待されたアラートを100%発報するか?
  • 最後にバックアップからリストアしたのはいつ?
1. Run at service levels

p.62 シナリオ:大量のトラフィックがきて内部共有サービスのレイテンシを悪化させ、SLOぎりぎりのライン
p.62 長くSLOギリギリの状態が続いても他のサービスに影響がないかを見る
p.62 いわゆる「ハイラムの法則」の延長

2. Run without dependencies

p.62 シナリオ:ソフトな依存関係のサービスの半分がエラーを返し、残りの半分はレイテンシーが増加している状態
p.62 SLOを守りつつグレースフル・デグラデーションとなるのがよい
p.62 依存関係のソフト/ハードは区別が難しいので、こうしたテストで見分ける
p.63 定期的にテストを実行しないと、依存関係はすぐに変わってしまう:Googleでも何年もテストを実行して、いまだに新しい発見がある
p.63 ローマは一日にして成らず、いきなりたくさんのことをやる必要はない:いくつかの依存関係に少量のレイテンシを追加するところから始めれば十分

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 定期的に、定式化された災害テストを注意深く行うことで、統制のとれたやりかたでシステムを試すことができる

Chapter 6: Microsoft Variation and Prioritization of Experiments

p.77 あなたのサービスで実験する場合の優先順位のつけかた、実験のバリエーションを考えるフレームワークを示す

Why is Everything So Complicated

p.77 最小のWebサイトでも多数のソフトウェア、ハードウェアから成る:ハードウェア、電源装置、各種ケーブル、ネットワーク、クラウドプラットフォーム...

An Example of Unexpected Complications

p.78 潜水艦のソナー設備の事例:計画段階では数日と思われていたが、実際の航海では何十日もかかった
p.78 現実世界でシステムに何が起こりうるかを包括的に考慮できていなかったため
p.78 カオスエンジニアリングの発展的原則の一つ:現実世界のイベントに変化を与える

A Simple System is the Tip of the Iceberg

p.79 シンプルなウェブサイトでも、裏側をすべて考えるとシンプルではない
p.79 インターフェース、コンポーネント間の規約、SLAを考えつつ、プロダクトを設計し実装するという非常に複雑な仕事
p.79 加えて、ハードウェア不良やソフトウェアのバグ、不十分にドキュメント化された手順などの問題もある
p.79 バージョンアップ、OSのパッチ、ハードウェアのメンテナンスなどの予定されたイベントもある

Categories of Experiments Outcomes

p.80 カオスエンジニアリングの結果の分類

【既知のイベント/既知の結果】
p.80 一番うまくいった場合

【既知のイベント/予期せぬ結果】
p.80 シナリオ通りに行かなかった場合。計画通り、実験を中断し、結果を記録して、再実験をしよう
p.80 学ぶべきことがたくさんあるはずだ
p.80 バージョンアップ、OSパッチ、秘密情報のローテーション、サマータイムの変更などが挙げられる
p.81 セキュリティパッチなどは、テストもスキップされがちで、結果として失敗確率が劇的に上がる
p.82 定期的に実践するから徐々に上達する:設計し、備えることで、大規模な問題でも無害に済ませられる

【予期せぬイベント/予期せぬ結果】
p.80 状況をコントロールできない危険性がある:可能な限りリカバリに努めよう
p.80 最も価値がある学びはここから得られる
p.82 MSのヘッドクオーターがDNSの不適切な設定により全世界から隔離された事件
p.82 データセンターに注目するあまり、ヘッドクオーターで問題が起きる可能性について度外視していた
p.82 予期せぬ結果についても受け入れ、可能な限りのリカバリを試みる必要がある

Prioritization of Failures

p.83 様々な種類のインシデントを優先順位づけして効率的に対処する

【頻度】
p.83 最も頻繁に発生するイベントから対応しよう:バージョンアップ、クレデンシャルのローテーション、サマータイム、セキュリティ問題など
p.83 頻繁に行えば行うほど上達する:練習しないと本番で失敗する

【影響度】
p.83 損失を完全に受け入れるしかない場合もある:世界規模の自然災害など
p.83 対処可能なリスクを理解しよう

【発生可能性】
p.83 定期的に発生するわけではないので、定例チェックするほど優先順位が高くないもの:例として、暗号が危殆化した場合
p.84 何が必要か、時間はどれくらいかかるか、影響はどれくらいか、変更中の機能の担保はどうするか、顧客への連絡は、といったことを考えておく必要がある

【発生可能性】
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、かなり古いバージョンのクライアントを利用している顧客、などなど。

Chapter7: LinkedIn Being Mindful of Members

p.91 自動車業界の事例:人体のシミュレーションとしてダミー人形で衝突実験を行う
p.92 カオスエンジニアリングでも同じ:可能な限り小さくはじめる

Learning from Disaster

p.92 チェルノブイリ原発事故
p.93 システムが不安定で適切な安全装置も、危険を知らせる十分な警報もなかった
p.93 カオスエンジニアリングの実験をする場合も安全第一にいくべき

Granularly Targeting Experiments

p.93 Netflixも最初からChaos MonkeyやChaos Kongに耐えるインフラを持っていたわけではない
p.93 最初は小さく始めることが重要:自分のユーザーで試す
p.94 フロントエンドがバックエンドにAPIリクエストを投げられない場合、ベストなユーザーエクスペリエンスは何かを考えるところからはじめよう
p.94 エラーページ?自動リトライ?別の機能へのフォールバック?

Experimenting at Scale, Safely

p.95 小さくはじめてうまくいったら、拡大して実験してみたくなる
p.95 拡大して実験することは重要だが、実験の前に重要なリスクを考慮する必要がある
p.95 実験を停止する基準を前もって定めておくことで、影響を素早く緩和しインシデント解決時間を短縮できる
p.95 実験の自動化のフレームワークに関わらず、「緊急停止ボタン」を用意しておこう:プロセスのkillコマンドや、一連のAPI呼び出しなど

In Practice: LinkedOut

p.96 LinkedOut:リクエストレベルでの障害を疑似的に発生させるフレームワーク
p.96 これはWaterbear(クマムシ)プロジェクトの一部:クマムシは高温や宇宙などの過酷な環境下でも生存できる頑丈さをもっている

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 小さな範囲で検証できたら、大規模に検証を行うことも重要

Chapter 8: Capital One Adoption and Evolution of Chaos Engineering

p.107 金融業界のソフトウェアはより複雑
p.107 各種機関への定期的な監査記録の提出が必要:カオスエンジニアリングが悪影響を与えてはいけない
p.108 ブロックチェーン、AI、機械学習はクラウドインフラ上の強固でスケーラブルなシステムが不可欠
p.108 デプロイやイミュータブル・インフラストラクチャと同じくらい、信頼性も継続的に検証が必要:カオスエンジニアリングの出番

Capital One Case Study

Blind Resiliency Testing

p.108 クラウドジャーニーが本格化する前からカオスエンジニアリングを実践していた
p.108 サービスの稼働率に影響する、内部・外部・アプリ・ハードウェア・統合部分のあらゆる要素の理解が必要
p.108 2013年に開始
p.109 リリース後、もしくは月1回定期的に実施:実験の一覧からランダムに選択したものを実施

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 信頼性の高いシステムを構築するには信頼性を検証するためのプラクティスが必要:それがカオスエンジニアリングの役割

Part III: Human Factors

p.117 回復力は人々の社会技術的sociotechnicalシステムによって生み出される:機能を実装するエンジニア、システムを運用保守するエンジニア、そのためにリソースを割り当てるマネジメント。
p.117 システムの回復力をうまく向上させるには、システムに関わる人間と非人間の登場人物の相互作用の理解が不可欠:カオスエンジニアリングは人間とマシンの社会技術的境界の理解を深めてくれる

Chapter 9: Creating Foresight

p.119 回復力のある組織:過去の成功から自信を得ず、さらに深掘りし、隠れたリスクを見つけ、システムに関するメンタルモデルを更新する機会として活用する
p.119 メンタルモデルの更新こそがカオスエンジニアリングの主目的

Chaos Engineering and Resilience

p.120 カオスエンジニアリングは脆弱性を見つけ出すためのものではない
p.120 カオスエンジニアリングは予期せぬシステムの動作結果を前にして、回復力の文化を構築することにある:回復力を高めるための手段の一つに過ぎない

Steps of the Chaos Engineering Cycle

Designing the Experiment

p.121 「全てのメンタルモデルは間違っているが、中には有用なものもある」
p.121 社内APIのユーザーはAPI稼働率100%を期待↔︎API開発者はユーザーの適切なハンドリングを期待:メンタルモデルのズレ
p.121 明示的にこの点について会話しない:お互いに当然だと思ってしまっているから
p.121 カオスエンジニアリングの出番:カオスエンジニアリングが我々のメンタルモデルがどうなっているか確認するきっかけとなってくれる
p.122 チームメイトのメンタルモデルとどう違うだろうか?
p.122 インシデントが起きたわけではないので、インシデントが起きた場合とは違って心理的安全性が保たれた場で話すことができる
p.122 こうした感情的な基礎のおかげで、学習に集中できる

Tool Support for Chaos Experiment Design

p.122 Netflixで使われていたJavaライブラリChAP:特定のリクエストを失敗させることができる
p.123 各チームに使い方を教えたりしたが恒常的な利用はなし:言われたときか、ホリデーシーズン前などにしか使われず
p.124 カオスエンジニアリングチームがシステム全体に詳しいわけではないので、システム全体に跨がる有意義な実験につながらず
p.124 各チームが安全に実験しやすいよう、自動化

Effectively Partnering Internally

p.125 実験の仮説を作るためのファシリテーション:チームメンバーそれぞれにシステムの理解を話してもらう
p.125 それぞれの期待結果を確認しあうことが実際に実験するのと同じくらい重要

Understand Operating Procedures

p.125 ファシリテータの最初の質問「システムのどんな動きや相互作用が気になりますか?」
p.125 まず、在職期間の短い人に聞いて、徐々に年次の上の人、専門知識のある人に聞いていく
p.126 ファシリテータは専門知識とギャップを特定し、このエクササイズを学習体験として扱うべし
p.126 次の質問「他のチームメイトがシステムについて知っていると思っていることは何か?」
その他の質問例

  • 気になる依存関係のサービスはある?
  • 自サービスの障害時に自サービスを利用するサービスはどうなる?
  • 自サービスで障害が起きたら何が起きる?フォールバックはあるか、それは何をする?エンドユーザーへの影響は?
  • 新たな脆弱性が生まれるような最近の自サービスの変更はあったか?それについて詳しいのは誰?
  • 障害が起きるとしたらその原因はなんだろう?
  • 設定パラメータに自信はある?タイムアウトやリトライの意味を理解している?
  • 日々の運用で最も怖いものは?

p.127 全員の理解がそろってから、実験のスコープを議論しよう

Discuss Scope

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

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

Hypothesize

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

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

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

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

Conclusion

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

Chapter 10: Humanistic Chaos

p.133 組織(organizations):複雑な分散システム
p.133 分散システムにカオスエンジニアリングを適用するなら、組織にも適用できるはず

Humans in the System

p.133 組織というシステムの構成要素は人
p.133 人間がいるから問題がおきるし、その問題を解決するのもまた人間

Putting the "Socio" in Sociotechnical Systems

p.134 モノリスからマイクロサービスへ、と技術を変えたところで、文化まで魔法のように変わることはない
p.134 システムについては、頻繁にメンタルモデルが修正される:アーキテクチャレビュー、設計、インシデントレビューなど
p.135 組織についてはどうか?:インシデントのエスカレーションフローは?誰かが休みの場合は考慮されているか?そもそもインシデントかどうかを判断する基準は?その仕組みが動作しているかモニタリングしている?
p.135 やると言っているだけのことと、実際にやっていることとは、大きな違いがある

Organizations Are a System of Systems

p.134 文書化された組織というシステム:休暇規定、オンコールシフトなど
p.134 暗黙知も多い:○○さんにはSlackで連絡すべし、XXに詳しいのは△△さん、など
p.135 あらゆる点で失敗する可能性がある:人間がその原因でもあり、システムを守るのも人間である

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チームにきて1スプリント過ごす
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 失敗するということがまさに学んでいるということ:調整して、動き続けよう

Chapter 11: People in the Loop

p.151 ソフトウェアを実装することと、それがどのように動き失敗するか理解しているということは全く異なる
p.151 システムの理解を維持し発展させていくには、システム動作のメンタルモデルを修正する能力があることが重要

The Why, How, and When of Experiments

The Why

p.152 ソフトウェアがどのように動作するかについて、自信を持つため
p.153 Continuous Deliveryの一種としてのカオスエンジニアリング

The How

p.153 文脈によって考慮すべきポイントが異なる

  • 実験対象は何か、対象でないものは何か
  • いつ、どれくらいの期間実験するか
  • どのように実験するか
  • 誰のための実験か
  • 実験の大目的は何か

The When

p.154 実験のタイミングに影響する諸条件

  • インシデントにおける予期せぬ動作
  • 新機能、新プロダクトのローンチ
  • システムの他の部分との結合(新しいインフラの導入など
  • 高負荷の予測されるイベント
  • 何らかの外部要因(株価の急変動、ニュース
During Incidents: "Is this related to what you're running?"

p.154 インシデントがあると、本番環境でのカオスエンジニアリングの実験は濡れ衣を着せられがち

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 人間は責任をもつことができるが、ソフトウェアはそうではない:カオスエンジニアリングを通じて、複雑なシステムを設計し運用する責任を手助けすることができる

Chapter 12: The Experiment Selection Problem ( and a Solution )

p.161 複雑なシステムを設計する上で最も難しいのは、人間と機械をどう使い分けるのがベストか見分けること

Choosing Experiments

p.161 複雑なシステムで実施可能な実験は天文学的な数にのぼる:20のマイクロサービス同士のやりとりを考えても、2^20、100万通り以上

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

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 直感の自動化が必要:カオスエンジニアリング実験の選択における専門家の役割をコンピュータに担わせるべき

PART IV: Business Factors

Chapter 13: ROI of Chaos Engineering

p.175 カオスエンジニアリングの結果がビジネス的価値を持つことを証明するのは非常に難しい

Ephemeral Nature of Incident Reduction

p.175 どうしてカオスエンジニアリングだけが障害を減らしたと断言できよう?
p.176 カオスエンジニアリングによってもたらされた改善が、別のビジネス上のプレッシャーを生み出す:その圧力によってカオスエンジニアリングのメリットは打ち消される

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段階が重要

Chapter 14: Open Minds, Open Science, and Open Chaos

p.183 カオスエンジニアリングは科学である

Collaborative Mindsets

p.183 カオスエンジニアリングは容易に衝突を引き起こす関係に陥りがち:他人のシステムに対して行われるから
p.184 システムの担当チームがシステムの弱点を見つけるのを助け、より回復力のあるシステムを構築する手助けをする、というマインドセットが重要
p.184 そのための手助けやツールを提供する必要がある
p.185 健全なカオスエンジニアリングの実践には共同作業Collaborationと責任の共有Co-ownershipが必須

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 そのためのオープンなツール、基準:オープンサイエンスのガイ絵が役に立つ

Chapter 15: Chaos Maturity Model

p.191 CMM:元ネタはCapability Maturily Model(能力成熟度モデル:ソフトウェア開発プロセスに必要なプロセスを組織の成熟度レベルに応じてまとめたモデル。)
p.191 カオス成熟度モデル:Netflix発。カオスエンジニアリングの手法に投資したい組織向け

Adoption

p.192 マネジメント層がカオスエンジニアリングに本腰を入れるのは可用性やセキュリティで問題が発生した後であることが多い

Who Bought into Chaos Engineering

p.192 インシデントに最も近い個人が、初期にカオスエンジニアリングを取り入れる
p.192 可用性のインシデントで呼び出されるチームがそれに続く:DevOps, SRE, インシデント管理チーム、運用チーム、IT部門

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 カオスエンジニアリング:ソフトウェア業界における可用性と安全性を改善するための最良の事前対策

Chapter 16: Continuous Verification

Where CV Comes From

p.205 別々にコードを書いているエンジニアの期待値にギャップがあるとき、そのコードの組み合わせは予期せぬ望ましくない結果を生む
p.205 その間違いに早く気づくほど、次に書かれるコードの間違いが少なくなる:反対に、早期にギャップに気づかなければ、次に書かれるコードはさらに悪いものになる
p.206 フィードバックループによってソフトウェアの可逆性が促進される
p.206 可逆性は複雑なソフトウェアシステムを切り抜けるために有効
p.206 CVは先のことを考えた(proactiveな)実験:ソフトウェア品質保証の一般的なプラクティスが反応的(reactive)テストを好むのと対照的
p.206 複雑なシステムには知っていることをテストする手法より、未知のことを探索する手法が必要
p.206 アジャイル、DevOps、SREといった人員への投資が必要な手法と異なり、スケールするためのツールが必須

Types of CV Systems

p.207 カオスエンジニアリングプラットフォームにより、営業時間中に際どい実験を行う
p.207 自動化されたカナリアリリースもこの分野
p.208 新しいコードの分岐がカオスエンジニアリングの「変数」に該当する
p.208 直感エンジニアリング(Intuition Engineering)という分野:NetflixのVizceralなどのツール。システムの全体像を提供するツール
p.208 Vizceral自体は実験を行わないが、システムの動作を確かめるためのproactiveなツール

CV in the Wild: ChAP

p.209 ChAP:Chaos Automation Platform

ChAP: Selecting Experiments

p.209 Monocleというツールも同時に作られた:実験の優先順位付を行い、優先順位付のプロセスをユーザーに理解させる
p.209 MonocleはRPCクライアントやHystrixコマンドの設定(タイムアウト、リトライなど)から依存関係の情報を集める
p.209 上記の情報から、ChAPが実験を行うのに安全か否かを判定する:安全であれば、実験の優先リストに追加される

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 ビジネスロジックが最も検証しづらい:不確実な環境によって変化しうるため、インフラやアプリとのミスマッチは不可避

Chapter 17: Let's Get Cyber-Physical

p.215 これまで見てきたのはインターネット中心的:AWS, Netflix, Facebookなど
p.215 本章では、伝統的な機能安全性のプラクティスとカオスエンジニアリングの関係について、サイバーフィジカルシステムの文脈で見ていく

The Rise of Cyber-Physical Systems

p.216 CPS:ハードウェアとソフトウェアが相互に接続され、実世界と結合している
p.216 例)航空電子工学、自動運転車、その他工業コントロールシステムなど
p.216 実世界では、障害のリスクが文字通り生死にかかわることもある

Functional Safety Meets Chaos Engineering

p.217 自動車業界ではISO26262、航空電子工学ではDO-178C/DO-254、原子力ではIEC 61513など様々な標準がある
p.217 多くはIEC 61508の機能安全性に関する標準に由来:過去のベストプラクティスや実際の事故をまとめたもの
p.217 FMEA:Failure Mode and Effects Analysis(故障モード影響解析)

  • 分析スコープを定義
  • スコープの全機能を特定
  • 機能ごとにありうる障害の全影響をリストアップ
  • 障害の影響度、発生確率、検知可能性などでランク付

p.218 ランクの高いものに優先して取り組む
p.218 こうしたやり方は分析スコープの定義や障害の予想の難しさから、恣意的な/気まぐれな結果につながってしまった
p.218 それでも、故障が起こりうる、というマインドセットを作る上で、こうしたプロセスにも一定の意味があった

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ではタイミングが生死を分ける

脚注
  1. ちょうどこれを読んでいる時に、Log4Shellが明らかとなった。 ↩︎

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 そうすれば、ソフトウェアのインシデントは運用の問題から初期の設計時の考慮事項となるだろう

Chapter 18: HOP Meets Chaos Engineering

What is Human and Organizational Performance (HOP)?

p.229 HOP:組織構造や職務プロセスを改善するためのアプローチ
p.229 カオスエンジニアリングとHOPの哲学的なルーツは、安全科学における「新しい見方」

Key Principles of HOP

p.230 HOPの5原則:運用上の安定性と回復性を改善するためのガイド

  1. 間違えるのは普通のこと / Error is normal
  2. 非難は何も修正しない / Blame fixes nothing
  3. 状況が行動を決める / Context drives behavior
  4. 学び改善することがきわめて重要 / Learning and improving is vital
  5. 意図的な反応が大事 / Intentional response matters

原則1:間違いは普通のこと

p.230 人間は間違えるもの:最も間違いをおかす人が最もたくさん仕事をしている、全く間違えない人は何もしていない
p.230 間違い得ないようにする必要はあるが、同時に、間違えても安全に失敗できるようにする必要がある

原則2:非難は何も修正しない

p.231 非難は何も修正しないだけでなく、重要な会話や不可欠な情報を隠してしまう
p.231 問題を起こしたら非難される場合、問題を起こした当の本人は問題について話したがらない
p.231 非難するのをやめて、問題からの学び、改善点、復旧方法にフォーカスすることで、働く人々が恐れずに問題について議論できる環境となる
p.231 非難はあなたやあなたの組織をより良いものにしない

原則3:状況が行動を決める

p.231 仕事の状況がビジネスのゴールからかけ離れた行動を引き起こすことがある
p.231 安全性が重視され怪我の件数ゼロが目標にされていたら、過小報告への圧力が高まってしまう
p.231 日々の仕組みがどのような行動を引き起こしているか:正しい行動につながっていなければ修正が必要

原則4:学び改善することがきわめて重要

p.232 学び改善するプロセスに必要なのは、事前に計画されたゴールに対して、結果がどうであったか確認することが重要
p.232 改善結果を効果的に分析または検査する必要がある:ここでカオスエンジニアリングが役立つ

原則5:意図的な反応が大事

p.232 インシデントが起きた/起きそうなときに、反応を起こさなければならない
p.232 そして反応の方法は、個人や上司、マネージャを非難するものであってはならない

HOP Meets Chaos Engineering

p.232 事故などに対して、なんらかの対策が実施されたかどうかに通常注目しがち:対策の効果や持続可能性にも着目する必要がある
p.233 職場環境において、なんらかの違いを生み出せただろうか?
p.233 システムがカオスな状態にあるのを観察することで、新しいことを学べる

Chaos Engineering and HOP in Practice

p.234 HOPではシミュレータが利用される
p.234 仕事に内在するカオス:システム/仕組みが想定通りに動かない、シミュレータでは再現できていなかった問題が起きる
p.234 原則1:間違いは普通のこと:研修生はシミュレータでも間違える
p.235 原則2:非難は何も修正しない:シミュレータなので非難する必要がない
p.235 原則3:状況が行動を決める:シミュレータと人間の相互作用で研修が成り立つ、不均衡があればシミュレータを修正
p.235 原則4:学び改善することがきわめて重要:シミュレータは安全な学習環境
p.235 原則5:意図的な反応が大事:教える側が良い意思決定のためにファシリテートすべし
p.235 HOPとカオスエンジニアリングのゴールは美しく重なっている

Conclusion

p.235 HOPは人間と組織の相互作用についての知識を最大限に引き出しより良い職場を作るための助けとなる
p.235 カオスエンジニアリングは哲学的にも実践的にもHOPを補完してくれる

Chapter 19: Chaos Engineering on a Database

Why Do We Need Chaos Engineering

p.237 TiDB:OSSのHTAP(Hybrid Transactional/Analytical Processing)DB
p.237 最も根本的で主要な要求事項:耐障害性があること
p.237 ユニット/インテグレーションテストはプロダクション・レディであることを担保するが、クラスタがスケールし、複雑性が増し、データ量がペタバイト級ともなるとカバーできない問題が出てくる:カオスエンジニアリングが必要

Rubustness and Stability

p.237 データ喪失や損傷はいかなる場合にも避けなければならない:しかし現実には障害は思いもよらない方法、場所、時間に発生する
p.238 ユニットテストのカバレッジが100%だからといって、耐障害性があるわけではない
p.238 よく設計されたインテグレーションテストをパスしたシステムだからといって、本番環境でうまく動くとは限らない
p.238 予測不可能な障害をシミュレートし、対応をテストするための仕組みが必要

A Real-World Example

p.238 TiDBでのレプリケーション:メタデータと書き込み実データからなるスナップショット
p.238 メタデータにデータサイズが書かれているが実データがなく、スナップショットが壊れている場合がある
p.239 Linuxのページキャッシュが、システムがクラッシュしたり電源障害によりフラッシュに失敗した場合に発生する
p.239 この問題だけを解決するのは容易だが、全ての問題をカバーするテストは書けない:より良い方法、カオスエンジニアリングが必要

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 ネットワーク分離については3パターンある:全く疎通できない、間接的に疎通可能、一方通行で疎通可能
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 さらなる段階として、カーネルレベルでの障害注入や、シュレディンガーに機械学習を利用して過去ログから効率的な障害を探すことを検討中

Chapter 20: The Case for Security Chaos Engineering

p.249 セキュリティ・カオスエンジニアリング:セキュリティ統制の失敗を、プロアクティブな実験によって発見し、システムが悪い条件でもうまく動作する自信をもつための手法
p.250 主観的な評価から、客観的な測定へとセキュリティを変化させるのが目的
p.250 カオス実験によって、未知の知らないことを減らし、既知の知らないことを改善可能な情報で置き換えることができる

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はよりよい理解のためのフィードバックループを作り、未知の事柄を明らかにし、攻撃対象領域を制限する

Chapter 21: Conclusion

p.263 回復力resilienceを生み出すのは人間である:機能を実装するエンジニア、システムを維持する運用担当、そのためのリソースを割り当てる経営者the management
p.236 カオスエンジニアリングは道具であり、回復力を改善するために利用できる
p.236 コードの特定の行にインシデントの原因を見つけると心理的満足は得られる:そこで止まってはいけない、人間、組織、人間同士の相互作用も無視してはいけない
p.264 「根本原因」を追い求めたり、ルールを強制しようとするよりも、インシデントレビューや回復力の要素を文脈に応じて考えることの方が実用的である
p.264 回復力を高めようとしてルールを強制するのは誤りである

  • 直感的には冗長化するとより安全に見えるが、実は経験的にはそうではない:チャレンジャー号のOリングも冗長化されていた
  • 直感的にはシステムの複雑さを取り除くとより安全に見えるが、実は経験的にはそうではない:最適化できる要素は安全性だけである
  • 直感的には効率的なシステム運用はより安全に見えるが、実は経験的にはそうではない:非効率さが衝撃を吸収する役割を担う

p.265 上記リストはまだまだ続く
p.265 人間だけが予想できない状況であっても、適切に考えることができる:複雑なシステムにおいて人間というファクタを考慮する必要がある
p.265 カオスエンジニアリングによって、人間と機械の間の社会技術的sociotechnical境界をよりよく理解できるだろう
p.265 ツールが回復力を作るのではない、人間が回復力を作るのだ:しかし、ツール、すなわちカオスエンジニアリングはその役に立つ

このスクラップは5ヶ月前にクローズされました
作成者以外のコメントは許可されていません