問題本文
ITサービスマネジメントのリリース管理では,変更管理によって計画し,認可されたものを本番環境に実装する作業を行う。リリース管理に関する記述として,適切なものはどれか。
選択肢
- ア.変更に関係のある利用者,運用管理者などには,リリース完了後に情報を提供すればよい。
- イ.リリース計画時には,計画した時間内に作業を完了できない場合も想定する。
- ウ.リリース後は,新たな障害が発生する可能性はないので備えは不要である。
- エ.リリースの規模にかかわらず,リリースは全ての利用者に対して同時に実施する。
正解
イ. リリース計画時には,計画した時間内に作業を完了できない場合も想定する。
解説
ITサービスマネジメントのリリース管理に関する問題. リリース管理(release management)は変更管理プロセスで計画・認可された変更を実際に本番環境へ展開する活動で,リリース計画策定,リリースパッケージの構築,テスト,展開,事後評価までを含む. 計画時には変更失敗時の切り戻し(ロールバック)手順や,作業時間超過のリスクを想定するのが鉄則. 利用者・運用管理者への事前告知,リリース後の障害発生に備えたモニタリング,規模に応じた段階的リリース(パイロット導入後の全展開)などもベストプラクティス. 一斉リリースより段階的展開で影響を限定する設計が一般的となる.
選択肢ごとの解説
- ア.誤り. 利用者や運用管理者には事前にリリース日時・影響範囲・切り戻し手順等を通知する必要があり,完了後の情報提供だけでは不十分. 業務影響の事前準備のために事前周知が必須で,これを怠ると現場混乱・障害対応の遅れを招くため,リリース管理のベストプラクティスから外れる行動.
- イ.正解. リリース計画では計画時間内に作業が完了しない場合に備え,作業遅延時の判断基準・切り戻し条件・延長判断などを事前に想定しておくのがリリース管理のベストプラクティス. 計画通り進まない事態に備えてリスク管理を組み込むことで,本番環境への影響を最小化できる.
- ウ.誤り. リリース後は予期しない障害や新たな不具合が顕在化する可能性があるため,監視体制とインシデント対応手順を備えておく必要がある. 「備え不要」は誤りで,リリース管理ではポストレビュー・モニタリング・必要時のロールバックを準備するのが標準的な運用となる.
- エ.誤り. 規模に応じてリリース方式は変える必要があり,全利用者同時実施は影響範囲が大きすぎる場合がある. 段階的リリース(パイロット展開後に拡大),サブセット先行展開,カナリアリリース等の手法でリスクを限定するのが定石であり,規模を問わず同時実施は不適切.
ITパスポート 2015年 (平成27年 秋期) の過去問一覧へ戻る・問34