実現には困難が伴いますが、偉い人が必ず指摘します。
例えば、蛍光管が2本ある蛍光灯で、片方がチカチカしだしたとします。
スペアの管がすぐに入手できない場合、チカチカする方のソケットだけを抜けば、ちょっと暗いのを我慢すれば、しのげます。チカチカしているよりはマシなのです。
複合的なシステムならば、縮退動作が可能になります。
WindowsパソコンでCドライブのHDDが壊れたら多分使い物になりません。
ですが、CPUをふたつ積んでいるマシンで片方のCPUが壊れたら、もう片方だけで動かせますね。
BIOSで設定を変更したら動かせるはずです。OSがブートのたびにCPUの個数を再認識してくれるなら。
このように、システムのある部分が壊れても、残りの部分である程度の機能を実現できるなら、壊れた部分を切り離して動作できる縮退動作を入れておくべきだという要求が沸いてくるのです。
極端な例はSUNのページにあります。
自動システム回復 (ASR)
http://docs.sun.com/app/docs/doc/806-3877/6jd0ctqqg?l=Ja&a=view
障害の発生したハードウェア部品を自動的に検出し、OBP ファームウェアに組み込まれた自動構成機能によって、システムは障害のある部品を構成解除し、システムの動作を回復します。障害の発生した部品がシステムの動作に必要なものでない場合は、ASR 機能によって、システムはユーザーの介入なしに自動的に再起動します。このような「縮退起動」によって、システムは、障害のある部品の交換を求める保守呼び出しを生成した上で、動作を継続することができます。
帳票印刷用のプリンタが壊れてビジー信号が立ちっぱなしだからといって、伝票入力ができない会計システムがあったとしたら、ユーザは怒り出すでしょう。
それにはうなずけるのに、みなさんが日々作っているシステムでは、
起動時にすべてのコンポーネントをチェックして、
異常があれば全機能停止
という間抜けなロジックがプログラムの一番最初で動作します。
さらに、各コンポーネントの状態を格納する変数は、
これは起動時に必ず初期化されるはずだから
などといって、ろくにレンジチェックもNULLテストもしないでアクセスしたりするコードが、グローバルに実装されているのです。
で、縮退動作の話が出ると、
あ～うちはコンポーネント化して作ってますんで楽勝ですよ
と安請け合いして火を噴くか、
システムの根幹に関わる改造ですので、ほぼ作り直しになります
という断り見積もりを提出するかのどちらかしかないのです。
いくつかの『すばらしいオブジェクト指向で実装されたシステム』を見てきましたが、どこへいってもモジュールの相互結合強度はすこぶる高く、プライベート変数はgetter/setter経由でグローバル変数と化しているのが現実です。
縮退動作の話が飛び出すきっかけは、大抵こんなことです。
システムのもっとも重要なコンポーネントが１ヶ月に１回、思い出したようにクラッシュする。
最重要コンポーネントなので、このコンポーネントが動作していないと、他の機能はまったく動作しない。
間抜けなのは、まったく動作しないはずなのに、ディスプレイには「致命的エラー。復旧できません。「OK」」というようなウィンドウが表示され、ログに記録されるのです。つまりCPUもメモリもプログラムも動作しているのです。
偉い人はそれをみて、
画面も出て操作もできる。だったら他の機能は動かせるんだろ？
といいます。
コメント