2011年1月10日月曜日

『システムはなぜダウンするのか』① 大和田尚孝著

とても読みやすかったです。
私たちは、ネットがつながらない・電車が止まった・ATMでお金を降ろそうとしたらエラーが発生した、といった問題が起きても気にとめることはありません。「あ、そうなんだ。不便だなー」と思うぐらいでしょう。しかし、実は様々な事情が何重にも重なりあって引き起こされるのであって、開発者の人たちは毎日頭をかかえているのです。こうした裏事情?に触れることができるとても興味深い一冊だと思います。



まとまってないから、とりあえず1、2章だけ。


1章 システムが止まった・・・ 
                ーダウンとは何か



停止=ダウンは誤解
本書では、以下の定義を与えることにします。
定義1.1
ダウンとは、システムが本体の役割を果たせていない状態のこと

例題:
OSやミドルウェアは問題なく動作しているが、一部のアプリケーションの機能だけが止まったときもダウンとみなします。利用者から見れば、「システムの一部の機能が使えない」という状態だからです。

例題:
点検のためにあらかじめ決めた計画に従ってシステムを止めることはダウンとは言いません。
「システムが本体の役割を果たせていない」というわけではないからです。

例題:
システムが不意に停止しても、待機系のシステムがすぐに起動して処理を引き継ぐなど、システムが途切れなく動き続けている場合は、ダウンとは言いません。ダウンを回避できたと言えます。これも定義通り。

なぜダウンするの?
一番の疑問でしょう。理由は突き止めれば、ただのテスト不足です。
この条件でダウンするということを開発時に分かっていれば、少なくともその条件ではダウンしないように設計し直すことができるからです。
しかし、テストをする人を責めるのは酷です。
なぜなら、テストを完全にこなすのは現実に不可能だからです。
前提条件の組み合わせによって、テストケースは膨大な数に膨れあがるからです。

ダウンは原因から4種類に分類できる
実は、ダウンの原因は4種類に分類することができます。以下のグループに分類できます。
①ソフトウェアの不具合
②性能・容量不足
③設定・操作ミス
④不慮の事故

ダウンが起きたとき、ダウンの発生状況等を考慮して上の4つから原因を突き止めることになります。


2章 きちんとテストしたはずなのに・・・
                ーアプリケーション・ソフトの不具合



バグとダウンの関連性
バグとは、アプリケーションソフトの不具合です。
バグはテストで見つかれば「不良」として処理されます。表面化せずに本番稼働をむかえると「バグ」のまま残ります。それが本番稼働中に表面化すると「不具合」が発生し、システムがダウンします。

しかしながら、以下の定義を与えないわけにはいきません。
定義2.1
どんなにテストを繰り返してもバグは残る

例題:
メガバンクの合併に関わる大規模なシステムの総合テストで、考えうる100万を超えるテストケースを最大6000人がかりで、10ヶ月をテストだけに費やしました。
それでも、バグはゼロになりません。複数のプログラムからなるソフトウェアにおける処理ルートと入力データお組み合わせは、100万をはるかに超えるからです。

重要なことは、「あれだけテストをしたのだから、バグは残っていないだろう」と考えるのではなく、時間の許すかぎりのテストをするのと並行して、バグが表面化したときの対処方法をあらかじめ講じておくことです。


盲点:日付問題
簡単な紹介で終わりにさせてもらいます。
面白い内容なので、是非調べてみてください。

・うるう年
うるう年の正確な条件を知っていますか?ここでは取り上げませんが、プログラムによっては、正しい動作をしないこともあるみたいです。有名な”2100年問題”もこれにあたります。なぜなら、2100年はうるう年ではないですから。

・2038年問題
これはUNIX系のOSで、経過秒数を格納する領域の桁数が足りなくなるのではないか、という点です。実際に2004年日本で、その問題が表面化されATMの機能が一部時間切れになりました。

・2007年問題
面白かったです。終戦直後の1945年から数年間に生まれた「団塊の世代」が定年を迎え大量に退職することにより、ベテラン技術者のノウハウが消失し、何十年も稼働を続けているシステムに以上が発生したときの原因の究明などができなくなる危険を指摘して言葉です。意外に笑い話ではないかもしれませんね。

0 件のコメント:

コメントを投稿