プログラミングで異常のもみ消しは駄目！

今日は朝から社内ミーティングをこなし、午後はある製品の機能追加を少し進めたりした後、夜にはProDHCPの客先へ向かい、セットアップ＆動作検証。そして、そのあと徹夜で別のシステムのProDHCPのリリース立ち会いで、明日の朝まで寝られません。。

インターネットのシステムの場合、日中にシステムの入れ替えはなかなか許可が出ず、大抵は夜中に行います。それならゆっくり寝てから・・・とも思うのですが、他の仕事もいろいろありますからねぇ。。

さて、今日はプログラムを作る上でとても大事なことをまた書いてみます。

「もみ消しはいかん！」と言うことです。

UNIX系のOSでは、プログラムが異常終了する際（たとえば、セグメンテーションフォルトとか、バスエラーとか）、OSがプログラムの異常を知らせてくれます。指定すれば、その瞬間のメモリー状態をファイルにダンプしてくれたり（core dump）、システムのログや、コンソールに異常終了を知らせてくれる仕組みがあります。わざわざそうなっているのには理由があり、問題があるプログラムに早く気がつくように、という気を利かせてくれているわけですね。

OSだけでなく、プログラミング言語にも、異常を知らせてくれる仕組みがあるものも多くあります。

プログラミングをしていると、この異常を知らせる仕組みのおかげで、問題に気がついて修正していくことができるのですが、それを客先へ納品する際や、製品としてリリースする際に「もみ消そうとする」人がいるようです。

要するに、問題が完全につぶせていないかもしれないので、とりあえず、異常終了を気付かれないようにしてしまうのです。

これは一瞬、良い方法だと思うかもしれません。異常が発生しても、ユーザに気付かれずに、うまいこと内緒でこっそり再起動でもしておけばいいだろう、というような感じです。しかし、これはサポートで悲劇につながりますので、絶対にすべきではありません。

ユーザから「どうもおかしい」「たまに死んでいるのではないか？」とクレームが来た際に、証拠隠滅のため、調査ができないのです。ユーザにも異常を見せにくくできている分、自分たちも調べられなくなってしまうのです。

ネットワークシステムでは、同じ現象を再現させることがとても大変です。特に不特定多数のユーザが使う、インターネット向けのシステムでは、端末も、ユーザの操作も、何もかもがあまりに多くの組み合わせを持ち、再現は非常に困難です。つまり、一度でも異常が起きたら、それをきちんと記録しておくくらいのことをしないと調べられないのです。

皆さんがもしプログラムを依頼する機会があったら、是非このあたりを見てみると良いでしょう。「よく分からないけどごまかす」というタイプのプログラマーに仕事を依頼するのは避けましょう。その代わり、問題が発覚しても厳しく追及しすぎないようにする事も大切です。人間がやることですから、なかなか最初から100%にはならないものです。あまりにも問題だらけというのも困ったものですが、ちょっとした問題で大騒ぎばかりしていると、本当にもみ消したくなってしまいます。本来のゴールは、信頼性の高いシステムをできるだけ早く作り上げることであるはずが、問題をもみ消して大騒ぎしないようにしようという方向に気持ちが向いてしまう心配がありますので・・・

おっと、そろそろ作業への集合時間ですので、このへんで。。