カオスエンジニアリング

1）基本原則

元の仮説としての定常状態。明確に規範を定義します（例： p95 <200 ms、エラー率<0。3％、重要な流れの成功>99。5%).

分離された変数。因果リンク効果と改善に一度に可能な限り1つの要因を変更します。
学位を取得しました。安全な環境での小さな振幅から始めます→カバレッジと強度を拡大します。
ガードレールだ。SLO/alert/error budgetの明示的な停止条件。
再現性。実験は決定的に再現可能でなければなりません（スクリプト/マニフェスト/IaC）。
倫理と安全。リスクの高い実験では、実際の個人データや金融取引はありません。

2）「安定状態」とは"

• キーエンドポイントのp50/p95/p99レイテンシ。
• 成功率とクリティカルパスの変換。
• エラー率、タイムアウト、「shed」リクエストの割合（飽和時に切り捨てられます）。
• 自己治癒率（MTTR）、（嵐のない）後退への抵抗。
• ドメイン不変量：「残高の短所」の欠如、一度実行された支払い、報告日の一貫性など。

3）注入のカタログ（私達が壊すもの）

ネットワーク：レイテンシ、ジッタ、損失/重複、帯域幅の制限、TLSブレーク、DNSフラップ。
計算：CPU過負荷、メモリ/GC圧力、ディスクリプタの疲労、クロックスキュー。
ストレージ：高いp95 I/O、 ENOSPC、リーダー/レプリカ障害、スプリットブレイン、長引くfsync。
依存関係：5xx/429、 「slow success」、外部APIの劣化、rate-limit。
データ：メッセージの重複/ミス、順序外れ、汚れたレコード、バージョンの競合。
操作：release/config、 featureフラグ、バグ、expired certificate、 key rotationに失敗しました。
人とプロセス：責任者の利用不能、手動更新の遅延、誤ったrunbook。

4）実験設計（テンプレート）

1.仮説： 「メインAPIの通貨サービスp 99に+300ミリ秒<450ミリ秒で、ブレーカーが開き、15分前≤古い応答が与えられます。」

2.注入：故障プロファイル（タイプ/振幅/持続時間）とターゲット輪郭。
3.メトリクス/ログタグ：marking 'chaos。experiment_id'、 'phase='recover'を注入します。
4.ガードレール：'error_rate> 2％'またはp99> SLA × 2で1分以上停止します。
5.結果/出力：オブザベーション、バグ、改善、作業計画、再実行のリスト。

5）観察可能性： 必須のもの

トレース：依存関係を介したリクエストパス；劣化したセグメントがマークされます。
リソースメトリック：CPU、 ヒープ/GC、 FD、 ディスクIOPS/lat、ネットワーク帯域幅、キュー深さ。
ビジネスメトリクス：コンバージョン/オペレーションの成功、補償された取引のシェア。
イベントログ：データベースリーダーを切り替える、開閉ブレーカ、レトレイ、予算。
実験パネル：ガードレールのしきい値と中絶「赤いボタン」を持つライブダッシュボード。

6）ガードレールとセキュリティ

技術的：エラー率/レイテンシーの上限、成功した操作のシェアの低下、DLQの成長。
組織：時間のウィンドウ、関係するオンコール、の原則「1つのゾーン-1つの実験」。
データ/コンプライアンス：合成のみまたは非人格的なキット。規制違反につながるテストを禁止します。
ロールバック：フラグ/ソフトドレイントラフィックの準備ができたロールバック/無効の手順。

7）現れるべき回復力パターン

タイムアウト予算とジッタ後退（ストームフリー）。
半開きおよび指数関数的な回復を用いる遮断器。
隔壁：臨界性プールの分離（支払いvsアナリスト）。
背圧とレート制限：予測可能な低優先カットオフ。
合体とキャッシュ、「ウォームアップ嵐」に対する保護。
補償アクションと副作用とサガのIdempotence。
データ復旧のためのクォーラム、feilover、およびアンチエントロピー。

8）サンプルシナリオ（スケッチ）

8.1遅い依存性（YAML）

yaml experiment: slow-downstream target: svc:api inject:
dependency:
name: currency mode: add_latency p95_ms: 300 duration: 10m guardrails:
error_rate: "< 1. 5%"
p99_latency: "< 450ms"
expectations:
breaker_open: true stale_data_served: "<= 15m"

8.2 DBリーダーの損失

注入：リーダーの停止/強制的な再選。
待機中：一時的な書き込み禁止、クォーラム読み取り、WAL/Outbox安全、自動復元レプリケーション、二重書き込みなし。

8.3ログディスク上のENOSPC

注入：95-100％にディスクを満たして下さい。
待機中：ログの緊急回転、重要なログの安全性、重要でない機能の無効化、アラートと自動修復。

