superior-reliability

優れた信頼性

想定される障害が発生しても重要なユーザー成果を確実に保ち、例外的な障害からは復旧できるようにします。チェックリストに従ってリトライ、サーキットブレーカー、冗長性を追加するのではなく、明示的なサービス目標、実際の障害ドメイン、運用上の責任体制に基づいて信頼性に取り組みます。

信頼性の契約を定義する

対策を提案する前に、以下を明確にします。

• 重要なユーザージャーニーと、それを支えるサービスまたはコンポーネントの境界。
• 許容できる可用性、正確性、レイテンシー、鮮度、耐久性。
• トラフィックとワークロードの特性、ピーク時の条件、依存先に割り当てる予算。
• 障害ドメイン、共有依存先、状態の所有者、影響範囲。
• 実際に存在するSLI/SLO、エラーバジェット、RTO、RPO、保持期間、または契約上の目標。
• 検知、対応、エスカレーション、復旧、意思決定の各責任者。
• インシデント、テレメトリ、容量テスト、アーキテクチャ、ランブックから得られる証拠。

テンプレートに数値目標が求められているからといって、数値目標を作り出してはいけません。合意済みの目標がない場合は、暫定的なリスクに関する問いを示し、複雑な対策を設計する前に証拠を集めます。

リスクと目標に基づいて取り組みを選ぶ

サービス指標、目標、エラーバジェット、障害モード、重要な依存先、または優先順位を定義する際は、references/objectives-and-risk-model.mdを参照してください。

• 単にプロセスの稼働時間ではなく、ユーザーの成果を守ります。
• 保守不能なテレメトリを作らずに、重要なジャーニーや深刻な影響を受けるグループが把握できる程度に指標を分類します。
• 影響、発生可能性、検知可能性、復旧の難しさに基づいて障害モードに優先順位を付けます。
• 影響範囲を縮小し、単一障害点を取り除くのは、そのコストを目標が正当化する場合に限ります。
• 計画メンテナンス、依存先の障害、データの正確性、処理の遅延は、実際のプロダクト契約に従って扱います。

範囲を限定したレジリエンスを設計する

タイムアウト、リトライ、バックオフ、ジッター、冪等性、サーキットブレーカーの動作、バルクヘッド、負荷制御、キュー、フォールバック、冗長性、グレースフルデグラデーションについては、references/resilience-and-graceful-degradation.mdを参照してください。

• エンドツーエンドの期限を1つ設定し、各呼び出しに予算を割り当てます。デフォルト値を積み重ねると、ユーザーの許容範囲を超えることがあります。
• 一時的な処理のうち、安全に繰り返せるものだけを、上限を設け、復旧時のリトライが同期して集中しないよう十分なジッターを加えて再試行します。
• 過負荷時もバックプレッシャーと公平性を維持します。
• 古い結果、不完全な結果、安全でない結果を完全な成功として提示せず、任意の機能を縮退させます。
• レジリエンスの状態を観測可能にし、復旧時の動作をテストできるようにします。

インスタンスが同じ設定、認証情報、リージョン、データストア、クォータ、デプロイ経路を共有している場合、冗長性を増やしても同じ障害が再現されることがあります。レプリカ数を数えるだけでなく、独立性を検証してください。

復旧を運用可能にする

アラート、ランブック、インシデント対応、バックアップ、復元、フェイルオーバー、災害復旧、訓練、インシデント後のフォローアップについては、references/recovery-observability-and-operations.mdを参照してください。

• ユーザーへの影響、または安全余裕の枯渇に結び付いた、実際に対応可能な症状に対してアラートを発します。
• 秘密情報や機密性の高いペイロードを公開せずに、診断に必要なコンテキストを保持します。
• ジョブの成功だけに頼らず、復元と整合性チェックを通じてバックアップを検証します。
• ランブックには、前提条件、中止条件、担当者、検証方法、エスカレーション先を記載します。
• インシデントから得た教訓を、担当者が明確な是正作業に反映します。振り返りを是正措置とみなしてはいけません。

明示的な許可、限定された影響範囲、監視、そして中止手順がない限り、カオス実験、フェイルオーバー、復元、トラフィック制限、本番環境への負荷試験、または共有システムへの障害注入を実行してはいけません。

障害時の動作を検証する

障害の仕組みを維持できる範囲で、最も制限の強い安全な環境を使用します。次の点を検証してください。

• 通常時の動作が引き続き正しいこと。
• タイムアウト、リトライ、キャンセル、フォールバックの各予算が想定どおりに組み合わされること。
• 依存関係の障害が、設計された境界を越えて連鎖しないこと。
• 過負荷が一定の範囲内に収まり、重要な処理に意図した優先度が与えられること。
• 重複や破損した影響を生じさせずに復旧が完了すること。
• 適切な症状でアラートが発報し、復旧が完了すると解除されること。
• ランブックと復元手順が、実施したレベルで主張どおりの結果をもたらすこと。

使用した目標、検証した障害モード、環境と影響範囲、観測された劣化と復旧、未検証の制御、残存リスクを報告してください。設定のレビューだけを根拠に、高可用性や災害復旧を主張してはいけません。

スキルを絞って組み合わせる

• 具体的なインシデントや原因不明の障害を診断するには、superior-debugging を使用します。
• レイテンシ、スループット、飽和状態、容量の最適化で測定が中心となる場合は、superior-performance を使用します。
• パイプライン、ロールアウト、デプロイの検証、ロールバックの実行には、superior-delivery を使用します。
• 障害、復旧、並行処理、レジリエンスのテスト設計が主な課題である場合は、superior-testing を使用します。
• データストアの一貫性、レプリケーション、マイグレーション、バックアップの仕組み、データ復旧には、superior-database を使用します。
• レジリエンスに関する変更が、ドメイン状態、ワークフロー、副作用の契約に影響する場合は、superior-logic を使用します。
• SLO、ランブック、復旧、アーキテクチャ、インシデント関連の手順を長期的に参照できる形で残すには、superior-docs を使用します。

明示的なスコープと根拠がない限り、通常の実装作業をマルチリージョンアーキテクチャ、カオスエンジニアリング、オブザーバビリティプラットフォームの移行へと拡大しないでください。