AIや自動化を使っていると、突然これまで動いていたものが動かなくなることがあります。
そのとき、とりあえず復旧できれば安心します。
ただ、同じ問題がもう一度起きたとき、「前回どう直したっけ？」から始まると、毎回同じ調査を繰り返すことになります。
読者
YuLab
自分はAI運用でトラブルが起きたとき、復旧だけでなく、次回の調査に使える情報を残すことを重視するようになりました。
この記事の結論
異常時は「直ったか」だけでなく、発生事実・変化点・調べたこと・原因・修正方法・次回の見分け方を残します。原因を特定できない場合でも、発生履歴は次回の優先順位を決める材料になります。
正常時のログを全部残す必要はない
記録が大切だからといって、毎回すべての正常結果を細かく残すと、管理作業そのものが増えてしまいます。
自分が目指しているのは、管理のための管理を増やすことではありません。
そのため、通常どおり動いたものは必要な結果だけを残し、異常が起きたときだけ調査に使える証拠を厚く残すようにしています。
実例｜GitHub Actionsの530認証エラーを切り分けた
ConoHa WINGへの自動デプロイを作っていたとき、GitHub Actionsで530 Login authentication failedが続いたことがありました。
認証エラーだけを見ると、FTPアカウント、パスワード、GitHub Secrets、Workflow、サーバー側など、原因候補が複数あります。
そこで同じ設定を何度も実行するのではなく、順番に切り分けました。
成功している別のWorkflowを再確認する
まず、すでに動いていた別の制作物のWorkflowを再実行しました。
こちらが成功するなら、ConoHaやGitHub Actions全体が止まっている可能性を下げられます。
設定を成功例へ寄せる
Workflowの書き方やSecretsの使い方など、成功済みの構成との差を減らしました。
「怪しいところを全部変える」のではなく、正常系との差を一つずつ小さくします。
GitHub Actions以外から直接接続する
同じ認証情報を使ってローカル環境からFTPS接続できるか確認しました。
これにより、「サーバー側の大枠が悪いのか」「GitHub側の渡し方に問題があるのか」を分けやすくなります。
認証条件を見直す
最終的にはFTPパスワードの条件を変更し、GitHub Secretへ再登録することでActionsが成功しました。
重要なのはパスワードそのものを記録することではなく、どの条件変更で成功したかを残すことです。
秘密情報は記録しない
トラブル履歴へ残すのは原因や条件です。実際のパスワード、トークン、Secretの値などは記事・Sheet・ログへ保存しません。
原因を特定できないトラブルでも記録する価値がある
一方で、すべてのトラブルで原因を特定できるわけではありません。
自分の運用では、以前は定期実行の結果が想定したチャットに出ていたのに、途中から新しいチャット側へ出力されるようになったことがありました。
原因を完全に特定できなくても、
- 以前はどう動いていたか
- いつから変わったか
- 今はどう動いているか
- 何を試したか
- 何回起きているか
を残せば、次に同じ現象が起きたときの調査材料になります。
原因不明だから記録しないのではなく、原因不明という状態自体を記録するという考え方です。
異常時に残す6つの情報
トラブル記録の基本
- 何が起きたか
- 正常時と何が違ったか
- 直前に変更したものはあるか
- 何を試し、何が分かったか
- 原因と修正方法は何だったか
- 次回は何を見れば同じ問題だと判断できるか
原因が分からない場合は「原因不明」とし、無理にもっともらしい説明を作らないようにします。
同じ修正を繰り返しても、情報は増えない
トラブル時にありがちなのが、同じ処理を何度も再実行することです。
偶然直ることもありますが、失敗し続ける場合は原因候補を減らせません。
そこで、1回試すごとに「何が分かったか」が増える方法を選びます。
成功例との比較、別経路からの直接接続、権限の確認、変更履歴の比較などです。
この考え方を使うと、AIにも「別の案を出して」ではなく、次にどの仮説を切り分ければ情報が増えるかを考えてもらえます。
発生頻度も調査優先度の材料にする
原因が分からない不具合をすべて最優先で追うと、運用が止まります。
逆に、一度しか起きていない小さな問題へ長時間かけても回収できないことがあります。
そこで、
- 影響が大きいか
- 繰り返し発生しているか
- 回避策があるか
- 通常作業を止めるか
を見て、調査優先度を変えます。
発生履歴が残っていれば、「最近3回起きているから優先度を上げる」といった判断ができます。
完了条件と異常履歴を組み合わせる
前の記事で扱った「サイレント停止」では、処理が途中で止まったことに気づくために完了条件を決めました。
今回の異常履歴は、その次の段階です。
止まったことに気づく → 原因を調べる → 結果を残す → 次回の判断を速くする
という流れにすると、同じ失敗を毎回ゼロから調査する負担を減らせます。
異常対応で残すもの
- 発生事実
- 正常時との差
- 変更点と試したこと
- 原因と修正方法
- 原因不明ならその事実と発生回数
- 次回の見分け方
次は「記録した情報を、別のAIやProjectでどう使うか」
原因や判断を残しても、それを次のチャットや別Projectで毎回人間がコピペしていては負担が残ります。
そこで自分は、Google Sheetを「人が毎日見る管理表」ではなく、AIが次の作業を続けるための共通の参照基盤として使うようになりました。
シリーズの次の記事では、Project間の引き継ぎで人間を転記係にしないための考え方を整理します。
コメント