8.4バーストトラフィック+シェーディング

注入：ホットエンドポイントで5分間3 RPSを×します。
待機中：低優先度、安定したp95「コア」、リトレイカスケードなし。

9） CI/CDのオートメーション

各リリースの段階でカオススモーク（安全な振幅で短い注射）。
毎晩、実験のカタログ（行列サービス×障害の種類）に従って実行されます。
Gates：「持続性がしきい値を下回っている」（たとえば、成功したフォールバックの割合は95％未満）場合、リリースはブロックされます。
アーティファクト：レポート、トレイル、CPU/ヒープフレームシュラップ、メトリクスと構成のスナップショット。

10）ゲームの日（ゲームの日）

• 役割：実験リーダー、メトリックオブザーバー、ロールバックオペレータ、ビジネス担当者。
• シナリオ：キャッシュの劣化、部分的なAZ/region-feiloverの失敗、「悪いリリース」、外部プロバイダの利用不能。
• 結果：runbookのギャップ、アラートの改善、SLOの調整、予算の再配分が見つかりました。

11）データ、イベント、MLの混乱

データストリーム：重複、ギャップ、オーダー外、遅延のテスト。idempotent消費者とDLQ戦略の検証。
リポジトリ：インデックスの劣化、ホットパーティション、ロックの競合、遅延下のレプリケーション。
ML：機能の遅延、ベースラインモデルへのロールバック、入力データ品質の劣化（ドリフト）-システムは「柔らかく鈍く」、落ちるべきではありません。

12）アンチパターン

観察可能性のない混乱：あなたは「盲目」であり、結論は投機的です。
ステージとガードレールなしのprodですぐに注射。
すべてに一度に「一つの大きな実験」-正確に何が働いたのかは不明です。
仮説のないHaphazardカオスアクションと修正後の再テスト。
インフラだけに焦点を当てて-ビジネス不変量は忘れられています。
人/プロセスを無視する：アラート、通話中、runbook-システムの一部。

13）実践の成熟度（モデル）

1.アドホック：局所的に単一の注射。
2.ステージカオス：シナリオのカタログ、繰り返し実行、ダッシュボード。
3.解放の混沌：各放出の煙の混乱、ゲート、レポート。
4.制限のある食べ物の混乱：低トラフィック、厳格なガードレール、準備ができてロールバック。
5.継続的な安定性：自動実験、SLO管理、作業フローとしての改善。

14）建築慣行との統合

抵抗試験：カオス実験はフォールトインジェクションと劣化シナリオを補完します。
負荷テスト：結合された負荷+失敗の実験はカスケードおよび再跡の嵐を明らかにします。
Code/RBAC/ABACとしてのポリシー：ガードレール、ロールバックステップ、制限はポリシーとして設計されています。
同意/プライバシー管理：データ処理モードに違反する実験を許可しないでください。
ジオアーキテクチャ：地域のフェイルオーバーのカオスチェックと管轄区域へのデータ結合。

15）ミニレシピ（擬似コード）

ブレーカ+劣化

if breaker. open():
return serve_stale(cache. max_age=15m)
try:
res = call(dep, timeout=250ms)
return res except Timeout:
breaker. trip()
return serve_stale()

リミッター+シェーディング

if cpu. load() > 0. 85 or queue. depth() > HIGH:
if req. priority < HIGH: return 503_SHED limiter. acquire()

Idempotent副作用

key = "payout:"+external_id if kv. exists(key): return kv. get(key)
res = side_effect()
kv. put(key, res, ttl=30d)
return res

16）建築家チェックリスト

1.定常状態とガードレールを定義？
2.スクリプトディレクトリ（ネットワーク/CPU/ストレージ/依存関係/データ/操作）はありますか？
3.観測可能性は、リソース、レイテンシの傾向、ビジネス不変性をカバーしていますか？
4.タイムアウト/リトリート/ブレーカ/リミッター/バルクヘッドが有効でパラメータ化できますか？
5.準備されたランブックと「赤いボタン」？
6.ステージと夜間の実験にカオススモークはありますか？
7.ゲームの日の「安全な」ウィンドウと役割はありますか？
8.実験は再現可能です（IaC/スクリプト）、結果はバージョン管理されていますか？
9.改善はタスクによって固定され、再テストは行われますか？
10.HTTPだけでなく、データとMLパイプラインがカバーされていますか？

おわりに

カオスエンジニアリングは「予期せぬ事件」を予測可能なシナリオに変えます。抵抗仮説、制御された注入、堅いガードレール、豊富な観察可能性および再試験の規律は解放の危険を減らし、プラットホームの信頼を高める用具である。その結果、チームはシステムの境界を理解し、失敗の状況でもエレガントに劣化してすぐにサービスをユーザーに返すことができます。