【ITニュース解説】My Auto-Remediation Bot Fixed the Wrong Service. Here's What That Taught Me About Real SRE.

あるITエンジニアが、システム障害発生時に自動で問題を検知し、適切な判断を下し、自律的に修復を行い、その後の記録まで残す「自動修復ボット」の開発に挑戦した話である。このボットは人間の介入なしに一連のプロセスを完結させることを目指していた。しかし、実際にシステムに障害を発生させてテストを行ったところ、想定外の事態が次々と発生し、そこから彼はSRE（Site Reliability Engineering、システムを信頼性高く運用するための技術と文化）の本質的な教訓を得た。

まず筆者は、ポートフォリオとしてシンプルなeコマースシステムを構築した。これは「注文」→「在庫」→「通知」という依存関係を持つ三つのマイクロサービスで構成され、Kubernetes上で動作する。さらに、信頼性の高いシステム運用に必須とされるPrometheusとGrafanaによる監視、SLO（サービスレベル目標）とエラーバジェットの設定、Chaos Meshによる意図的な障害注入といったSREの要素を組み込んだ。そして、システムが故障した際に自動で対応するPython製のコントローラーが、最も野心的な部分であった。このコントローラーは「検知 → 判断 → 行動 → 学習」という一連のサイクルを完全に自動化することを目指したのである。彼はすべてのテストを「Game Day」と名付け、事前に仮説を立て、実際に実行し、何がうまくいかなかったかを正直に記録していった。

インフラ構築が完了し、いよいよ自動修復コントローラーを実際の障害に対してテストする「Game Day 005」が実施された。目標は、在庫サービスに障害を発生させ、アラートマネージャーがアラートを発報し、コントローラーが自律的に対応する様子を観察することだった。しかし、このテストで三つの深刻な問題が明らかになった。

一つ目の問題は、アラートがコントローラーにまったく届かなかったことである。アラートマネージャーやPrometheusは正しく設定され、アラートも発報されていたが、コントローラーが反応しなかった。調査の結果、Prometheus Operatorがすべてのアラートルートに自動でnamespaceフィルターを注入しており、筆者のアラートルールにはそのラベルが欠けていたため、アラートがどこにも到達せずに消えていたことが判明した。ログにもエラーは表示されず、発見が非常に困難な問題であった。欠けていたラベルを追加することでこの問題は解決した。

二つ目の問題は、コントローラーが誤ったサービスを修復しようとしたことである。アラートのルーティングが修正され、アラートはコントローラーに届いた。しかし、コントローラーはアラートを発報した「注文サービス」だけを見てしまい、根本原因が依存関係にある「在庫サービス」にあることを理解していなかった。結果として、コントローラーは完全に正常な注文サービスを再起動し、実際の障害を引き起こしている在庫サービスには何も手出ししなかったのである。これは、システムの依存関係を考慮せずにアラート元だけを見て対処することの危険性を示した。

三つ目の問題は、システムが何も修復されていないにもかかわらず「回復した」と誤って報告したことである。驚くべきことに、コントローラーは48秒で回復を宣言した。原因は、修復アクション直後でPrometheusの監視データがまだ取得されていない場合（これはデータ収集間隔を考慮すると通常の状況である）、コードがKubernetes APIでPodが「Ready」状態であることだけを確認して成功と判断していたためである。Podが起動している「Ready」状態と、サービスが健全に機能している「Healthy」状態とはまったく異なる概念であり、この違いをシステムが認識していなかったことが問題であった。

これら三つのバグは、穏やかな合成テストでは決して見つからず、実際の障害条件でテストを行ったからこそ明らかになったのである。

「Game Day 006」では、これらの問題を修正し、その修正が機能することを検証した。特に興味深かったのは、クロスサービス診断の問題の修正である。これは単なるバグ修正ではなく、設計上の意思決定を伴うものであった。筆者は三つのアプローチを検討した。一つはコードに静的な依存マップを組み込む方法、二つ目はサービス間の呼び出しを計測して実際に障害を起こしている下流サービスを特定する証拠ベースの方法、三つ目はnamespace内のすべてのPodを広範囲に調べる方法である。筆者は、サービス数が三つと少ない現状では、トポロジーが既知でシンプルであるため、静的な依存マップを選択した。これはコードを読めばコントローラーの知識範囲が明確にわかり、監査しやすいという利点があった。サービスグラフが拡大すれば証拠ベースのアプローチが適切だが、現段階では不要な複雑性を避けたのである。

