カオスエンジニアリング
――回復力のあるシステムの実践

[cover photo]
  • 2022年06月 発行
  • 316ページ
  • ISBN978-4-87311-988-5
  • 原書: Chaos Engineering
  • フォーマット 本 PDF EPUB

オライリー・ジャパンで書籍を購入:
定価3,740円

Ebook Storeで電子版を購入:
価格2,992円

ソフトウェアをはじめとするあらゆるシステムは、発展するにつれて必然的に複雑性が増していきます。
本書は、カオスエンジニアリングの基本となる理論と原則を説明し、組織が複雑性を受け入れながら、システムにおける弱点を発見するとともに、自信を持って障害に対処する力をつけるための実践方法を解説します。
ソフトウェアがビジネスの根幹を担う企業であるSlack、Google、Microsoft、LinkedIn、Capital Oneでの事例を紹介し、ゲームデーを中心としたカオスエンジニアリングプログラムの実践、実験の選択や自動化にあたっての課題、継続的ベリフィケーションの設計と実施、さらにはデータベースやセキュリティ分野への応用例などについて説明します。
Netflixでカオスエンジニアリングチームを立ち上げた先駆者である著者に加え、さまざまな組織のリーダーたちがカオスエンジニアリングについて多角的に解説する本書は、エンジニアのみならず、あらゆる「複雑なシステム」に関わる方々にとって必携の一冊です。

関連書籍

SRE サイトリライアビリティエンジニアリング
ソフトウェアアーキテクチャの基礎
モノリスからマイクロサービスへ

はじめに

イントロダクション:カオスの誕生
    マネジメントの原則 as Code
    Chaos Monkeyの誕生
    大規模化:モンキーからコングへ
    規律の明文化
    コミュニティの誕生
    急速な進化

第I部 舞台準備

1章 複雑なシステムとの出会い
    1.1 複雑性についてじっくり考える
    1.2 複雑性との遭遇
        1.2.1 例1:ビジネスロジックとアプリケーションロジックの不整合
        1.2.2 例2:顧客起点のリトライの嵐
        1.2.3 例3:休暇シーズンのコードフリーズ
    1.3 複雑性に立ち向かう
        1.3.1 偶発的な複雑性
        1.3.2 本質的な複雑性
    1.4 複雑性を受け入れる

2章 複雑なシステムの舵を取る
    2.1 動的安全モデル
        2.1.1 経済性
        2.1.2 ワークロード
        2.1.3 安全性
    2.2 複雑性の経済的支柱
        2.2.1 状態
        2.2.2 関係
        2.2.3 環境
        2.2.4 可逆性
        2.2.5 ソフトウェアに適用された複雑性の経済的支柱
    2.3 システム的な観点

3章 原則の全体像
    3.1 カオスエンジニアリングとは何か
        3.1.1 実験 vsテスト
        3.1.2 ベリフィケーション(検証)vsバリデーション(妥当性確認)
    3.2 カオスエンジニアリングではないもの
        3.2.1 モノを壊す
        3.2.2 抗脆弱性
    3.3 発展した原則
        3.3.1 定常状態に関する仮説を立てる
        3.3.2 実世界の事象を多様化させる
        3.3.3 本番環境で実験する
        3.3.4 継続的に実行できるよう実験を自動化する
        3.3.5 影響範囲を局所化する
    3.4 「原則」の未来

第II部 原則の実践

4章 Slackの惨劇シアター
    4.1 カオスの組み込み
        4.1.1 古めのシステムにありがちなデザインパターン
        4.1.2 新しめのシステムにありがちなデザインパターン
        4.1.3 基本的な耐障害性に着手する
    4.2 惨劇シアター
        4.2.1 ゴール
        4.2.2 逆ゴール
    4.3 プロセス
        4.3.1 準備
        4.3.2 演習
        4.3.3 振り返り
    4.4 プロセスがどのようにして進化したか
    4.5 マネジメント層を味方につける
    4.6 結果
        4.6.1 キャッシュの非一貫性を避ける
        4.6.2 何度も、何度でもやってみよう(安全のために)
        4.6.3 不可能性に関する結果
    4.7 まとめ

