運用管理・評価・監査

このページは、作ったシステムをどう安定運用し、どう評価するか を整理するページです。

開発が終わったあとの「回す段階」で必要になる ITIL、SLA、システム監査、内部統制、信頼性指標 を、運用管理、合意水準、評価・監査の流れで切り分けます。

試験では、これらが「何を目的にしているのか」「どんな場面で使い分けるのか」「何を指標にするのか」を問われます。

ITIL（IT Infrastructure Library）は、IT サービス運用を体系立てて整理した ベストプラクティス集 です。重要なポイントは「ツールや製品ではなく、運用をどう組織するか」という知識体系だということです。

システム開発の仕事は「本番リリースの瞬間」で終わりではなく、その後「何年も止めずに運用し続ける」ことが実際の価値を生みます。ITIL は、その長期的な運用を体系的・計画的・継続的に改善する ための共通言語を提供します。

試験では「ITIL は枠組み」「SLA は目標値」と切り分けることが重要です。ITIL は「何をすべきか」の構造、SLA は「どのレベルで達成するか」の具体数字です。

ITIL v3 では、IT サービスの全体を 5 つの段階（ライフサイクル）に分けます。各段階には主要なプロセスと目的があります。

メカニズム: 各ライフサイクルが順番に進むのではなく、循環します。改善サイクルの中で「戦略→設計→移行→運用→改善→(戻って戦略へ)」という流れです。この循環が「継続的」という言葉の意味です。

試験では「本番運用で具体的に何をするか」が問われるため、サービスオペレーション の代表的なプロセスを深く理解することが重要です。

この 2 つはしばしば混同されますが、対象と目的が全く異なります。一つは「症状」を扱い、もう一つは「原因」を扱う並行活動です。

メカニズム: インシデントが報告された直後、運用チームは並行して 2 つの活動 を始めます。一つは「とにかく復旧させる」インシデント対応で、もう一つは「なぜこんなことが起きたのか」を調べる問題管理です。つまり、復旧と根本原因調査は同時進行 します。復旧が先でなければサービスが止まったままだし、原因を調べずに再起動だけしていると、同じ障害が何度も起きます。

試験での見分け方: 「とにかく直す」「素早く復旧」という言葉が出たらインシデント。「なぜそれが起きたのか」「原因を調査」「再発防止」という言葉が出たら問題管理です。

システムに加えるあらゆる変更（OS パッチ、設定変更、新機能リリース、ライブラリ更新など）を統制するプロセスです。

目的: 変更による予期しない障害（サイドエフェクト）を防ぎながら、必要な変更を計画的に進める。

流れ: 変更要求が出ると、CAB（Change Advisory Board：変更諮問委員会）という審査会が「この変更は安全か」「他のシステムに影響しないか」を検討してから実行を許可します。

標準変更 vs 緊急変更:

緊急時は手続きを簡略化しても、記録には残します。これが「監査証跡」となり、後の監査で「なぜこの変更を入れたのか」を説明できるようにします。

複数の変更や新機能を「まとめて」本番環境に導入するプロセスです。個別の変更を 1 つ 1 つ入れるのではなく、テスト済みのパッケージとして展開するという考え方です。

IT 環境を構成するあらゆる要素（ハードウェア、ソフトウェア、ライセンス、ドキュメント）の情報を一元管理します。これにより「今、本番で何が動いているのか」を常に把握できます。

構成管理の 3 つの要素:

メカニズム：CMDB を更新し続けることで、「突然障害が起きた時に何が変わったのか」を即座に追跡できます。

システムの処理能力を計画的に管理し、パフォーマンスを保つプロセスです。「CPU が 80% で止まる」「メモリが満杯」といった状況を事前に防ぎます。

サービスが利用可能な状態をどれだけ保つかを管理します。目標（SLA）を立てて、それを実現するための施策（冗長化、フェールオーバー等）を講じます。

メカニズム：稼働率を上げるには、故障を減らす（MTBF を大きく）か、復旧を速くする（MTTR を小さく）か、またはその両方を改善します。

サービスレベルを管理する際、外部との合意、内部目標、部門間の約束という 3 つの異なるレベル があります。試験では、この 3 者の関係と使い分け を理解することが重要です。

3 者の関係: 外側から内側へ、段階的に「より高い目標」を設定します。

