ITサービスマネージャ 2014年 午後1 問03
データセンタの運用に関する次の記述を読んで、設問1～3に答えよ。
U社は、首都圏の数社の顧客からシステム運用を受託し、自社のデータセンタで運用サービスを提供している。U社では、データセンタで災害が発生しても運用サービスの提供に支障を来さないように、自家発電装置と無停電電源装置の設置、免震装置の導入などによって災害対策を強化している。
データセンタ全体は運用管理者が管理している。データセンタの組織には権限及び責任に対応して専門部署があり、電源及び空調設備関係についての専門部署にはファシリティ担当が割り当てられている。また、データセンタのオペレータは、受託したシステムの運用状態を表示するシステム監視コンソール、及び空調設備関係の状態を表示する空調監視コンソールを使い、日常監視を行っている。
〔オペレータが行うインシデント対応手順〕
オペレータは、システム監視コンソールと空調監視コンソールに表示されるメッセージによってインシデントの発生を認識し、対応を行う。インシデント発生時の対応手順を、表1に示す。
なお、目標復旧時間は、優先度“高”が2時間以内、優先度“低”が8時間以内と決められている。
システム監視コンソールと空調監視コンソールに出力される表示メッセージは、統一した基準に従って種類分けされている。例えば、空調監視コンソールの表示メッセージの種類は、表2のとおりである。
〔空調機に発生したインシデントとその対応〕
データセンタでは、10台の空調機を使用していて、そのうちの1台にインシデントが発生した。そのときの対応は、次のとおりであった。
① 22時に、警告メッセージ“空調機の一つが冷房設定から送風設定に切替え”が空調監視コンソールに出力された。
② オペレータは、インシデント管理システムにインシデントを登録し、優先度を割り当てて記録を更新した。
③ オペレータは、障害対応マニュアルを参照したが、当該メッセージについての対応指示の記載はなかった。
データセンタでは、毎日8時に運用管理者主催の運用会議を行っている。この会議には、オペレータとファシリティ担当が参加し、議題はオペレータの引継ぎ、インシデントの報告などである。
空調機にインシデントが発生した翌日の会議で、オペレータがインシデントの状況を報告した。報告を受けて、ファシリティ担当のS氏がサーバルームの温度変化の状況を調査した。その結果、想定以上の上昇傾向がみられた。この傾向が続くと、サーバルームの温度がデータセンタで定めた温度基準値を超え、重大な事態になる状況であったことから、運用管理者はS氏に改善の検討を指示した。
〔データセンタの入室管理〕
データセンタは幾つかの区画に分かれていて、各区画には多くの部屋がある。入室管理は次のとおりである。
・区画ごと、部屋ごとにアクセス権が設定されていて、入室が制限されている。
・入室場所には電子錠を設けていて、ICチップ付きの入室カードを使って開錠する。
外部関係者がデータセンタを訪問する際には、最初に入室受付で入室時の手続を行う。外部関係者の入室については、表3に示す手順を定めている。
〔空調機の臨時保守作業〕
S氏は、運用会議の後に、インシデントが発生した空調機の臨時保守作業を保守会社に依頼した。S氏は、当日10時から作業を開始するように依頼した後、保守作業者T氏の入室の事前申請を行い、承認された。入室場所は、インシデントが発生した空調機の設置場所であるサーバルームとした。予定時刻に到着したT氏は入室受付を行い、空調機の保守作業を実施した。
〔新規システムの受入れに伴う変更〕
データセンタでは、サーバ、ストレージ、保守端末などの機器類をラックに収容している。これらの機器をラックに収容するに当たっては、機器の重量、電源容量などを考慮する必要があり、V氏が専任のラック管理者として任命されている。ラック管理者は、ラック内の機器収容状況をラック収容情報として管理し、CMDBに登録している。ラック収容情報の更新権限は、ラック管理者だけに与えられている。
ある開発プロジェクトで新規システムを稼働させることになり、準備が始まった。データセンタでは、新規システムの受入れに際し、サービス担当者を選定し、受入れとサービスの運用を担当する。今回は、W氏がサービス担当者となった。また、U社では、新規システムの受入れに際し、U社規定の変更管理プロセスが適用される。そこでW氏は、変更要求を起票した。
V氏は新規システムの受入れに伴う、W氏の変更要求に基づき、サーバ、ストレージ及び保守端末の重量、電源容量などを考慮し、ラック内の収容場所を選定した。W氏が変更要求を起票した後、変更審査が行われ、V氏も審査員として参加した。変更審査は完了し、変更が承認された。V氏は承認された変更内容に基づき、新規に収容する機器の情報をラック収容情報としてCMDBに登録し、更新した。
〔構成監査の実施〕
U社の構成管理プロセスでは、毎月、構成監査を行うように規定されている。構成監査の一つとして、CMDBに登録されているラック収容情報に基づき、当該機器がラックに適切に収容されているかどうかを確認する。新規システムについて確認した結果、(ア)ラック収容情報にはW氏の変更要求に基づく保守端末の登録があるにもかかわらず、ラックには保守端末が収容されていないことが分かった。
運用管理者が変更管理の記録を調査したところ、W氏の変更要求については、変更を展開する作業で作業ミスが発生し、保守端末のラック収容も中止され、元に戻されていた。記録では変更の失敗が記載されていて、変更要求は終了していた。
なお、本番稼働まで日程に余裕があることから、現在、変更計画を見直している。計画が確定した後、再度新規システムの変更要求を行い、作業を実施する予定である。
運用管理者は調査を進め、W氏の変更要求に伴うV氏の作業が、変更管理に関わるサービスマネジメントのプロセス規定どおりに実施されていないことを発見した。そこで、運用管理者は、データセンタに構築されている構成品目と構成情報とで不一致が発生する事象の再発防止に向けて、（イ）プロセス規定の活動項目を周知し、データセンタの関係者に徹底することにした。
設問1：〔空調機に発生したインシデントとその対応〕について、(1)、(2)に答えよ。
設問1（1）
問題文を見るオペレータのインシデント対応における問題点を、理由を含めて50字以内で述べよ。
模範解答
表1の段階的取扱いで示した①及び③の状況が発生しているのに、専門部署に回復処理を依頼しなかった。
解説
解答の導き方
まず、インシデントの優先度が適切だったかを確認します。空調監視コンソールに表示されたのは「冷房設定から送風設定に切替え」という警告メッセージです。表2では、警告は優先度「低」のインシデントとして扱うため、この優先度の割当て自体は問題ではありません。優先度「低」の目標復旧時間は8時間以内です。
次に、表1の回復処理と段階的取扱いを確認します。オペレータは障害対応マニュアルを参照しましたが、当該メッセージへの対応指示はありませんでした。表1では「障害対応マニュアルに、表示メッセージに対応した処理の指示がない」場合、専門部署に回復処理を依頼すると定めています。したがって、この時点で専門部署へ依頼すべきでした。
さらに、インシデントが発生したのは22時で、翌日の運用会議は8時です。会議までに10時間が経過しており、優先度「低」の目標復旧時間である8時間を過ぎています。しかも、ファシリティ担当の調査では、サーバルームの温度が上昇し、温度基準値を超えるおそれがありました。この状況からも、目標復旧時間内に回復できないおそれがある場合に当たります。
つまり、表1の段階的取扱いで示された①と③の状況が生じていたにもかかわらず、専門部署に回復処理を依頼しなかったことが、オペレータの対応上の問題です。
誤りやすいポイント
- 警告を優先度「低」とすることと、専門部署への依頼が不要であることを混同しないでください。優先度にかかわらず、表1の条件に該当すれば段階的取扱いが必要です。
- 「障害対応マニュアルに指示がない」場合も、オペレータが対応を続けるのではなく、専門部署へ依頼します。
- 翌日の会議で状況を報告したことだけでは、目標復旧時間内の対応や専門部署への依頼を満たしたことにはなりません。
FAQ
Q: 優先度「低」でも、専門部署への依頼が必要ですか？
A: はい。優先度は目標復旧時間を決めるものです。マニュアルに対応指示がない場合など、表1の条件に該当すれば依頼が必要です。
A: はい。優先度は目標復旧時間を決めるものです。マニュアルに対応指示がない場合など、表1の条件に該当すれば依頼が必要です。
Q: ③の状況と判断できる根拠は何ですか？
A: 22時の発生から翌日の8時までに10時間が経過し、8時間以内という目標復旧時間を過ぎています。加えて、温度上昇が続けば基準値を超えるおそれがあると分かっています。
A: 22時の発生から翌日の8時までに10時間が経過し、8時間以内という目標復旧時間を過ぎています。加えて、温度上昇が続けば基準値を超えるおそれがあると分かっています。
Q: 優先度の割当てが問題だったのですか？
A: いいえ。警告メッセージは表2で優先度「低」とされています。問題は、マニュアルに指示がないと分かった後も専門部署に依頼しなかったことです。
A: いいえ。警告メッセージは表2で優先度「低」とされています。問題は、マニュアルに指示がないと分かった後も専門部署に依頼しなかったことです。
関連キーワード: インシデント管理、優先度判定、目標復旧時間、段階的取扱い、エスカレーション
設問1（2）
問題文を見る温度の異常につながる温度の上昇を早期発見するために、表示メッセージを改善する場合、その改善策を60字以内で述べよ。
模範解答
温度警告用のしきい値を設定し、定期的な温度状況表示の際、測定値がしきい値を超えた場合は種類を警告に変更する。
解説
解答の導き方
この設問では、サーバルームの温度が基準値を超えて異常になる前に、温度上昇の兆候を検知する方法を考えます。
本文では、空調機が冷房設定から送風設定に切り替わったときは「警告」メッセージが出ています。一方、表2では、定期的な温度状況の表示は「通知」であり、温度がデータセンタで定めた温度基準値を超えると「異常」として扱うことが分かります。つまり、温度基準値を超えてからでは、異常を早期に捉えることができません。
また、S氏が温度変化を調査したところ、想定以上の上昇傾向があり、その傾向が続くと温度基準値を超える状況だったとあります。空調機の設定切替えだけでなく、実際に測定した温度の上昇を早く検知する必要があります。
そこで、温度基準値に達する前の段階で警告できるよう、温度警告用のしきい値を設定します。定期的な温度状況の表示時に測定値をそのしきい値と比較し、超えていた場合は、表示メッセージの種類を「警告」に変更すれば、温度上昇を早期に把握できます。
誤りやすいポイント
- 空調機が冷房設定から送風設定に切り替わったことだけを監視対象にすると、実際のサーバルームの温度上昇を直接捉えられません。
- 温度がデータセンタで定めた温度基準値を超えた時点で「異常」とするだけでは、異常になる前の兆候を早期に検知できません。
- 温度状況を表示するだけではなく、しきい値を超えた場合にメッセージの種類を「警告」に変更することまで示す必要があります。
FAQ
Q: 温度基準値を超えた場合に「異常」と表示する仕組みだけでは不十分なのはなぜですか。
A: 基準値を超えた時点ですでに異常状態だからです。基準値に達する前の上昇を検知するため、より早い段階のしきい値を設けます。
A: 基準値を超えた時点ですでに異常状態だからです。基準値に達する前の上昇を検知するため、より早い段階のしきい値を設けます。
Q: 温度がしきい値を超えたら、なぜ「警告」にするのですか。
A: 温度基準値を超える前の注意すべき状態として知らせ、異常に至る前に対応できるようにするためです。
A: 温度基準値を超える前の注意すべき状態として知らせ、異常に至る前に対応できるようにするためです。
関連キーワード: しきい値、温度監視、警告メッセージ、異常検知、インシデント管理
設問2：
問題文を見る〔データセンタの入室管理〕について、表3中の作業手順④では、許可された者だけにアクセスを許すために、ある確認を行っている。aに入れる適切な内容を、30字以内で述べよ。
模範解答
・作業者が本人であることの確認を行う。
・作業者の識別情報を認証する。
解説
解答の導き方
-
設問は、入室時の手続④で、入室管理者が申請内容などを確認した後に行うことを問うています。外部関係者には、事前申請とその承認が必要です。
-
入室管理者は、作業者が記入した入室受付票と、承認済申請内容を照合します。これにより、訪問日時や作業者氏名、入室場所などが申請と一致しているかを確認できます。
-
ただし、記載内容が一致していても、受付に来た人が申請された作業者本人であるとは限りません。別人が申請者の氏名を名乗っている可能性があるため、許可された者だけを入室させるには、作業者が申請者本人であることも確認する必要があります。
-
その確認をしたうえで、手続⑤では「入室場所のアクセス権を入室カードに登録」します。したがって、aには、作業者本人であることを確認する内容が入ります。「作業者の識別情報を認証する」という表現も適切です。
誤りやすいポイント
- 入室受付票と承認済申請内容の照合だけで、本人確認もできていると考えないようにしましょう。照合できるのは、記載された情報の一致です。
- 入室カードにアクセス権を登録することと、作業者本人を確認することは別の手続です。本人確認は、カードを貸し出す前に必要です。
- 入室場所のアクセス権を確認するだけでは、受付に来た人が許可された作業者かどうかは判定できません。
FAQ
Q: 申請内容と受付票の照合だけでは、なぜ不十分なのですか？
A: 記載内容が一致していても、受付に来た人が申請された作業者本人とは限らないためです。
A: 記載内容が一致していても、受付に来た人が申請された作業者本人とは限らないためです。
Q: 本人確認の具体的な方法まで答える必要がありますか？
A: 問われているのは確認する内容です。作業者本人であることの確認や、作業者の識別情報の認証を示せば十分です。
A: 問われているのは確認する内容です。作業者本人であることの確認や、作業者の識別情報の認証を示せば十分です。
関連キーワード: 本人確認、認証、アクセス制御、入退室管理、アクセス権
設問3：〔構成監査の実施〕について、(1)、(2)に答えよ。
設問3（1）
問題文を見る本文中の下線（ア）の状況が発生した原因を、〔新規システムの受入れに伴う変更〕のV氏の作業内容に基づいて、50字以内で述べよ。
模範解答
変更の展開前に、新規に収容する機器の情報をラック収容情報として登録し、CMDBを更新したから
解説
解答の導き方
-
まず、構成監査で見つかった不一致を確認します。ラック収容情報には保守端末が登録されている一方、実際のラックには保守端末がありません。つまり、CMDBに記録された構成と、データセンタにある実物の構成が一致していません。
-
次に、V氏がCMDBを更新した時点を追います。本文では、変更審査が完了して変更が承認された後、V氏が新規に収容する機器の情報をラック収容情報としてCMDBに登録しています。これは、変更の実作業が完了する前に、予定している機器構成をCMDBに反映したことを示しています。
-
その後の実作業では、作業ミスによって保守端末のラック収容が中止され、元に戻されています。変更の記録にも失敗が記載されています。したがって、実際の構成は変更前の状態に戻ったのに、CMDBには変更後の予定構成が登録されたままになり、不一致が発生しました。
この流れから、原因は、変更の展開前に新規に収容する機器の情報をラック収容情報として登録し、CMDBを更新したことだと判断できます。承認された計画と、実際に変更が完了した状態は別に扱う必要があります。
誤りやすいポイント
- 保守端末の収容作業が失敗したことだけを原因にしないことです。失敗後に実物が元の状態に戻ったとき、CMDBの記録も実際の状態に合わせておく必要があります。
- 変更が承認された時点で、機器の収容が完了したと考えないことです。承認は変更を実施してよいという判断であり、作業の完了を意味しません。
- 「変更の記録が失敗を記載していた」ことと、CMDBの構成情報が正しいことを混同しないことです。変更記録と構成情報は別の情報です。
FAQ
Q: 変更が承認された段階で、CMDBを更新してはいけないのですか？
A: 承認された内容は実施予定の構成です。実際の変更が完了したかどうかを確認し、完了した構成をCMDBに反映する必要があります。
A: 承認された内容は実施予定の構成です。実際の変更が完了したかどうかを確認し、完了した構成をCMDBに反映する必要があります。
Q: 今回の不一致は、作業ミスだけで起きたのですか？
A: 作業ミスによって保守端末の収容が中止されたことが直接のきっかけです。しかし、不一致が残った原因は、実作業より先にCMDBを変更後の構成に更新していたことです。
A: 作業ミスによって保守端末の収容が中止されたことが直接のきっかけです。しかし、不一致が残った原因は、実作業より先にCMDBを変更後の構成に更新していたことです。
Q: 変更が失敗して元に戻された場合、構成情報はどうあるべきですか？
A: 実際に構築されている構成を表す状態に保ちます。CMDBが変更後の内容に更新済みであれば、失敗後の実際の状態に合わせて修正する必要があります。
A: 実際に構築されている構成を表す状態に保ちます。CMDBが変更後の内容に更新済みであれば、失敗後の実際の状態に合わせて修正する必要があります。
関連キーワード: CMDB、変更管理、構成監査、構成情報、ロールバック
設問3（2）
問題文を見る本文中の下線（イ）で周知すべき活動項目の具体的な内容を、30字以内で述べよ。
模範解答
CMDBの記録は、変更の展開の成功後に更新する。
解説
解答の導き方
-
この設問は、構成情報と実際の機器の状態が食い違わないようにするため、変更管理のどの活動を関係者に徹底するかを問うています。
-
本文では、変更が承認された後、V氏が「新規に収容する機器の情報をラック収容情報としてCMDBに登録し、更新した」とあります。この時点では変更が承認されたことは分かりますが、機器の収容作業が成功したことまでは確認できません。
-
その後、変更の展開作業でミスがあり、保守端末のラック収容は中止されて元に戻されていました。つまり、実際には保守端末がラックにないのに、CMDBには保守端末が登録された状態となり、構成情報との不一致が生じています。
-
したがって、再発防止のために周知するのは、変更が承認された段階ではなく、変更の展開が成功した後にCMDBを更新するという活動です。
誤りやすいポイント
- 変更の承認と変更の展開の成功を同じものとして扱わないようにします。承認は実施してよいという判断であり、実際に構成が変更されたことを示すものではありません。
- 「変更要求を終了する」と「CMDBの記録を更新する」を混同しないようにします。問われているのは、構成情報と実際の状態の不一致を防ぐための更新時期です。
- 変更計画の見直しや再申請を答えにしないようにします。設問は、今回の不一致を防ぐために周知すべきプロセスの活動項目を尋ねています。
FAQ
Q: 変更が承認された時点でCMDBを更新してはいけないのですか？
A: 承認時点では、作業がまだ実施されていない可能性があります。変更後の構成が実際に実現したことを確認してから更新します。
A: 承認時点では、作業がまだ実施されていない可能性があります。変更後の構成が実際に実現したことを確認してから更新します。
Q: 変更の展開に失敗した場合、CMDBはどう考えればよいですか？
A: 実際の構成が変更前の状態に戻っているなら、CMDBも実際の構成と一致している必要があります。変更後の構成を登録したままにすると不一致になります。
A: 実際の構成が変更前の状態に戻っているなら、CMDBも実際の構成と一致している必要があります。変更後の構成を登録したままにすると不一致になります。
Q: なぜCMDBの更新時期が重要なのですか？
A: CMDBの情報を実際の構成と一致させるためです。記録が実態と異なると、構成の把握や運用上の判断に支障が生じます。
A: CMDBの情報を実際の構成と一致させるためです。記録が実態と異なると、構成の把握や運用上の判断に支障が生じます。
関連キーワード: 構成管理、変更管理、CMDB、構成監査、変更の展開
