安定性試験

1）基本的な概念と目標

信頼性-パフォーマンスの確率。回復力-失敗の間と後の行動。
SLO/誤った予算：劣化「受諾可能性」基準。
定常仮説：安定したメトリクスの形式的な期待（例：p95 <200ms、エラー率<0。5%).この実験は、仮説が持続していれば成功したと考えられている。
障害の種類：ネットワーク（遅延、損失/重複、破損）、計算（CPU、メモリ）、ストレージ（I/O、ディスク枯渇）、依存関係（5xx、タイムアウト、レート制限）、論理（部分インシデント、遅い劣化）、運用（リリース、構成）、ダーク（分割）-脳、時間のシフト）。

2）サステナビリティのピラミッド

1.ロジック障害（リトレイ、idempotency、タイムアウト）のユニットテスト。

2.フォールトインジェクト付きコンポーネントアダプタ（Testcontainers/tc-netem）

3.ネットワーク/データベース/キャッシュとリアルワールドプロファイルとの統合/システム。
4.runbooksのpre-prod（そしてprod）でのカオス実験。
5.ゲームの日-チームのシナリオ演習（人々+ツール）。

3）基礎としての観測性

SLI： p50/p95/p99レイテンシ、エラーレート、彩度（CPU/ヒープ/FD/IOPS）、ドロップ/タイムアウト、キューの深さ。
トレース：失敗時のボトルネックを見つける。
セマンティックレジリエンスメトリクス：graceful-degrade success rate、 shed request rate、 self-healing rate （MTTR）。
ラベリング実験：'カオス。experiment_id'、 'phase=inject/recover'がイベント/ログに表示されます。

4）欠陥の注入のカタログ

ネットワーク：遅延/ジッタ、損失/重複/並べ替え、帯域幅の制限、バーストの嵐、TLSの破断。
ホスト：CPUの制限、メモリリーク/制限、GCの一時停止、ディスクリプタの枯渇、「クロックスキュー」。
ストレージ：レイテンシの増加、EROFS、 ENOSPC、レプリカの劣化、リーダーの損失。
依存関係：5xx/429、スローダウン、DNSフラッピング、古い証明書、レート制限、「部分的な応答」。
データ：ストリームに破損、「穴」を書き込む、イベントの重複、バージョンの競合。
操作：リリース、フィーチャーフラグ、設定ドリフト、手動エラー（シミュレーションの一部として）に失敗しました。

5）安定性パターン（何を点検するか）

各RPCのジッタのリトレースとタイムアウト。
遮断器（開始/半開き、指数関数的回復）。
隔壁（クリティカルドメインへのプール/キューの分離）。
Load Shedding（飽和時に優先度の低いリクエストをリセット）。
Backpressure（チェーン、並行限界の信号）。
Idempotency（「副作用」のidempotencyキー）。
ソースが劣化した場合のキャッシュとスタック。
Graceful Degradation（軽量応答、古いデータ、機能の無効化）。
タイムアウトの予算。
Atomicity/compensation （佐賀/Outbox/Transactional Inbox）。
クォーラムとレプリケーション（R/Wクォーラム、可用性のための一貫性の低下）。
アンチエントロピー/リプレイ（イベントホールからの回復）。

6）注射と期待のための処方箋（擬似コード）

ジッタとブレーカでリトレイ

for attempt in 1..N:
if breaker. open(): return fallback()
res = call(dep, timeout = base 0. 8)
if res. ok: return res sleep(exp_backoff(attempt) jitter(0. 5..1. 5))
if attempt == N: breaker. trip()
return fallback()

シェーディングとバックプレッシャー

if queue. depth() > HIGH          cpu. load() > 0. 85:
if request. priority < HIGH: return 503_SHED limiter. acquire () # constrain concurrency

Idempotency

key = hash("payout:"+external_id)
if store. exists(key): return store. get(key)
result = do_side_effect()
store. put(key, result, ttl=30d)
return result

7）実験： シナリオと仮説

7.1「依存性が遅い」

注入：+400外部APIへのms p95。
待機中：タイムアウトの増加≤ X％、ブレーカの開閉、フォールバック応答、保存p99サービス<SLA、レトレイ中にカスケードなし。

7.2「部分的なキャッシュ損失」

注入：Redis/Cacheシャードノードの50％の障害。
待機中：ミスが増加しましたが、ソースへの雪崩がなく（要求合体/不変TTL）、自動ウォームアップと回復。

