達人が語る,インフラエンジニアの心得

第1回 トラブルコールを楽しむのだ

この記事を読むのに必要な時間:およそ 2 分

真夜中のトラブルコール

筆者は某アスキーという会社で,あるサービスの技術部に配属されたとき,まさにそういう状況でした。

技術部には他にエンジニアがいない状況でした。技術部の上司の人達はいましたが,主に予算取りが仕事だったりマネジメントが仕事だったりで,トラブル対応するのは独りだけだったのです。しかもそのとき,筆者はまだエンジニアになりたてというなかなか素敵な状況。ネットワークやUNIX※1の知識はまあ多少はありましたが,仕事でとなると話は別です。

当時一番辛かったのが,メールサーバの障害でした。なぜかそのサービスでは,某タンデム社のえらい高いマシンがメールサーバとして導入されていました。えらい高いマシンといってもHimaraya※2ではなかったですが。NonStop-UXというタンデムオリジナルのOSを積んだマシンでした。なんせ,NonStopと言うだけあり,あらゆる部品が冗長化されています。もちろん一番壊れるHDDもRAID化されています。

ところがこのマシンのHDDが,壊れる壊れる……。ほぼ毎日壊れてました。毎日壊れるということは,毎日トラブルコールが起こって対応しないといけなかったわけです。しかも,決まって深夜に壊れます。まるで意思があるかのように深夜に壊れます。

とはいえHDD障害なので,現着してもメーカの到着をまって,作業を見守って,復旧後にシステムを確認するくらいしかやりようがありません。毎日夜中になると電話がかかってきて,バイクで首都高を走ってデータセンターまで行くという日々。正直辛かったですねえ。

あまりにもよく壊れるので,メーカのほうで調査してくれたのですが,しばらくして原因がわかりました。IBMのHDDのあるロットに問題があって,そのロットのHDDを使っているとシステムがハードウェア障害と見なしてしまう,というのものでした。実際にHDD自体が壊れるのか,壊れてないけど壊れているように見えるのかまではわかりませんでしたが。ロットの問題なので,替えても換えても壊れたわけですね。ロット自体をずらしてもらったところ,めっきりHDDの障害は発生しなくなりました。

ところで,このメールサーバのHDD障害は,主にメーカのエンジニアを部屋に入れて,作業を見守るのがその役割です。なので,あまりに毎日続いて寝不足だったとき,さすがに技術部の部長には頼めないですが,自分と年齢もあまり違わない主任のような立場の人がいたので,対応を代わってもらえないか頼んでみたことがあります。その答えはNOでした。こういう大人にはなるまいと思ったことを覚えています。

※1
まだLinuxはマイナーで,SunOSが一番メジャーなころ(4.1.xくらい)です。
※2
Tandem(現在はHewlett-Packard)⁠ノンストップコンピュータ”。その信頼性の高さから,金融機関などに多く導入され,現在でも現役で動き続けているマシンも多い。

みんなの期待が重荷から糧に変わるとき

そんな日々を1年近く続けているうちに,発生するたいがいのトラブルには対応できるようになりました。自分のスキルも上がり,システムの深いところまで理解できるようになったため,予防措置を取る余裕もでてきました。このころには,あまりトラブルコールが鬱陶しくなくなってきていました。周囲から頼りにされることも増えてきたので,むしろトラブルが発生したときに,いかにサービスダウンを防ぐか,ダウンしたとしてもそのダウンタイムを最小にするか,ということがやりがいになってきました。

もちろんトラブルコールを歓迎する気にはなりませんが,トラブルコールがあっても「ぅあ」と思うのは1秒たらずで,通話ボタンを押すときにはすでに「いっちょやったるか」という気分になっていたものです。⁠俺じゃなきゃ解決できないんだな?」という気分が自分のモチベーションになっていた部分は否めません。

ちょっと話は逸れますが,以前自宅の電話がISDNになっていた時期があって,その場合ISDNルータ(名機YAMAHA RT100だった)に電話機をつなぐのですが,RT100は電話が着信すると電話機自体が鳴るまえに,一瞬「カチッ」という音がします。現役バリバリのころは,このカチッという音で目が覚めて,電話が鳴るときにはもう立ち上がりかけていたものでした。気分は特殊部隊員とでもいうようなものです(言い過ぎ)⁠

特殊部隊というより⁠ニュータイプ⁠か?!

特殊部隊というより“ニュータイプ”か?!

まあトラブル対応なんて,もちろん真剣にやらないと駄目ですが,どこかでそういう楽しみというか演出でもしないと,やってられないよ! というのはあるかもしれません。もちろんこのようなオフィス外でのトラブルコールだけではなく,勤務時間中にもトラブル対応が必要なことはありますが,いずれにしてもトラブルが発生したときに,それをある意味楽しむようになれるかどうかはとても重要だと思います。

最後に踏みとどまれるために

インフラエンジニアに必要なのは,サービスに対する責任感と自覚,それに見合うスキル,そして逃げない覚悟です。スキル以外のものは,自分の気の持ちようでどうにでもなります。あとはスキルをいかに早く身につけるかが重要だと思います。そしてそのスキルを身につけるのも,またトラブル対応だったりするのです。

著者プロフィール

山崎徳之(やまざきのりゆき)

青山学院大学卒業後,アスキー,So-netなどでネットワーク,サーバエンジニアを経験。オン・ザ・エッヂ(現ライブドア)のデータセンターである「データホテル」を構築,運営。2003年にベイエリアにおいてVoIPベンチャーであるRedSIP Inc.を創業。2006年6月に株式会社ゼロスタートコミュニケーションズ(現 ZETA株式会社)を設立,代表取締役就任(現任)。ECソリューションの「ZETA CX」シリーズとして検索エンジンやレコメンドエンジンを開発,販売している。

blog:http://blog.zaki.jp/
社長コラム:https://zetacx.com/column

コメント

コメントの記入