なぜバッファが必要なのか: SLA（99.9%）がぎりぎりの目標では、ちょっとの問題で達成できなくなります。だから内部的には SLO（99.95%）という高い目標を立て、多少の問題が起きても SLA を守れるようにします。

ある企業が SaaS 型の顧客管理システムを導入した場合：

過去問では、SLA・OLA に似た略語として UC や NDA を混ぜてきます。ここで重要なのは、UC はサービス提供を下支えする契約、NDA は秘密保持の契約 であり、役割がまったく違うことです。

たとえば、顧客に「99.9% 稼働」を約束する SaaS 企業は、自社内では OLA を結び、データセンター事業者や回線事業者とは UC を結ぶことがあります。一方で、業務委託の打合せ前に交わす NDA は、稼働率や応答時間を定める文書ではありません。

試験で サービス水準を規定する文書はどれか と聞かれたら、NDA を外せるかがポイントです。

年度別の設問では、SLA、SLM、ITSMS、ISMS を一気に並べて、文書 と 活動 と 管理の仕組み を混線させる問題が出ます。ここは「何者か」を先に固定すると迷いにくくなります。

SLA は外部に見せる約束、SLM はそれを回す運用管理、ITSMS は IT サービス管理全体の枠組みです。したがって、サービス品質を継続的に管理する仕組み を問われたら ITSMS、契約として何%を約束するか を問われたら SLA、その達成状況を見て改善する活動 を問われたら SLM を選びます。

また、ITSMS と ISMS は名前が似ていますが、前者は サービス品質、後者は 情報セキュリティ が中心です。可用性や応答時間 が主語なら ITSMS、漏えい・改ざん・アクセス制御 が主語なら ISMS と切ると誤答を減らせます。

認証制度が出る問題では、規格そのもの と 制度を運営する登場人物 が混ざります。ここは 誰が審査するか 誰が認めるか 何を認証するか で整理します。

また、ITSMS と ISMS では参照規格が違います。ITSMS は IT サービス管理、ISMS は情報セキュリティ管理です。したがって、JIS Q 20000-1 は IT サービス管理の文脈、ISO/IEC 27001 は情報セキュリティ管理の文脈だと切り分けます。

認証制度の設問では、固定のセキュリティレベルを守る制度 と読んでしまうと誤ります。認証は 管理の仕組みを継続的に回しているか を見るものであり、単一の設定値を守るだけではありません。

年度別の設問では、ITSMS 認証は会社全体でしか受けられない、単一組織内のサービスだけが対象 のような誤答が出やすいです。ここは 認証の対象はサービスマネジメントの仕組み であり、必ずしも会社全体を丸ごと問う制度ではないと押さえます。

試験で 可用性や応答時間を継続的に管理、サービス単位、認証登録 とあれば、ITSMS 認証の文脈を疑います。反対に、機密性・完全性・可用性 を情報資産保護の観点で問うなら ISMS です。

システム監査は、情報システムが有効・安全・効率的に運用されているかを、独立した第三者が評価する活動 です。重要なポイントは「独立性」です。被監査部門から独立していなければ、「自分たちに都合よい評価」になってしまいます。

メカニズムの本質は「プロセスチェック」です。「このシステムは安全に作られたのか」「運用は正規の手続きに従っているのか」「記録は適切に残っているのか」を確認します。

試験での頻出ポイント: システム監査は「助言」が目的であり、改善の実施は被監査部門が行います。監査人は「問題を指摘する」役、「改善する」役ではありません。

実際の監査プロセスは以下のような順序で進みます。

監査では「どうして『そこに問題がある』と判定したのか」を明確に示す必要があります。

これらが無いと「単なる感想」になるため、監査の信頼性が失われます。

監査には 2 つのアプローチがあります。

試験では両方の概念が出るので、違いを理解しておく必要があります。

内部統制は、企業の業務が適正に行われるための仕組みや体制 です。システム面だけでなく、組織全体のルール、手続き、監視の枠組みを含みます。

金融商品取引法（J-SOX 法）で上場企業に内部統制報告書の提出が義務付けられています。これが「内部統制が試験に出る」理由です。

内部統制を実装するには、6 つの要素が互いに支え合う必要があります。

IT 統制は「基盤」と「個別業務」の 2 層で考えます。

IT 全般統制: システム開発・保守、運用管理、アクセス管理、バックアップ等の 基盤的な統制

IT 業務処理統制: 個々の業務処理の正確性・完全性を確保する 業務的な統制

