【運用管理の勘所⑧】「回復管理」とは?

2011年5月10日ITIL Foundation, 運用管理

システムマネジメントサービス部の中原です。

「運用管理の勘所」第8回目は「回復管理」について解説します。

システム運用 「回復管理」とは

「回復管理」とは

「異常事態」の状況下では復旧を急ぐ必要があるため、検討の時間は充分に確保できません。また、心理的にもなかなか冷静な判断ができない状態になります。そこで事前の準備が非常に大切になってくるわけです。

情報システムに障害が発生した後、迅速かつ安全に復旧するための管理が回復管理です。

障害による被害を最小限に抑えるためには、自動化可能な回復処理を自動化したうえで、考えうるあらゆる障害を想定して事前にできることを準備し、対応手順を整え、体制や役割を明確にしておくことが肝要で、これを担う回復管理の目的は次の2点です。

  • 障害発生時の迅速な対処策決定
  • 迅速かつ正確な回復処理の実施

もし回復処理が適切に行われなかった場合には、二次障害を引き起こし回復時間が大幅に延びたり、後になってからデータの矛盾に気付き復旧が非常に困難になってしまう危険性があります。

したがって、回復計画から実施までの手順を、二次災害を含む様々な障害を想定して用意しておかなければなりません。

さまざまな障害を想定し事前に回復手順を完備

回復処理は、迅速・確実に行わなければなりません。障害発生の都度、対応方法を検討したり、手順化されていない方法で回復を試みると、無駄な時間を要したり、障害を悪化させる危険も大きくなります。

回復処理を確実に実施するためには、前もって、想定できる限りさまざまなシステム停止状態からの回復手順を網羅的に整備しておくことが必須です。

障害回復の鍵はコントロール

障害を速やかに回復させるために最も大切なのは統制です。一つ一つの現象に対してそれぞれの対応者が無秩序に対応を行えば、事態をさらに悪化させてしまうこともありうるからです。

こういった事態を避けるために、一人の監督者(コントローラー)をあらかじめ設定しておき、障害が発生した場合には、情報の集中管理と指揮命令体系の一本化を計ることが大切です。

同時に、利用者への広報内容を統一し混乱を抑えることで、対応負荷の軽減を計ることができます。

回復計画の見直しも重要

障害を想定する中で、サービスレベルを維持できない事態が考えられた場合には、原因を根本的に除去する対策が必要となります。

“障害を起こさないようにする"対策は「問題管理」の守備範囲と重複する感がありますが、回復管理側から情報化計画などにフィードバックを行うことは重要です。

例えば、設備の増強(データの物理的破壊に対する二重化や自動切替の準備)、手順の見直し(回復計画の見直し)などがこれに相当します。もちろん、根本対応を実施する際には、障害による損失に対して費用的に見合った対策となっているかの確認が必要となります。

体制

回復管理を実施する上での責任者・担当者などの体制を整備し、各担当の役割を明確にすることで、より円滑に障害対応を進めることが可能となります。

名称と主な役割

  • 回復管理責任者
    • 回復管理における障害対応(作業・広報含め)の全責任を負う。上位組織や、社外への報告の義務を負う。状況に応じ回復作業の実施判断を行う(例:システム運用部長)
  • 回復管理担当者
    • 回復管理を行う。社内ユーザー部門、システム連携・接続先部門などの社内関連組織への報告の義務を負う。状況に応じ回復作業の実施判断を行う(例:システム運用課長)
  • 監督者(コントローラー)
    • 回復管理における障害対応の全コントロールを行う。作業担当任命・各種調整・連絡・確認会招集などを実施する(例:運用担当者)
  • 対応者
    • 原因調査・障害回復作業・履歴の記録などを行う(例:システム担当者)

管理項目

以下に記す管理項目について、障害発生後速やかに確認を取るとともに、関係各位への連絡を行い、対応者全体で随時確認できるようにホワイトボードなどを活用し、迅速、正確な障害回復を図ることが肝要です。

障害発生時の管理項目

  • 発生日時/検知日時
    • 障害が発生し障害として認識された日時
  • 発生箇所
    • 障害が発生した場所(ロケーション、機能、システムなど)
  • 状況
    • 障害発生状況およびその事象
  • 影響範囲
    • その障害により、サービスが受けられないまたは低下するユーザー、業務単位・拠点単位など
  • 回復目標時間
    • 回復目標とする時刻(※サービスレベルで定義されている障害発生時の回復目標時間や許されるサービス停止時間に基づく設定が望ましい)
  • 広報
    • 障害発生を通知すべき先、通知すべき項目、手段

障害対応時の管理項目

  • 障害対応者
    • コントローラー、ハードウェア/ソフトウェアごとの対応者など、体制と役割の明確化
  • 障害原因
    • 障害を引き起こした直接・間接の原因(※直近の変更作業や最新の構成図を参照する。過去の障害履歴や対応中の障害についても調査する)
  • 回復作業(対応作業)
    • 対象ハードウェア/ソフトウェア、実施内容、確認項目(OK/NG判断基準)、作業担当者、所要時間など
  • 回復見込み時間
    • 回復作業の実施により、回復が見込まれる時間(※ユーザー広報されるため、結果的に誤報とならないよう、注意が必要)
  • 回復作業実施による障害状況変化とその経緯
    • 回復作業実施の結果(OK/NG)、対応により変化した状況(または変化しなかった状況)
  • エスカレーションおよび広報
    • 影響範囲・時間経過による、連絡先、連絡範囲、連絡項目、回復予定時刻、回復までの影響、回復作業中の影響など
  • 広報手段
    • 影響度・影響範囲・緊急性などにより使用手段(ツール)・文言を定義
  • 次回広報予定時間
    • 次回ユーザーへの広報予定時間
  • 次回確認会開催日時
    • 次回全体確認会の実施予定時間

エスカレーション、広報とその手段

発生した障害の状況、影響範囲(社内・社外、社会的影響、営業的損失、損害賠償の有無など)によりエスカレーション(上位・関連組織への連絡・報告)、広報(エンドユーザーやその管理組織への連絡・報告)の対象として、予め定義しておく必要があります。

影響を受ける関連組織名称と該当者の例

  • 経営サイド
    • 社長、取締役、CEO
  • 上位組織管理者
    • システム運用部門上位組織管理者(CIOなど)
  • 社外関係会社
    • 契約先会社、接続・インターフェース・処理連携先企業
  • 社内関連部門
    • 開発部門、保守部門、オペレーションなどの運用部門
  • ユーザー管理部門
    • ユーザー統括部門、各事業部統括部門
  • エンドユーザー(社内)
    • 各部門でのシステム利用者、営業マン・庶務含む全社員
  • エンドユーザー(社外)
    • 一般消費者や顧客(個人・企業)、Webなどのサービス利用者

障害範囲・状況に応じた広報手段の例

  • 全部署/クライアント
    • 各部署のキーマンへ電話/FAXで広報
  • 対象者が限定
    • 対象者へeメールで広報
  • 不特定多数
    • コールセンターへ障害内容を通知すると共に、電子掲示板にて広報
  • 対象ネットワーク・管理サーバーの障害時
    • コールセンターへ障害内容通知

いかがでしたでしょうか。

全8回にわたってシステム運用管理の勘所を紹介してきました。システム運用管理は、非常に奥が深く、継続的に改善が求められるものです。この連載で紹介された勘所を参考に、ぜひより良いシステム運用を実現してください。

  • 株式会社アークシステムの来訪管理・会議室予約システム BRoomHubs
  • 低コスト・短納期で提供するまるごとおまかせZabbix