ITエンジニア歴20年以上の筆者ですが、サーバ更新は地味に最高級難度のプロジェクトだと思います。
クラウドサービス(PaaSやSaaS)が増えつつありますが、世の中にはまだまだ物理サーバや仮想サーバが沢山あります。
仮想化により、サーバの物理的寿命は無くなりつつありますが、サーバOSにはやはり寿命(サポート期限)があります。
Windows Server 2008も2020年1月にサポートが切れたところなので、苦労してサーバ更新を実施された方も多いのではないでしょうか?
この記事では、サーバ更新で気を付けるべき6つの重要ポイントをご説明します。
今後サーバ更新をする方は、是非とも目を通していただき、サーバ更新プロジェクトを無事に乗り越えていただければ幸いです。
私はサーバ更新を専門的に担当していた時期があり、同時並行で6システム、年間10サーバ以上の移行を担当したことがあります。
かなりの激務でしたが、この中での気づき、失敗事例から得たノウハウが多数あります。
下記には、どれも実際のサーバ更新プロジェクトの中で得た、リアルなノウハウ・失敗事例から抽出したものばかりですので、
必ず皆さんの参考になる情報があると考えます。
サーバ更新プロジェクトはIT界の総合格闘技
サーバ更新プロジェクトは、IT界の総合格闘技と私は呼んでいます。システムの新規開発よりも断然難しいです。
何故かと言うと、サーバ更新では、アプリケーション、ネットワーク、サーバ構築、ユーザ調整、物品調達、セキュリティ、費用配賦、移行設計といった、とても幅広いスキルを要求されます。
これら難しい工程があるにも関わらず、ユーザにとっては何のメリットもないため調整は難しく、
限られた停止時間でかつ、低価格で実現する必要があります。
しかもサーバ更新と言うのは、ハードウェアかOSの期限切れを起因として実施するため、前回実施したのは軽く5年以上前で、前回のノウハウや有識者はいなくなっていることがほとんどです。
この超過酷なミッションをなんとか乗り越えるため、下記の6つのポイントに気を付けて進めてください。
1.ネットワーク
経験上、最も問題が起こりやすいのはネットワーク周りです。
現行システムが機嫌よく動いているのは、ファイアウォールやサーバの通信許可ポートが適切に設定されているためです。
現行システムに必要な穴あけ(許可設定)は全て把握していますか?
モバイルPCや、海外からのシステム利用は考慮されていますか?
連携システムとの通信経路は把握していますか?
インターネットにアクセスできる設定(プロキシ等)は入っていますか?
IPアドレスとか、接続文字列がプログラムに埋め込まれていないか確認しましたか?
メール送信するための、メールゲートウェイの設定は済んでいますか?
DNSは切り替え設定はいつ実施しますか?TTL(Time To Live)の設定は適切ですか?
ネットワーク周りの設定は、申請や反映に時間がかかることが多いですが、リードタイムは考慮されていますか?
2.ジョブ
ジョブもトラブルの代表選手です。
今動いているジョブは、設計書に記載されているジョブがすべてと確信できますか?
なんてこのジョブがこの時間に動いているか理解していますか?(後続のジョブがあったり、他のシステムが出力ファイルを監視していたりしませんか?)
新旧のジョブの繋ぎ替えは考慮できていますか?いつが旧サーバの最終ジョブ実行で、いつから新のジョブに切り替わりますか?
3.ユーザ
ユーザ調整は忘れがち、遅れがちでトラブルになりやすい要素です。
サーバ更新するといったら、あのバグは当然直してくれるんでしょ?と言われたらどうしますか?
サーバ更新時にクラウドにもっていく場合、レスポンスが劣化する可能性を考慮していますか?
システムの作りによっては、オンプレよりレスポンスが著しく劣化する場合があります。その場合のユーザに納得してもらう論理、またはプログラム修正の費用は確保していますか?
共同利用システムの場合、サーバ更新のタイミングで、利用会社が減少することがあります。その場合、新システムの利用料(配賦)は、旧システムより高くなりませんか?高くなる場合、論理的な説明ロジックはありますか?
4.ソフトウェア調達
新サーバでは新しくソフトウェアを購入が必要となる場合があります。
データベース、HULFTやJP1など、新サーバで利用するソフトウェアのライセンスは購入済みですか?
サーバ更新期間中のライセンスは2重で必要になりませんか?
最新バージョンにバージョンアップする場合、スクラッチのシステムはそれでも動作するか確認していますか?
5.環境の変更
サーバだけでなく、環境周りの変更を見落としていませんか?
サーバ更新のタイミングで、利用端末の条件(端末の解像度、OS、ブラウザ)が変わっている場合、アプリケーションの動作確認は不要ですか?
サーバのフォルダをシステムが利用している場合、そのフォルダの権限設定は引き継がれていますか?
6.移行設計
移行設計とリハーサルは十分ですか?
ユーザと調整したシステム停止時間内で、ジョブの切り替え、データ移行、ネットワーク設定変更、疎通確認は全て可能ですか?
リハーサルで発生した問題課題は全て解決できていますか?
移行時に問題が発生した場合、ネットワーク、インフラ、アプリ、ユーザの各担当者の緊急連絡先は明確になっていますか?
切り戻しポイントは設定していますか?本当にそのタイミング、手順で切り戻しができると自信を持って言えますか?
最後に
長くなってしまいましたが、これらがサーバ更新において最も気を付けて欲しいポイントです。
これだけ潜在的にリスクがあるんだということを、ユーザ、関係者の共通認識としていくことも有効なリスクヘッジです。
是非とも参考にしていただき、サーバ更新を無事に乗り切ってください。