社内SEの徒然なる日記

子会社との合併に伴うシステム移行 No15 移行リハーサル

■ 移行リハーサル

今回はプログラム作成を外注したので、本番の一ヶ月前には移行プログラム群が仕上がりました。

いつもであれば、プログラムの完成は本番の数日前(良くて一週間前)だったので、ぶっつけ本番に近い状況で処理をしていたのですが、これだけ期間に余裕があれば色々とできそうです。

ってことで、一か月前のデータを使って移行リハーサルを行うことにしました。

■ 移行リハーサル

①開発環境に本番環境のデータを投入

本番環境のDB(Oracle)からデータ・ポンプ・エクスポート(expdp)でデータを引っこ抜いて、開発環境のDBにデータ・ポンプ・インポート(impdp)で突っ込みます。

これに大体30時間。時間が掛かるのはデータ量が多いってのもあるのですが、開発環境のDBサーバーの性能不足が主な要因だったりします(開発者が私しかいないので、あんまり費用を掛けられない)。

②プログラム資産の再登録

プログラムのバージョン違いが嫌だったので、開発環境のプログラムを全て入れ替えます。

これが意外と手間取りました。プログラムのリリース登録は自動化しているので簡単なはずだったのですが、実際にやってみるとリリース登録処理が異常終了。開発環境に対してリリース登録処理を行うのは3年ぶりだったので、当時との環境の違いとかで色々と問題が・・・

これの原因調査と復旧に数時間。

③移行用データの取得

移行のためのデータや数値チェック用の資料(在庫表やB/S)の取得を依頼したのですが、出てきたデータのレイアウトが以前と違う。何でも、データを取得するためのパラメータをなくしてしまったそうです。

今更プログラム側を直すわけにもいかないので、なんとか当時のレイアウトを再現してもらいました。

④移行処理

ここまで3日ほどかけて準備が完了。事前に作っていた移行手順書を見ながら移行処理を実行!

エラー発生、対応、エラー発生、対応・・・・・・・・・・・・日付が変わりました(--;)

っていうか、エラー出すぎ!

まぁ、最後の一ヶ月で残高とか色々と整理する予定だったので、移行リハーサルの時点ではエラーが出ても仕方ない部分があるのですが、エラーの発生箇所がある妙に偏っているってのはどういうことだ?

⑤数値チェック

最後に数値チェック。

基本的には、前回(子会社との合併に伴うシステム移行 No14 移行処理の設計と移行準備)書いた方針でトータル金額(件数)のチェックを行います。

ここが大変でした。上で書いたエラーを突破する為に、どうしようもないデータについては移行しない(DB上から物理削除)したものですから、当然B/Sの数値とは差異が出る訳で、その差額分が削除したデータが移行された時の数値と一致しているかを確認して・・・

疲れた。

■ 後書き

実際のところ、移行リハーサルでプログラムのバグ、数値検証ツールの不備、移行手順書の漏れ、と言った問題の発見ができたので手間を掛けたかいがありました。

さて、後は発見した問題を修正して本番を迎えるだけです。


前回:子会社との合併に伴うシステム移行 No14 移行処理の設計と移行準備
次回:子会社との合併に伴うシステム移行 No16 移行処理

投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end ---
スポンサードリンク

PageTop

コメント


管理者にだけ表示を許可する