Self-healingの安全な範囲を定める

既知の状態から復旧する

Self-healingは、定義された障害を自動的に検出し、承認された復旧操作を試みます。停止したプロセスの再起動や、正常でないインスタンスの置き換えが例です。操作は、障害とサービスの状態モデルに適合する必要があります。

Kubernetesは、障害が起きたワークロードのインスタンスを置き換え、宣言された状態に実際の状態を合わせることができます。ただし、アプリケーションの誤ったロジックや、あらゆるストレージ障害を修正するわけではありません。インフラの復旧とソフトウェアの正しさには、別々の確認が必要です。Kubernetesのself-healing。

仕組みを選ぶ前に、目標を定義します。エクスポートの復旧とは、対象の処理が正しく完了することです。コンテナーの稼働は、前提条件の一つにすぎません。

三種類の変更を区別する

復旧後に、エージェントが修正を提案する場合があります。その提案は、新しいソフトウェア変更です。復旧コントローラーから無制限の権限を引き継いではいけません。

確認に失敗したとき、コントローラーが自分の成功基準を書き換えることも禁止します。そうしないと、サービスを改善せずに、改善したと報告できてしまいます。

有効にする前に復旧ポリシーを書く

以下のポリシーは架空のものです。数値は設計上の選択を示す例であり、推奨するデフォルト値ではありません。

最小権限のIDを使います。ポリシーのバージョン、トリガーの証拠、操作、リソース、結果をログに記録します。コントローラーを無効にする独立した手段を用意します。エスカレーションを受ける人間の責任者を定めます。

復旧の成功だけでなく失敗経路もテストする

再試行によって、副作用を繰り返すことがあります。ワーカーがファイルを保存した後、ジョブの完了を通知する前に停止するかもしれません。再実行を許可する前に、冪等性を検証してください。Cloud nativeの障害例を参照してください。

再試行は、過負荷の依存先にさらに負荷をかけることもあります。試行回数の上限、タイムアウト、適切なバックオフを使います。すべてのインスタンスが同時に再試行することを避けます。AWSは、バックオフとjitterが、この負荷の増幅を抑える理由を説明しています。再試行のガイダンス。

架空のポリシーを、三つのケースでテストしてください。ワーカーが一つ停止した場合は、復旧する必要があります。データベースが停止した場合は、置き換えの繰り返しを防ぐ必要があります。完全性の障害が疑われる場合は、自動化を停止し、対応の判断を求める必要があります。

テレメトリの欠落も確認します。Heartbeatがない理由は、ワーカーの障害かもしれませんし、収集経路の障害かもしれません。コントローラーには、AIの説明に対する自信ではなく、その操作を正当化できる十分な証拠が必要です。

ポリシーが役立つかを測定する

検証済みの復旧、失敗した試行、エスカレーション、重複した処理、ユーザーへの影響が続いた時間を記録します。似た条件で、以前の運用方法と比較します。

根本にある不具合は、エンジニアリングの作業として残します。メモリリークのあるプロセスを繰り返し再起動すれば、直近の影響を減らせても、リーク自体は続きます。Self-improvementに進み、観測したことを恒久的な修正につなげてください。