フェイルセーフ

【なぜバグは起きるのか】
まずは質問。

椅子と椅子の間に幅３０ｃｍ長さ１ｍの板が渡してあるとする。この間を落ちずに渡ることができるか？

これは多分たいていの人ができます。

それでは同じ幅・長さの板が、高層ビルと高層ビルの間の非常避難路に渡してあった時はどうか？

これは渡れる人はたぶん半分くらいでしょう。

符号１個の付け忘れのプログラムのバグで宇宙ロケットが誤って爆発してしまったという事故が以前アメリカでありました。多くの人は「なんでそんな簡単なものをミスるんだ」と思ったかも知れませんが、バグというのは上の板のようなものです。

通常の状態の中で見れば気づくはずのものが、その高度に組み上げられた長大なシーケンスの中では見落とされてしまう。

それをプログラマ個人の責任だというのは、あまりにも酷でしょうし、そうとしか考えなかったら、人類にはある程度以上のサイズのソフトは組めません。またもう今後プログラマーになろうという人は出てこないでしょう。

（同様の問題が近年病院で起きつつあります。早めに手を打つ必要があります。でないと50年後には医学生も看護学生もいなくなります）

更にこうしたらどうでしょうか。

幅３０ｃｍの板を、ドーバー海峡に渡した。この海峡をこの板の上を歩いて落ちずに渡ることができるか。ドーバーでできるのなら、太平洋の東京とサンフランシスコの間ではどうか？

人間の注意力だけに頼って、何十万行・何百万行といった大きなプログラムをバグ無しで組もうとするのは、そのくらい困難なことです。

(2000-07-18)

【古い機械と新しい機械】

松本零士さんの「銀河鉄道９９９」にこういう語りが出てきます。

『機械には二種類ある。歯車の２～３個取れてもなんとか動き続ける機械とどこか１ヶ所でも悪くなると全体がダウンしてしまうもの。昔の機械には前者が多かった』

ワインバーグという人はこんな事を言っています。

『プログラマーがプログラムを書くようなやり方で建築家が設計をしたら、キツツキが一羽とんできただけで町が崩壊してしまう』

松本さんが皮肉ったのも近年のコンピュータを利用した機器のことでしょう。

いつだったが私が専門学校出たてのプログラマのソースをチェックしてあげていたとき、こんな感じのコーディングに出くわしました。

　IF  IN-SOK >= 10 AND IN-SOK <=30
　    OUT-TAN = IN-SOK * 20 + 100.
　IF  IN-SOK >  30 AND IN-SOK <=50
　    OUT-TAN = IN-SOK * 25 - 50.
　IF  IN-SOK >  50 AND IN-SOK <100
　    OUT-TAN = IN-SOK * 30 - 300.

「ね、このプログラム IN-SOKが10未満の場合はどうなるの?」「IN-SOKは10以上の数字しか入力されません」「オペレータの人が間違って入力してたら?」

システムのバグの多分８割程度はこの手の問題である。正しい操作が行われている限り問題なく動いているが、利用者がミスをした時に、それをカバーしきっていないのである。

ということで、明日はいよいよ「フェイルセーフ」について書きます。

(2000-08-05)

【ファイルセーフ・フェイルソフト】

現代の航空機には多数の「フェイルセーフ」(fail safe),「フェイルソフト」 (fail soft) の機構が組み込まれています。

基本的に、どこかにトラブルがあっても他の部分でカバーして全体の機能に影響がでない仕組みを「フェイルセーフ」といい、若干機能が落ちるもののなんとか動く場合を「フェイルソフト」といいます。

フェイルセーフを実現するには「予備の回路」が必要であり、フェイルソフトはいくつものバイパス機構が必要です。

現在の大型ジェット機は2～4個のエンジンを持っていますが、この内幾つかのエンジンが止まっても1個だけでも動いていれば、その１個だけで飛び続けることが可能です。更にはエアバス(エンジン2機)になりますと、両方止まってしまった時のために非常用のプロペラが翼の中に内蔵されており、最後の最後にはこれが自動的に飛び出して最低限の浮力を確保するようになっています。これで長時間の飛行は困難だと思いますが近くの空港までくらいはなんとかなるはずです。

以前タイ航空のA300機内で日本の暴力団員が手榴弾を誤爆させてしまった時、エンジンが両方停止してしまったのですが、このプロペラのお陰で無事着陸させることができました。

先日のコンコルドの事故の場合は、第二エンジンにトラブルがあった時に本来なら供給が停止するはずの燃料の供給が止まらず、流れ続けてそれが爆発につながってしまったようです。当時(1969初飛行)はまだそのあたりのフェイルセーフの思想が弱かったのかも知れません。

