qa-resilience

QA レジリエンス

クイックリファレンス

症状	最初に確認する項目
依存先が遅い、または応答しない	デッドラインとタイムアウト予算
依存先で一時的な障害が発生している	ジッターとリトライ予算を設けた回数制限付きリトライ
依存先で障害が継続している	サーキットブレーカーとフォールバック
依存先からレート制限を受けている	Retry-After に従い、縮退時の動作を明示し、クォータに関する経路を意図的にテストする
正常なプール内で1つのホストに問題がある	外れ値検出またはエンドポイントの切り離し
キューまたはプールが飽和している	バルクヘッド、同時実行数制限、負荷遮断
容量が変化すると静的な同時実行数制限が実態に合わなくなる	静的なバックストップを備えた適応型同時実行数制限を使用し、グッドプットのプラトーを確認する — load-shedding-backpressure.md
重要度の低い機能が停止している	グレースフルデグラデーションまたは機能フラグによるフォールバック
レジリエンスの検証	カオスエンジニアリングの前に、決定論的な障害注入を行う

このスキルを使用する場面

• リトライ、デッドライン、ヘッジ、サーキットブレーカー、バルクヘッド、過負荷保護
• 縮退モードの UX や API の動作
• サービスメッシュまたはゲートウェイのレジリエンスポリシー
• カオスエンジニアリング、ゲームデー、DR 訓練、障害注入
• 正常系の負荷テストだけでなく、障害時の動作に基づくリリースゲート

別の項目を参照

• 単純な CRUD や単一プロセスのユーティリティ → 通常のエラーハンドリングで十分な場合があります
• フロントエンドのみの障害時動作 → software-frontend
• サービスの実装詳細 → software-backend
• テレメトリーの計装 → qa-observability
• より広範なプラットフォームおよびインシデント運用モデル → ops-devops-platform

---

ワークフロー

1. 重要なユーザージャーニーと、それを阻害する可能性のある依存先を特定します。
2. 依存先ごとの契約を定義します。
   • タイムアウトまたはデッドラインの予算
   • リトライの責任範囲
   • サーキットブレーカーまたは外れ値ポリシー
   • 同時実行数とキューの制限
   • 依存先が利用できない場合の縮退時の動作
3. ポリシーを適用する場所を決定します。
   • アプリケーションコード
   • クライアントライブラリ
   • メッシュまたはゲートウェイ
4. 段階的にテストします。
   • 設計レビューまたはチェッカーの出力で確認できるのは、ポリシーの整合性のみです
   • 決定論的な障害注入では、指定した制御可能な障害への応答を検証します
   • 本番環境以外での段階的なカオスエンジニアリングでは、その環境における動作の制限と復旧を検証します
   • 範囲を絞った本番カナリアまたはゲームデーで検証できるのは、ガードレールを設けたうえで観測した対象経路と時間帯のみです
5. 合格または不合格を判定するシグナルを定義します。
   • バーンレート
   • p95 または p99
   • フォールバック率
   • サーキットブレーカーの状態遷移
   • 遮断した負荷量
   • 復旧時間
6. 注入した障害、定常状態についての仮説、影響範囲の上限、中止条件、観測時間、復旧結果、および実際の観測ではなくシミュレーションした依存先を記録します。

---

選択的な検証とハザード分析

• 復旧／フェイルオーバープロトコルが同時に発生する障害下で不変条件を維持するかどうかを問う場合、または反例が必要な場合は、形式手法を使用します。性質、初期状態、遷移／環境の前提、検証した上限、結果／トレース、およびモデルとコードの限界を提示します。有限状態での不変条件チェックでは、活性や復旧時間は確認できません。通常のタイムアウト／再試行の設定や、挙動を直接観測できる名前付き障害テストには使用しません。
• 再試行、ロールバック、フェイルオーバー、オペレーター、その他の機能する制御が相互に作用して、金銭的影響の重複や破壊的な復旧など、明確に定めた許容できない損失を引き起こす可能性がある場合は、安全工学を使用します。損失 → ハザード → 安全でない制御アクションとそのコンテキスト → 制約 → 担当者 → 検証エビデンスを、残る不明点も含めて提示します。有害な相互作用に関する問いを伴わない、通常の可用性やレイテンシの調整には使用しません。稼働時間やハザード図だけでは安全性を証明できません。

レジリエンスポリシー、障害注入の実行、復旧エビデンス、リリースの推奨事項はこのスキルで扱い、基礎知識は明示した不足を補う場合にのみ使用します。

パターンルール

• 再試行は単一のレイヤーでのみ行います
• 再試行の前に期限を設定します
• ヘッジングは、冪等またはキャンセルセーフな読み取りに限ります
• 過負荷への対処では、後から破綻させるのではなく、早い段階で負荷を切り捨てる必要があります
• 過負荷テストは、「503が発生した」ことではなく、容量を超えてもグッドプットが頭打ちになることで合格とします。切り捨て応答は、Retry-Afterに従い、予算内で、再試行を担当するレイヤーでのみ再試行します
• 規制対象の企業（EU DORA、UK FCA/PRAのオペレーショナルレジリエンス）では、重要な各ビジネスサービスをインパクト許容度に照らしてテストし、サードパーティも含めます。スコープの決定は法務担当者が担います。詳しくはdisaster-recovery-testing.mdを参照してください
• ReadinessとLivenessは、上限があり、浅い状態を維持する必要があります
• レジリエンスの挙動は対象を絞ったチェックに含めます。レート制限や縮退モードのテストが、無関係な正常系スイートに漏れないようにします
• 本番環境での実験には、影響範囲の制限、中止基準、ダッシュボード、担当者が必要です

