book

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

by Casey Rosenthal, Nora Jones, 堀明子, 松浦隼人

June 2022

Beginner to intermediate

316 pages

4h 29m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　　マネジメントの原則 as Code　　Chaos Monkeyの誕生　　大規模化：モンキーからコングへ　　規律の明文化　　コミュニティの誕生　　急速な進化
　　1.1　複雑性についてじっくり考える　　1.2　複雑性との遭遇　　1.3　複雑性に立ち向かう　　1.4　複雑性を受け入れる
　　2.1　動的安全モデル　　2.2　複雑性の経済的支柱　　2.3　システム的な観点
　　3.1　カオスエンジニアリングとは何か　　3.2　カオスエンジニアリングではないもの　　3.3　発展した原則　　3.4　「原則」の未来

　　4.1　カオスの組み込み　　4.2　惨劇シアター　　4.3　プロセス　　4.4　プロセスがどのようにして進化したか　　4.5　マネジメント層を味方につける　　4.6　結果　　4.7　まとめ
　　5.1　DiRTテストのありかた　　5.2　Googleにおけるテストのスコープ　　5.3　まとめ
　　6.1　なぜ、こんなにもすべてが複雑なのか？　　6.2　実験結果のカテゴリ　　6.3　障害の優先順位づけ　　6.4　変化の度合い　　6.5　大規模環境における実験のデプロイ　　6.6　まとめ
　　7.1　災害から学ぶ　　7.2　粒度別の実験　　7.3　大規模な実験を安全に行う　　7.4　実践編：リンクトアウト（LinkedOut）　　7.5　まとめ
　　8.1　Capital Oneにおける事例　　8.2　実験の設計時に留意すること　　8.3　ツール　　8.4　チーム構造　　8.5　普及に向けた活動　　8.6　まとめ
　　9.1　カオスエンジニアリングとレジリエンス　　9.2　カオスエンジニアリングサイクルとその各ステップ　　9.3　カオス実験のデザインをサポートするツール　　9.4　組織内で効果的にパートナリングする　　9.5　まとめ
　　10.1　システムの中の人間　　10.2　エンジニアリングの適応能力　　10.3　原則を実践に移す
　　11.1　なぜ、どのように、いつ実験するのか　　11.2　まとめ
　　12.1　実験の選択　　12.2　可観測性：機会　　12.3　まとめ
　　13.1　長続きしないインシデント削減の性質　　13.2　Kirkpatrickモデル　　13.3　もう1つの費用対効果の例　　13.4　副次的な費用対効果　　13.5　まとめ
　　14.1　協調的なマインドセット　　14.2　オープンな科学、オープンソース　　14.3　まとめ
　　15.1　導入　　15.2　すべてをまとめる
　　16.1　CVの起源　　16.2　CVシステムのタイプ　　16.3　実世界におけるCV：ChAP　　16.4　身近なシステムにもCVがやって来る
　　17.1　サイバーフィジカルシステムの台頭　　17.2　機能安全とカオスエンジニアリングの出会い　　17.3　サイバーフィジカルシステムにおけるソフトウェア　　17.4　FMEAの一歩先にあるカオスエンジニアリングへ　　17.5　プローブ効果　　17.6　まとめ
　　18.1　HOPとは何か　　18.2　HOPの基本原則　　18.3　HOPとカオスエンジニアリング　　18.4　まとめ
　　19.1　なぜカオスエンジニアリングが必要なのか？　　19.2　カオスエンジニアリングの適用　　19.3　障害の検知　　19.4　カオスの自動化　　19.5　まとめ
　　20.1　セキュリティへのモダンなアプローチ　　20.2　セキュリティカオスエンジニアリングと現在の手法　　20.3　セキュリティゲームデー　　20.4　セキュリティカオスエンジニアリングにおけるツールの例：ChaoSlingr　　20.5　まとめ　　20.6　寄稿者・レビュワー

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

5章Google DiRT：災害からの復旧テスト

Jason Cahoon

「希望は戦略ではない」　これは、Googleのサイトリライアビリティエンジニアリング（Site Reliability Engineering＝SRE）チームの座右の銘で、カオスエンジニアリングの基本理念を見事に具体化するものです。システムは障害を許容するようエンジニアリングされているかもしれませんが、大規模環境で目に見える形で障害の条件をテストするまでは、常に期待と現実が一致しないリスクがあります。GoogleのDiRT（Disaster Recovery Testing）プログラムは、サイトリライアビリティエンジニア（Site Reliability Engineers＝SREs）によって2006年に始められ、クリティカルな技術システムやビジネスプロセスに対して意図的に障害を引き起こし、リスクがまだ明らかにされていないものをあぶり出す目的がありました。DiRTプログラムに精通したエンジニアは、実際には緊急事態ではないときに本番環境における緊急事態を分析するとずっと容易になるという、重要な見解を打ち出しています。

災害テスト（disaster testing）は、障害に対してうまく対処できた場合にはシステムの回復力を証明し、適切に対処できたと言えない状況においては制御された方法で信頼性のリスクを露呈させることができます。制御されたインシデントの発生中に信頼性のリスクを表出させると、綿密な分析と先手をとった問題の緩和措置が行えるようになります。予期せぬ障害が発生した時のように、問題の深刻さと時間的なプレッシャーが次々と誤りを招き、不完全な情報に基づいてリスクの高い決断が迫られる状況下で問題が顕在化するのを待つことになるのとは対照的です。 ...