システム開発■ 移行リハーサル
今回はプログラム作成を外注したので、本番の一ヶ月前には移行プログラム群が仕上がりました。
いつもであれば、プログラムの完成は本番の数日前（良くて一週間前）だったので、ぶっつけ本番に近い状況で処理をしていたのですが、これだけ期間に余裕があれば色々とできそうです。
ってことで、一か月前のデータを使って移行リハーサルを行うことにしました。
■ 移行リハーサル
①開発環境に本番環境のデータを投入
本番環境のＤＢ（Oracle）からデータ・ポンプ・エクスポート（expdp）でデータを引っこ抜いて、開発環境のＤＢにデータ・ポンプ・インポート（impdp）で突っ込みます。
これに大体３０時間。時間が掛かるのはデータ量が多いってのもあるのですが、開発環境のＤＢサーバーの性能不足が主な要因だったりします（開発者が私しかいないので、あんまり費用を掛けられない）。
②プログラム資産の再登録
プログラムのバージョン違いが嫌だったので、開発環境のプログラムを全て入れ替えます。
これが意外と手間取りました。プログラムのリリース登録は自動化しているので簡単なはずだったのですが、実際にやってみるとリリース登録処理が異常終了。開発環境に対してリリース登録処理を行うのは３年ぶりだったので、当時との環境の違いとかで色々と問題が・・・
これの原因調査と復旧に数時間。
③移行用データの取得
移行のためのデータや数値チェック用の資料（在庫表やB/S）の取得を依頼したのですが、出てきたデータのレイアウトが以前と違う。何でも、データを取得するためのパラメータをなくしてしまったそうです。
今更プログラム側を直すわけにもいかないので、なんとか当時のレイアウトを再現してもらいました。
④移行処理
ここまで３日ほどかけて準備が完了。事前に作っていた移行手順書を見ながら移行処理を実行！
エラー発生、対応、エラー発生、対応・・・・・・・・・・・・日付が変わりました(--;)
っていうか、エラー出すぎ！
まぁ、最後の一ヶ月で残高とか色々と整理する予定だったので、移行リハーサルの時点ではエラーが出ても仕方ない部分があるのですが、エラーの発生箇所がある妙に偏っているってのはどういうことだ？
⑤数値チェック
最後に数値チェック。
基本的には、前回（子会社との合併に伴うシステム移行 No14 移行処理の設計と移行準備）書いた方針でトータル金額（件数）のチェックを行います。
ここが大変でした。上で書いたエラーを突破する為に、どうしようもないデータについては移行しない（DB上から物理削除）したものですから、当然B/Sの数値とは差異が出る訳で、その差額分が削除したデータが移行された時の数値と一致しているかを確認して・・・
疲れた。
■ 後書き
実際のところ、移行リハーサルでプログラムのバグ、数値検証ツールの不備、移行手順書の漏れ、と言った問題の発見ができたので手間を掛けたかいがありました。
さて、後は発見した問題を修正して本番を迎えるだけです。
前回：子会社との合併に伴うシステム移行 No14 移行処理の設計と移行準備
次回：子会社との合併に伴うシステム移行 No16 移行処理
投稿記事の一覧：http://harikofu.web.fc2.com/
--- blog end ---
スポンサードリンク
0
0
