Open35

『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 正しい実験を選択するためには、システム全体の理解、とくに対応可能に設計された障害に対してどのように対応しているかを理解することが必要

ログインするとコメントできます