応用情報技術者 2023年 春期 午後 問10

解答の論理構成

1. 【問題文】の表2には、指標として
   • 「MTBF」(Mean Time Between Failures：平均故障間隔)
   • 「MTRS」(Mean Time to Restore Service：平均修復時間)
     が示されています。
2. MTBFは｢ITサービスを中断なしに、合意された機能を実行できる能力｣を測る指標です。長く故障しないほどサービスは安定するため、値は“大きい方が望ましい”です。
3. MTRSは｢ITサービスに障害が発生した後、通常の稼働状態に戻す能力｣を測る指標です。復旧に要する時間が短いほど利用者影響が小さいため、値は“小さい方が望ましい”です。
4. よって「MTBFの値は大きい方が、MTRSの値は小さい方が望ましい」とする選択肢「ア」が正解となります。

誤りやすいポイント

• MTBFとMTTR／MTRSを混同し、両方とも「短いほど良い」と誤解する。
• MTBFを「平均故障時間」と読み違え、値が小さい方が安定すると勘違いする。
• MTRSとダウンタイム全体を同義と考え、「長い保守時間＝高品質」と思い込む。

FAQ

解答の論理構成

1. 表2には三つの特性が並びます。
   • 「可用性」―指標は「サービス稼働率」
   • 「a性」―指標は「MTBF」
   • 「保守性」―指標は「MTRS」
2. ITIL では、可用性 (Availability) を構成する代表的な要素として
   • Reliability（サービスを中断なく提供できる能力）
   • Maintainability（復旧のしやすさ）
   を定義しています。
3. 表2の説明「ITサービスを中断なしに、合意された機能を実行できる能力」は ITIL の Reliability の説明と一致します。
4. Reliability を日本語訳すると通常「信頼性」です。
   • 5字以内という設問条件も満たします。
5. よって a に入る語は「信頼」となります。

誤りやすいポイント

• 「可用性」と「信頼性」を同一視してしまう
  (指標が異なるので混同は禁物です)。
• 「MTBF」を「保守性」と結び付けてしまう
  (MTBF は故障間隔＝信頼性の指標、MTRS が保守性の指標)。
• 「耐障害性」「冗長性」など類似語を当てはめる
  (どちらも MTBF の直接指標ではありません)。

FAQ

解答の論理構成

1. サービス稼働率計算式の確認
   表3には次の式が示されています。
   ――「（サービス時間 － サービス停止時間¹） ÷ サービス時間 × 100（％）」
   これが可用性（サービス稼働率）の算出公式です。
2. 目標可用性の把握
   表4には「月間目標値99.5%以上」とあります。したがって、ダウンタイムはサービス時間の $0.5\%$ 以内に収める必要があります。
3. 1 か月のサービス時間を計算
   同じく表4よりサービス時間は
   ――「L社の営業日の午前6時〜翌日午前2時（1日20時間）」
   1 月の営業日数は本文で「1 月の L 社の営業日の日数を 30」と明示されています。
   よって総サービス時間は
   $20\text{時間/日}\times 30\text{日}=600\text{時間}$
   分単位に直すと
   $600\text{時間}\times 60=36000\text{分}$ です。
4. 許容される停止時間を算出
   可用性 $99.5\%$ を維持するために許される停止時間 (Downtime) は
   $36000\times (1-0.995)=36000\times 0.005=180\text{分}$
5. 結論
   b に入る数値は 180 となります。

誤りやすいポイント

• 「24時間365日」と混同して 1 か月 720 時間で計算してしまう。
• 日数 31 日で計算、あるいは営業日以外も含めてしまう。
• $99.5\%$ を $0.95$ と読み違え、計算誤差を生む。
• 分換算を忘れ、答えを「3 時間」と書いて減点される。

FAQ

解答の論理構成

1. 既存の SLA（表4）には
   「サービス時間」「サービス稼働率」「計画停止時間」の3項目しかなく、障害発生後にどれだけ早く復旧できるかを示す項目がない。
   ――【問題文】「X 氏は、サービス停止しないことはもちろんだが、サービス停止した場合に迅速に対応して回復させることも重要だと考えた。」
2. ITIL では障害後の復旧能力を “保守性” と呼び、指標に「MTRS」を用いる。
   ――【問題文】表2「保守性…指標 MTRS」
