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 カオスエンジニアリング ―回復力のあるシステムの実践

8章Capital Oneにおけるカオスエンジニアリングの導入と進化

Raji Chockaiyan

カオスエンジニアリングは、障害を受容したうえで、それらの障害からシステムの弱点について学ぶ視点を提供します。クラウドネイティブの環境では、このようなソフトウェア開発の方法は無視できません。クラウドネイティブなシステムでは、障害はいつでも発生するものとして受け入れ、あらゆる類の障害に耐えうる堅牢なシステムのエンジニアリングと構築が必要になります。また他の制約の少ない業界と比べ、金融サービス領域のソフトウェアは、さらに考慮する必要のある複雑性のレイヤーをいくつか持っています。障害発生中に、ひとり親家庭の親が初めて家を購入するローンを申し込みに来るかもしれませんし、他の顧客は資金をモバイル機器に移行しようとしているかもしれませんし、とある学生は信用履歴の開始点となる初めてのクレジットカードを申し込もうとしているかもしれません。障害の大きさにより、ちょっとしたイライラからブランドへの愛着を損なうレベルまで幅広い結果がもたらされ、金融機関としての評判が下がった結果、事業に影響が及ぶ可能性もあります。

加えて、銀行の事業のやり方には関係する管理機関があります。必要な監査結果は、定期的に金融の監督機関へ提出しなければなりません。米国においては、OCC（Office of the Comptroller of the Currency、通貨監督庁）、CFPB（Consumer Financial Protection Bureau、消費者金融保護局）、FinCEN（Financial Crimes Enforcement Network、金融犯罪取締ネットワーク）、連邦取引委員会（Federal ...