メカニズム：IT 全般統制が不十分だと（例えば、誰でも本番 DB を改ざんできる）、IT 業務処理統制も機能しません。基盤あってこその業務統制です。

この 3 つも頻繁に混同されますが、守るべき内容、日常的に回す仕組み、独立して点検する活動 という役割差があります。

コンプライアンス は「何を守るべきか」であり、活動そのものの名前ではありません。内部統制 は守れる状態を作る仕組みで、システム監査 はその仕組みが本当に機能しているかを、独立した立場から確かめる活動です。したがって、監査人が自ら改善を実施する という選択肢は不適切です。

システムの品質を数字で測るための指標群です。試験では特に計算問題が出題されやすいため、各指標の計算式と意味を確実に理解する必要があります。

可用性 と 信頼性 を同じ意味で覚えると、年度別の設問でかなり落とします。壊れにくさ と 使える割合 は別物です。

つまり、信頼性が高い は めったに壊れない、保守性が高い は 壊れてもすぐ直せる、可用性が高い は 全体として使える時間が長い という意味です。可用性 は 信頼性 と 保守性 の両方に影響されます。

RASIS は、システム品質を広く見るための観点です。

試験では、可用性、信頼性、保守性 の 3 つが特に狙われます。計算問題 なら可用性、定義問題 なら MTBF と MTTR の対応、文章問題 なら 壊れにくい と すぐ直せる の言い換えに注意します。

稼働率の公式 MTBF / (MTBF + MTTR) は「稼働している時間」を「稼働+停止の合計時間」で割ったものです。

例:

つまり、システムが 1010 時間の周期で 1 度故障し、そのうち 1000 時間は動いている、という意味です。

可用性の値は、停止時間に直すと感覚的に理解しやすくなります。

問題文で 計画停止を含むか、サービス時間帯だけで計算するか が指定されていたら、その条件を優先します。数字だけ見て機械的に 99.9% = 8.76 時間 と当てはめないことも重要です。

複数のコンポーネントが直列に接続されている場合、全体の稼働率はコンポーネント稼働率の掛け算 です。1 つでも故障すると全体が止まるからです。

全体の稼働率 = R1 × R2 × ... × Rn

例: Web サーバー（稼働率 0.92）、App サーバー（0.95）、DB サーバー（0.90）が直列

直列システムでは、稼働率が低いコンポーネントに足を引っ張られます。

複数のコンポーネントが並列に冗長配置されている場合、全体の稼働率は『1 から全て故障する確率を引く』 です。1 つ故障しても他が動くからです。

全体の稼働率 = 1 - (1 - R1) × (1 - R2) × ... × (1 - Rn)

例: DB サーバー 2 台が並列冗長（各稼働率 0.9）

ポイント：1 台が故障する確率は 0.1、両台が同時に故障する確率は 0.1 × 0.1 = 0.01（1%）です。だから稼働率は 99% になります。

実際のシステムは直列と並列が混在することが多いです。各パートを段階的に計算 します。

例: 以下の構成

ステップ 1: DB 2 台の並列稼働率

ステップ 2: Web → DB（並列） → Storage が直列

システムが故障した場合、どのように対応するかという設計方針です。試験では、3 つの原則と、その実装方法（冗長化、デュプレックス等）を理解する必要があります。

試験での見分け方:

故障に強いシステムを作るために、待機系をどう配置するかで 3 つの形態があります。

メカニズム：ホットスタンバイは「常に一歩手前の準備をしている」ため、即座に切り替えられます。コールドは「何もしていない」ので起動が遅い。ウォームはその中間です。

2 つの同一システムを Active-Standby で配置し、Active が故障したら即座に Standby に切り替える方式です。

特徴:

2 つの独立したシステムが同時に同じ処理を行い、結果の一致を確認してから出力する方式です。

特徴:

メカニズム：デュプレックスは「動き続けること」を優先、デュアルは「正確であること」を優先します。

高回復力システム基盤の設問では、複数の構成モデルを並べて どれにも共通する条件は何か を問うことがあります。このとき、待機系の台数やバックアップサイトの有無を先に見始めると迷いやすく、まず 共通条件 と モデル差 を分ける のが重要です。

すべてのモデルに必須 と問われたら、個別構成ではなく、まず基盤設備や災害耐性のような土台条件を見てください。遠隔地バックアップや二重センタ化は強力ですが、全モデル共通とは限りません。

試験問題を読む際、以下の順序で分類します。