航空機でそのあたりのことが相当強く言われて誕生したボーイングの767はコンコルドより10年後の1981年初飛行です。エアバスA300は1987年初飛行。
767やA300では安全性が高いため航空機関士を乗せずに、機長と副操縦士の２人だけで飛ばすのが一般的になっています。これらの飛行機は飛んでいる最中はほとんどコンピュータ(オートパイロット)が飛ばしているようなもので、人間が本当に操縦するのは離着陸の時だけです。

一般の企業ソフトで散々な言われようのするこの問題ですが、航空機のシステムにおいては、この技術に関して長い蓄積があります。

(2000-08-06)

【ファイルセーフとミスの関係】

フェイルセーフ機構は万一の時に二重三重の備えをしておき重大事故を防ぐための備えです。

ですからここで勘違いしてもらっては困るのは「フェイルセーフがあれば、多少のミスは許される」という安易な考え方です。

アメリカのライト・フィールド研究所のエド・マーフィー空軍大尉は1949年エドワーズ空軍基地で If something can go wrong, It will. と発言し、これが「マーフィーの法則」と一般に言われています。

マーフィーの法則に関する巷の本は笑い話的にこれを扱っていますが、実際は「絶対間違いが起きるから、それを避けるようにすること」という教訓がここにはあります。

「ここには1963から2005までの数値しか入れないでください」

などとソフト技術者はよく言うわけですが、そう言われていても、うっかり入れてしまうことはある。その結果ファイルが蒸発してしまったらまずい。

マーフィー大尉は「間違う可能性があったら、絶対誰か間違う。だから間違わないように設計してくれ」と言ったわけです。航空機のシステムにはこういう思想が徹底しています。

ただ問題は「どこまでカバーするか」ということになります。通常の利用の仕方で100万年に1度しか起きないような事態まで想定してシステムを作っていたら、システムの開発に莫大なお金がかかってしまいます。

ですから「手を抜く」ことも必要になります。これはミスとは別の問題。

一般に企業システムなどは開発者が利用者の近くにいるため、何かの事態が起きた時もすぐに対処できます。そのため、多くの企業システムの開発者は数ヶ月に1度程度しか起きないくらいのことは無視して設計作業を行っています。そしてそういう事態の時は「こう操作して欲しい」と言っておきます。

しかし、その時指示通りにオペレータが操作してくれなくて困ったことが起きても「復旧不能」にはならないような仕組みを必ず組み込んでいるものです。これは事実上のフェイルソフト。

しかしこれは一種のマキアベリズムであり、こういう哲学が欠けている設計者は実際に事故が起きてから「申し訳ありません。復旧できません。伝票を再度入力して下さい」などと、とんでもないことを言い出します。

こういうフェイルソフト思想というのは大っぴらに発言すると「君はこのシステムがダウンすると最初から思っているのかね。そんなことでは困るじゃないか。きちんと作ってくれよ」などとしか言われません。だから沈黙しておき、誰にも気づかれないように、また他のシステム技術者が分析しても意図的に組み込んだとは思われないように、巧妙に仕組んでおきます。

例えばファイルを更新する時、一般にいったん一時ファイルに書き出してから、書き戻しながら更新するというのはよく行われる手法です。こういう一時ファイルは作業を始める前に確保して、終わったら消去すればいいのですが....わざと手を抜いて、消さずに残しておくのが良い。何かの時のバックアップになるからです。しかもこの作業は

　A.更新しながら一時ファイルに書き出してからコピーして戻す。
　B.一時ファイルにコピーしてから、更新しながら書き戻す。

という２通りの方法がありますが、絶対 B にすべきです。Aでは終わった時一時ファイルにはマスターと同じものしかありませんが、Bだと一世代前が残せるからです。

しかしこういうことを理解している多くの設計者はこういうことを誰にも教えません。人に言った瞬間「ダウンする原因を取り除くべき」という「正論」にさらされてしまうから。

だから、これはマキアベリズムなのです。こういう人が作ったシステムには一見「ムダ」とか「手抜き」と思われるようなシステムの「枝葉」が付いています。

さて、企業システムで数ヶ月に１度程度の事態を無視している一方でマイクロソフトなどの超大手が作成したパッケージソフトになると、エラー確率がそういうシステムの100分の1以下くらいまで減らされています。多数の顧客に利用されるシステムはそれだけ事故発生率が高くなるので、逆に製造段階で確率を下げておかないと使い物にならない。