また、コントローラーのデフォルトの動作も変更した。以前は明確な信号が得られない場合に、盲目的にDeployment全体を再起動するフォールバックがあったが、これを除去した。今後は、アラートを発報したサービスもその依存サービスも問題を示す信号がない場合、コントローラーは何も行動せず、イベントをログに記録し、人間の介入を待つように変更した。「わからない」と認めるシステムの方が、推測で行動するシステムよりも信頼できるという判断であった。

回復確認についても、常にPrometheusからの実際のデータが必要となるように厳格化した。データがまだないからといって「成功」と見なすことはなく、「確認を続ける」という動作になった。

この修正版をテストする前に、筆者は実際のカオス注入ではなく、アラートマネージャーが送信するペイロードをシミュレートする合成アラートで論理を検証した。これにより、診断が正しいサービスをターゲットにしていることを確認できた。その上で、以前よりも短い時間で実際のテストを再実行した。結果として、コントローラーは、アラートが注文サービスから発報されたにもかかわらず、在庫サービスが根本原因であることを正しく特定し、修復に成功した。

しかし、このテストで新たな、正直な、そしてまだ未解決の限界も明らかになった。筆者が設定したカオスエンジニアリングは、15秒ごとに新しいPodを繰り返し停止させていた。コントローラーが特定したPodを再起動しようとする間に、Chaos MeshがそのPodを再び停止させてしまうケースがあったのである。これは404エラーとして適切に処理され、システムがクラッシュすることはなかったが、反応的なPodごとの修復では、コントローラーの反応ループよりも速く再生成される根本原因には追いつけないことを示していた。筆者はこの点を既知の制限として記録し、隠蔽することなく公開した。

プロジェクトの最後の段階は、「Game Day 007」である学習ループの完成、つまり自動化された事後分析レポートの生成機能であった。コントローラーが処理したすべてのインシデントは、Prometheusデータで強化され、永続的に保存される実際のレポートに変換されるべきと考えたのである。実際のカオスを用いた検証テストでは、アラートの発報、クロスサービス診断、そして自動生成された事後分析レポートのすべてが期待通りに機能した。レポートには実際の稼働率曲線、アラートがトリガーされた正確な燃焼率、そして「Game Day 006」で発生した404エラーまでがインシデントの記述として記録されていた。

しかし、生成された数字を注意深く確認したところ、筆者はさらなる問題を発見した。確認済みと未確認の回復をカウントするメトリクスの合計が合わなかったのである。四つのインシデントのうち二つ、特に修復アクション自体がエラーになったインシデントは、そのメトリクスでは「見えない」状態だった。これは、コードが「確認済み」と「未確認」の二つのカテゴリしか持っておらず、「アクション自体が失敗した」という状況がどちらにも分類されなかったためである。この小さな不整合は、「エラーなしで実行された」という前提を疑い、手動で数字を確認したからこそ発見できたものであった。

この一連の経験から、彼は重要な教訓を得た。一つ目は、実際の障害に対してテストすることはオプションではなく、システムの信頼性を確認する上で不可欠であるという点である。これらすべてのバグは、完璧に振る舞う合成テストでは見過ごされていただろう。問題が表面化したのは、協調しない現実的な条件をシミュレートしたからこそである。二つ目は、決して失敗しなかったシステムは、まだ十分にテストされていないということである。カオスエンジニアリングが期待通りの結果しか示さないのであれば、それは自身の仮説を検証しているだけであり、システムの本当の脆さを発見しているわけではない。三つ目は、何がうまくいかなかったかを記録することの方が、何がうまくいったかを記録するよりも価値があるという点である。成功例だけを記したドキュメントは、物語の半分しか伝えない。期待した結果と実際に起こったこと、その理由、そしてどのような変更を加えたかを記した「Game Day」の記録こそが、真のエンジニアリング能力を証明する。最後に、すべての限界を直ちに修正する必要はないということである。Podの削除と持続的なカオス注入との間の競合のように、まだ解決されていない問題も存在する。しかし、限界を認識し、その原因を理解し、現時点での優先順位ではないと意識的に判断することも、成熟したエンジニアリングの意思決定である。