前回はトラブルコールを怖れない、という内容について書いてみましたが、まあ怖れる怖れないには関係なくトラブルコールはやってくるので、今回は、いざやってきたトラブルコールをどう打ち倒そうか、ということについて書いてみます。
トラブル対応のキホンと「省略」
トラブルといっても内容は実にさまざまです。ハードウェアが壊れた、クラッキングされてる、キャパあふれ、ポカミスなどいろんなことが起こります。キャパあふれひとつとっても、アクセス過多（DoS、DDoS含む）、ディスク溢れ、I/O（特にディスク）逼迫などバラエティに富んでいます。
そんなトラブルへの対応は、
- 原因究明
- 対応
- 再発防止
という順番で行われるパターンが多いでしょう。
本来これは1→2→3という順番で行われるものですが、原因究明がなかったり、再発防止がなかったりすることもまま（多々）あります。
原因究明がないケースというのは、「とりあえず再起動したらなおった」とかいった場合ですね。こう書くと偉い人が「そういう態度はエンジニアとして駄目だ」とか言いそうですが、まあ別に偉い人がなんて言うかなんてここでは無視します。
原因究明がないケースといってもその事情はさまざまで、原因究明しなくても良いときもあれば悪いときもあります。しなくて良いケースとしてわかりやすいのが、バックボーンのスイッチが暴走しているときなどです。くそ高いCISCOやJuniperのルータやスイッチも暴走しますからね。こういう時に「なんで暴走してるんだろう？原因を突き止めなくては！対応はそれからだ」などと言っているようでは失格です。それで長時間暴走を放置してネットワーク障害が長時間続いたら、偉い人に「なんですぐに復旧させないんだ」とか言われますきっと。
逆に原因究明がないのが悪いケースというのは、「んー、よくわかんないしとりあえず再起動してみよう」というようなケースです。まあそれが「偶然にも結果的に」最善の策で、偉い人に「よくやったぞ」とか褒められることもあるかもしれませんけどね。
この、原因究明がなくても良いケース、悪いケースの違いは、判断の根拠があるかどうかです。たとえば、経験的に再起動すれば復旧することが推測できているときと、良くわからないから、というのは雲泥の差があります。
また、再発防止について言えば、「これはやらなくて良いケース」というのはほとんどありません。しいて言えば、「やりようがないケース」というのがあるくらいです。1ヵ月くらいすると暴走することが経験的にわかっているのにベンダに言っても認めてくれないような場合とか、対策にはお金が必要で、そのお金が認められないような場合などがあります。
そもそも、再発防止というのはトラブル対応ではなくてトラブル予防なので、トラブル対応という括りに入れていいかどうかはさておき、「普通は」トラブル対応のあとに再発防止をするので、ここでは一緒くたにしています。
「高度な」判断とは？
トラブル対応というのは、正常な状態に早く戻して、かつデータを失わない、というのが目的です。データを失わないケースでは、とにかく正常な状態に早く戻せばいい、ということになります。データを失うリスクがあるケースはちょっとやっかいで、復旧を優先するか、データの保護を優先するか、これは高度な判断が必要になります。高度な判断というのは、エンジニアとしてスキルが高くないとできない判断、という意味ではなくて、そういう事について責任を負う人が判断しないといけない、という意味です。
筆者の場合、某アスキーにいたときは、障害が起こると「データを失うリスクをとってでも早く戻しなさい」というのが当時の事業部長の判断でした。某アスキーというか、某アスキーがやっていた某インターネットフリーウェイというサービスでは、です。
その後筆者は、某インターネットフリーウェイが提携していた某ハイパーネットという会社が倒産し、サービスの継続が困難になったために某So-netに転職をしました。その某So-netにおいて、ハードウェアが原因でメールサービスに障害が発生したことがありました。ハードウェア（ディスク）の障害でしたが、メーカのエンジニアが言うには、「データを失う可能性はあるが、fsckするしかない」ということでした。
fsckが好きなエンジニアなんてこの世にはいないでしょう。そこで当時の上司にそれを報告して判断を仰いだところ、「復旧よりデータを守るほうを優先して、もう少し時間をかけてでもデータを全部戻す方法がないか追及したほうが良い」という指示でした。つまり、某So-netは某インターネットフリーウェイとは全く逆の方針だったということです。
このときは、結局データを無事全部守ることができました。メーカの人が言うことがいつも正しいわけではないという良い例でもあります。
経験とその先にあるもの
さて、データを失うかもしれないリスクは、ここでは一旦置いておくとします。話を簡単にするために、「いかに早くサービスを復旧させるか」に焦点を当ててみたいと思います。
サービスを復旧させるには、おおざっぱに言って2つのスキルが必要です。「原因を突き止めるスキル」と「解決するスキル」の2つです。そして、相対的には、「原因を突き止めるスキル」のほうが重要というか、より高度なスキルというか、突き止めることができる人は、まあ解決することもできると思います。逆に、原因がわかれば対処方法はわかるけど、原因は突き止められない、という人もいると思います。
もちろん、原因がすぐわかることもよくあります。むしろ、すぐわかるケースのほうがほとんどかもしれません。プロセス落ちてるだけとか、dfしたら100%だとか、dmesgしたらいっぱいエラーがでてるとか、そもそも電源が落ちてて入らないとか、ケーブルが鋭利な刃物で切断されているとかです（昔はISPが競合のISPのケーブル切ったりしてたそうです。こわいですねー……）。
でも、なかなか原因がわからないことも、もちろんあります。こういうときに必要だと筆者が思うのは、経験と空間的思考です。
経験は、もちろんたくさん場数を踏めば、以前発生したのと同じパターンに再度遭遇する確率があがっていくわけで、すぐに解決できる可能性が高くなると言えます。
空間的思考とは、なんのことわからないというか、そもそもこの表現が適切かどうかもわからないですが、「頭の中に同時にたくさんの要素を思い浮かべて処理することができる」ような能力です。でもこれって実はTVの走査線のように、同時ではなくて、すごく短時間に次々と処理しているのかもしれません。
いずれにしても、ある程度トラブル対応の場数を踏んでくると、経験したことがないケースに遭遇しても、「ハッ」と原因かもしれないものが思い浮かぶことがあります。もちろん外れることもありますが、場数を踏むほどに、当たる確率が上がるようにも思います。
以前に、トラブル対応をしているときに「なんでそんなにすぐに原因が思いあたるんですか」と聞かれたことがありますが、そのとき初めて「なぜか原因が思い浮かぶという現象がある」ということを意識しました。こんなことは、方法論として説明できないので「なんの参考にもならん」と言われればまあそこまでですが、よく似た話として、電気回路の設計の経験を積んでいくと、ある時点で、回路を見ただけで各ポイントの電圧がなぜかわかるようになる、オームの法則が身体に染みついた状態になる、というのを聞いたことがあります。
なので、いつかそうなると思って、たくさんトラブル対応の経験をしていくのが良いと思います。たとえ、そういう現象が自分には起こらなくても、少なくとも「経験」は増えていき、同じことが発生したときに対処できる可能性は上がるのは間違いありません。そしてなにより、トラブル対応していくことで、抜群に成長することができます。
トラブル対応のときに成長、というのは前回も触れましたが、トラブル対応をしていてこれが一番良い点（？）なので、次回か次々回くらいにとりあげます。
使える「武器」を持て！
また、トラブル対応のときには、身につけていると役に立つ武器というのもあります。特に筆者が強力だと思うのは、tcpdumpとstraceです。というかパケットダンプとシステムコールトレースです（FreeBSDはktraceだったし、Solarisはtrussだったし…）。パケットとシステムコールを見れば、かなりのことがわかります。
「パケットは嘘をつかない」というのは、昔の口癖でした（口癖というのは嘘です）。tcpdumpの出力を見たり、straceの出力を見たりするのは、少し慣れは必要です。ただ、そんなに難しいものではないので、ぜひ慣れましょう。
straceは、
# strace -f -F -p プロセスID
もしくは
# strace -f -F コマンド
とすれば、forkした先まで追うことができますし、tcpdumpの場合には、
# tcpdump -xnls 0 port ポート番号
などとすれば、パケットの内容を見ることができます。
また、筆者のblogにtcpfilterという、tcpdumpの出力のhexをASCIIに変換するscriptを掲載しておいたので、もしよかったら使ってみてください。
ちなみにstraceではuserlandの挙動を追うことはできませんが、開発時はさておき、運用している環境で発生したトラブルなら、システムコールのほうが役に立ちます（というか、稼動環境でdebuggerとか動かせないし…）。
あとは、各種プロトコルは手打ちできるほうがいいですね。とはいっても、text系のプロトコルだけで、binary系のプロトコルは手では打てないですが。よくあるのはHTTPとかSMTPとかですね。
スキルよりも大切なこと
ところでトラブル対応には、現象から追う人と理屈から追う人がいるように思います。現象から追う、というのは、「こういう現象が出ている、こう変えるとこう変わる」というのを繰り返して原因を突き止めるやり方です。理屈から追う、というのは、「こういう仕組みで動いているんだから、こうするとこうなるはずだ」という推察を働かせることで原因を突き止めるやり方です。
経験的に言うと、この2つはあまり優劣はなく、現象から追うと一発で解決できることもあれば、ドハマリすることもあり、理屈から追うと、だいたい一定の時間で解決する、という一長一短があります。ただ、現象から追うことができても理屈から追えない人はいますが、理屈から追う人は現象からも追えることが多いように思います。両方使いわけられるのが一番いいですね。
筆者の場合、わりと理屈から追うパターンのほうが多かったですが、これも場数を踏んでくると「今回は現象からいったほうが早そうだ」というのがなんとなく予想できるようになり、そういう場合には現象から、というような使い分けをしていました。まあそうはいっても、ハマるときはハマります。人がハマった話を聞くのはおもしろいでしょうから、ハマりネタについてもそのうち書いてみます。
トラブルを解決するスピードというのは、こういった、身につけておいたほうがいい最低限の武器を身につける、経験している場数の多さ、アプローチの手法などによって変わってきます。でも一番重要なのは集中力というか、早く復旧させないと、という気合いだと思いますね。人によっては「ゾーンに入る」というような表現をする人もいますが、なんかかっこいい表現なので最近筆者も真似して「ゾーンに入る」と言ったりします。
トラブル対応しているときっていうのは、アドレナリンが出て、ついでに背中からも冷たい汗がたくさん出て、普段の数倍とか数十倍で考えている気がします。あとトラブル対応の背中を後押ししてくれるのは、それが困難であればあるほど、解決したときのヒーロー感というのは大きな快感になり、それを感じたいという欲求であったりもします。
トラブル対応を多かれ少なかれやったことがある人であれば、いろんな策を講じて効果がないことが続いたときに、なぜか「このトライで判明する（もしくは復旧する）」という確信のようなものが舞い降りてくる瞬間というのは味わったことがあると思います。
いずれにしても、トラブル対応というのは、「まずい状況を正常にしないといけない」という意識というか、責任感が高い人でないと、いろんな意味で努まらないものです。世の中的には、どうしても何かを作り出す人、プログラマなどのほうが脚光を浴びがちですが、それらもインフラが安定していてこそ意味があるんです。ということも、プログラマであれば知っていることなのですが、そうでない非エンジニア系の人にもちゃんと理解してもらえると、とても良いと思います。
