はじめに

『インフラエンジニア』という表現は、筆者にはあまり馴染みがないのですが、ここでは運用を主とするサーバおよびネットワークエンジニアという前提で、「⁠インフラエンジニアとは何か？」について語ってみたいと思います。

まずインフラエンジニア（違和感）のお仕事は、予測可能な、というか計画できるものと、（⁠悪い意味で）予測はできるけど計画なんて立てられない、というものに分けることができます。

前者は、インストールだったりセットアップだったりゆとりのあるチューニングだったりするわけですが、後者はトラブル対応だったりゆとりのないチューニングだったりします。前者はまあSE的な要素もあるし、この場では期待されていないだろうなあ、と思うのではしょりますが…。

…何が言いたいかというと、この連載ではインフラエンジニア（違和感）の直面するトラブル対応について、具体例や心構えやメリット（？）やデメリット（？？）について書いてみますのでどうぞよろしくお願いします。

自分の後に誰もいない？

トラブル対応の一番の特徴と言えば、いつ発生するかわからないところです。しいて言えば、わりと起きて欲しくない時を選んで発生しているような気もしますが。インフラエンジニア（違和感）が初期に乗り越えるべき壁の一つに、電話が鳴るのを怖れない、いや怖れてもいいけど挫けない、というものがあります。

所属しているのがでかい組織で、他にもたくさんエンジニアがいて、きちんとシフトも組まれていて、自分より詳しい人もたくさんいる、というまるで夢のような状況ならば、自分が休みのときに電話がかかってこないし、自分の後ろに誰もいない冷や汗出ちゃうようなことはありませんが、そもそもその場合は自分がそこにいなくてもいいんじゃない？的な、夢というよりむしろ悪夢じゃないそれ、という感じなので、そいういう場合は除きます。

自身のスキルがある程度以上になってくるとか、他に誰もいない、自分が一番最後の砦というような状況では、いつ何時電話でトラブルコールが来るかわかりません。慣れないうち（慣れるものじゃありませんが）は、この電話は正直あまり良いものではないというか、正直言って嫌なものです。

ああ、せっかく寝てたのに…とか、寝不足なのに…とか、久しぶりの飲み会なのに…とか、そんな状況は関係なく、というかそういう時をむしろ狙って電話はかかってきます。

でも、正直このトラブルコール、慣れれば慣れるものなんです。「⁠そんなわけあるかー！！」という声も聞こえてきそうですが。日々の仕事でトラブル対応をこなしていると、原因の推測も速くなるし、どう対処していけばいいかのイメージもわきやすいし、そもそもそういうトラブルコールへの精神的な閾値が低くなります。

ピンチ＝チャンスなり

もしいつまで経ってもトラブルコールに慣れない、鬱だ、という人がいたとしたら、その原因は主に2つあるのではないかと筆者は思います。

ひとつは、そもそも向いてないパターン。仕事に向いていないのか、運用に向いていないのか、いずれにしてもこのパターンは考えてもしょうがないので、さておいておくとします。

もうひとつは、自分で解決できないトラブルが多いパターン。この、自分で解決できないというのは、単に自身のスキルが足りていないのに何故かさまざまな理由で自分が一番最後の砦になっているようなケースもあれば、ハードウェア障害が多くてメーカに現調を頼むしかないケースもあります。

特に自分のスキルが足りていないのに、自分でなんとかしないといけないパターンというのは、「⁠もし解決できなかったらどうしよう」というプレッシャーががっつりのしかかってきます。そして、こういうケースこそが、インフラエンジニア（違和感）の一番のチャンスの場だったりします。

トラブルほど成長のチャンスになるものはありません。この「トラブルこそチャンス」というトピックは、また別の回で取りあげたいと思いますが、いずれにしてもこの状況というのは、自分が成長さえすれば通過できるステージです。いつまでたってもトラブルコールが慣れない、不安に苛まれる、という場合にはとっととスキルを身につけて、トラブルへの対応力を上げてしまえば、そういう状況からはある程度解放されます。

真夜中のトラブルコール

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

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

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

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

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

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

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

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

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

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

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

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

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

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