故障しないプログラムの作り方

最初に注意してほしいのは、テーマが「バグのないプログラム」の作り方ではないということです。つまり「プログラムには必ずバグがある」という想定です。この想定の下での話になります。
# え？バグのないプログラムがある？・・・想定外です。

ここでは、例えプログラムにバグがあっても故障しないプログラムというものを考えます。

1.2 故障しないプログラムは故障を発見できること

故障しないプログラムが必要とするのは「故障していることを発見できる」ということです。逆の方法としては「正しく動作しているということを発見できる」ということです。

しかしこの発見プログラムにも当然バグがある可能性があります。「故障を発見できないバグ」と「正常動作を発見できないバグ」が起こる可能性があります。

1.3 故障発見プログラムよりも正常動作発見プログラムが優れていること

故障を発見することと正常動作を発見することは論理的に考えれば、等価です。裏表になります。つまり故障していなければ正常動作で、正常動作していれば故障していません。

しかし、実際は(1)正常動作を発見するプログラムと、(2)故障を発見するプログラムを比べると、正常動作を発見する方が優れています。

本来は等価なプログラムなのですが、なぜ、筆者はこんなことをここで書いているのか？もしかしたら読者にも経験があり、「ある、ある」と頷いている方もいるかも知れません。そこでこの謎を明かしたいと・・・あ、時間切れです。次へ続きます。

次からは、この故障発見プログラム（または正常動作発見プログラム）を考えてみます。

先頭へ戻る

2. 故障を発見するには？

2.1 バグの大原則

ここでは故障発見のところをもう少し詳しく書いていきます。
# 誤魔化されないように注意してください。

故障発見プログラムの前に、バグの大原則について書きます。

大原則
その1. プログラムにバグはある
その2. バグは想定不可能

「その1」に関しては、これは観測事実からの想定です。またはプログラムの正当性を証明しない限り、バグなしを保証できず、これをバグがあると表現していると思ってください。「その2」に関しては、もしバグが想定できるならば、それをキャッチして処理すればいいだけですから、それはもはやバグとは呼ばずに例外と呼びます。この原則の下にこれから故障発見のプログラムを考えていきます。

2.2 故障発見プログラムと正常動作発見プログラムの差

前回は「(1)正常動作を発見するプログラム」と、「(2)故障を発見するプログラム」を比べて、正常動作を発見する方が優れていると書きました。よね？たぶん。きっと。

これはデフォルトで未発見=falseにしておき、見つかれば true にする発見プログラムの構造を考えたとき、誤検出して発見してしまうバグよりも、発見できないバグの方が多いだろうという知見、経験、ヤマ勘からです。

でもこれは大原則の「バグは想定できない」というのにも反しますし、バグは多少ではなく、1個でも重大なバグは地球よりも重いということになり、これにも相容れません。

フェールセーフの考えからは、エネルギーの低い方（デフォルトでそうなる方）に安全側を設定するのですが、プログラムのバグにはエネルギーの法則が成立しないかも知れません。
彼らのエネルギーはフリスクだけかも知れません。あ、これはデバッグするときのエネルギーでした。

と言うところで、紙面が尽きました。次回でまた会いましょう。

先頭へ戻る

3. 正常動作を発見するには？

3.1 ヘルスチェックには二通りあること

今回は正常動作の発見方法です。

このようなことをするのにヘルスチェックがあり、その一つの方法として、自己申告型があります。「自分は健康だ」とか「自分は正常だ」のように自分自身の状態を自分自身が言い、それを発見プログラムが聞き取るという方法です。しかし例えば列車の中で人間が「自分は正常だ」というときには必ず異常です。「俺は正常だ。世の中の方が異常なんだ。」と思う方は気を付けてください。プログラムもまた自分自身が正常だと言うのは信用できません。

次は問診型ヘルスチェックがあります。「私の声が聞こえていますか？」「あなたのお名前はなんですか？」「おうちはどこ？」のように、夜中に徘徊している人に聞くアレです。しかしこれも油断できません。家族がその質問だけは脊髄反射で答えてバグが出ないようにネタを仕込んでいるかも知れません。

例えば、あるプログラムに聞いてみましょう。「あなたの名前は?」「WIndows OS です」「あなたは何をしていますか？」「世界中のすべての人が公平に幸福になるようにスケジューリングや割り当てをしています」もちろん、このプログラムは自意識過剰でナルシストで自惚れで自信過剰でビッグマウスで、異常です。または嘘つきです。

ということで、ヘルスチェックは自己申告型と問診型があり、それぞれ問題があるというところまでです。・・・ってそれだけだったの？

先頭へ戻る

4. 寸劇：想定できないもの

4.1 いきなり寸劇が始まったこと

脚本によれば、今回は故障発見後の処理（慌てぶりを含む）方法でしたが、ここでA君とG君が乱入してきましたので、インターミッションとして、放送致します。（って脚本って何？A君とG君って誰? それよりも何よりも今まですべてがインターミッションじゃなかったの？）

