解説

• MTBF(Mean Time Between Failure)は、システムの修復が完了し正常に稼働し始めてから、次回故障するまでの平均の時間、すなわち平均故障間隔を指します。より長い期間にわたり故障せずに連続で稼働できるシステムの方が優れているため、故障から故障までの期間は長いほど良いことになります。よって、MTBFは大きいほど望ましいと言えます。
  なお、サービスマネジメントにおいては、システムダウンに至らないサービス品質の低下もインシデントと捉えるので、MTBFの代わりに平均サービス・インシデント間隔(MTBSI)という指標が使用されることもあります。
  
  MTRS(Mean Time to Restore Service)は、サービスが停止したときに、サービスを復旧させるために要する平均の時間、すなわち平均サービス回復時間を指します。当然ながら、サービス停止している時間は短いほど良いので、MTRSは小さいほど望ましいと言えます。
  
  したがって「ア」の記述が適切です。
  
  ∴ア：MTBFの値は大きい方が，MTRSの値は小さい方が望ましい。
  
  
• 〔aについて〕
  空欄には、MTBFが評価指標となっている特性の名称が入ります。"a性"という語尾、表2の「ITサービスを中断なしに，合意された機能を実行できる能力」という説明、およびMTBFを指標としていることを総合すると、システムやサービスマネジメントについての一般的な知識より、信頼性が当てはまることがわかります。信頼性は、ITサービスまたは他の構成アイテムが中断なく、合意された機能をどれだけ長く実行できるかを示す指標であり、MTBFまたはMTBSIとして測定・評価されます。したがって空欄aには「信頼」が当てはまります。
  
  ∴a＝信頼

解説

• 〔bについて〕
  空欄を含む一文は「サービス停止の月間合計時間がb分以下であれば，表4のサービス稼働率のサービスレベル目標を達成する」となっているので、サービスレベル目標を達成するために許容される1月の最大サービス停止時間を計算することになります。分単位で答えることに注意が必要です。
  
  ここで計算の前提となる各条件は次のとおりです。
  • 目標とするサービス稼働率は99.5%
  • サービス稼働率の算出式は、サービス時間－サービス停止時間サービス時間×100
  • サービス時間は、午前6時～翌日午前2時の1日20時間
  • 1月のL社の営業日の日数は30日
  L社の1月のサービス時間は「20時間×30日＝600時間」です。サービス稼働率の算出式を見ると、サービス停止時間をサービス時間全体の「1－99.5%＝0.5%」以内に収めればよいとわかるので、
  
  　600時間×0.5％＝3時間＝180分
  
  したがって空欄bには「180」が当てはまります。
  
  ∴b＝180
  
  愚直に各値をサービス稼働率の算出式に当てはめて、
  
  　99.5 ≦ 600時間－サービス停止時間600時間×100
  　99.5×600÷100 ≦ 600－サービス停止時間
  　99.5×6 ≦ 600－サービス停止時間
  　597 ≦ 600－サービス停止時間
  　サービス停止時間 ≦ 3時間 ＝ 180分
  
  と計算することもできます。
  
  【別解】
  問題文中の「90分間サービス停止した。3月のL社の営業日の日数を30とすると，サービス稼働率は99.75%」に着目すると、同じ営業日数のときに90分間の停止で0.25%だけ稼働率が低下したことから、その2倍まで許容できることになるので「90分×2＝180分」と導くことができます。
  
  
• 下線①を含む文は「X氏は，サービス停止しないことはもちろんだが，サービス停止した場合に迅速に対応して回復させることも重要だと考えた。そこで，X氏はM社の責に帰するインシデントが発生してサービス停止したときのサービスレベル項目を表4に追加できないか，M社と調整することにした」となっています。文脈より、追加されるサービスレベル項目はサービスが停止したときに、ダウン状態から迅速に回復させることを目的としていることがわかります。
  
  表4を確認するとサービス稼働率についてはM社と合意している一方で、サービス停止した場合の回復時間についてはM社と合意していません。X氏はこの状況を鑑みて、サービス停止した場合にサービスを回復させる時間についても、SLAに含めるべきであると考えたと判断できます。したがって「サービス停止からサービス回復までの時間」「サービス停止からの復旧時間」などの解答が適切となります。
  
  ∴サービス回復までの最大時間
  
  
• 下線②を含む文は「今後，経理部では，勤務時間を製造部に合わせて，交替制で夜勤を行う勤務体制を採って経理業務を行う…。この場合，会計系業務システムのサービス時間を見直す必要がある。そこで，X氏は，…，経理部との調整を開始することにした」となっています。文脈より、調整事項とは経理部の勤務体制の変更と会計業務システムのサービス時間に関連する内容であるとわかります。
  
  Sサービスのサービス時間について表3を確認すると、計画停止時間として毎月1回、午前2時から午前5時の間、サービス停止する旨が記載されています。計画停止でSサービスが停止すると、会計系業務システムも当然に使用できなくなり、夜勤中の経理部の業務に支障を来します。経理部が夜勤を行うことになった場合には、計画停止時間を避けて業務を行う必要があるため、その調整が経理部との間で必要となります。
  
  ∴計画停止時間を考慮して経理部の勤務時間を定めること

解説