3. SLA に復旧時間を組み込む場合、MTRS をベースに「サービス回復までの最大時間」など、上限時間を定義するのが一般的。
4. 以上より、X 氏が追加を検討するサービスレベル項目は
   「サービス回復までの最大時間」となる。

誤りやすいポイント

• 稼働率を高める＝可用性対策完了と早合点し、復旧時間（保守性）を軽視しがち。
• MTBF と MTRS を混同し、「平均故障間隔」を追加項目にしてしまう。
• 「インシデント対応時間」「障害検知時間」など似た用語を選び、SLA で求められる“回復完了まで”を定義し忘れる。

FAQ

解答の論理構成

• 【問題文】では、経理部が「勤務時間を製造部に合わせて…夜動を行う勤務体制」を検討しており、これに伴い「会計業務システムのサービス時間を見直す必要」があると記述されています。
• 一方、Sサービスのサービスカタログ（表3）には「計画停止時間　毎月1回　午前2時〜午前5時」と明示されています。
• しかし現在のSLA（表4）は「サービス時間　L社の営業日の午前6時〜翌日午前2時（1日20時間）」「計画停止時間　なし」としており、サービスカタログにある計画停止時間をSLA上は考慮していません。
• 夜勤体制を組むと午前2時〜午前5時も経理業務の稼働時間帯に含まれる可能性があります。すると、クラウド事業者が実施する「毎月1回　午前2時〜午前5時」の計画停止が業務に直撃し、サービス停止リスクが高まります。
• したがって、経理部とは「計画停止時間をどう扱うか」を調整し、勤務時間（＝業務利用時間）を計画停止時間と重複させないよう決定する必要があります。
• 以上より、②で調整すべき内容は「計画停止時間を考慮して経理部の勤務時間を定めること」となります。

誤りやすいポイント

• サービスカタログ（表3）の内容をSLA（表4）が自動的に包含すると誤解し、計画停止時間の存在を見落とす。
• 「サービス時間を延長する／24時間化する」という方向だけに着目し、計画停止時間との重複を検討し忘れる。
• 計画停止時間を「インシデントによる停止」と同列に扱い、稼働率計算に含めてしまう。

FAQ

解答の論理構成

1. IaaS ではクラウド事業者が担う層とユーザが担う層が明確に分かれます。問題文には
   　「I サービスでは、物理サーバ、ストレージシステム、ネットワーク機器などの IT基盤のコンポーネント(以下、物理基盤という) は、それぞれが冗長化されて…」
   　「また、ハイパーバイザー型の仮想化ソフト (以下、仮想化基盤という) を使って…」
   　とあり、M社がこれらを構築・維持していることが読み取れます。
2. 一方で、ゲストOSより上位の層については記述がなく、通常のIaaSモデルでは利用企業（ここではL社）が用意・管理します。したがって
   　・「ウ：ゲストOS」
   　・「オ：ミドルウェア」
   　・「ア：アプリケーションソフトウェア」
   　は L社の守備範囲です。
3. 以上から、M社が構築して管理する範囲は
   　イ：仮想化基盤
   　エ：物理基盤
   　の二つとなり、模範解答「イ、エ」と一致します。

誤りやすいポイント

• 「SaaS と IaaS を混同」
  会計系で利用している SaaS のイメージをそのまま当てはめ、アプリ層まで M社が管理すると誤解しやすいです。今回は I サービス（IaaS）であり責任分界点が異なります。
• 「ゲストOSもクラウド事業者が自動提供する」と思い込む
  PaaS ならOSまで面倒を見てもらえるケースがありますが、IaaS では OS の選定・パッチ適用は利用者側です。
• 「仮想化基盤＝ユーザが操作できるのでユーザ管理」と短絡する
  操作と運用責任は別物です。ハイパーバイザー自体の設計・冗長化・障害対応はクラウド事業者が負担します。

FAQ

解答の論理構成

1. 問題文では、IaaS を利用した災害対策サービスにより
   「西日本のDCのIサービスのユーザーデータファイルは、東日本のDCのIサービスのユーザーデータファイルと常時同期している」
   と説明されています。
2. これを受けて X 氏は
   「現在行っているユーザーデータファイルのバックアップの遠隔保管を廃止できる」
   と判断しました。
