[解説]ITサービスマネージャ試験 2018年(平成30年)秋期 午後1 問2 テーマ:リリース及び展開

[解説]ITサービスマネージャ試験 2018年(平成30年)秋期 午後1 問2 テーマ:リリース及び展開

テーマ:リリース及び展開

出典:平成30年度 秋期 ITサービスマネージャ試験 午後 問2

ITサービスマネージャを想定して、サービス利用者、システム開発者からの要求に対応する改善能力、適用保守や是正保守に対するシステム環境管理能力、リリース及び展開計画に関する能力などを問う。

問題文の構成

  • 序文 冒頭
  • [情報システム部の概要]
  • [ツールによるデプロイの自動化]
  • [受注管理サービスの変更]
  • [受注管理サービスのインシデント発生と対応]
  • [業務ルール変更計画の実施]

序文 冒頭

  • W社 東京本社と欧州支社がある家具屋

序文はシンプルに「海外拠点がある」ということだけを説明しています。

[情報システム部の概要]

登場人物やシステム構成に関する説明セクションです。

システム構成に関する説明

  • 情報システム部 システム開発課とシステム運用課がある。
  • 情報システム部が「受注管理サービス」を提供。受注管理サービスは受注管理システムで提供される。
  • 受注管理システムは定期保守以外24時間365日稼働
  • 図1に構成図。稼働環境はLBで振り分け。テスト用は開発環境と保守環境。
  • ソースコード(SC)のビルドを行うライブラリ管理サーバ
  • 受注管理システムが使えない時の「Sorryサーバ」

午後1の問題すべてに共通しますが、図や表で概要を理解して問題文を読み解くクセをつけておきたいです。

注釈の数が多いですね。
問2のテーマは「リリース及び展開管理」なので、構成図にもそれらに関係が深いリソースが記載されています。
ライブラリ管理であり、テスト用サーバー群がそれにあたります。

テスト用サーバーが「開発環境」と「保守環境」の2つに分かれているところが特徴的ですよね。
注釈をみると、開発環境=適応保守、保守環境=是正保守と用途が違うことが書かれています。
「ということは、同じシステムを別目的で同時期に改修するときに注意が必要だよな」と、引っ掛かっておくとよいと思います。

サビマネ経験者や現在その職にある方は、もうこの構成を見ただけでリリース事故のつらい経験を1つや2つ思い出しちゃうかも、というくらいのフラグ感です。

役割に関する説明

  • 開発課はソフトの保守、運用課はビルドとデプロイ(展開)
  • 表1 役割の詳細。
  • 開発課はソフトの保守とテスト。
  • 運用課はデプロイ。時間帯とか全停止の時のSorryサーバへの振り分けなど。

開発課のテストに関する説明で、「新規に作成したPG」のテスト「のほか・・・」で続くところに注目です。
テスト内容の範囲をあえて明示しているということは、設問に絡む可能性があります。

[ツールによるデプロイの自動化]

デプロイ自動化への背景と取り組み内容の説明セクションです。

  • 欧州から「デプロイの時間帯を22時から20時に変えて」との要望
  • 開発課から「ビルドとテスト用サーバーへのデプロイ頻度を増やして」との要望
  • PGのデプロイ自動化支援ツール
  • 欧州、開発課の要望に応える。ミス防止作業品質向上。
  • 表2 ツールの内容。
  • AP展開ツール 「稼働環境のAPサーバ1台ごとにPGを順次デプロイ
  • ただし、テーブル定義変更のときはサービス停止。
  • 表3 ツールの処理手順 APサーバ1台ごとに閉塞と解除する流れ。

表1のシステム運用課の役割の説明のなかで、「デプロイの時はサービス停止してSorryサーバへ振り分け」と書いてありました。
一方で、このセクションでは、ツール導入によって「稼働環境のAPサーバ1台ごとにPGを順次デプロイ」できるようになると書いてあります。
つまり、ツール導入前までは「デプロイ=停止」だったけど、ツール導入後は「デプロイの時に必ずしもサービス停止しないケースがある」、ということになります。

[受注管理サービスの変更]

デプロイ方法の変更につづいて、今度はプログラムの変更です。
冒頭の「適応保守」「是正保守」を意識しながら読んでいきましょう。

  • 業務ルール改正で10月末までに稼働環境に修正プログラム適用が必要
  • 対象は「請求プログラム」と「共通プログラム」でデータベースに影響は与えない。
  • 10月12日に稼働環境に展開。AP展開ツールを使う。
  • 10月3日に変更諮問委員会で承認

修正対象が明示されていますね。
「業務ルール改正」に伴うプログラム修正、ということは「適応保守」の対応ということになります。
で、対象は「請求プログラム」と「共通プログラム」と明記されています。

このあたりで「あー、同じプログラムを是正保守で同時期に修正してたらマージ漏れとかデグレで痛い目みそうだよ、これ・・・」っていう暗澹たる感情が湧いてくる皆さんは、歴戦の勇者です。

[受注管理サービスのインシデント発生と対応]