7.3「データベース内のスプリットブレイン」

注入：リーダーの損失、レプリカに切り替えます。
待機中：レコードの短期的な拒否、クォーラムからの読み取り、データの損失なし、Outboxはメッセージを失いません。

7.4 「ENOSPC/ディスク・フル」

注入：95-100％ディスク。
待機中：ログの緊急回転、ノンブロッキング機能の障害、重要なログの安全性（WAL）、アラートとオートリキッド。

7.5「トラフィックバースト」

注入：ホットエンドポイントへの3つのRPSの× 10分。
期待：優先度の低いシェーディング、「核」パスの安定したp95、限界内のキューの成長、DLQ嵐はありません。

7.6「時計のスキュー」

注入：ノード時間を+/− 2分ずらします。
待機中：正しいTTL/署名（余裕）、リトレイの単調なタイマー、許容可能なドリフト付きの有効なトークン。

8）実験の環境と安全性

プリプロッド、合成データ、configs/topologyをできるだけ製品に近づけることから始めてください。
販売-制御されたウィンドウのみ、フィーチャーフラグ、ステップバイステップの振幅、自動ロールバック、「赤いボタン」。
ガードレール：RPS/バグ制限、SLOガード、クリティカルインシデント中のリリースをブロックします。
ランブックが必要です：ロールバックする方法、誰を呼び出すか、どこを見るか。

9）オートメーションおよびCI/CD

コードとしての実験のカタログ（YAML/DSL）：目標、注入、メトリック、しきい値、ロールバック「ボタン」。
各リリースの煙カオス：短い注射（例：ステージで2分+200ミリ秒から中毒）。

マトリックスナイトラン-サービス×故障モード

リリースゲート：安定性がしきい値を下回っている場合のデプロイの禁止（たとえば「、遅い依存性」の下の「フォールバックカバレッジ<95％」）。

10）データと一貫性

補償の確認（佐賀）：部分的に実行された操作は、合意された状態にしなければなりません。
リプレイ/イベントの重複、オーダー外の配信、穴とリプレイをテストします。
失敗後のドメイン不変量を確認する：残高が負ではない、トランザクションが動かない、制限が違反されない。

11）アンチパターン

happy-pathのみをテストし、失敗なくロードします。
ジッタのないレトライ→劣化した嵐。
グローバルタイムアウトの予算がない→カスケードタイムアウト。
すべてのタスクのための単一のプール→隔離なし（隔壁）。
「無限」キュー→レイテンシー/PDEの増加。
実験のゼロ・テレメトリー→「盲目」カオスの実践。
ロールバック/制限/責任ある所有者なしで販売中の混乱。

12）建築家のチェックリスト

1.定常仮説とSLOが定義されていますか？
2.各RPCにタイムアウト、ジッターリトリート、ブレーカーがありますか？
3.隔壁、リミッター、背圧、負荷分散を実装しましたか？
4.キャッシュステディ：合体、キャッシュストーム保護、ウォームアップ？
5.副作用のためのOutbox/Saga、 idempotentキー？
6.Quorums/replication/feiloverテスト済みですか？
7.CI/CDに実験、夜間の混乱、ゲートのカタログはありますか？
8.メトリクス/トレースマーク実験、ダッシュボードはありますか？
9.「Runbook」と「red button」の準備はできましたか？
10.Dev/SRE/Supportを搭載した通常のゲーム日？

13）ミニツールとサンプルシナリオ（YAMLスケッチ）

ネットワーク（tc/netem）

yaml experiment: add-latency target: svc:payments inject:
netem:
delay_ms: 300 jitter_ms: 50 loss: 2%
duration: 10m guardrails:
error_rate: "< 1%"
p95_latency: "< 400ms"

CPU/ヒープ

yaml inject:
cpu_burn: { cores: 2, duration: 5m }
heap_fill: { mb: 512 }

依存関係

yaml inject:
dependency:
name: currency-api mode: slow p95_add_ms: 500 fallback_expectation: "serve stale rates ≤ 15m old"

結論

レジリエンス試験は「カオス・トリック」ではなく、システムを不具合の下で予測可能にする規律です。明確な仮説、テレメトリー、制御された実験のカタログとアーキテクチャに埋め込まれたパターン（タイムアウト、ブレーカ、分離、アイデンポテンス）は、潜在的なインシデントを制御されたシナリオに変えます。チームはリリースに自信を持ち、失敗した状況でも安定したサービスを提供します。