基本情報技術者(FE)対策
サービス管理と監査
作ったあとの話
ここまでは作る側の話でした。今回は作ったシステムを動かし続ける仕組み(サービスマネジメント)と、それが正しく行われているかを外から確かめる仕組み(システム監査)です。どちらも似た用語が並びますが、境目に数字と立場が絡むので、そこを軸にすると整理できます。
SLAは数字の約束
SLA(Service Level Agreement)は、提供する側と利用する側が、サービスの水準を数値で取り決めた合意です。稼働率、障害からの復旧目標時間、応答時間などを書きます。決めた水準を測って見直し続ける活動がSLM(サービスレベル管理)で、SLAが文書、SLMが回し続ける活動、という関係です。
稼働率の約束は時間に直せます。1か月を30日として計算します。
- 月間の総時間 = 30日 × 24時間 = 720時間
- 稼働率99.5%の約束なら、停止してよい割合は 0.5%
- 許容される停止時間 = 720 × 0.005 = 3.6時間 = 3時間36分
99.9%にすると 720 × 0.001 = 0.72時間、つまり43分12秒しか止められません。0.4ポイント上げただけで許容停止が5分の1になるので、水準を上げるほど費用が跳ね上がる、という説明が正しい記述として出ます。
インシデント管理と問題管理
この2つの取り違えが最頻出です。
| 活動 | 目的 | 例 |
|---|---|---|
| インシデント管理 | まず復旧させる。原因究明は後回しでよい | 再起動して業務を再開させる |
| 問題管理 | 根本原因を突き止め、再発を防ぐ | メモリ漏れを特定して修正する |
| 変更管理 | 変更の影響を評価し、承認する | 修正版を出す可否を判断する |
| リリース管理 | 承認された変更を本番へ確実に展開する | 修正版を配布し稼働を確認する |
| 構成管理 | 機器やソフトの構成情報を正確に保つ | 台帳と実機を一致させる |
| キャパシティ管理 | 将来の負荷に対し資源が足りるかを見る | 3年後の利用者増に備える |
暫定の回避策で業務を戻したらインシデント管理、原因を掘ったら問題管理と切り分けてください。利用者からの連絡窓口はサービスデスクです。
システム監査
システム監査は、情報システムが目的に照らして適切かを、独立した立場の監査人が点検して報告する活動です。押さえるべきは次の3点です。
- 独立性 — 監査人は監査対象の部門から独立していなければなりません。自分が構築に関わったシステムを自分で監査することはできません
- 手順 — 予備調査で対象の概要をつかみ、本調査で証拠を集め、評価して監査報告書にまとめます。報告先は監査の依頼者(経営者など)で、被監査部門ではありません
- 監査証跡 — 処理がいつ誰によって行われたかを後から追える記録です。ログや伝票がこれにあたります。監査の結論は、監査人の心証ではなく監査証拠に基づいて出します
監査人は改善を勧告しますが、改善そのものを実施する立場ではありません。監査人が自ら是正する、という選択肢は誤りです。
内部統制とITガバナンス
内部統制は、業務が法令とルールに従って行われるよう組織の中に組み込む仕組みです。代表的な要素が職務分掌で、申請する人と承認する人を分ける、開発担当者に本番環境の更新権限を与えない、といった形をとります。ITガバナンスは、経営者がIT投資と活用を統制する取組みで、内部統制より上の視点にあります。
次回はストラテジ系に移り、経営戦略の用語を扱います。
