2月に障害発生の「Doblog」。5月30日をもってサービスを終了
http://internet.watch.impress.co.jp/cda/news/2009/04/24/23277.html
障害中のdoblogでしたが遂にサービス終了ですか…。
こないだのSoftbankの通信障害もそうだけど、いざというときに復旧がスムーズにいかないってことは多いよね。
これら2つの障害も、いざというときのためにバックアップ用のシステムは作っていたと思うんだけど。
バックアップシステムってのは障害が発生したときにリストアができるのがバックアップシステムなわけで。
でもそれがちゃんと出来ないバックアップシステムってのは意外と多い気がする。
バックアップシステムが想定通りに動かない最大の原因は、「本番環境で試せない」ってことなんだと思います。
災害予防訓練をいくらしても、「阪神大震災」が実際にやってきたら想定外のことがいくらでも起こるのといっしょで。
でも、震災を一度でも経験した人は、次に震災が来たときには予防訓練をいくら積んだ人よりもいろんなことが迅速に行動できるんだと思います。
つまり、いくら災いに備える準備をしても、その準備にはどこか不完全な部分はあって、実際に災いを経験して痛い目に遭うまではなかなかそれは分からないということです。
本番稼動しているシステムは、たいていテスト用のミニチュア環境もあって、本番稼動に載せるまでは開発者はそのテスト環境を使って開発したり検証したりするわけなんですが、予算が無いとかの関係でなかなか本番環境と瓜二つのクローンを作るという訳にはいかない。
それでよく、「テスト環境でのバックアップ切替のシミュレーションはうまく出来ていたが、本番環境でいざ障害が発生するとうまくバックアップシステムが作動しない」という事態になります。
自然災害と同じで、事前に描いていた復旧シナリオが100%完璧な形で遂行できるかどうかってのは非常に難しい問題で、実際起こってみるとうまくいかないってのは、僕はある程度仕方のないことなんじゃないかなと思います。
ただ、そういう危険性を減らすのは出来ると思います。
僕が思うのは、「バックアップシステムがうまく稼働しないこともあるのだから、さらにそのバックアップシステムも作っておくべき」なのかなぁと。つまりバックアップシステムを三重にするってことですね。
障害が起きてバックアップシステムが動き出した瞬間から、バックアップシステムはもはやバックアップシステムではなくて、それが本番稼動システム、つまり主役のシステムに躍り出ちゃうってことだから、そのシステムをバックアップする仕組みもまた必要ではないでしょうか？と。
または、次のような考え方もあるでしょう。
普段バックアップシステムってのは眠っていることが多くて、普段は使われてないシステムです。なので、いざ使おうとするとうまく起動しなかったり、想定外の動きをしたりします。ならいっそのことずっと動かしておけばいいじゃない、ということ。
アクティブースタンバイの構成ではなくて、アクティブーアクティブの構成にしておく方が耐障害性は強いということです。
これは、インターネットという網全体が、局所的な機器の障害で停止することがないのと同じです。
とまぁいろいろやり方はあるんでしょうが、最終的には予算と人的リソースですね…これが満足に供給されてないから完璧なシステムにはできないってことが多いです。
よく事故が起こる交差点があって、その対策のために信号機をつけることは出来ても、立体交差にする余裕はないってことです。
