【運用管理の勘所⑥】「変更管理」とは？
システムマネジメントサービス部の石田です。
「運用管理の勘所」第6回目は「変更管理」について解説します。
「変更管理」とは
定常的に稼動しているシステムにおいて、何らかの問題が発生するのは、システムを構成するハードウェアや、その中で動作するソフトウェアに"変更を加えた後"の場合が多いものです。
ハードウェアの場合には経年変化による劣化が原因で問題を起こすこともありますが、アプリケーションプログラムやシステム環境定義なども含め、ソフトウェアが問題を起こすのは、利用状況に大きな変化があったことや、何らかの変更を加えたことが主要な原因なのです。
このように危険と背中合わせの変更作業を管理する手法を変更管理と呼び、目的は次の2点です。
- 正確な変更業務の実施
- 変更業務の生産性向上
この変更管理によって、変更作業を計画段階から動作試験・本番反映まで、系統的に管理することが、システム全体の信頼性向上に大きく役立つことになります。
システム変更は時にシステム稼動全体に影響を及ぼすと心得よ !
システムトラブルはシステムに変更が加わったことが原因で発生しやすいものです。
しかし、システムには日常的に、ハードウェア/ソフトウェアの追加、削除、入れ替え、データ量/処理量の増減といった、様々な変更が必要で、変更を行わないわけには行きません。
そのためシステム変更にあたっては、危険性を十分意識し、可能な限り安全に実施できるように検討する必要があります。
ではどうすれば安全かつ効率的に、システム変更を行えるのでしょうか？ポイントは5つあります。
変更履歴を蓄積し、再利用する
システム変更作業のうち、日常的に頻繁に行われるもの（定常的な登録系作業）は、運用業務に組み込まれて明確な作業手順とチェックのもとに行われるため、大きなトラブルの可能性は少ないです。
しかし、非定常的な作業（大規模システム変更、トラブル対応変更など）に関しては、作業手順や、影響の確認、チェック方法などをその都度計画し実施する必要があり、作業もれ、チェックもれによるトラブルの危険性が高まります。
このような変更作業の安全性、効率性を高めるために、変更履歴の蓄積と再利用が重要になります。変更作業の作業履歴保存用のデータベースを用意し、変更作業計画時に過去事例を参照することで、頻度の少ない変更作業の正確で効率的な実施に役立てることができます。
さまざまなフェーズでチェックをいれる
「計画」、「テスト」、「変更作業」、「結果確認」という変更作業の各フェーズにおいて、複数の人間によるチェックを行うことが重要です。一連の変更作業の妥当性をチェックし、問題があれば、その問題が取り除かれるまでチェックを繰り返すしくみも確立しましょう。
定められた手順、段階に従って作業する
事前に作業体制、作業手順を決め、それに従って変更作業を実施します。理由のない作業の省略や、日程/手順の変更を行うとトラブルが発生しやすく、対応も困難になりがちです。
戻し手順も忘れずに用意する
さまざまなチェックを行い、手順に従って変更を行ってもトラブルを招くことはあります。想定外の状況で強行突破を試みると問題をこじらせることが多いため、迅速に変更前の状態に戻すことが最も賢明です。
戻し手順や環境（バックアップなど）は、前もって準備しておきましょう。でなければ迅速に回復できないばかりか、戻し作業そのものが不可能になる場合すらあります。
“カタすぎる"管理はコスト高を招く
システム変更はトラブルという危険と裏腹なため、慎重なチェック体制と手順に従った作業が必須です。すべての変更作業に最高レベルの管理を行うのは管理負荷が膨大になり効率的とはいえません。そこで重要になってくるのが、コストとのバランスです。
一般的には、変更作業ごとに影響度を考慮した管理レベル（変更区分）を設定し、影響度（トラブルの危険性）の低い変更作業は、チェック回数を減らしたり、テストを軽くしたりすることで管理負荷（コスト）をさげるという方法でバランスを取っています。
体制
変更管理を実施する上での責任者・担当者など体制を整備することによって、変更管理業務を円滑に進めることができるようになります。その例を示します。
- 変更管理責任者
- 変更管理の全責任を負う（例：システム運用部長）
- 変更管理担当者
- 変更管理を行う（例：システム運用課長）
- 変更作業者
- 変更作業の計画・実施、実施申請を行う（例：運用担当者）
- 変更検定者
- 一連の変更計画の確認を行う（例：検定対象となる技術のスペシャリスト）
管理項目と変更区分
管理項目
変更作業を安全、円滑に行うために管理すべき項目は以下のとおりです。
- 変更対象
- 変更対象のOS名、ソフトウェア名、ハードウェア名などの情報
- 変更種別、区分
- 追加/削除などの変更種別、変更の重み付け、影響範囲などをあらわす区分
- 変更者
- 変更申請者の部署、氏名など
- 変更内容
- 変更計画、概要
- スケジュール
- 作業予定日時など
- 変更結果
- 作業結果
変更区分
管理項目のうち、本番システムの業務・運用に対する影響度を考慮し、変更区分を的確に定義することが重要です。影響度の高い区分の変更は当然、変更管理の流れの中でよりシビアなチェックを必要とします。変更区分決定の観点は以下の通りです。
- ユーザーへの影響度
- 影響が全ユーザーに及ぶか、一部ユーザーか
- サービス停止の必要性
- サービス停止が必要か
- 変更実績の有無
- 同様の変更を行ったことがあるか
- テスト環境の有無
- 事前に変更確認できる環境があるか
- 緊急度
- トラブル対応などで変更に緊急を要するか
変更作業の項目（ステップ）
変更作業には下表に記すような項目（ステップ）があり、各ステップでは、計画書、チェックシートなどを用いてチェックを行います。影響度の高い変更は、すべてのステップを実施する必要がありますが、影響度の低い変更は、2.以降で省略可能な項目もあります。
例えば、手順の確立した日常変更作業を行う場合2.～6.は省略可能です。事前に、変更区分（影響度）ごとに、実施すべき項目を決定しておきましょう。
- 変更申請
- 変更計画を変更管理担当者に申請する
- 変更検定
- 変更計画の是非を問う
- テスト検定
- テスト計画の是非を問う
- 移行検定
- 移行計画の是非を問う
- 移行結果報告
- 移行が正常に完了したかを確認する
- 移行完了報告
- 移行の全行程が完了したことを確認する
構成管理資料への変更情報の反映
ある変更を実施したとき、それが「構成管理」で管理している資源に関する変更であれば、構成管理の資料に変更情報を反映 (フィードバック) する必要があります。これを怠ると、構成管理情報と現状構成とのズレが生じ、システム運用全体の信頼性、正確性が損なわれます。
変更履歴の蓄積と再利用
変更履歴の蓄積
変更作業時の安全性と効率の向上のために、変更作業履歴を蓄積することが重要です。変更履歴を蓄積するためのデータベースを用意し、変更作業完了時にその変更作業内容を入力することを義務付ける必要があります。
変更実績の再利用
変更計画時に、変更履歴データベースを参照し、同様変更作業の作業内容、影響範囲、チェック方法、注意点などを確認することにより、常時行われていない変更作業の安全性、効率性を高めることができます。
いかがでしたでしょうか。次回は「問題管理」について紹介します。
https://devlog.arksystems.co.jp/2011/04/26/9681/
