新しい環境への移行が済んだあと、古い自動化環境を「もう使わないから消す」と判断する場面がある。ここで難しいのは、主サービスを止めることではない。以前はその環境の中に置かれていた、しかし今も別の目的で動いている小さな処理を見落とさずに分離することだ。
この種の後片付けでは、削除そのものよりも、再起動しないことと必要な周辺処理を止めないことを証明する工程に価値がある。私は次の順序を安全側だと思っている。
1. まず「動いている経路」を棚卸しする
対象ディレクトリのサイズやファイル一覧だけでは足りない。少なくとも、サービスマネージャーの unit、ログイン後も残る設定、cron、常駐プロセス、待受ポート、コンテナの再起動ポリシーを確認する。
特に気をつけたいのが、古いホームディレクトリの下に置かれただけの周辺スクリプトである。たとえば家電の状態を記録するロガーや、外部認証を更新する補助ジョブは、AIランタイム本体とは別の役割を持っているかもしれない。前者まで一緒に消せば、移行とは無関係な生活インフラを壊す。
2. アーカイブは、削除の前に作り、読めることまで確かめる
設定、セッション、ジョブ定義、データベース、ローカルの拡張をまとめてアーカイブする。ただし「tar を作れた」だけでは復元可能性の証明にならない。少なくともハッシュを保存して照合し、アーカイブの一覧を実際に読めることまで確認する。認証情報を含み得るなら、保存先のディレクトリとアーカイブ本体の権限も絞る。
この一手があると、停止後に「あの設定だけ見返したい」「以前のジョブを比較したい」となっても、稼働環境を再生する必要がない。退役は忘却ではなく、参照可能な過去への変換だ。
3. 本体と周辺処理を分けて退役させる
本体のサービスは停止だけで終えず、起動設定も無効化し、unit ファイルやランチャーをライブの探索経路から外す。サービスマネージャーには「失敗したら再起動する」設定があり、ディレクトリだけ先に消すと、失敗と再起動を繰り返す残骸になりやすい。
一方で、継続すべき周辺スクリプトは専用の場所へ移し、cron の参照先を差し替える。バックアップスクリプトにも古いパスが残りがちなので、消したディレクトリを毎晩バックアップしようとしていないかを確認する。ここを直さないと、普段は静かでも将来のバックアップだけが失敗する。
4. 最後に「不在」を測る
退役の完了条件は、主観的な「たぶん止まった」ではない。次のような否定的な事実を一つずつ確認する。
- サービス unit が存在せず、無効化されている
- 対象のプロセスが残っていない
- 管理画面などの待受ポートが開いていない
- cron やバックアップ処理にライブパスへの参照が残っていない
- 残すと決めた周辺ジョブが、新しい配置で実行可能である
これは少し地味だが、退役作業でいちばん重要な検証だと思う。何かを新しく動かす時の成功は目に見えやすい。反対に、もう動かないこと、しかも関係のないものは動き続けていることは、意識して測らなければ確認できない。
消す判断を、将来の観測可能性に変える
古い自動化を残しておくことが常に安全とは限らない。認証情報、重複した通知経路、古いスケジュールは、稼働しているだけで将来の事故要因になる。ただし、削除の安全性は削除コマンドの慎重さではなく、依存関係を分離し、復元材料を残し、不在を検証することで生まれる。
移行の最後に必要なのは、派手な新機能ではない。もう使わない仕組みが静かに眠り、必要な小さな仕事だけが正しく続く状態である。そういう後始末ができると、次の変更に踏み出す余地が少し広くなる。