前回に続き、トラブルに備えた開発と設計について考える。システム稼働後にはシステム・ダウンなどの事故やトラブルが必ず起こるという前提に立ち、起こったときにその被害を極力抑えるために設計上考えておくべき課題を提起した。
 |
プロジェクト体制を採って開発するするシステムでは、システムをいくつかのサブシステムに分けて開発することになるが、各サブシステムの開発がそれぞれ自由に展開できるように分割できることが望ましい。
性能要件が厳しく、要求される性能を実現するために全体設計の最適化が求められることもあるが、何とか実用に耐える性能が実現できるなら、性能の最適化を図るよりも、分業開発が楽にできて、納期遅れが発生しないようなサブシステム分割設計を考えることも大事である。
そのためには、（1）各サブシステムの機能が明確で、だれにも簡単な言葉で機能を説明でき、誤解のないようになっていること、（2）各サブシステム間の独立性が高く、相手を気にせず開発できること、（3）インタフェースが単純で、極力同じになっていること、などが求められる。要は全体最適化と分割統治によるプロジェクト推進の最適化との妥協点を探ることである。
 |
例えば、オンライン・リアルタイム処理が途中で止まったり、間違った処理結果が出たりしたとき、その原因を特定するために、処理がどこまでどういう経過をたどったかが分ることが重要だ。そのためにも、原因を追求しやすいように中間処理結果や通過足跡の保存を考慮しておきたい。
特に稼働後に事故が起こり、その対策を打つ場合には、事故原因の特定が急がれるだけに、処理の足跡が残っていることは極めて重要である。
さらに何か起きたときには、端末オペレータ、システム運用者、SE、ハード保守者がみな同じレベルで状況を把握できるようにすることが大事である。システムから各所への状態表示や通知方法が的確かどうかもレビューしておきたい。
 |
システムが何らかのエラーや異常を検出した場合は、エラー・メッセージを出力するのは当然として、オペレータが、そのときどうすればよいかが分るように、「対策提案型エラー報告」を出すことを考えて設計しておきたい。
基幹システムのように、専任の運用者がしかも交代制でシステムを運用している場合は、オペレーションの多様性よりもミスオペレーションがないほうが要求されるはずである。
また特に多数の一般消費者がアクセスするオークション・システムなどは、少しでもダウン・タイムが減ることが求められるので、オペレータが混乱したり、誤操作をしたりしないよう、設計者は運用者の立場で運用状況をシミュレーションしておく必要がある。
もちろんエラーの原因は、システム保守者、SE、設計者などがしっかり追究しなければならないので、どこかに原因追究に役立つクールな事実情報を表示したり、記録したりしておくことは当然必要である。
 |
発生確率が極めて小さく見える事象も、もし起きたらどうするかをきちんと設計しておく必要がある。ランダムといっても、10年後に起こる確率と明日起こる確率は同じであるし、世の中はランダムに見えて実際には偏っている事象も多い。だから「確率の低い事象も必ず起こる」と逆説的に考え、大きな問題がないかレビュー・テストするほうが現実的であろう。「人はミス、機械は壊れ、バグ残る」を前提に徹底的にケース分析を実施したい。
ただ個々に別々の対応を考えると論理が複雑になるので、対策の種類はあまり増やさず、トラブル対策の基本方針を立て、だれにでも分かりやすい対策にまとめることが大事であろう。
