この忌々しい戦争
2001年に思い切ってフリーランスのITコンサルタントになりました。ロンドンの元同僚がフランスの旅行ショーに行き、ソフトウェアとデータベースの設計者を探しているヨークシャー出身の男性2人に偶然出会うなど、あり得ない偶然が重なり、その夏、私はノースヨークシャーに行き、別荘レンタル会社で働くことになりました。
正直に言うと、「コテージ」という言葉を聞いて、「誰かの小屋で経営されている小さな会社」と思ったものです。ですから、70席のコールセンターと、予約システムのOracleバックエンドを稼働させる8CPUのSun Microsystemsサーバーを備えた、田舎にあるかつての工場を訪れた時は、少なからず驚きました。
素晴らしいパワフルなシステムでした。サーバーハードウェアは格安で入手できました。選んだモデルは販売終了間近だったため、8基すべてのプロセッサはまだ必要ではありませんでしたが、後々旧式キットを拡張する際に問題が発生する可能性があったため、満杯にすることに決めました。もちろんサポートも問題ありませんでした。スペアパーツの在庫は数年間は正式に確保されており、もちろん最高水準（つまり非常に高額）の保守契約も締結していました。これにより、資格を持ったエンジニアによる1時間のオンサイトサポートだけでなく、ベンダーが同社のオフィスに専用線を引いてプロアクティブな監視を行ってくれました。
ストレージアレイも多数搭載され、満杯でした。当時の常識通り、比較的小型で高速回転のディスクが大量に搭載されていました。これにより、スピンドルとプラッターの数を最大限に増やし、同時読み取りと書き込みを最大化し、読み取り/書き込みヘッドの移動によるロスを最小限に抑えることができました。当時はSSDという言葉すら耳にしたことがなく、ストレージ技術用語で「スピニング・ラスト」と呼ばれるものしか選択肢がありませんでした。
使い心地は抜群で、昔Sunのシステム管理者として経験を積んだこともあり、とても馴染み深いマシンでした。動作も速く、あまり使われておらず、毎月1週間、カンブリアからOracleのエキスパートが来てくれて、作業の指示、データベースの最適化、アップグレードなどを行ってくれたので、Oracleのインストール管理の魔法のような煩わしさを心配する必要もありませんでした。
一緒に働くのも素晴らしい会社でした。開発マネージャーは私の主な相棒で、お互いをよく知るようになりました。ある晩、6時45分頃、彼の家で夕食をとっていた時に、コールセンターから電話がかかってきました。「予約システムがダウンしています」
数分後（彼の家はオフィスの隣の村だった）、私たちはサーバールームへ駆け込んだ。Sunのコンソールは起動中と表示されていたが、途中でクラッシュしてしまった。もう一度再起動するように指示すると、パワーオンセルフテストでCPUの故障が示された。「なるほど」と思い、CPUボードを1枚取り外した（CPUボードは4枚あり、それぞれ2つのプロセッサが搭載されていた）。もう一度再起動し、コーヒーを飲んで一息ついた。「クラッシュした。20分間全ディスクをチェックする」というサイクルが終わるのを待つと、コールセンターのスタッフは満足そうだった。
その時、電話が鳴った。「こんにちは、こちらは監視センターです。サーバーに問題が発生しています」。まさか、シャーロック。マークの食卓で冷えていく糖蜜スポンジケーキを証拠に、この事実は十分承知していると指摘した。
故障した部品を交換するためにエンジニアを派遣するよう依頼し、そのエンジニアには安全運転をお願いしました。後者の指示には理由がありました。当時、その地域にはオンコール対応のエンジニアが2人おり、それぞれ1時間離れた場所に住んでいたのです。それも、天気が良く、大きな黄色い路肩監視カメラや青色灯の車に乗った制服を着た人がいなければの話ですが。1時間というのは楽観的な時間でしたし、CPUボードが不足していたとはいえ、サービスは実際には問題なく稼働していたので、エンジニアが途中で自殺する事態は避けたかったのです。
興味深いことに、スペアパーツはエンジニアよりも近くにあったに違いありません。というのも、修理担当者が到着する数分前に、部品が詰まった茶色の箱を持った宅配便業者が到着したからです。9時半までには、すべては元通りになり、通常の状態に戻りました。
私がその会社で働いていた数か月間に、さらに 2 回の障害が発生しましたが、その 2 回とも、同じことが起こりました。つまり、私たちが問題を回避した後、監視センターから電話がかかってきたのです。
ある時、オペレーターから、何かが不格好にクラッシュした場合（つまりシステムからモニターに「I'm die」イベントが送信されていない場合）、気づかないことが多いと聞きました。しかし、通常は「おい、見てみろよ、クラッシュしたぞ」という重大なログメッセージのおかげで、システムが復旧したことに気付くそうです。本当に、ありがとうございます。
私はそのシステムの使用を通じて 3 つの重要な教訓を学びました。
- 常に期待通りの動作をするとは思わないでください。冗長コンポーネントに障害が発生した場合、システムはそれを見えない形で交換し、残りの7つのコンポーネントで動作を継続すると聞いていました。しかし実際には、システムがクラッシュし、物理的に取り外すまで再起動を拒否することもありました。
- 保守契約においてオンサイト対応の具体的な時間制限をご希望の場合は、ベンダーにエンジニアの拠点を尋ねてください。私たちはヨークシャーの奥地に住んでいましたが、エンジニアの住所や居住地を知った上で、自宅から1時間以内に現場に到着することはおそらく法的に不可能だと判断しました（仮に到着できたとしても、ギリギリでした）。
- 更新時にメンテナンスベンダーに厳格に対処すれば、翌年のサービスで大幅な割引を受けられる可能性があります。
®
