システム運用のリリース管理の説明です。
リリース管理の目的は、変更管理で承認されたITシステムの変更を安全・無事かつサービスの品質を落とさずに行うことです。
１．リリース管理でやること
リリース管理では、主に以下のようなことを実施します。
①リリース手順書、切り戻し手順書の作成
②コンティンジェンシープランの作成（小規模な変更は省略する場合も多い）
③リハーサル（小規模な変更は省略する場合も多い）
④リリース作業
⑤リリース後の本番サポート（小規模な変更は省略する場合も多い）
これらをリリース計画書にまとめ、リリース判定会議で評価をします。
基本的にリリース判定会議をやる頃には、リリース日が決まっていてユーザー側の準備も整ってしまっているので、リリース判定会議でNGが出ることは稀です。NGを出せば業務影響も出ますし、ベンダーにも追加費用が発生するので、基本的には何か不足があっても、リリース日までに対応するようにと改善指示が出るくらいです。
会社によっては、リリース判定会議の中でテスト内容の確認をしたりする残念なところもあります。
リリース判定会議では、リリース時の体制やユーザーへの周知状況、初回稼働時のサポート体制、コンティンジェンシープランなどが判定の対象となるので、システムの品質についてはリリース判定よりも前に確認しておくことが重要です。
２．リリース時の体制
大規模な変更では、リリース手順書などのリリース作業に必要なドキュメント以外に、通常はリリースや本番稼働を円滑に行うための体制を敷きます。
本部をどこかの会議室に設置して、ユーザーからの問合せや障害の情報を本部に集め、本部から各拠点の窓口に指示を出します。
本部では朝会や夕会、場合によっては昼会を実施して、システムの稼働状況を確認し、それを経営に報告します。
通常、本部の設置期間は長めに計画しておきます（１週間くらいが多いです）。本部を解散する条件も予め決めておいて、条件を満たせば早めに本部を解散します（問題が出なければ、３日くらいで解散することが多いです）。
このように、リリースから本番稼働のサポートまでを本部を中心とした体制で、どのように運用していくのかをリリース計画書にまとめます。
たまにコンティンジェンシープランとリスクヘッジを混同する人がいます。
リスクヘッジは、リスク管理でいうと低減とか回避、転嫁といった対応のことです。
それに対してコンティンジェンシープランは、リスクが顕在化した場合の対応のことです。
例えば、データ移行作業で旧サーバーのデータをハードディスクに落として、公共交通機関を利用して、別のデータセンターに人が運搬して、新サーバーに移行する計画があったとします。
この作業では運搬中にハードディスクが壊れたり、盗難・紛失したりするリスクがあります。
そのリスクに対して、ハードディスクを２台用意して、２人で運搬するという対応とした場合、これはリスクの低減であって、コンティンジェンシープランではありません。
この場合のコンティンジェンシープランは、２台とも壊れたり、盗難・破損したり、公共交通機関が大雪で止まってしまったりしてリスクが顕在化した場合の対応となります。そのため移行が一日（あるいは数日）遅れることで、本番日も旧システムを使い続ける対応（運用の整理等）がコンティンジェンシープランとなります。
もう一つの例では、同じような移行をネットワーク経由で実施する計画があったとします。回線が冗長化されていないので、ネットワーク障害が起きた場合、移行が中断するリスクがあります。
そのリスクに対して、事前に回線を冗長化しました。これもリスクの低減であって、コンティンジェンシープランではありません。
この場合のコンティンジェンシープランは、２回線ともネットワーク障害が起きることでリスクが顕在化した場合の対応となるので、ハードディスクにデータを落として、人が運搬するといったような対応がコンティンジェンシープランとなります。
２つ目の例は、バックアッププランとして、コンティンジェンシープランと区別するプロジェクトもあります。その場合のコンティンジェンシープランは、目的が達成されない場合のプランとなるので、旧システムを使い続ける場合の運用を整理したものになります。
【振り返り】
リリース管理の説明は以上で終了となります。次回はサービスデスクの説明をしていきたいと思います。
①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理