5章 Google DiRT:災害からの復旧テスト
    5.1 DiRTテストのありかた
        5.1.1 実施時の約束事
        5.1.2 何をテストするか
        5.1.3 どうやってテストするか
        5.1.4 結果を集める
    5.2 Googleにおけるテストのスコープ
    5.3 まとめ

6章 Microsoftにおける実験の多様化と優先順位づけ
    6.1 なぜ、こんなにもすべてが複雑なのか?
        6.1.1 予期せぬ複雑性の例
        6.1.2 シンプルなシステムは氷山の一角
    6.2 実験結果のカテゴリ
        6.2.1 既知の事象と予期せぬ結果に関して
        6.2.2 未知の事象と予期せぬ結果に関して
    6.3 障害の優先順位づけ
        6.3.1 依存関係を探究する
    6.4 変化の度合い
        6.4.1 変化する障害
        6.4.2 変化と優先順位づけを組み合わせる
        6.4.3 変化を依存関係に展開する
    6.5 大規模環境における実験のデプロイ
    6.6 まとめ

7章 LinkedIn メンバーに対して配慮すること
    7.1 災害から学ぶ
    7.2 粒度別の実験
    7.3 大規模な実験を安全に行う
    7.4 実践編:リンクトアウト(LinkedOut)
        7.4.1 故障モード
        7.4.2 実験対象の絞り込みに LiXを使う
        7.4.3 高速な実験のためのブラウザエクステンション
        7.4.4 自動実験
    7.5 まとめ

8章 Capital Oneにおけるカオスエンジニアリングの導入と進化
    8.1 Capital Oneにおける事例
        8.1.1 ブラインド回復力テスト
        8.1.2 カオスエンジニアリングへの移行
        8.1.3 CI/CDにおけるカオス実験
    8.2 実験の設計時に留意すること
    8.3 ツール
    8.4 チーム構造
    8.5 普及に向けた活動
    8.6 まとめ

第III部 人間的な要素

9章先見性を生み出す
    9.1 カオスエンジニアリングとレジリエンス
    9.2 カオスエンジニアリングサイクルとその各ステップ
        9.2.1 実験をデザインする
    9.3 カオス実験のデザインをサポートするツール
    9.4 組織内で効果的にパートナリングする
        9.4.1 運用手順を理解する
        9.4.2 スコープを議論する
        9.4.3 仮説を立てる
    9.5 まとめ

10章 人間的なカオス
    10.1 システムの中の人間
        10.1.1 社会技術システムに「社会性」を入れる
        10.1.2 組織はシステムのシステム
    10.2 エンジニアリングの適応能力
        10.2.1 弱いシグナルを見つけ出す
        10.2.2 失敗と成功は表裏一体
    10.3 原則を実践に移す
        10.3.1 仮説を立てる
        10.3.2 実世界の事象を多様化させる
        10.3.3 影響範囲を局所化する
        10.3.4 事例 1:ゲームデーをゲームする
        10.3.5 コミュニケーション:あらゆる組織にとってのネットワークレイテンシ
        10.3.6 事例 2:点と点とをつなぐ
        10.3.7 リーダシップはシステムに表れる特性
        10.3.8 事例 3:基本的な想定を変える
        10.3.9 安全にカオスを組織する
        10.3.10 高度と方角さえあれば進んでいける
        10.3.11 ループを閉じる
        10.3.12 失敗しないのだとしたら、学んでいないということ

11章 ループの中の人々
    11.1 なぜ、どのように、いつ実験するのか
        11.1.1 「なぜ」について
        11.1.2 「どのように」について
        11.1.3 「いつ」について
        11.1.4 機能配分、あるいは人間が得意なことと機械が得意なこと
        11.1.5 置き換えの神話
    11.2 まとめ

12章 実験の選択に関する課題(と、その解決策)
    12.1 実験の選択
        12.1.1 ランダムな探索
        12.1.2 専門家の時代
    12.2 可観測性:機会
        12.2.1 直感エンジニアリング(Intuition Engineering)の可観測性
    12.3 まとめ

第IV部 ビジネス要因

