稼働中の基幹システムのサーバに、提供元が公開したOSの修正プログラムを適用したい。 サービスの変更管理の考え方に沿った進め方として、最も適切なものはどれか。
正解：エ
ア提供元が検証済みの修正なので、可否の判断は省いて全サーバへ一斉に適用する。
誤り。提供元の検証は、その組織で動いている業務やソフトの組合せまでは 見ていません。変更管理が評価するのは修正そのものの品質ではなく、 自分たちのサービスに及ぶ影響です。だから可否の判断は省けません。
イ利用者に影響が出ない夜間に担当者の判断で適用し、翌朝に結果を報告する。
誤り。時間帯の配慮は妥当ですが、担当者だけで決めて実施する点が変更管理に 反します。実施前に承認を得ないと、障害が起きたときに何をいつ変えたのかを たどれず、原因の切分けにも時間がかかります。
ウ適用後に不具合が出ても受け付けられるよう、サービスデスクの要員を増やす。
誤り。これはインシデント管理側の備えで、変更そのものの是非は問えていません。 起きてから対応する構えだけを整えるのは、影響を事前に評価して失敗の確率を 下げるという変更管理の考え方とは順序が逆です。
エ影響する業務と範囲を評価し、元に戻す手順を用意した上で承認を得て適用する。
正解。変更管理は、影響の評価、承認、切戻し手順の用意、実施と記録という 流れで進めます。うまくいかなかったときに元の状態へ戻せることまで含めて 準備するのが、稼働中のサービスを守る要点です。
動いているものに手を入れる前の作法
走っている車のタイヤを交換するなら、止める場所、必要な工具、失敗したときに どうするかを先に決めます。稼働中のシステムへの変更も同じで、良かれと思って 加えた一手が業務を止めることがあります。変更管理はそれを防ぐ仕組みです。
変更管理が確かめること
- なぜその変更が必要か（放置した場合のリスクを含む）
- どのサービスや業務に影響するか、停止が必要か
- いつ実施するか、誰が作業し、誰が承認するか
- 失敗したときに元へ戻す手順（切戻し）が用意できているか
- 実施後、何をいつ変えたかを記録に残したか
影響範囲を調べるには、機器やソフトの構成情報が最新である必要があります。 変更管理と構成管理が組で語られるのはこのためです。
混同しやすいものとの違い
| 用語 | 役割 |
|---|---|
| 変更管理 | 影響を評価し、承認と切戻し手順を整えてから変更を実施する |
| 構成管理 | 影響範囲を調べるための構成情報を最新に保つ |
| インシデント管理 | 起きてしまった中断や品質低下から復旧させる |
| 問題管理 | 障害の根本原因を取り除き、再発を防ぐ |
試験では「担当者の判断で」「急ぎなので承認を省いて」という記述が出たら、 変更管理としては誤りだと判断できます。緊急の変更にも、簡略化した承認手順を あらかじめ決めておくのが本来の姿です。