3. しかし前段でシステム部が実施していた対策は、
   「ストレージに保存されているユーザーデータファイルがマルウェアによって破壊されるリスクに備え、…フルバックアップを磁気テープに取得…遠隔地に保管」
   というものでした。
4. 常時同期は物理災害による停止には有効ですが、マルウェア感染や論理障害が発生した場合、その破壊データも即座に同期先へ伝搬します。
   ➡ リストア可能な“点”としてのバックアップを遠隔地に保持し続ける必要があります。
5. よって、上司が指摘した見直し点は「バックアップの遠隔地保管を廃止する」という X 氏の考えそのものです。

誤りやすいポイント

• 冗長構成とバックアップを同一視し、同期先があればバックアップ不要と誤解する。
• 災害対策＝地震・火災だけと考え、マルウェアや誤操作など論理障害を軽視する。
• 「99.99%以上」の高稼働率があればデータ保護も十分と勘違いし、RPO・RTOの視点を忘れる。

FAQ

解答の論理構成

1. 問題文は、X 氏が「サービス可用性管理」として「サービスカタログに記載されているサービスレベル項目のほかに、④可用性に関するKPIを設定する」ことを求めています。
2. 可用性を管理・改善する KPI には、ITIL などで「サービス停止回数」「平均故障間隔 (MTBF)」「平均修復時間 (MTRS)」といった“実際に起きた故障や停止”を直接数値化する指標が推奨されています。
3. 解答群を可用性との直接性で評価すると次のとおりです。
   • ア「M社が提供するサービスのサービス故障数」
     → 故障が発生した回数そのものであり、可用性低下の直接原因を示す代表的 KPI。
   • イ「M社起因のインシデントの問題を解決する変更の件数」
     → 変更の件数は改善施策の作業量であり、可用性“結果”を測る指標ではない。
   • ウ「M社のDCで実施した災害を想定した復旧テストの回数」
     → テスト回数は備えの活動量であって、可用性実績を示さない。
   • エ「M社のサービスデスクが回答した問合せ件数」
     → 利用者サポートの負荷を示すが、可用性とは無関係。
   • オ「SLAのサービスレベル目標が達成できなかった原因のうち、ストレージ容量不足に起因する件数」
     → 特定原因の件数で範囲が狭く、総合的な可用性 KPI になりにくい。
4. よって、最も適切な KPI は「ア：M社が提供するサービスのサービス故障数」となります。

誤りやすいポイント

• 「変更件数」や「復旧テスト回数」のように“活動量”を KPI と誤認して選択してしまう。KPI は“結果指標”としての可用性実績が求められます。
• 「ストレージ容量不足に起因する件数」のように原因を限定した指標を採ると、他要因の故障を把握できず改善の全体最適を損なうことに気付きにくい。
• 問合せ件数＝障害発生数と短絡的に結び付ける誤解。問合せは操作質問なども含み、可用性 KPI としては粒度が粗すぎます。

FAQ

解答の論理構成

1. 【問題文】では、災害発生時に「基幹業務システムを一部縮退」してコストを抑える方針を検討する場面で、X氏が⑤判断基準を設定すると述べています。
2. 同じ段落には、判断基準を「事業の視点から捉えた機能ごと」に適用し、「継続する機能を決める」と記されています。すなわち、BCPで最優先すべきかどうかを決める尺度は、事業継続に欠かせない機能かどうかです。
3. これに対応するキーワードは、前段で示された
   「基幹系業務の ITサービスは、生産管理など事業が成功を収めるために不可欠な重要事業機能を支援しており、高可用性の確保が必要である。」
   という一文に含まれる「重要事業機能」。
4. したがって、災害時に“どの機能を残すか”は「重要事業機能をどの程度支援しているか」で評価することになり、答えは
   「重要事業機能の支援度合い」
   となります。

誤りやすいポイント

• サービス可用性（稼働率）とサービス継続性（BCP対策）の区別を取り違え、可用性指標（MTBF／MTRSなど）を判断基準に挙げてしまう。
• 「重要」の対象を「システム」や「基幹系機能」と誤認し、本文にある「重要事業機能」を用いずに解答してしまう。
• 判断基準＝費用やリソース量と読み違え、コストそのものを挙げてしまう。

FAQ