• パブリッククラウドのIaaSである、Iサービスを提供するM社の管理範囲が問われています。IaaS(Infrastructure as a Service)は、CPU、メモリ、ストレージ、ネットワーク、電源などの基礎的なハードウェアリソースをサービスの形で提供するものです。サービス利用者は、提供されたインフラ機能の上に、OS、ミドルウェア、開発環境、システムやアプリケーションを含む任意のソフトウェアを用意し、実装し、稼働させることができます。
  
  クラウドサービスでは、サービスとして提供される部分はサービス提供者側の管理に属し、利用者が独自に実装した部分はサービス利用者側の管理に属します。本文中の記述を読むと、Iサービスでは物理サーバ等の物理基盤が提供され、仮想化基盤を使って仮想マシン環境を実現しているとありますから、サービス提供者であるM社が構築して管理する対象は「イ：仮想化基盤」と「エ：物理基盤」であるとわかります。それ以外は、Iサービスの上にL社が構築する部分ですので、L社の管理する範囲となります。
  
  ∴イ，エ
  
  
• 本文中にはX氏の考えた内容として3つが記載されています。1つ目の自然災害に対して有効という点は、東日本と西日本にDCがあることから適切、2つ目の物理サーバの機器障害でも業務を継続できるという点も、物理基盤が冗長化されていることから適切と言えます。したがって、指摘の対象となったのは、3つ目の現在実施しているバックアップの遠隔地への保管（以下、遠隔地保管）を廃止できるという考えであると見込みがつきます。
  
  L社の現在のバックアップ状況は、定期的にユーザーデータファイルのフルバックアップを2組の磁気テープに取得し、1組を本社に、もう1組を遠隔地保管するというものです。遠隔地保管をやめるということは、L社側のバックアップは本社に保管されるものだけになるということです。
  
  一方、Iサービスから提供される災害対策サービスについては、次のように説明されています。
  • 西日本のDCのIサービスにもユーザーデータファイルを保存し，東日本のDCのIサービスのユーザーデータファイルと常時同期させる
  • 東日本のDCの仮想マシン環境のシステムイメージは，システム変更の都度，西日本のDCにバックアップを保管しておく
  この2点より、ユーザーデータファイルは2つのDCで同期されているだけで、定期バックアップの対象とはなっておらず、ユーザーデータファイルのバックアップが取得されるのは、システムの変更時のみということが読み取れます。ファイルの同期はデータを最新に保つことを目的としており、バックアップの代替として使うことはできません。もしも片方のシステムのデータがマルウェア等の侵入により破壊されてしまった場合、その破壊されたデータがそのまま同期されてしまうことになり、過去のバージョンには復元できないためです。
  
  クラウドサービス利用の一般的なリスクマネジメントとして、サービス提供者がバックアップ機能を提供しない場合は、利用者側がバックアップ機能の導入に責任を負うことになります。特にハードウェアリソースの提供を主とするIaaSでは、バックアップ取得の責任は一般的には利用者側にあります。また、急なサービス停止や両DCのデータが同時に破損してしまう可能性もゼロではないので、備えとしてクラウドサービス上のデータのバックアップを取得しておくことは重要です。
  
  Iサービス側で定期バックアップがされていない以上、クラウドに構築した基幹系業務システムのユーザーデータファイルをバックアップする責任はL社にあります。したがって、従前のとおり本社保管だけではなく、災害対策としての遠隔地保管を実施する必要があります。したがって、遠隔地保管を廃止というX氏の考えは見直すべきであると言えます。
  
  ∴バックアップの遠隔地保管を廃止すること
  
  
• 可用性は、利用者が必要なときに必要なだけ利用できる度合いです。またKPI(Key Performance Indicator)は、目標達成のために行う活動の実施状況をモニタリングするための指標です。可用性の良しあしを左右するという視点から考えると、可用性に関してモニタリングすべきとして、サービスカタログで提示されている稼働率のほか、故障回数、MTBF、MTBSI、MTRSなどが考えられます。
  
  したがって、可用性に関連するKPIとして適切なのは「ア：サービス故障数」となります。これは午前問題でも頻出の論点です（H29春55ほか）。
  • 正しい。可用性管理のKPIです。
  • インシデント管理のKPIです。
  • ITサービス継続性管理のKPIです。
  • サービスデスクのKPIです。
  • キャパシティ管理のKPIです。
  ∴ア：M社が提供するサービスのサービス故障数
  
  
• 下線⑤の判断基準とは、基幹系業務システムのうち、災害時に継続する機能と縮退する機能とを事業の視点から選択するための基準です。非常災害時には、平常時に実施している全ての事業・業務を継続することは困難となり、重要な事業に必要不可欠な業務から優先順位を付けて継続または早期復旧することが求められます。BCPの策定においては、事業影響度分析を行った結果を踏まえて、優先的に継続・復旧すべき重要業務を特定し、目標復旧時間や目標復旧レベルを決定します。かたや重要業務ではないと判断された業務は、重要業務の復旧にめどがついた段階で復旧時期を検討することになります。
  
  基幹系業務システムの事業視点からの役割について確認すると、〔L社のITサービスの現状〕に「基幹系業務のITサービスは，生産管理など事業が成功を収めるために不可欠な重要事業機能を支援しており，高可用性の確保が必要である」と記述されています。重要事業機能の支援する機能については継続する必要があるので縮退の対象からは外し、その他の部分の縮退を考えることになります。つまり、縮退対象となるかどうかは、機能ごとに重要事業機能を支援する度合いによって決定されることになります。
  
  ∴重要事業機能の支援度合い