言ってるそばから、インシデント発生です。是正保守でプログラム修正がありますね。

  • 10月4日にインシデントが発生
  • 「売上プログラム」と「共通プログラム」の不具合
  • DBサーバの在庫管理ファイルに誤り
  • 在庫管理ファイルの誤り修正はAPサーバからDBサーバへの通信を「発生しない状態」で行う
  • AP修正後にファイル修正
  • 22時に始めようと計画するが、20時開始にするよう提言。
  • 20時50分に完了

プログラム修正対象を確認

ということで、「適応保守」と「是正保守」のプログラム修正対象バッティングをチェックしておきます。

業務ルール改正の適応保守では『「請求プログラム」と「共通プログラム」でデータベースに影響は与えない。』

10月4日のインシデントでは『売上プログラムと共通プログラムに不具合・・・DBサーバーの在庫管理ファイルの一部に誤りが発生』

適応保守=「請求プログラム」、「共通プログラム」
是正保守=売上プログラム」、「共通プログラム」

ということで、「共通プログラム」が同時期に修正されるという事実を認識しておきましょう。

時系列を確認

「適応保守」と「是正保守」のリリースまでの時系列を整理しておきます。

  • 10月3日(水) 適応保守のプログラム修正とテスト完了し 変更諮問委員会で承認
  • 10月4日(木) 13時 インシデント発生 即座にPG修正し保守環境にデプロイしてテスト完了
  • 10月4日(木) 18時 是正保守の緊急諮問委員会開催
  • 10月4日(木) 20時 是正保守修正プログラムを稼働環境へデプロイ

10月3日以前のプログラムに対して「適応保守」でプログラム修正とテストは終わっていますが、
10月12日(金)までは稼働環境へリリースしないです。

「適応保守」のプログラム修正が先に終わっているのですが、「是正保守」修正分が先に稼働環境へリリースされている状態。
つまり、「適応保守」のプログラム修正元の状態が変わった、ということがポイントです

あと、やっとここで「欧州支社の休憩時間」がでてきますね。
DB修正があるのでシステムの利用停止が必要=メンテナンス時間帯に注意、というポイントです。
この問題のために欧州支社があったわけですね。

[業務ルール変更計画の実施]

適応保守プログラム改修分のリリースに関するセクションです。

  • 10月10日に「業務ルール変更計画」に関する緊急諮問会議。
  • 10月3日に承認されているが、10月4日の修正に対する追加テストの確認
  • 10月12日に「請求プログラム」と「共通プログラム」を稼働環境にデプロイ

10月12日のリリースはDB変更がなくデプロイツールで実施なので、システム停止がありません。
なので、東京本社、欧州支社の業務影響を気にすることなくリリースができました、ということです。

設問1 [ツールによるデプロイの自動化]について

設問1 問題

AP展開ツール導入の利点を、40字以内で述べよ。
なお、欧州支社及びシステム開発課からの要望の実現、反復的なシステム開発の実現、作業ミスの防止及び作業品質の向上は除く。

設問1 解答例

稼働環境にデプロイするときにサービスを停止しなくて済む場合がある。

設問1 ポイント解説

表1に「PGを稼働環境にデプロイする場合…すべてのAPサーバのサービスを停止する」と記載があります。
一方で、表2のAP展開ツールの処理概要には「受注管理サービスの利用に影響を与えないように・・・稼働環境のAPサーバ1台ごとにPGを順次デプロイする」と記載されています。

デプロイ時にシステム停止をしないことで業務影響を抑えられることは利点ですよね。
ただし、必ず無停止でデプロイできるかというと、違いますよね。

表2には「データベースのテーブル定義変更などの場合は・・・サービスを停止させる必要があるので」とも書かれています。

なので、デプロイの時にサービス停止をしなくてよい、ではなく、「しなくてよい時がある」というような、「場合によっては停止が必要だけど、停止しなくてもいいケースができたよ」という表現を求められます。

今回の問題文のように「〇〇は除く」というパターンはわりと出てきますが、解答の内容を絞り込めるので、むしろありがたい設問とも言えます。
問題の本文の中に明示しない条件やメリットデメリット要素を読み解く練習をしておくことが大切です。

設問2 [受注管理サービスのインシデント発生と対応]について

設問2-(1) 問題

(1)本文中の下線(ア)の修正作業について、不具合を修正したプログラムをAP展開ツールで稼働環境にデプロイした後に実施する理由を、30字以内で述べよ。
ここで、要員・システム資源は不足していないものとする。

設問2-(1) 解答例

プログラムの不具合によって再度誤りが発生してしまうから
または
AP展開ツールによってLBの閉塞解除が行われるから

設問2-(1) ポイント解説

[受注管理サービスのインシデント発生と対応]の①記述を確認します。
『プログラムの不具合によって、DBサーバの在庫管理ファイルの一部に誤りが発生しており・・』と書かれています。

不具合のあるプログラムによって不正なデータが作成される。
ということは、修正PGの展開前にデータ修正したら、また不正データが新たに生まれる可能性があります。

先に修正PGを展開してからデータを修正するのが自然な流れなので、あとは解答文をなるべく問題本文内の表現で書くことに気を付けて書けばOKですね。

