前回はトラブルコールを怖れない，という内容について書いてみましたが，まあ怖れる怖れないには関係なくトラブルコールはやってくるので，今回は，いざやってきたトラブルコールをどう打ち倒そうか，ということについて書いてみます。

トラブル対応のキホンと「省略」

トラブルといっても内容は実にさまざまです。ハードウェアが壊れた，クラッキングされてる，キャパあふれ，ポカミスなどいろんなことが起こります。キャパあふれひとつとっても，アクセス過多（DoS，DDoS含む⁠）⁠，ディスク溢れ，I/O（特にディスク）逼迫などバラエティに富んでいます。

そんなトラブルへの対応は，

1. 原因究明
2. 対応
3. 再発防止

という順番で行われるパターンが多いでしょう。

本来これは1→2→3という順番で行われるものですが，原因究明がなかったり，再発防止がなかったりすることもまま（多々）あります。

原因究明がないケースというのは，「⁠とりあえず再起動したらなおった」とかいった場合ですね。こう書くと偉い人が「そういう態度はエンジニアとして駄目だ」とか言いそうですが，まあ別に偉い人がなんて言うかなんてここでは無視します。

原因究明がないケースといってもその事情はさまざまで，原因究明しなくても良いときもあれば悪いときもあります。しなくて良いケースとしてわかりやすいのが，バックボーンのスイッチが暴走しているときなどです。くそ高いCISCOやJuniperのルータやスイッチも暴走しますからね。こういう時に「なんで暴走してるんだろう？原因を突き止めなくては！対応はそれからだ」などと言っているようでは失格です。それで長時間暴走を放置してネットワーク障害が長時間続いたら，偉い人に「なんですぐに復旧させないんだ」とか言われますきっと。

逆に原因究明がないのが悪いケースというのは，「⁠んー，よくわかんないしとりあえず再起動してみよう」というようなケースです。まあそれが「偶然にも結果的に」最善の策で，偉い人に「よくやったぞ」とか褒められることもあるかもしれませんけどね。

この，原因究明がなくても良いケース，悪いケースの違いは，判断の根拠があるかどうかです。たとえば，経験的に再起動すれば復旧することが推測できているときと，良くわからないから，というのは雲泥の差があります。

また，再発防止について言えば，「⁠これはやらなくて良いケース」というのはほとんどありません。しいて言えば，「⁠やりようがないケース」というのがあるくらいです。1ヵ月くらいすると暴走することが経験的にわかっているのにベンダに言っても認めてくれないような場合とか，対策にはお金が必要で，そのお金が認められないような場合などがあります。

そもそも，再発防止というのはトラブル対応ではなくてトラブル予防なので，トラブル対応という括りに入れていいかどうかはさておき，「⁠普通は」トラブル対応のあとに再発防止をするので，ここでは一緒くたにしています。

「高度な」判断とは？

トラブル対応というのは，正常な状態に早く戻して，かつデータを失わない，というのが目的です。データを失わないケースでは，とにかく正常な状態に早く戻せばいい，ということになります。データを失うリスクがあるケースはちょっとやっかいで，復旧を優先するか，データの保護を優先するか，これは高度な判断が必要になります。高度な判断というのは，エンジニアとしてスキルが高くないとできない判断，という意味ではなくて，そういう事について責任を負う人が判断しないといけない，という意味です。

筆者の場合，某アスキーにいたときは，障害が起こると「データを失うリスクをとってでも早く戻しなさい」というのが当時の事業部長の判断でした。某アスキーというか，某アスキーがやっていた某インターネットフリーウェイというサービスでは，です。

その後筆者は，某インターネットフリーウェイが提携していた某ハイパーネットという会社が倒産し，サービスの継続が困難になったために某So-netに転職をしました。その某So-netにおいて，ハードウェアが原因でメールサービスに障害が発生したことがありました。ハードウェア（ディスク）の障害でしたが，メーカのエンジニアが言うには，「⁠データを失う可能性はあるが，fsckするしかない」ということでした。

fsckが好きなエンジニアなんてこの世にはいないでしょう。そこで当時の上司にそれを報告して判断を仰いだところ，「⁠復旧よりデータを守るほうを優先して，もう少し時間をかけてでもデータを全部戻す方法がないか追及したほうが良い」という指示でした。つまり，某So-netは某インターネットフリーウェイとは全く逆の方針だったということです。

このときは，結局データを無事全部守ることができました。メーカの人が言うことがいつも正しいわけではないという良い例でもあります。

経験とその先にあるもの

さて，データを失うかもしれないリスクは，ここでは一旦置いておくとします。話を簡単にするために，「⁠いかに早くサービスを復旧させるか」に焦点を当ててみたいと思います。

サービスを復旧させるには，おおざっぱに言って2つのスキルが必要です。「⁠原因を突き止めるスキル」と「解決するスキル」の2つです。そして，相対的には，「⁠原因を突き止めるスキル」のほうが重要というか，より高度なスキルというか，突き止めることができる人は，まあ解決することもできると思います。逆に，原因がわかれば対処方法はわかるけど，原因は突き止められない，という人もいると思います。

もちろん，原因がすぐわかることもよくあります。むしろ，すぐわかるケースのほうがほとんどかもしれません。プロセス落ちてるだけとか，dfしたら100%だとか，dmesgしたらいっぱいエラーがでてるとか，そもそも電源が落ちてて入らないとか，ケーブルが鋭利な刃物で切断されているとかです（昔はISPが競合のISPのケーブル切ったりしてたそうです。こわいですねー……⁠）⁠。

でも，なかなか原因がわからないことも，もちろんあります。こういうときに必要だと筆者が思うのは，経験と空間的思考です。

経験は，もちろんたくさん場数を踏めば，以前発生したのと同じパターンに再度遭遇する確率があがっていくわけで，すぐに解決できる可能性が高くなると言えます。

空間的思考とは，なんのことわからないというか，そもそもこの表現が適切かどうかもわからないですが，「⁠頭の中に同時にたくさんの要素を思い浮かべて処理することができる」ような能力です。でもこれって実はTVの走査線のように，同時ではなくて，すごく短時間に次々と処理しているのかもしれません。

いずれにしても，ある程度トラブル対応の場数を踏んでくると，経験したことがないケースに遭遇しても，「⁠ハッ」と原因かもしれないものが思い浮かぶことがあります。もちろん外れることもありますが，場数を踏むほどに，当たる確率が上がるようにも思います。

以前に，トラブル対応をしているときに「なんでそんなにすぐに原因が思いあたるんですか」と聞かれたことがありますが，そのとき初めて「なぜか原因が思い浮かぶという現象がある」ということを意識しました。こんなことは，方法論として説明できないので「なんの参考にもならん」と言われればまあそこまでですが，よく似た話として，電気回路の設計の経験を積んでいくと，ある時点で，回路を見ただけで各ポイントの電圧がなぜかわかるようになる，オームの法則が身体に染みついた状態になる，というのを聞いたことがあります。

なので，いつかそうなると思って，たくさんトラブル対応の経験をしていくのが良いと思います。たとえ，そういう現象が自分には起こらなくても，少なくとも「経験」は増えていき，同じことが発生したときに対処できる可能性は上がるのは間違いありません。そしてなにより，トラブル対応していくことで，抜群に成長することができます。

トラブル対応のときに成長，というのは前回も触れましたが，トラブル対応をしていてこれが一番良い点（？）なので，次回か次々回くらいにとりあげます。