変更・構成管理と日々の運用作業

結論：運用の正解は「記録する・確かめる・早く組む」

このレッスンの問題は、ほぼ次の3原則で解けます。

1. 記録する：変更した内容や構成（何がどこにあるか）は必ず書き残し、最新の状態に保つ
2. 確かめる：影響を確かめてから変更・廃止する。確かめる順番は土台から上へ
3. 早く組む：運用部門は完成後に引き継ぐのではなく、要件定義の段階から参加する

逆に「必ず深夜」「常に全員」「一切変えない」「全部止める」のように極端な言い切りの選択肢は、まず誤りです。

変更管理と構成管理の違い

変更管理は「システムを変えるときの手続き」、構成管理は「いま何がどうつながっているかの台帳づくり」です。家のリフォームでたとえると、工事の申請・記録が変更管理、間取り図と設備の一覧が構成管理にあたります。工事をしたら間取り図も書き直す、という関係です。

変更の記録が役立つ理由は、障害が起きたとき「直前に何を変えたか」が原因究明の最大の手がかりになるからです。変更依頼は到着順ではなく、影響と緊急度から優先度を決めて処理します。

サービス廃止時の資産の識別

ITサービスをやめるときは、使っていた資産（サーバ・ディスク・ライセンスなど）を洗い出して整理します。ここで怖いのは別のサービスと共有している資産を誤って消すことで、共有先のサービスが止まりインシデント（サービスの中断や品質低下）が起きます。

試験では「消しすぎ」を問うているのに「残しすぎ」の結果（無駄遣い）を並べてきます。問題文がどちらの方向のミスかを先に確認しましょう。

ネットワーク構成の変更に備える

運用を始めたネットワークも、拠点の追加や機器の入れ替えで必ず変わります。いつでも安全に変更できるよう、機器管理台帳やネットワーク図を適時更新しておくのが正解です。

ひっかけは「運用開始後は構成を変えない」「全業務を止めてから変える」「ベテランに任せる」のような非現実的なルールです。属人化（特定の人しか分からない状態）を防ぐのが台帳と図の役割です。

OSバージョンアップは「土台から上へ」確かめる

システムは積み木のように重なっています。一番下がOS、その上にデータベース（DB）、さらにその上で業務アプリケーションが動きます。OSを替えたら、すぐ上のDBが動くか → その上のアプリが動くかの順に確認し、問題がなければバージョンアップします。

「サポートが終わるから検証なしですぐ更新」「同じメーカだから問題ないはず」は誤りです。確認を省いたり、一部の層だけ確認したりする選択肢を外しましょう。

【最頻出】開発部門と運用部門の協働

このレッスンで一番出ているテーマです（本試験2回・免除8回）。開発部門と運用部門が別組織だと、完成してから「こんな運用はできない」と分かる事故が起きがちです。そこで正解は、運用部門も要件定義・開発の段階から参加し、運用のしやすさ（運用性）の観点で要件を出したり助言したりすることです。

要件定義をする人なら、「運用チームを最初の要件定義に呼んでおけば、監視項目やバックアップ時間の要件が漏れない」と考えると分かりやすいでしょう。

見破り方は単純で、「両部門が・早い段階から関わっているか」を見ます。「後で」「だけで」「〜が作って引き渡す」はすべて×です。この問題は年度をまたいで、ほぼ同じ選択肢で繰り返し出ています。

日々の運用を助けるツール

たくさんのPCを少人数で管理するために、クライアント管理ツールを使います。機能ごとの役割を区別させる問題が出ます。

「検出したい」ならインベントリ収集、「電源を入れたい」ならWake on LANです。Wake on LANは起動するだけの機能なので、誤動作の検知・トラフィック管理・不正アクセスの監視といった監視系の選択肢は誤りです。

運用のアウトソーシングとシフトの人数

アウトソーシング（外部委託）でシステム運用を外に出す最大の利点は、自社の情報システム部門を企画や開発に専念させられることです。「いつでも自社運用に戻せる」「問題を把握しやすい」「自社で対応しやすい」は、ノウハウが社外に出るぶん、むしろ逆になります。

24時間365日の有人運用は、シフト勤務の最少人数を計算させる問題として出ます。下の例題で手順を確認しましょう。