設問2-(2) 問題

本文中の下線(イ)について、Y氏が作業開始時刻の変更を提言した理由を、40字以内で具体的に延べよ。

設問2-(2) 解答例

欧州支社のサービス利用者が利用中の時間帯であり、業務に影響があるから。

設問2-(2) ポイント解説

[受注管理サービスのインシデント発生と対応]の②の記述を確認します。

『在庫管理ファイルの誤り修正作業は、APサーバからDBサーバへの通信が発生しない状態で行う必要がある』と書いてあります。
つまり、サービス停止が発生するということですよね。

[ツールによるデプロイの自動化]の欧州支社の業務影響に関する記述を確認します。

『業務影響を与えるので、PGを稼働環境にデプロイする時間帯を変更してほしい』
『欧州支社の1時間の休憩時間帯の開始時刻に当たる東京本社の20時に作業開始・・・』

サービス停止を伴うメンテナンスなので、欧州支社の休憩時間に合わせたい。
しかし、[受注管理サービスのインシデント発生と対応]の④では『22時から一連の作業を開始…』とあります。

ちょっと待ってよ、欧州支社の皆さんが休憩終わって仕事バリバリやってる時間帯じゃん。ってことになりますよね。
『東京本社の22時は欧州支社の14時であり、業務影響を与えるので』、時間帯変えてくれっていう要望を受けているY氏としては、これをスルーしちゃうと欧州支社から文句をいわれちゃう。
おそらく諮問会議の席上でY氏は「やば、これをそのまま承認したら怒られる」っていう感じで、焦ったに違いないです。(勝手な想像です笑)

設問3 [業務ルール変更計画の実施]について

設問3 (1) 問題

システム開発課がテストできるように、 [受注管理サービスのインシデント発生と対応]の対応完了後、システム運用課が速やかにテスト用サーバに対して実施すべき内容を、40字以内で述べよ。

設問3 (1) 解答例

売上プログラムと共通プログラムをテスト用サーバーの開発環境にデプロイする。

設問3 (1) ポイント解説

同時期に「適応保守」開発と「是正保守」開発が並行していることから、それぞれがPGの修正をしている元ソースに相違が出てしまうことをキャッチしてどう対応できるかを問う問題と言えます。

「是正保守」開発である不具合対応のプログラム修正対応が、「適応保守」開発である業務ルール対応プログラム修正より先に行われていましたよね。

図1の注釈を見てみます。

開発環境に関する注3に『適応保守で修正したプログラムのテストを行う』
保守環境に関する注2は『是正保守で修正したプログラムのテストを行う』
と書いてあります。

不具合対応の修正プログラムはまだ、開発環境に撒いてませんよね。
このまま業務ルール変更対応のプグラム修正とテストを行うと、稼働環境とは異なる状態でのテストになるため、既存機能にも影響がでるような不具合、デグレードのリスクが発生することになります。

ということで、いち早く「開発環境」に最新プログラムをデプロイすることが運用課のミッションになります。
解答文としては、対象のプログラム名、対象環境が明記されていることが採点基準になるだろうと思いますので、本文中の表現を使って記載するように心がけましょう。

設問3 (2) 問題

本文中の下線(ウ)について、システム開発課が追加で修正すべき内容を、25字以内で述べよ。

設問3(2) 解答例

共通プログラムの不具合修正内容を反映すること。

設問3(3) ポイント解説

ここまで時系列で確認してきた通り、適応保守開発は是正保守のプログラム修正前に行われています。
そして、是正保守が修正したのは「売上プログラム」と「共通プログラム」です。
適応保守開発の範囲は「請求プログラム」と「共通プログラム」でしたよね。

重複するのは「共通プログラム」なので、「共通プログラム」の不具合修正を反映させる必要がある、ということになります。

設問3(3) 問題

本文中の下線(エ)について、システム開発課が追加でテストすべき内容を、40字以内で述べよ

設問3 (3) 解答例

不具合を修正することによって、想定外の影響がでていないかどうかを確認すること。

設問3(3) ポイント解説

設問3(2)でもふれたとおり、このまま業務ルール変更対応のプグラム修正とテストを行うと、稼働環境とは異なる状態でのテストになるため、既存機能にも影響がでるような不具合、デグレードのリスクが発生することになります。

デグレチェックにあたる追加テストを40字使って説明する、というのがポイントです。
デグレがないかチェックする、と一言で済ませたいのですが膨らませる必要があります。
これはIPA記述試験で共通のルールですが、「40字以内」と指定された場合は、「より具体的にかけよ」という意味が込められています。
逆に「10字以内」の指定の場合は、「より端的に一言で答えなさいね」といった感じです。

膨らませ方のコツとしては、テストすべき背景とどのようなことを確認するテストかといった「なぜ」「なにを」「どうする」という要素を拾ってくることだと思います。

役割を入れ込む意味で「だれが」とか、時系列を答える必要があるなら「いつ」という感じで、設問によって要素は変わりますが、膨らませる=具体化するときには「5W1H」の要素を拾ってくる、ということを意識すると良いと思います。

以上