サーバーリプレースの当日。
やることは頭に入っているつもりでも、いざ始まると「次は何だったか」と手が止まる瞬間があります。
正直に告白します。私も若いころ、深夜作業の途中で手順が飛んで、先輩に確認しながら進めたことがありました。準備したつもりでも、緊張と眠気の中では、当たり前のことが抜けます。
だから今は、当日の作業を時系列で書き出しておくようにしています。
今回は、リプレース当日の作業項目を、前日準備から切り替え後の確認まで順番に解説します。案件によって細部は変わりますが、骨格はほぼ共通です。
リプレース全体の進め方はサーバーのリプレース作業で失敗しないための進め方に、計画書の書き方はサーバーリプレース計画書の書き方にまとめています。
当日の作業は、5つのフェーズに分かれる
まず全体像です。リプレース当日は、この5フェーズで進みます。
- 前日までの準備
- 作業開始前の確認
- 停止・移行作業
- 起動・確認作業
- 切り替え後のフォロー
多くの人が意識するのは3と4だけですが、事故が起きるのは1と2の準備不足が原因であることがほとんどです。そして、評価が決まるのは5です。
以下、フェーズごとに作業項目を見ていきます。
フェーズ①：前日までの準備
当日の成否は、ここでほぼ決まります。
確認・準備する項目
- 作業手順書の最終確認（関係者全員が同じ版を持っているか）
- 新環境の構築完了確認
- 事前テストの完了確認
- バックアップ取得（当日とは別に、前日時点のものを確保）
- 必要なアカウント・権限の確認（当日ログインできない、が一番怖い）
- 必要なファイル・スクリプトの配置
- 作業端末の準備（VPN接続確認、必要ツールのインストール）
- 連絡先リストの最終確認（顧客、ベンダー、社内）
- 利用者への停止告知が完了しているか
- 当日の集合時間・場所・体制の確認
**特に見落とされやすいのが「権限の確認」**です。
普段は使わない管理者権限が必要になる場面で、当日になって「ログインできない」となると、そこで作業が止まります。前日に必ず、実際にログインして確認してください。
そして、前日時点のバックアップは別途確保しておきます。当日のバックアップが失敗する可能性もあるからです。
フェーズ②：作業開始前の確認
作業開始の直前、5〜10分でいいので、この確認をやります。
確認項目
- 参加者全員が揃っているか
- 各自の役割と担当作業の再確認
- 連絡手段の確認（電話がつながるか、チャットに全員いるか）
- 中止・延期の判断（この時点で問題があれば、始めない）
- 判定ポイントの時刻を全員で共有
- 切り戻しの判断者を確認
「始めない」という選択肢を、この時点で持っておくのが重要です。
体制が揃っていない、事前確認が終わっていない、顧客側の準備ができていない——こういう状態で始めると、途中で止まります。始めてしまうと引き返しにくくなるので、始める前が最後の判断機会です。
フェーズ③：停止・移行作業
ここからが本番です。
作業項目
- 利用者への停止アナウンス（最終）
- アプリケーション・サービスの停止
- 停止したことの確認（プロセス、接続数、ログ）
- 現行環境のバックアップ取得
- バックアップの取得完了確認（サイズ、エラーの有無）
- データのエクスポート
- データの転送
- データのインポート
- データ整合性の確認（件数、サイズ、チェックサム）
- 設定ファイルの移行
- IPアドレス・DNSの切り替え
「停止したことの確認」を飛ばさないでください。
停止コマンドを打っただけで次に進むと、実はプロセスが生きていて、移行中にデータが更新されるということが起こります。プロセス一覧、接続数、ログ——複数の観点で止まったことを確認します。
データ整合性の確認も必須です。件数だけでなく、可能ならチェックサムまで見ます。移行が「終わった」ことと「正しく終わった」ことは別です。
フェーズ④：起動・確認作業
新環境を立ち上げて、動作を確認します。
作業項目
- サービス・アプリケーションの起動
- 起動ログの確認（エラーが出ていないか）
- 基本動作確認（ログイン、画面表示、主要機能）
- 連携先との疎通確認（双方向）
- 監視の動作確認（アラートが飛ぶか、監視画面に出ているか）
- バッチ・スケジュールタスクの設定確認
- ログ出力の確認
- 顧客側での動作確認（可能であれば）
- 判定会議：継続か切り戻しか
監視の確認を必ず入れてください。 移行後に監視が止まっていて、障害に気づけなかった——これは実際によくある事故です。
そして最後の判定会議。ここで「継続」と決めたら、もう戻れないという前提で判断します。曖昧なまま進めると、翌日以降に問題が発覚したときに対処が難しくなります。
具体的なテスト項目はサーバーリプレースのテスト項目一覧にまとめているので、確認の抜けが気になる方はそちらも見てみてください。
フェーズ⑤：切り替え後のフォロー
作業が終わっても、まだ終わりではありません。
当日中にやること
- 顧客への完了報告
- 利用者への再開連絡
- 作業記録の整理（実施時刻、発生事象、対応内容）
- 旧環境の扱いの確認（すぐ止めるか、しばらく残すか）
翌営業日にやること
- 業務開始後の稼働確認
- 利用者からの問い合わせ対応体制の確保
- 夜間バッチの実行結果確認
その後1週間〜1ヶ月
- 定期バッチの初回実行確認（週次、月次）
- リソース使用状況の確認
- 旧環境の停止・撤去
特に月次バッチの初回実行は要注意です。移行の翌月まで、リプレースは完全には終わっていません。カレンダーに印を付けておいて、必ず確認します。
抜けやすい作業項目5つ
ここまでの中から、特に抜けやすいものを挙げておきます。
1. 権限・アカウントの事前確認
当日ログインできないと、そこで詰みます。前日に実際にログインして確認。
2. 停止したことの確認
コマンドを打っただけで進まない。プロセスと接続を見る。
3. 監視の動作確認
移行後に監視が死んでいるのが一番怖い。
4. 連携先との双方向疎通
こちらから送れても、向こうから来ないケースがある。
5. 月次バッチの初回実行確認
翌月まで気を抜かない。カレンダーに印を。
当日、判断に迷ったときの基準
最後に、現場での判断基準を書いておきます。
1. 予定時刻を過ぎたら、まず状況を共有する
黙って作業を続けないこと。遅れているという事実を、その時点で関係者に伝えます。「あと少しで終わるから」と黙って続けて、結果的に大幅超過するのが最悪のパターンです。
2. 想定外のことが起きたら、一度手を止める
慌てて対処すると、状況を悪化させます。手を止めて、何が起きているかを確認してから動く。深夜の判断は、日中より確実に鈍っています。
3. 迷ったら、切り戻す
「たぶん大丈夫」で進めた結果、翌日に大きな問題が出るくらいなら、切り戻して再チャレンジしたほうがいい。切り戻しは失敗ではなく、計画に組み込まれた選択肢です。
まとめ
サーバーリプレース当日の作業項目を、5フェーズでまとめます。
5つのフェーズ
- 前日までの準備 — 権限確認、バックアップ、体制確認
- 作業開始前の確認 — 始めるかどうかの最終判断
- 停止・移行作業 — 停止確認とデータ整合性が肝
- 起動・確認作業 — 監視確認を忘れない、判定会議で決める
- 切り替え後のフォロー — 翌月の月次バッチまでが本当の完了
抜けやすい5項目
- 権限・アカウントの事前確認
- 停止したことの確認
- 監視の動作確認
- 連携先との双方向疎通
- 月次バッチの初回実行確認
判断に迷ったときの基準
- 予定時刻を過ぎたら、まず状況を共有する
- 想定外のことが起きたら、一度手を止める
- 迷ったら、切り戻す
リプレース当日は、緊張します。深夜作業なら、なおさらです。
でも、作業項目を時系列で書き出しておけば、当日は順番になぞるだけになります。頭で覚えようとせず、書き出して、それを見ながら進める。それだけで、事故の確率はぐっと下がります。
次のリプレースが、静かに終わることを願っています。
コメント