スコープノート
この記事の以前のバージョンでは、非常に正確な MTTF 数値と、指数関数的な信頼性の向上についての強力な主張が使用されていました。これらの数字は、正当化される基礎的な仮定よりも正確でした。信頼性モデルは有用ですが、それは独立性、検出待ち時間、修復の成功、スタンバイの準備状況に関する明示的な仮定と組み合わせた場合に限られます。
1. フォールト トレランスは役割の範囲から始まります
マルチエージェント チームは、1 つのプロセスがクラッシュしたからといって失敗することはありません。必要なロールが利用できなくなり、代わりに受け入れられるロールが時間内に引き継ぐことができない場合、この機能は失敗します。つまり、分析の主な対象はインスタンス リストではなく、ロール マップです。
したがって、チームは最初に、証拠の収集、統合、ポリシーのチェック、承認、例外処理などの役割をモデル化する必要があります。そうして初めて、どのロールにバックアップがあり、どのロールにバックアップがないのかを尋ねることができます。
2. よりシンプルな可用性モデル
計画ウィンドウ 'H' について、役割 'r' を実行できる 1 人のエージェントが必要なときに利用できない確率を 'q_r(H)' とします。 「m_r」の交換可能なエージェントがその役割をカバーでき、障害が一次近似では独立したものとして扱われる場合、「A_r(H) = 1 - q_r(H)^{m_r}」は有用な役割可用性推定値となります。
必要なロールがすべて同時に必要な場合、単純なシステム推定値は「A_system(H) およそ product_r A_r(H)」となります。これは正確ではありませんが、依存関係の構造を明示せずに正確な MTTF 値を提示するよりもはるかに正直です。
3. 冗長性によって本当に得られるもの
冗長性は 2 つの異なる方法で役立ちます。レプリカの冗長性により、同じロール内のインスタンスの障害がカバーされます。クロストレーニングの冗長性により、安全に役割を引き受けることができるエージェントのセットが拡張されます。オペレータは両方を測定する必要があります。
エージェント「a」が役割「r」を安全に引き受けることができる場合の単純なカバレッジ行列「M[a, r] = 1」は、多くの場合、単一の信頼性の見出しよりも有益です。列の合計は、各ロールが実際に持つバックアップの数を示します。行には、1 つのエージェントが多すぎる役割のバックアップとして過負荷になっているかどうかが示されます。
4. スタンバイ戦略
ホットスタンバイ
中断コストが極端で、状態の発散がゼロに近くなければならない場合に使用します。ホット スタンバイは高価ですが、理由は簡単です。
ウォームスタンバイ
秒スケールの回復が許容される場合に使用します。ウォーム スタンバイは、チェックポイントの鮮度、再生速度、フェイルオーバーの所有権がすべて設定されている場合にのみ機能します。これらがなければ、楽観的なドキュメントになってしまいます。
コールドスタンバイ
数十秒または数分の中断を許容できる機能にのみ使用してください。コールド パスは、重要なレビューや停止機能ではなく、補助タスクに役立ちます。
5. 優雅な劣化が壊れやすい完璧に勝つ
堅牢なチームは、事前に劣化モードを定義する必要があります。たとえば、バックアップ容量が再確立されている間、証拠と承認のパスを維持し、オプションのレポート生成を一時停止し、異常な例外を人間にルーティングします。
これは、システムが完全に正常であるか完全に停止しているかのように装うよりも優れていることがよくあります。重要なのは、部分的な故障でも重要な停止および確認面が無傷のままであるかどうかです。
6. リカバリプロトコルは冗長性と同じくらい重要です
リカバリを行わない冗長性は、次の停止を遅らせるだけです。チームには回復ラダーが必要です。最新の状態が信頼できる場合はチェックポイントを再開し、ローカル状態が古い場合は共有ログを再構築し、破損が疑われる場合はクリーン リスタートを実行します。
各リカバリ モードには、宣言された所有者、タイムアウト、およびフォールバックが必要です。そうしないと、フェイルオーバーは机上では高速に見えますが、実際には、最初に選択したパスに障害が発生すると停止します。
7. 社内ドリルの要点
内部障害挿入訓練では、ロール カバレッジとウォーム フェイルオーバーにより、非冗長ベースラインと比較してチーム レベルの停止を数倍削減できることが一貫して示されています。正確な上昇率は、検出の品質と最近のバックアップの実行状況によって異なります。
より信頼性の高い定性的結果は次のとおりです。チームが失敗したのは、古いバックアップ、不明瞭なフェイルオーバーの所有権、現実的な負荷の下で実行されたことのないバックアップ エージェントよりも、レプリカの不在によるものでした。
8. 設計チェックリスト
- エージェントを数える前に重要な役割をマッピングする
- 各重要な役割が実際に持つ独立したバックアップの数を追跡する
- アーキテクチャ図だけでなく、ドリルでウォーム パスとコールド パスを演習する
- 停止およびレビュー権限を維持する低下モードを定義します。
- 正確な MTTF 推定を約束ではなくシナリオの出力として扱う
結論
エージェント チームのフォールト トレランスは、役割の範囲と回復の問題として扱うのが最適です。単純な可用性モデルは計画には役立ちますが、仮定については正直である必要があります。運用目標は美しい信頼性の数値ではありません。これは、重要な権限サーフェスを維持し、予測どおりに劣化し、オペレーターがすでに実践した訓練を通じて回復するシステムです。