13章カオスエンジニアリングの費用対効果
    13.1 長続きしないインシデント削減の性質
    13.2 Kirkpatrickモデル
        13.2.1 レベル 1:反応
        13.2.2 レベル 2:学習
        13.2.3 レベル 3:行動
        13.2.4 レベル 4:結果
    13.3 もう 1つの費用対効果の例
    13.4 副次的な費用対効果
    13.5 まとめ

14章 オープンな心、オープンな科学、そしてオープンなカオス
    14.1 協調的なマインドセット
    14.2 オープンな科学、オープンソース
        14.2.1 オープンなカオス実験
        14.2.2 実験における発見と、共有可能な結果
    14.3 まとめ

15章 カオスの成熟モデル(CMM)
    15.1 導入
        15.1.1 カオスエンジニアリングに賛同しているのは誰か
        15.1.2 組織のうち、どのくらいの割合が参加するか
        15.1.3 事前に満たす必要のある条件
        15.1.4 導入にあたっての障壁
        15.1.5 洗練の度合い
    15.2 すべてをまとめる

第V部 進化

16章継続的ベリフィケーション
    16.1 CVの起源
    16.2 CVシステムのタイプ
    16.3 実世界における CV:ChAP
        16.3.1 ChAP:実験の選択
        16.3.2 ChAP:実験の実行
        16.3.3 ChAPにおける発展した原則
        16.3.4 継続的ベリフィケーションとしてのChAP
    16.4 身近なシステムにも CVがやって来る
        16.4.1 パフォーマンステスト
        16.4.2 データの成果物
        16.4.3 正確性

17章 サイバーフィジカルで行こう
    17.1 サイバーフィジカルシステムの台頭
    17.2 機能安全とカオスエンジニアリングの出会い
        17.2.1 FMEAとカオスエンジニアリング
    17.3 サイバーフィジカルシステムにおけるソフトウェア
    17.4 FMEAの一歩先にあるカオスエンジニアリングへ
    17.5 プローブ効果
        17.5.1 プローブ効果に対処する
    17.6 まとめ

18章 HOPとカオスエンジニアリングの出会い
    18.1 HOPとは何か
    18.2 HOPの基本原則
        18.2.1 原則 1:誤りは正常である
        18.2.2 原則 2:非難しても何も直らない
        18.2.3 原則 3:コンテキストが行動を左右する
        18.2.4 原則 4:学習と改善が不可欠である
        18.2.5 原則 5:意図的な対応が重要である
    18.3 HOPとカオスエンジニアリング
        18.3.1 カオスエンジニアリングとHOPの実践
    18.4 まとめ

19章 データベースにおけるカオスエンジニアリング
    19.1 なぜカオスエンジニアリングが必要なのか?
        19.1.1 堅牢性と安定性
        19.1.2 実世界での例
    19.2 カオスエンジニアリングの適用
        19.2.1 私たちのカオスの取り入れ方
        19.2.2 故障注入
        19.2.3 アプリケーションにおける故障注入
        19.2.4 CPUとメモリにおける故障注入
        19.2.5 ネットワークにおける故障注入
        19.2.6 ファイルシステムへの故障注入
    19.3 障害の検知
    19.4 カオスの自動化
        19.4.1 自動実験プラットフォーム:Schrodinger
        19.4.2 Schrodingerのワークフロー
    19.5 まとめ

20章 セキュリティカオスエンジニアリングの事例
    20.1 セキュリティへのモダンなアプローチ
        20.1.1 人間的な要素と失敗
        20.1.2 手近な標的を取り除く
        20.1.3 フィードバックループ
    20.2 セキュリティカオスエンジニアリングと現在の手法
        20.2.1 Redチームの実践の問題点
        20.2.2 Purpleチームの実践の問題点
        20.2.3 セキュリティカオスエンジニアリングから得られる恩恵
    20.3 セキュリティゲームデー
    20.4 セキュリティカオスエンジニアリングにおけるツールの例:ChaoSlingr
        20.4.1 ChaoSlingrの物語
    20.5 まとめ
    20.6 寄稿者・レビュワー

21章 おわりに

訳者あとがき
索引

Feedback

皆さんのご意見をお聞かせください。ご購入いただいた書籍やオライリー・ジャパンへのご感想やご意見、ご提案などをお聞かせください。より良い書籍づくりやサービス改良のための参考にさせていただきます。
[feedbackページへ]