検証する障害モード

• タイムアウトと期限の伝播
• 再試行ストームと副作用の重複
• 依存先の部分的な停止
• 下流サービスの遅延とロングテールレイテンシ
• キューの蓄積と接続プールの枯渇
• プール内の単一の不良ホストの挙動
• 縮退モードの応答と古いデータへのフォールバック
• レート制限への対処、Retry-After、クライアントのバックオフに関する想定
• 復旧後またはバックエンドのリセット後における、ユーザーから見える状態の収束
• フェイルオーバーとフェイルバックの挙動
• 準安定障害：元の引き金が解消した後も自己解消しない自己持続型フィードバックループ（再試行の増幅、キャッシュミスの集中、キューの滞留、接続プールの頻繁な変動）。詳しくはreferences/cascading-failure-prevention.mdを参照してください

---

テストの段階

まずは決定論的テスト

• 制御されたテストで、レイテンシ、エラー、タイムアウト、不正なペイロード、利用できないエンドポイントを注入します
• 意図した制御が作動し、誤った制御は作動しないことを確認します

次にカオステスト

• 非本番環境から始めます
• 影響範囲を小さくし、時間枠を固定します
• エラーバジェットまたは顧客への影響が基準を超えた場合は、直ちに停止します

最後にDRとゲームデイ

• RTOとRPOの主張を明示的に検証します
• 技術的なフェイルオーバーだけでなく、復旧の責任分担もリハーサルします

---

運用上のガードレール

• すべての実験で、仮説と定常状態の指標を明示する必要があります
• すべての実行で、タイムスタンプ、対象、影響範囲、ダッシュボードへのリンクを記録する必要があります
• 再試行、ブレーカーの遷移、ヘッジング、負荷の切り捨て、フォールバックのテレメトリーフィールドは、レジリエンス契約の一部です
• リリースは、リソース使用量だけでなく、信頼性に関する挙動を条件にしてゲートする必要があります

アンチパターン

• タイムアウトがない
• すべてのホップでリトライする
• 固定間隔または無制限のリトライ
• システム全体のリトライ予算がない固定の呼び出しごとのリトライ回数（エラー率が上昇しても引き締められない）
• 冪等性のないリトライ
• 安全でない書き込みのヘッジ
• バルクヘッドやキューの上限がない
• 深すぎるレディネスチェックまたはライブネスチェック
• 劣化モードが通知されない
• フェイルオーバー計画がテストされていない
• ハッピーパスのみの負荷テスト

---

スクリプト

スクリプト	目的
scripts/resilience_checker.py	宣言されたパターンの適用範囲を採点して不足を報告します。不正な申告は拒否します

一般的な使用方法：

python scripts/resilience_checker.py assess --input data/sample-service-profile.json
python scripts/resilience_checker.py gaps --input data/sample-service-profile.json
python scripts/resilience_checker.py report --input data/sample-service-profile.json --output resilience-report.md

実際の JSON ブール値と、ヘッジングを適用しない場合の明示的な根拠を指定してください。ヒューリスティックによるスコアは宣言された適用範囲を示すものであり、障害時の動作や復旧を立証するものではありません。入力形式と採点ロジックについては、scripts/README.md を参照してください。

ASCII フロー

Resilience request
  -> Identify failure mode: slow, transient, sustained, overloaded, or degraded
  -> Set deadlines, retry budgets, isolation, and fallback ownership
  -> Add telemetry for saturation, errors, latency, and degraded behavior
  -> Validate with deterministic fault injection before chaos experiments
  -> Gate release on recovery evidence, SLO impact, and rollback path
  -> Document runbook actions and residual risk

ナビゲーション

基盤の適用レシピ

• references/reliability-theory-applied.md
• references/distributed-systems-applied.md

コアリファレンス

• references/circuit-breaker-patterns.md
• references/retry-patterns.md
• references/timeout-policies.md
• references/deadlines-hedging.md
• references/bulkhead-isolation.md
• references/load-shedding-backpressure.md
• references/gateway-mesh-resilience.md
• references/graceful-degradation.md
• references/health-check-patterns.md
• references/cascading-failure-prevention.md
• references/disaster-recovery-testing.md

運用リソース

• references/resilience-checklists.md
• references/chaos-engineering-guide.md
• references/chaos-tooling-recipes.md
• references/idempotency-key-design.md
• references/resilience-telemetry.md
• references/slo-as-code.md
• references/ai-llm-resilience-failure-modes.md
• assets/runbooks/resilience-runbook-template.md
• assets/testing/fault-injection-playbook.md
• assets/testing/template-resilience-test-plan.md
• data/sample-service-profile.json

関連スキル

• ops-devops-platform
• software-backend
• software-architecture-design
• qa-observability
• qa-debugging
• software-security-appsec
• data-sql-optimization
• dev-api-design

学びのループ

過去の決定や落とし穴が関係する場合は、learnings.consolidated.md があれば参照してください。必要な履歴を確認する場合、または利用可能な代替としてのみ、learnings.md を使用してください。それ以外の場合は、どちらも参照しないでください。

適用後、記憶しておく価値のあるパターン、防止すべきミス、または意外だった分野の事実に遭遇した場合は、agents-skills-feedback-loop/scripts/append_learning.py を使用して、日付入りの箇条書きを learnings.md に1件追記してください。SKILL.md 自体は変更しないでください。