---
A君: で何にしても駄目なんでしょ。プログラムにはバグもあるし、故障もするんでしょ。
数学的にも実際にも。
G君: 数学的に言っては駄目じゃ。工学は数学じゃなく、何が何でも解を見つけるんじゃ。
どんな事をしても。どんな制限をしても。どんな、、
A君: 「プログラムを書かなければバグはない、故障はしない。」という制限のこと？
G君: こら、それはわしが最後のオチに言おうと思っておったのに。
A君: じゃ、これ以外にどんな妥当な制限があるんですか。見せてもらおうか、連邦軍の制限やらを。
G君: バグの傾向性を調べて、その出現確率を元にして、故障発見のアルゴリズムに適用するんじゃ。
A君: それって「バグは想定不可能」の原則に矛盾しませんか？
G君: ええい、数学じゃない、工学じゃ！
A君: 工学という言葉を便利な免罪符にしていません？
それに形式手法とか、プログラムの正当性検証とかをやっていたんじゃないの？
G君: いや、それは置いておいておいて。
えっと、ツッコミすぎてはいかんということじゃ。おとななんだから。
A君: ・・・え？もう時間？分かりました。
ところで、故障しないプログラムはどうすれば作れるんですか。
G君: それはじゃ、数学的にプログラムの正当性を証明するんじゃ。
あ、これは30年前の原稿ではないか。
ごほん。故障しないプログラムは、確率的、社会工学的、心理学的、探偵的、杉下右京的に作る総合芸術じゃ。
---

はい、カット。Aさん、Gさん、御苦労さまでした。ありがとうございました。また、お願いしますね。

ふー。おい、今回のは何だ。次回は真面目に行くぞ。

先頭へ戻る

5. フェールセーフとは？

5.1 フェールセーフは低エネルギーな状態が必要なこと

今回はやっと確率論が出てくる予定です。確率さん、舞台袖で出番を待っていてくださいね。では始まります。

---
プログラムは、低エネルギー状態が定義できる物理現象でないため、真のフェールセーフは実装できません。きっぱり。

だってだって、プログラムは論理だけでできているものダカラ。もっと正確には
「プログラムは妄想でできている」

ものですから。妄想にフェールセーフはありません。リスクはありますが。

---閑話開始
「結婚は妄想でできている」という有名な言葉がありますが、
#あれ？あったかな？まぁいいや、まぁいいです
この意味では、プログラムは結婚のようなものです。
# 何段階か、論理のジャンプがありますが、気にしないで、気をつけてください。
---閑話休題

5.2 想定できないバグを想定すること

性悪説によれば、プログラムはバグであり、プログラマは必ずバグを作ります。プログラムにバグがないように見えるときは、バグを発見できていないだけであり、それは偽善です。

プログラマはどのようにバグを作るのか？
・・・これは「バグは想定できない」とする前提2により、ありとあらゆるパターンが偏在しています。

そこで以下のことを考えます。
「プログラムはどのように（間違って）バグがないように見えるのか？」
つまり、プログラムの偽善を見破るには、どうすればいいかです。偽善を見破りながら、正常系の検出を行う方法です。

ここで確率の登場です。フェールセーフを偽善的に実装するために、いよいよ登場です。偽善を確率で見破ります。いよいよ、登場です！！あ、登場とともに時間切れです。それでは次回またお会いしましょう！

確率：「っておい！私は何のために登場したんだ？」

次回予告「確率と統計の怪しい関係、その結末は？」です。・・・たぶん、違うものを放送する予定です。

先頭へ戻る

6. 多数決はプログラムを救えるか？

6.1 多重系は安全・安心か？

ここでの私たちの目的は、
# 私たちって誰のこと？
バグがあるにも関わらず、
# ここはもうツッコミをいれなくてもいいのね？
一見、正常に動作しているように見えるプログラムの偽善
# 偽善って何？ああ、偶然、動いているってこと？
を暴くということです。

そこで前回に登場した確率の再登場です。
# やっと確率的正常動作診断の話になる！

その前に、多重系のお話をします。
故障しないシステムを作るには多重系のシステムで作ればいいという話があります。物理現象であるハードウェアはこれが成立します。ディスクにしろ、プロセッサやメモリにしろ、これらを多重化すれば、それだけ故障は少なくなります。つまり金持ちは故障しないということです。三重県に納入するシステムはもちろん3重の多重システムにすべきです。

しかしプログラムではこの多重化はどうでしょうか？金持ちのプログラムは故障しないのでしょうか？例えば、ロケットのプログラムを別々のアルゴリズムとデータ構造で作成します。そしてロケットの発射までは全員一致型で判断し、ロケットが飛んでからは、多数決で判断すると言う多重系を考えます。

一見、この多重化されたロケットプログラムは故障しない強いシステムのようです。 NASA でも JAXA でも採用していそうです。

6.2 多重系は安全でないこと

でも故障には強くありません。
「プログラムは多重化しても故障に強くなりません」
残念ながら、このようになります。

なぜ強くならないかと思われた方は・・・続きはこちらです（有料）。

ということはせずにここでばらしちゃいます。
# 言葉使いも変わってきているし、それに次回までだと覚えていないだけだろう！

プログラムを多重化しても故障に強くならないのはなぜか？

その前にプログラムの多重化の仕組みを考えてみます。プログラムの多重化とは、同じ機能の別々のプログラムを複数動作させ、その結果を例えば、一致型や多数決型で判断します。

もう気づかれましたでしょうか。多重化の欠点を。

そうなのです。結果の判断のところは多重化されていません。一致判断や多数決判断は一重です。

ハードウェアの多重化とは違い低エネルギーが使えないのでここにバグが生まれます。

それでは、例えば多数決判断の部分を多重化するというのはどうでしょう。もちろん駄目です。メタ多数決判断が必要になってきて、無限ループします。

ということで、今日辺りの教訓。
「この世には金で解決できないこともある。例えば愛だ！」・・・て違う。

確率：私の出番はいつ？
・・・あれ、あんた、いたの？

先頭へ戻る

facebook の調べ Android の調べ鉄道の調べビールコレクション