メールの送受信や共有ファイルへのアクセスが正常でも、それだけでITインフラの健全性は判断できません。日常の利用状況からは、保守期限の切れた機器、不要な管理者権限、復元できないバックアップなどが見えにくいためです。
ITインフラを点検する際は、現在の稼働状態に加え、障害の影響範囲と復旧に必要な条件を確認します。対象にはサーバーやネットワーク機器だけでなく、クラウドサービス、アカウント、設定情報、保守契約、運用手順も含まれます。
1．構成管理：業務とシステムの依存関係を把握する
IT資産の一覧には、機器名や台数だけでなく、「どの業務で使われているか」を記録します。障害時の優先順位を決めるには、故障した機器と停止する業務の関係が必要だからです。
例えば、受注システム自体が稼働していても、認証サーバーが停止すればログインできなくなる可能性があります。クラウド上の業務システムも、社内のインターネット回線や接続機器に障害が起きれば利用できません。
構成情報として整理する項目は、次のとおりです。
| 管理対象 | 記録する情報 | 確認する目的 |
|---|---|---|
| サーバー・仮想環境 | 用途、OS、稼働するシステム、接続先 | 停止時に影響する業務を把握する |
| ネットワーク | 回線、ルーター、スイッチ、接続構成 | 通信経路と障害の影響範囲を確認する |
| クラウドサービス | 利用部門、管理者、認証方式、契約情報 | 管理責任と利用条件を明確にする |
| データ | 保存先、利用システム、バックアップ対象 | 保護すべき情報の漏れを確認する |
| 保守・運用 | 担当者、委託先、対応範囲、連絡先 | 障害時の連絡と作業依頼を進める |
構成図では、一つの機器や回線が停止すると全体が使えなくなる箇所も確認します。このような箇所を「単一障害点」と呼びます。
機器が2台あっても、電源や接続先のスイッチを共有していれば、同時に停止する可能性があります。冗長化の有効性は、台数だけでなく、どの障害を回避できる構成かで判断します。
2．ライフサイクル管理：使用年数とサポート状況を確認する
機器の使用年数、ハードウェアの保守期限、OSやソフトウェアのサポート期限は、それぞれ別に管理します。
サーバー本体の保守が継続していても、搭載するOSのサポートが終了している場合があります。反対に、ソフトウェアを更新していても、故障時の交換部品を確保できない機器では、復旧に時間がかかります。
点検では、以下を確認します。
- 機器の導入時期と保守終了日
- OS・ソフトウェア・ファームウェアのバージョンとサポート期限
- 修正プログラムの適用状況
- 交換部品や代替機の調達可否
- 保守契約の受付時間、対応内容、対象外となる作業
保守契約に記載された「受付時間」や「駆け付け時間」は、業務の復旧を保証する時間とは限りません。部品交換後に、設定の復元やデータの戻し作業が必要になることもあります。
更新の優先順位は、年数だけで決めず、停止した場合の業務影響、外部からのアクセス可否、代替手段の有無を組み合わせて判断します。すぐに更新できない場合は、接続範囲の制限などの暫定対策と、更新までの期限を明確にします。
3．アクセス管理：アカウントと権限を業務に合わせる
退職者のアカウントや異動前の権限が残っていても、通常の業務では不具合として表れません。しかし、不要なアクセス経路が残り、アカウントが不正利用された場合の影響を広げます。
確認の基本は、現在の在籍者・担当業務と、システム上のアカウント・権限を照合することです。
特に、管理者権限は日常業務に必要な権限と分けて扱います。通常のメールやWeb閲覧にも管理者アカウントを使っていると、その認証情報が漏れた場合に広い範囲へ影響するおそれがあります。
点検対象には、社員のアカウントだけでなく、委託先の保守用アカウントやシステム間連携用のアカウントも含めます。所有者、用途、利用期限が分からないものは、依存する処理を確認したうえで整理します。
また、管理者や外部接続用アカウントへの多要素認証の適用状況、操作ログの保存状況も確認します。緊急時に利用する認証情報は、閲覧権限と利用記録を管理できる方法で保管し、担当者個人の記憶やメールに依存させない運用が必要です。
4．バックアップ：取得結果と復元能力を確認する
バックアップ処理が「成功」していても、必要なデータがすべて含まれているとは限りません。新しい共有フォルダや業務システムを追加した際に、バックアップ対象の設定が更新されていないことも考えられます。
まず、業務で利用しているデータの保存先と、バックアップ対象の一覧を照合します。そのうえで、保存期間、取得頻度、保管先、復元方法を確認します。
復旧条件を整理する際には、次の二つの指標を使います。
- RTO（目標復旧時間）：停止したシステムを、どれくらいの時間で復旧させるかという目標。
- RPO（目標復旧時点）：障害前のどの時点までデータを戻す必要があるかという目標。
この二つを分けることで、「早く再開するための対策」と「失われるデータを抑えるための対策」を具体化できます。
例えば、直近1時間分を超えるデータの消失を許容できない業務では、1日1回のバックアップだけでは要件を満たせません。取得間隔に加え、処理の失敗や遅延も含めて、実際にどの時点へ戻せるかを検証します。
復元テストでは、ファイルを取り出せることに加えて、必要なシステムが起動し、利用者が業務を再開できるところまで確認します。設定情報、認証、ライセンス、接続先などが不足すると、データが戻っても業務は再開できません。
なお、冗長化や同期はバックアップとは役割が異なります。誤削除や破損が同期先にも反映される構成では、過去の正常な状態へ戻す仕組みが別途必要です。バックアップ自体が同時に被害を受けないよう、保管先と管理権限の分離も確認します。
5．復旧体制：担当者が不在でも対応を開始できる状態にする
復旧時間には、修理やデータ復元だけでなく、異常の検知、状況確認、関係者への連絡、作業判断にかかる時間も含まれます。
監視通知が担当者一人にしか届かない、保守契約番号が分からない、停止や切り替えを判断できる人が決まっていない、といった状態では、技術作業に入る前に対応が止まります。
障害対応手順には、次の情報を残します。
- 通知を受ける担当者と、不在時の代替担当者
- 初動で確認する監視画面やログ
- 保守会社への連絡先、契約番号、伝える情報
- システム停止や代替環境への切り替えを判断する責任者
- 復旧手順と、業務再開を確認する方法
手順書の保管先にも注意が必要です。社内サーバーの停止手順を、そのサーバー上だけに保存していると、障害時に参照できません。障害の影響を受けにくく、必要な担当者が安全にアクセスできる場所を用意します。
整備後は、主担当者以外が手順をたどれるかを確認します。連絡先の一覧があるだけでは、必要な権限や情報がそろっているかまでは分からないためです。
点検結果を改善計画につなげる
確認した課題には、対象システム、業務への影響、暫定対策、担当者、対応期限を記録します。「要確認」のまま残さず、何を調べれば判断できるかまで明確にすると、次の作業につながります。
優先して対応するのは、重要業務に直結し、代替手段がなく、復旧方法も確認できていない箇所です。権限の整理や連絡先の共有で改善できる課題もあれば、機器更新や構成変更が必要な課題もあります。
最初の点検対象には、停止すると影響の大きい業務を一つ選びます。その業務が使うシステム、データ、認証、ネットワークをたどり、バックアップと復旧手順まで確認すると、設備一覧だけでは見えなかった不足を具体的な改善項目にできます。
