無人実行に踏み切る前に決めておく権限の範囲
人が見ている状態での実行と、誰も見ていない時間帯の自動実行では、求められる安全性の水準がまったく異なります。対話的に動かしているときは、想定外の動きに気づいた時点で止められますが、無人実行ではその機会がありません。したがって、自動化する前に、その処理がどこまでの操作を許されるのかを明示的に決めておく必要があります。
権限は必要最小限から始め、運用の実績を見ながら広げるのが基本です。読み取りだけで完結する処理と、外部に変更を加える処理では、失敗したときの影響が桁違いに異なります。特に、削除や送信のように取り消しが効かない操作を含む場合は、自動実行の対象に含めるかどうかを慎重に判断すべきです。便利さを優先して範囲を広げた結果、想定外の被害が出る例は珍しくありません。
失敗を前提としたリトライと通知の設計
定期実行では、通信の一時的な不調や外部サービスの応答遅延など、自分の側に原因がない失敗が必ず発生します。一度の失敗で処理全体を諦める設計にすると、運用は不安定になります。一方で無制限に再試行すると、問題が解消しないまま負荷をかけ続けることになります。再試行の回数と間隔を決め、限度を超えたら止めて知らせる形が現実的です。
通知の設計も同じくらい重要です。すべての実行を通知すると、そのうち誰も読まなくなり、本当に危険な通知が埋もれます。逆に何も通知しなければ、静かに失敗し続けている状態に長く気づけません。正常時は記録だけにとどめ、失敗が続いたときや通常と異なる結果が出たときにだけ知らせるという方針が、注意を持続させるうえで有効です。
外部連携を含む処理でのログの残し方
自動実行の調査は、実行時の状況を再現できないという前提で行うことになります。そのため、何が起きたかを後から復元できるだけの記録が残っているかどうかが、問題解決までの時間を決定的に左右します。いつ開始し、どの手順を通り、どの外部先とやり取りし、どこで終わったのかという流れを追える粒度で記録しておく必要があります。
ただし、記録には残してはいけない情報も含まれ得ます。認証に関わる値や、個人に関わる情報をそのまま書き出してしまうと、記録自体が新たなリスクになります。何を残し、何を伏せるかの方針をあらかじめ決め、記録の保存期間も併せて定めておくべきです。調査に必要な情報量と、保持することの危険性の釣り合いを取る設計判断が求められます。
自動実行が想定外の動きをしたときの停止手段
どれだけ慎重に設計しても、想定外の挙動が起きる可能性は残ります。そのとき重要なのは、迷わず即座に止められる手段が用意されているかどうかです。設定を書き換える、認証情報を無効にする、実行そのものを止めるなど、方法は複数あり得ますが、いずれにせよ手順が事前に決まっていて、慌てた状況でも実行できることが条件になります。
加えて、止めた後に安全な状態へ戻せるかも考えておく必要があります。処理の途中で停止したときに中途半端な状態が残るのであれば、それを解消する手順も併せて用意しておくべきです。停止は最終手段ではなく、通常の運用手段の一つとして位置づけ、実際に試しておくことをお勧めします。使ったことのない緊急手順は、必要なときに機能しないものだからです。