多くのソフトハウスが1990年代に消滅していった裏事情がここにあります。
ソフトの価格が安くなっている中で利益を上げるためには大量販売ができなければならない。しかし大量販売するにはバグの率を下げるための開発投資が必要。しかし資本金が数千万円以下の小さなソフトハウスにそんな投資は不可能。結局そういう所は生き残れない社会構造になってきたのでしょう。

しかし逆に最近のそういう低エラーのソフトはフェイルソフト機構がどうも弱すぎるような気がしています。

MSDOS時代のテキストエディタには万一途中でシステムが落ちた時に作業用の一時ファイルからテキストを復旧する機能が付いていたものがあります。
これに対して最近のマックやウィンドウズのエディタでこういうのはあまり見ません。ダウンの時のために何分かおきにデータをセーブする仕組みを持っているものがありますが、こういうソフトは「セーブして欲しくなかったのに勝手にセーブされていた」という事故を引き起こしています。

「ダウンした時に限って適切なバックアップが存在しない」

これもマーフィーの法則。

(2000-08-07)

【本来は本格的に組み込むべき】

さて企業システムでは肩身の狭いフェイルセーフ思想ですが、本当はちゃんと理解してもらって、本格的に組み込むべきです。

コンピュータのハードのレベルでは例えばメモリのECC機能みたいなものがあって、自己チェックしながら動いています。昔のACOS600なんてマシンは 1バイトが9ビットになっていて、これもパリティチェックをしながら動いてました。この機械は主に科学技術計算に使用されていましたので、ダムの設計とか原子力発電所の設計とかで万一にもミスがあっては、ということで重宝されていたと思います。

ソフトにもこういう仕組みは必要です。監査法人のトーマツなどは1990年頃からこういう問題をかなり強調していました。

伝票の借方・貸方などは1980年代頃までの多くのシステムでは矛盾が原理的に起きないようになっていましたが、これがまずい。原理的に矛盾が起きないシステムでは、本当に誤りがあっても気づかれません。

わざと処理の経路を複数化して、両方の結果を比較すべきです。

また、日計を日々累積していったものと、個々の伝票から再集計したものとの比較、などといった仕組みが自動的に動くようにしておくべきです。

ただ、こういうシステムを組み込む時に一番困るのが「精密にしてしまうと誤魔化せないじゃないか」という声です。

私も一度はっきりと「決算前に伝票を調整したいからね。過去の伝票を直接変更できないというのは困るんだよね」などと客先から言われたことがあります。受注しているソフトハウスのＳＥとしては、こういうことを言われても「それはダメです」とは言えない。

客先の社長さんなどと話をしている時には「修正伝票入れるのが正しいやりかたなんですよ」と言えるし、結構納得してくれるのですが、それ程の権限を持っていない人と仕様の詰めをせざるを得ない時は、相手が「今のやり方」を変えようとしてくれないので、こちらも妥協せざるを得ない。万一警察の捜査が入った場合は共犯に問われるかも知れませんが、やむを得ないところでしょう。

最初からごまかしたい人の前にフェイルセーフは意味を持ちません。

(2000-08-08)

【ボトムアップかトップダウンか】

高層ビルやトンネルなどといった大規模な建造物は最近ではコンピュータで何日も、どうかすると何ヶ月も掛けて設計と、負荷に対するシミュレーションが行われています。これが今のような高速なコンピュータのなかった1960年代とかはたいへんだったようで、霞ヶ関ビルの設計には10年もの時間がかかっています。

ある若手の設計士は初めてビルの設計を任されて、張り切って何週間もパソコンを操作し、多くの人にも相談。安全性・コスト・その他いろんな点から最良と思える設計図を完成。クライアントにも評価してもらって、いざ現場に出陣しました。

そして現場の監督さんにその設計図を見せたのですが。。。。

監督さんは「ああ、なるほどね」というと、その設計図を見ながら紙の上になにか簡単な絵をフリーハンドでちゃちゃっと書き、それを部下に示して、「さぁやるぞ」と声を掛けた。

設計士の書いた立派で精密な設計図は書類ケースの中に眠ったまま。

現場には現場のノウハウがあります。

たとえばトンネルの工事に長年関わっていた、ある監督さんは、強度に関する設計が万一あまかった時のことを考えて、指示されている厚さより必ず数十センチ、特に強度が必要そうな所は１メートルくらい、コンクリートを厚くしておくのだと言っておられました。

ここ150年くらいの日本の「高度技術」の進展のかげには、この手の現場レベルの配慮があります。

しかしこの現場レベルの努力がこのように「より安全に」という方向に進めば良いのですが、「より簡単に」とか「より安く」という方向に進むと、困った事態が引き起こされる場合もあります。それを次回に。

(2000-08-09)

Dropped down from digital episode.