エンジニアがいつも繰り返す失敗とは? 後編 
油断は大敵!

米オラクルのエンジニアにしてQ&Aサイト「Ask Tom」を主宰するトム・カイトによる、技術者がスキルを向上するためのヒントをお送りしよう。(編集部)

■セキュリティは大事
 「オラクルデータベースは安全だ。だから我々がセキュリティについて気にする必要はない。それよりも、画面の見た目を直す方が重要だ。セキュリティ機能は後で簡単に追加できるだろう」――こんな風に考えるエンジニアも少なくない。

 しかし、もし自動車メーカーにこれと同じように考えるエンジニアがいたらどうだろうか。とてもカッコよいクルマを開発した。クルマのそばに近 づくとドアが自然に開いて、シートに座るとドライバーの体格にぴったり自動調整される。自宅までの道のりも自動操縦で、車庫に勝手に収まってくれる。しか し翌朝見てみるとクルマはそこにはない。誰かが乗っていってしまった。

 そして慌てて駆けつけたクルマのディーラーはこう言う。「はいはい、確かにセキュリティ上の欠陥がありました。これがセキュリティ対策用の大 きなチェーンです。ご自宅にクルマを止めたらこのチェーンでどこかにくくりつけてください。クルマの底に潜り込む必要があるのでちょっと不便かもしれませ んし、キズが着くこともあるかもしれませんがご了承ください」。――セキュリティについては最初から考慮しなくてはならないことがおわかりいただけるだろ う。

  tc_101106-02-01.jpg
後からセキュリティ対策を行おうとすると、大変な事態が待ち受けているものだ。


■「すべてうまくいく」と思い込む
 エンジニアはしばしば、「すべてうまくいく」と思い込むクセがある。これはもっとも大きな失敗のひとつで、しかも何度も繰り返されるものだ。 例えば、いわゆる「予期せぬエラー」について「いつか発生しうる」といった程度で捉えるのではなく、「必ず発生する」と考えるべきだ。そして、予期せぬエ ラーをキャッチするコードを書いたら、それをスキップするのではなく必ずログを残すコードを書くべきである。

tc_101106-02-02.jpg
TT- Mobileのスマートフォン「Sidekick」のユーザーデータがすべて失われたことを報道したTechCrunchの記事。データのアウトソーシン グを行っていたMicrosoftの子会社Microsoft Dangerが、SAN(Strage Area Network)のアップグレード作業時にバックアップミスを犯し、ユーザーデータを失ってしまったという。TechCrunchは「われわれの記憶で は、インターネット史上、無能が原因の最大の惨事の一つだろう」と苦言した。(出典:TechCrunch)

 また、そうした「例外処理の方針」をできるだけ早い段階で立てておく必要がある。まずは「どこで例外をキャッチすべきか?」という点。個々の 作業単位でtry/catch節を記述し、例外をキャッチする。このとき、例外発生時のリトライやスキップが適切に行える範囲を作業単位としておく。

 定めておくべき方針は他にもある。例外をキャッチしたらどうするか?エンドユーザー、開発エンジニア、管理者のいずれに知らせるべきか?この 作業単位でリトライすればエラーが解消されるか?リトライするまでにどの程度待つべきか?それとも別の処理に切り替えるべきか?アプリケーションの状態異 常によって起きたエラーか?エラーによってアプリケーションに状態異常が発生するか?――といった点について事前に定めておこう。

 データのバックアップとリストアも重要なポイントのひとつだ。例えば「Ask Tom」 のデータベースサーバーは当初、私の机の下にあるPCで稼働させていたが、データの規模も大きくなりデータセンターに移動した。その後もAsk Tomサーバーの管理は私自身で行っていた。ディスクが不調になった時も蹴っ飛ばして直したりしていたものだ。そんな状態だったため、データが失われる危 険性が気になり始めていた。もちろんバックアップは作成していたが、なにぶん片手間のデータベース管理だったため、バックアップデータが本当にリカバリで きるか定期的に確認するまでは実施していなかった。

 そこで私は「Ask Tom」 を「apex.oracle.com」ドメインに移行した。このドメインのデータベースサーバーは、すべてオラクルの専任の管理者がバックアップとリカバ リを責任持って実施している。「データを絶対になくさない」のが彼らの仕事だ。この移行によって、Ask Tomのデータベースサーバーを私自身が自由に変更できなくなったものの、いまやデータは極めて、極めて安全な状態にある。

 データは、バックアップさえ取っておけばよいものではない。データがリカバリできることまでを専任の管理者が責任をもって確認することが重要 だ。私はこれまで何度も、「RAID5のストレージなのだから心配することはないよ」と説明するエンジニアを見てきた。しかし実際には、ディスクドライブ は一度にまとめて故障するものだ。新しいSAN(ストレージエリアネットワーク)を購入してフタを開けてみるといい。そこに収まっているディスクドライブ のシリアル番号を見れば、1234、1235、1236...といった具合に連続していることも多い。こうした状況で「ロット不良(同時期に製造された製 品の大規模な不良)」が発生していれば、いとも簡単にSANのデータが完全に失われてしまう。だから、バックアップとリストアについてはどのような場合も 軽視してはならない。

(終わり)


前の記事 <<  最初の記事へ  >> 次の記事

《エンジニアがいつも繰り返す失敗とは?》シリーズをお見逃しなく!