「Divide by Zero（ゼロ除算）」とは

プログラムを利用して数値を０で割ろうとすると発生することがあるエラー。エラーにならずに、NaN（Not a Number）を返す言語もある。

割り算を行う箇所では０除算は必ず考慮しておくのが常識とされているので、システム障害が発生してエラーの原因を探りこれが見つかったりすると、周囲の視線が痛いことになったりするので、ちゃんと制御を入れておくことがオススメされるもの。

「考慮に値しない確率」とは

10の何十乗とか百乗分の１のような、限りなくゼロに近い確率のこと。

どの程度の確率まで考慮する必要があるかは、それが発生した際に起こる被害の大きさと、それに対応するためにかかるコストと、その設計を行う際のエンジニアの気分によって決められる。

以前見かけた例として、ユーザがログインする際に前回ログイン日時が、ちょうど１年前の同じ時間、同じ分、同じ秒だった場合に正常にログインできないという事象（どう見てもバグ）がある。ただ、発生する確率が極めて低いうえ、１秒でもズレた時間に再度ログインすればちゃんと処理されるので、気にしなくていいかという結論に至った。

ハードウエアのトラブルなどでは、例えばHDDが１本飛んだだけでシステムが全停止になったり、RAIDを組んでおいたHDDが２つとも同時にお亡くなりになったりする場合についてまで考慮すべきかは、そのシステムが止まった時に発生するダメージなどによって変わると思われる。

人命にかかわる医療関係の機器や、証券やFXのような巨額のマネーが飛び交うようなサイト、数十万人に影響が出る交通機関のシステムなどは、どこまでも不慮の事象が発生する可能性を消していかなければならないので、設計していて頭が痛くなりそうな気もする。

「試験」とは

開発現場で試験という言葉を使用すると、情報処理技術者試験等の資格試験を連想される場合もあるが、大抵は単体試験や結合試験といった、ソフトウエアの試験を指すもの。

試験はシステムに存在するバグを洗い出し、精度を上げることを目的に行われる。これをちゃんと行わずに、微妙なバグを内包した状態でリリースしてしまうと、後で痛い目に遭うことがあるもの。

特にユーザの入力によって簡単に発生したり、閾値チェックを一回りすれば見つかったりする、「そのバグは試験で見つけられないとおかしい」系のバグを残しておくと、会議室に呼び出されて偉い人から小一時間ほど説教されるとか、世間さまから指を指されて笑われる等の、激しく心が萎える事態に陥ることがあるので、危険である。

昔はちゃんとした試験を通過したシステムであればバグはないはずとかいう、プログラマの常識から若干外れた認識でシステムが取り扱われていたが、最近は開発者以外の間にもバグのないシステムは存在しないという認識が広まりつつあるお陰で、バグ数とテスト工数のトレードオフを考慮して、ある程度のバグが残るのは仕方ないという認識の下で行う試験も存在する。例えば個人情報や決済等が絡まない、GoogleのようなWEBサービスでは、その傾向が強く見られる。

そのため、通常の試験では発見するのが難しいバグ、例えばサーバがダウンして待機系に処理が移る瞬間だけ異常な動作が起こるとか、通常に運用していれば問題ないが連続497日稼動させると不具合が生じるといった内容の場合は、「仕方ないよね」と言ってくれる優しい現場もこの世には存在するようだ。

「DIFF」とは

差分という意味で使われることが多い。

Linuxを使用していると、「diff ファイル名1 ファイル名2」と書くだけで、2つのファイルの間で差分がある箇所を確認することができる。手作業で何かを直したあと、このDIFFを見ると、自分が触った行だけが確認できるので、作業漏れやミスがないかチェックする用途で使用できる。

筆者のようなミスの多いエンジニアは、作業後にDIFFを見ておかないと恐ろしいほど高確率でミスを発生させてしまったりする。 

「スペルチェック」とは

WordやExcelなどのオフィスソフトや一部のIDEに搭載されている、誤字を検出してくれる機能。

Officeや辞書ソフト等のチェック機能は、残念なことに一般的な言葉に対してだけ正しく機能する場合が多い。そのため、ライブラリの名前とか最近新しく生まれた用語などが大量に盛り込まれた文書を扱っていると、正しい言葉を使っているのに大量にチェックを付けられることがあるもの。

特に、ソースを本文に貼り付けたメールをOutlookで送信したりすると、ほとんどの記述が片っ端から誤字扱いされるという悲しい現象に出合ったりする。

あまりにチェックされる項目が多過ぎて、本当の誤字を見過ごしてしまうことも多い、エンジニア的には扱い方が難しいもの。

「レプリケーション」とは

複数のハードウエア間で同じ情報を整合性を持ちつつ取り扱うこと。

レプリケーションを使用すると、複数台のDBサーバをアプリケーション側ではそれほど意識することなく（少しは意識しないと筆者のような状況に陥るので注意）取り扱うことができる。

複数のDBサーバを使うと、台数の分だけ負荷を分散することができたり、もし一台で運営しているDBサーバがお亡くなりになったりしたら、管理者の胃に穴が空くような復旧作業が発生すること請け合いなのに対して、複数台でデータを共有していれば、もう一台のほうにある程度完全なデータが入っているから、新規にDBサーバを立て直すだけでいけるかもといった余裕を持った気持ちで障害対応に当たることができるかもしれない（INSERTされてから情報がほかのサーバに伝播する前に壊れたら、さすがにその分のデータは戻らないが）といったメリットがある。

ただし、各DB間で整合性を取るということは、INSERTやUPDATEが発生したら、必ずその情報をレプリケーションしているすべてのサーバに伝えなければならないということになる。その場合、もし複数のDBで同時にINSERTが発生したらどうしようとか、1つのサーバにデータがINSERTされた直後に、別のDBサーバにその情報の問い合わせが来たらどうしようとか、考えていると頭が痛くなるようなことを解決しなければならない。

また、データの追加・改変が行われてから、その情報がほかのサーバに伝播するまでには多少のタイムラグが発生する。DBMSの作りによっては大量の処理要求が発生すると、INSERTの情報を全体に伝播するのに1分以上かかっちゃいましたというような、いろんな問題を併発させそうな現象を起こしてくれることもあるので、注意が必要なもの。

「遅延」とは

1つの処理が完了するよりも速いペースで新しい要求が発生し続けることで、キューに処理がたまり、命令してから処理が完了するまでに、普段とは比べ物にならないくらい長く時間がかかってしまうような現象。主に高負荷やネットワークの帯域不足などによって発生する。

某・腹話術師さんの芸で、「システムが、遅れて、動いているよ」と言ってもらった感じと言えば分かりやすいだろうか（きっと分かりづらいだろう）。

一部のエンジニアは、遅延が発生している際に当該アプリケーションの状況を調べると、「わーい、プロセスが500個も立ち上がってる」とか「凄い。ロードが100まで行ってる。3桁とか久々に見た」といった言葉をなぜか非常に高いテンションで、かつちょっとうれしそうな声で口にしたりすることがある。こういったトラブル発生時に、どうしてテンションが高まるのかは不明である。

遭遇する代表的な遅延の例として、メール遅延がある。スパム業者の人々が頑張り過ぎて、サーバが取り扱える以上のペースでメールをバラまいたりすると発生する。メールのユーザから見てもスパムは厄介なものだが、メールサーバの管理者はもっと厄介だと思っているかもしれない。