本番移行を止められないとき、何を準備したか――続行判断・切り戻し・完了承認を分けた理由
本番移行のリハーサルでは、手順が最後まで動くかを確認するだけでは足りません。
私が携わったプロジェクトでは、リハーサルで想定より大幅に時間がかかった移行タスクがありました。しかし、移行作業に使える端末は限られており、複数の作業チームで共用していました。時間がかかったタスクへ複数台を追加で割り当てれば、ほかの作業へ影響します。
そこで、今回は端末を増やして並行化するのではなく、実測した時間に合わせて、そのタスクの実施期間を延ばしました。
一方、プロジェクトによっては、サーバーの契約期間や保証期間の終了が迫っており、本番移行そのものを中断できない場合もありました。そのような案件でも、異常時の切り戻しや復旧を諦めたわけではありません。
前回は、1件ずつの登録から一括移行へ変更し、リハーサルで本番手順と時間を確認した経験を紹介しました。
今回は、そのリハーサル結果を本番スケジュールへどう反映したか、移行を止めにくい条件の中で何を準備し、誰が続行と完了を判断していたかを紹介します。
リハーサルで想定時間を大幅に超えた
本番移行前のリハーサルで、予定していた時間を大幅に超えるタスクが見つかりました。
リハーサルで確認した実行時間を無視し、当初の予定時間のまま本番へ進むことはできません。かといって、単純に端末を増やせば短縮できる状況でもありませんでした。
そこで、リハーサルの実測結果を基に、そのタスクへ割り当てる実施期間を延ばしました。
リハーサルを「予定どおりに終わることを確認する場」と考えるのではなく、予定と実態の差を見つけ、本番スケジュールを修正する場として使っていました。
端末を増やせば短縮できるとは限らなかった
移行作業に使える端末は、各チームが自由に増やせるほど潤沢ではありませんでした。
多くの作業チームが限られた端末を使いながら、それぞれの移行タスクを進めていました。一つのタスクが複数台を占有すると、その分だけ、ほかのチームが使える端末が減ります。
優先度が特に高い作業でなければ、一つのタスクの短縮だけを目的として複数台を占有することはできませんでした。
今回のタスクも、端末を追加して並行作業にするのではなく、必要な時間を本番スケジュールへ反映しました。
これは、技術的に並列実行できる可能性を全面的に否定する話ではありません。限られた端末を複数チームで共用する移行計画の中で、今回のタスクへ複数台を割り当てる選択をしなかった、ということです。
※予定時間を超えたタスクについて、端末の追加ではなく実施期間を延ばし、後続作業を含む本番スケジュールへ反映するイメージです。
プロジェクトごとに続行・中断条件が決まっていた
本番移行を続けるか中断するかの基準は、すべてのプロジェクトで同じではありませんでした。
あるプロジェクトでは、旧サーバーの契約期間や保証期間が終了する事情があり、本番移行を中断して旧環境の利用を続ける選択ができませんでした。移行後に障害が見つかった場合は、移行後の環境で対応する前提でした。
ただし、これは「問題が起きても、そのまま進める」という意味ではありません。
移行計画全体を中断できるかという判断と、個別作業で異常が起きたときに復旧する判断は、分けて考える必要がありました。
中断不可でも切り戻しと復旧を準備した
本番移行の前には、バックアップ環境を用意し、異常時の切り戻しや復旧手順を準備することになっていました。
移行全体を中断しにくいプロジェクトでも、個別の移行処理が失敗したときに、どこまで戻すのか、どの手順で復旧するのかは必要です。
「旧環境を使い続けるために移行全体を中断すること」と、「異常が起きた処理を切り戻して復旧すること」は同じではありません。
この二つを分けておかなければ、中断できないという言葉だけが先行し、異常時の対応まで準備しなくてよいように受け取られてしまいます。
最終的な続行判断は請負側で行わなかった
続行や中断の最終判断は、契約先の会社と元請け会社が行っていました。請負側である弊社が、単独で決めていたわけではありません。
請負側は、移行作業の実行状況や確認結果を報告します。一方、サーバーの契約や保証などを含めた最終判断は、判断権限を持つ組織が行います。
技術的な状況を確認して報告する役割と、事業上の制約を含めて続行を決める役割を分けていました。
三つの確認後、管理チームへ報告した
移行後は、データ件数、ファイル単位のハッシュ値、実機動作を確認しました。
ただし、各作業チームが自分たちの確認を終えただけで、移行全体の完了にはしていませんでした。
確認結果を、移行全体をコントロールする管理チームへ報告しました。その報告を受け、管理チームが移行全体の完了を承認していました。
この流れでは、作業チームによる技術確認と、管理チームによる全体の完了承認を分けています。
※「続行・中断の判断」と「移行結果の確認・完了承認」を別の流れとして示すイメージです。契約先・元請け会社は続行・中断を判断し、作業チームは確認結果を管理チームへ報告し、管理チームが移行全体の完了を承認します。
まとめ
本番移行前のリハーサルで、想定より大幅に時間がかかるタスクが見つかりました。
移行端末は複数チームで共用しており、今回のタスクへ複数台を割り当てて並行化する選択はできませんでした。そこで、実測時間に合わせてタスクの実施期間を延ばし、本番スケジュールへ反映しました。
また、本番移行そのものを中断できないプロジェクトでも、バックアップ環境、切り戻し、復旧手順は準備していました。移行全体の中断と、個別処理の異常からの復旧は、分けて考える必要があります。
続行の最終判断は契約先と元請け会社が行い、請負側は技術的な確認結果を報告しました。移行後は、件数、ハッシュ値、実機動作の確認結果を管理チームへ報告し、移行全体の完了承認を受けていました。
移行計画では、処理時間だけでなく、利用できる端末、ほかのチームへの影響、異常時の復旧、最終判断と承認の責任まで決めておく必要がありました。
次の記事：