応用情報技術者 2014年 秋期 午後 問10

解答の論理構成

1. 【問題文】には、 「問題を調査・分析してaを特定した経緯と結果」
   「問題のaを特定するための調査及び診断を行う」
   と二度繰り返し登場しています。ここで “特定” という動詞が使われていることから、a には「調査・分析の結果、究明する対象」が入ると読み取れます。
2. ITIL などの問題管理プロセスでは、障害の再発防止を目的に「根本原因（Root Cause）」を突き止めることが必須とされています。
3. 「調査・分析して○○を特定」「○○を特定するための調査及び診断」という流れは、まさに「根本原因」を探る一連の作業を指します。
4. 以上より、a に入る適切な字句は「根本原因」と判断できます。

誤りやすいポイント

• 「主原因」「原因分析」など、似た語を選んでしまう。問題管理の正式用語は「根本原因」です。
• インシデント管理の観点で「障害原因」と答えてしまう。問題管理では “根本” にこだわる点が重要です。
• 図1を先に見て「変更要求」や「暫定策」など他のキーワードと混同する。

FAQ

解答の論理構成

• 【問題文】には「初めに、問題管理データベースからbを参照して、過去に特定された問題でないか確認する。」とあります。ITIL の問題管理では、この参照対象は「既知の誤り（Known Error）」です。よって
  b＝「イ：既知の誤り」
• 「特定した問題は、問題管理データベースに記録する。」や「サービスデスクからの問題の通知」が冒頭に記載されており、これはインシデントが問題管理へエスカレーションされる典型形です。図1最上段のcは問題管理と密接に連携するプロセスであり、ITIL では「インシデント及びサービス要求管理」が該当します。よって
  c＝「ア：インシデント及びサービス要求管理」
• 【問題文】には「問題の恒久策実施のために、何らかの変更が必要な場合、変更要求（RFC）を発行する。」と明記されます。RFC を扱うプロセスは ITIL の「変更管理」です。図1でdは変更の有無を判断するひし形の右側に配置されており、変更プロセスを示しています。よって
  d＝「ク：変更管理」

誤りやすいポイント

• 「リリース及び展開管理」と混同しやすい
  RFC を扱うのは変更管理であり、リリース管理は変更確定後の本番展開フェーズです。
• 「構成管理」との取り違え
  構成管理は CI（構成アイテム）の属性や関係を維持しますが、インシデント起点の問題受付を示す c とは役割が異なります。
• 「暫定策」と「既知の誤り」の混同
  既知の誤りは原因が判明している問題の登録名であり、暫定策（ワークアラウンド）はその場しのぎの対処方法です。語句を取り違えると b を誤答しやすくなります。

FAQ

解答の論理構成

1. まず、障害原因は「ディスクの経年不良」と【問題文】に明記されています。

   分析の結果は、ディスクの経年不良となっていた。

2. 恒久策として取られていた対処は「障害を起こしたディスクを交換」するだけでした。

   恒久策として、障害を起こしたディスクを交換すると記載されていた。

3. しかし同一ロットのディスクは同時期に故障しやすいという証拠が示されています。

   同一の製造ロットで、同じように使用されているディスクは、障害も同時期に起こす確率が高い。

4. さらに実際に「一昨年度」「昨年度」「今年度」に繰り返し交換が発生している事実からも、交換しても根本原因（ロット全体の経年劣化）は残ったままです。
5. よってN君は「他のディスクも順次故障する可能性がある」と判断し、個別交換は恒久策にならないと結論づけました。

誤りやすいポイント

• 「RAID6 だから2台まで壊れても平気」と考え、恒久策＝交換で十分と誤解する。
• 「経年不良」を個体の問題と捉え、ロット全体に広がるリスクを見落とす。
• 障害回数の増加を偶然とみなし、傾向分析を行わない。
• 恒久策と暫定策の区別をあいまいにし、交換手順を恒久策に分類してしまう。

FAQ

解答の論理構成

1. 目的の再確認
   本問は、本文中の下線②「障害の兆候を出して、障害が発生する前に交換する方式」を実現するために、メッセージ監視機能の設定をどう変更すべきかを問うています。
2. 障害の兆候が分かるメッセージの特定
   【問題文】には、 「ディスクの読取りエラーと書込みエラーのエラーメッセージを検出すると問題管理担当者にメールで通知する設定になっているが、不良セクタの代替処理発生のメッセージを検出してもメールで通知する設定にはなっていなかった。」
   とあります。
   ここで “不良セクタの代替処理発生” メッセージこそが障害発生前に現れる兆候です。
3. 要求される設定変更
   したがって、既にメール通知されている「読取りエラー・書込みエラー」に加え、「不良セクタの代替処理発生」の検出時にもメール通知を行うよう設定を拡張すれば、障害の兆候を早期把握できます。
4. 40字以内でのまとめ
   上記を簡潔にまとめたものが模範解答
   「不良セクタの代替処理発生のメッセージの検出をメールで通知する。」
   となります。

誤りやすいポイント

• 読取りエラー・書込みエラーの通知は既に設定済みであることを見落とし、同じ内容を解答に書いてしまう。
• 「SMART情報を監視する」など本文にない追加機能を答えてしまい、設問条件を逸脱する。
• “不良セクタ” だけをキーワードにし、代替処理発生という「障害の兆候」を明示しないことで意図が伝わらなくなる。

FAQ

解答の論理構成

1. 事実確認
   ・「これまでに発生したディスク障害では、即時の対応を重視し、定期保守を待たず、日中、システムを停止せずにディスクを交換」していた。
   ・一方で「販売管理システムの定期保守は、週次に、システムを停止して実施している」。
   ・さらに「RAID6構成でシステムを停止せずにディスク交換した場合のデータ再構築処理は、高頻度のディスクアクセスを伴うので、機器に対する負荷が高く、二次的な障害の危険性が増す」というリスク情報も得ている。
2. 問題点の抽出
   システム稼働中の再構築はディスク全体に負荷を掛けてしまい、「同一の製造ロットで…障害も同時期に起こす確率が高い」状況では二次被害を誘発しやすい。
3. 解決方針の導出
   ・週次の定期保守ではシステムを計画停止するため、大量アクセスを回避できる。
   ・停止中なら再構築処理の I/O 影響が抑えられ、業務への影響も限定的。
   したがって、障害予兆を検知したディスクは「定期保守時のシステム停止中に交換」するのが最適となる。
4. 結論
   上記を踏まえ、本設問③の改善内容は「ディスク交換を定期保守時のシステム停止中に実施する。」である。

誤りやすいポイント

• RAID6 の冗長性を過信し、「稼働中交換が安全」と思い込む。再構築負荷による二次障害リスクが見落とされやすいです。
• 予兆検知後に“すぐ交換”と即断し、業務時間帯の I/O 影響を軽視してしまう。定期保守という計画停止の好機があることを忘れがちです。
• 「障害が発生する前に交換」のみで回答を終え、実施“時期”への言及を欠いて減点されるケースが目立ちます。

FAQ