リリース管理に不可欠なテストとリハーサル：システム管理入門（5）（1/2 ページ）

リリース管理の目標は、ITインフラの変更を本番環境に確実に実装することである。そのために不可欠なのが「テスト」と「リハーサル」だ。

[谷 誠之（テクノファイブ），＠IT]

　今回は、「リリース管理」という概念についてお話します。

　前回は「変更管理」について述べました。リスクの少ない、変更の手順が完全に標準化されているようなもの（例えばプリンタのトナー交換やウイルス対策ソフトのウイルスパターンファイルのアップデートなど）以外の ITインフラの変更は、必ず変更管理プロセスを通すようにしましょうという内容でした。ここで大切なのは、「ITインフラの変更」にはハードウェアやソフトウェアの変更だけでなく、人の変更も含まれるということです。

　変更管理の最終目標は、変更したことが原因で、業務に負の影響が起きるということを避けるということです。ITILには難しいことが書いてありますが、この最終目標さえ外さなければスモールスタートでも問題ありません。

　ITIL v3の「サービストランジション」という書籍に面白いことが書いてあります。「変更管理は『7つのR』だ」というのです。これは変更が本番環境にもたらすメリットやデメリットを把握するために、システム管理者が理解しておく必要があるので、紹介しておきます。

　1. Raised：その変更を「提起」したのは誰か

　2. Reason：その変更の「理由」は何か

　3. Return：変更よって得られる「見返り」は何か

　4. Risk：変更に伴う「リスク」は何か

　5. Resource：変更に必要な「リソース」は何か

　6. Responsible：変更の「責任者」は誰か

　7. Relationship：その変更はほかのどんなものと「関係」しているか

　筆者はさらに、この7つのRをまとめる8つ目のR、「Report」を付け加えます。システム管理者は7つのRを正確に把握し、変更にかかわるすべてのステークホルダー（技術スタッフ、ITシステムの利用者、お金を出す責任のあるマネージャなど）に「説明する」必要があるというわけです。前回の連載で、すべての変更をシステム管理者が「認識」しておくことがとても大事だと述べたことに関係します。

リリース管理とは

　IT構成要素を変更すると決まったら、次はその変更を実際に本番環境に導入する活動です。その一連の活動を「リリース」と呼びます。ITIL v2では「リリース管理」、ITIL v3では「リリース管理および展開管理」の範ちゅうです。ITIL v3における原題は「Release and Deployment Management」となっていますが、ReleaseとDeploymentを明確に区別している様子もないので、本連載では変更を本番環境に導入することをリリースと表現します。

　リリース管理の最終目標は、変更管理が計画した変更を、技術的な意味合いにおいても業務的な意味合いにおいても、本番環境に確実に実装することであり、それを通してITサービスを確実に稼働させ、顧客と事業を守ることです。そのために不可欠なのが「テスト」と「リハーサル」です。

　テストは、リリースが本番環境にもたらす正の影響と負の影響を探ることを目的とします。ここでは、次の点に注目します。

（1）計画されたリリース手順が問題なく実行できるか
（2）計画されたリソースに過不足はないか
（3）リリースがほかのITインフラに負の影響を与えないか
（4）仮にリリースに失敗した場合、安全に元の状態に戻せる（切り戻し）か
（5）切り戻しの手順は確立されているか

　（1）や（3）は比較的重視されるでしょう。（2）や（4）はどうでしょうか。例えば、小さなテスト環境で1人のスタッフが1時間でリリースを完了できたからといって、それを実際に本番環境にリリースする際にも1人が1時間でリリースできるとは限りません。さまざまな要素を検討する必要があります。

　リハーサルを行うのも重要です。可能であれば、（仮想的なものでもいいから）本番環境とまったく同じ環境を作ってリハーサルするのが望ましいといえます。特に人的リソース、ネットワークリソース、電源容量といったリソース面の不足は、できるだけ本番環境に近いものでリハーサルを行わないと分かりません。

　15年以上も前の話ですが、筆者の失敗を1つ披露しましょう。クライアントPC16台に新しいアプリケーションを展開するのに、そのアプリケーションをWindowsサーバ（共有フォルダ）に置いて、当時まだ斬新だった「アプリケーションのプッシュ型配布」を試みました。筆者は1台のWindowsサーバ、2台のクライアントPCを使ってテスト環境を作り、プッシュ型配布が可能かどうかをテストしました。「よし、これで大丈夫だ」と確信して本番環境に展開しようと16台すべてのPCにユニキャストでプッシュ配布しようとした途端、ネットワークが飽和状態に陥り、配布は失敗してしまったのです。

　当時のネットワークは10Mbpsが主流の時代でしたし、マルチキャスト配信も一般的ではありませんでした。まだ十分な知識も技術もなかった筆者は、「2台のPCに配布するのが○○分でできるのだから、16台のPCに配布するのは最低でもその8倍の時間で終わる」と思っていたのです。実際には飽和状態になったネットワークはコリジョン（衝突）の嵐となり、配布はまったく進まず、ついには通信がタイムアウトしてしまったわけです。結局、4台ずつの配信を4回実施することでなんとかその場を乗り切りました。

　こんな古い例を持ち出したのは、例が簡単だからです。現在では便利なツールが提供されている反面、ITインフラがより複雑になってきています。どこにどのようなボトルネックが潜んでいるか分かりません。ネットワークやデータベースなどは、仮想的に過負荷をかけられるようなツールが存在しているので、そうしたツールを使ってリハーサルを行い、計画に問題がないかどうかを確認しましょう。