過剰なリスクに怯えないためのリスクマトリックス

前回の補足です。

ファーストサーバ事件の衝撃を受けて、バックアップの確認や、普段取っていないバックアップについて、
「あれも取らなきゃ」「何でこれは毎日取ってないのか」との指示を受けて、てんてこ舞いな人もいたと思います。

しかし、そもそも何でもかんでもバックアップしてないといけないものでしょうか?

リスクの対応の方法を決める際には、ヒートマップやリスク・コントロール・マトリックスなどのリスクマップが有効です。

これは、縦軸にリスク発生時の影響の大小、横軸に発生頻度の大小を記したものです。

マトリックスで整理することにより、発生可能性と影響度を横軸・縦軸にレベル分けし、グラフ化することによって、最もリスクが高い箇所を浮き立たせることができます。

ちなみに、今回のファーストサーバ騒動は、「起こるはずのない致命的な事故が起きた」という点で、
図の左上に入るべきでしょう。

万一、起きた際の影響を少なくするためにバックアップが必要だった、という教訓を残しましたが、
そもそも顧客にはバックアップを取る手立てが無かったりしたそうで…
その場合は、保険等に入って、リスクを他社へ「移転」するか、必要なデータについては2重管理を行うか、
…あるいは、踏み入れてはいけない道だった…は、今じゃないとわからないことでした。

大事なのは、過剰に反応してバックアップ地獄や復旧テスト地獄に陥らないこと。
そして、発生確率の少ないものにばかり対応して、1番重要な高確率・影響大のリスクへの対応をおろそかにしないこと、でしょう。

This entry was posted in it. Bookmark the permalink.

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

次のHTML タグと属性が使えます: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>