- 目次 -
●障害はいきなり発生する
ことITシ ステムに関して言えば、システム停止の原因はさまざまなことに起因し得ます。システムそのものが停止する可能性もありますし、それがつながるネットワーク が停止することもありえます。または電源供給がストップしてしまう可能性も、セキュリティ侵害の場合も、自然災害に起因するケースも排除できません。
例えば2007年5月に、NTT東日本のIP系サービス約300万回線が最大7時間に渡って停止する障害が発生しました。発生は日勤帯終了後であったため に大きな実害に至らなかった企業が多かったようですが、回線停止によってシステムによる定常作業が実施不可能になり、手書きのFAXで業務を進めた企業も あったと聞きます。
<関連リンク>
NTT東日本の大規模障害の原因報告と対策会見
http://itpro.nikkeibp.co.jp/article/NEWS/20070516/271232/
そ のような場合に自社としてどのような対応を行うのか、これは企業規模の大小を問わず、ITシステムを活用する経営者なら考えておきたい事項です。自社のコ ア業務に対してはもちろんのこと、ITに関しては特に、その整備に時間やコストがかかることが多々ありますから、早い段階で検討しておきたいものです。
●障害に備えるための考え方
・何を守るのか
ITシステムに関する事業 継続検討にあたっては、まず自社にとって重要性の高い業務やサービスを特定することから始まります。
次に、特定した業務やサービスの提供 品質を監視する対象項目をリストアップし、監視対象を明確化します。つまり、何がどうなれば障害とみなすのかを考え、それらを監視できるようにするという ことです。
・どのくらい動かなくてもいいのか
そしてそれらの業務やサービスが、障害によって復旧するまでにかかる時間の 目標値(RTO:Recovery Time Objective)と、どれだけの時間さかのぼった状況に復旧すればよいかの目標値(RPO:Recovery Point Objective)をそれぞれ考慮します。
例えば、一瞬たりとも止まって欲しくなければ、RTO=0です。また、障害発生時点の状態で 復旧してくれなければ困るのであれば、RPO=0になります。
これらの数値の決定は経営判断です。経営上重要なものは何かをベースに優先 度を設定します。この数値により、この後決定する具体的な対処にかかるコストが変わってきます。
その後、RTOやRPOをベースとして、 担当レベルで具体的な対応策を考えていきます。
●対策の立て方
ま ずは管理ルールの策定です。
システム障害が発生した場合の対処手順を定めておく必要があります。発生時の一次対応のみならず、上層部へ のエスカレーションのフロー、障害箇所別の緊急連絡先なども定めておく必要があります。これがなければ、障害が発生してもその後に必要な動作が誰もできま せん。
次に技術的対策の実施を検討します。
ITに関しては、例えば保有データに関するバックアップの必要性がある場 合、何のデータをどのようにバックアップするのか、また復旧させる際はどのような手順を取れるのかについて方法を策定します。システムに対する対処が必要 で、それが現状ではなされていない場合、システム改修や追加が必要になることもあります。
次の事例は、大手企業のものですが、事業継続対 策をどのように実践しているかについて参考になると思います。
<関連リンク>
事例1:コロナ:中越地震と豪雨の被災経験を生かしてBCP を強化
http://itpro.nikkeibp.co.jp/article/JIREI/20070531/273133/
事 例2:アサヒビール:社員のノートPCで基幹系を代替し、1000万円以下の投資で商品納入を継続
http://itpro.nikkeibp.co.jp/article/COLUMN/20070221/262670/