【事実と推測】リモートからトラブルシューティングを行うときのコツ

ここ最近、リモートでトラブルシューティングを行う機会が増え、それに伴い、現地であれば色々自分で調べられることも、周りの人に調べてもらってその情報を元に切り分けを行うことが多くなりました。

この記事ではそのときに重要だと感じたことを書いてみます。

「事実」と「推測」を分けて報告してもらうこと
問診票みたいなシートを作る
パケットキャプチャとログは重要な「事実」
推測は？
まとめ
IT/インフラエンジニアの地位とスキル向上のために

「事実」と「推測」を分けて報告してもらうこと

これがとにかく一番大事です。

【NG な報告例#1】
ネットワークが全断しました！
⇒　すべての箇所から調べたの？

【Good な報告例#1】
VLAN 10 の PC と VLAN 20 の PC インターネットにアクセスできなくなりました。(事実)
他の人の声も聞くと、おそらくネットワークが全断したのだと思います。(推測)

【NG な報告例#2】
パケットドロップが発生して通信に遅延が発生しました！
⇒　パケットドロップがあるっていうのはどうやって発見したの？

【Good な報告例#2】
インターネット通信が体感的に遅いです。(事実)
複数のサイトへアクセスしましたがいずれも同じです。(事実)
PCからパケットキャプチャを取ったところ、TCP の再送が大量に出ています。(事実)
なのでどこかでパケットドロップか遅延が発生しているのだと思います。(推測)

【NG な報告例#3】
特定サイトにアクセスできません！なんかセッションが切れました！
⇒　セッションが切れた、というのは何で判断したの？そもそも何のセッション？TCPコネクションのこと？どんな画面になってるの？エラー画面？スピナーが回った状態？

【Good な報告例#3】
特定サイトにアクセスすると 500 internal error の画面が表示されます。(事実)
つまりサーバまでは通信が届いています。(事実)
これはネットワークではなくアプリケーションの不具合だと思います。(推測)
※最後もほぼ事実ですが、例えばプロキシを介した場合に限定して発生する不具合だと
アプリケーションとプロキシの組合せの問題である可能性も否定はできない。

事実は無視できないものですが、推測は人の感情や経験によりねじ曲がりやすいものです。推測により間違った方向に行ってしまうと手戻りが発生します。きちんとこれらを区別した上で、原因を探っていくことが重要です。

最初は「ネットワークが遅い！」といってネットワークを調査したのに、実は問題なのはプロキシの高負荷でした、なんてこともあります。

実はこの話、実験論文の「結果」と「考察」が分けられる理由と同じなのです。

実験論文でもミスリードしないように、客観的な事実を示す「実験結果」と個人的な推測を示す「考察」に分けられています。

この手の話をするときは「まず事実を伝えます。～です。ここまでが事実です。ここからは私の推測なのですが、～」と言ってもらえると、聞き手はとても聞きやすいです。

問診票みたいなシートを作る

トラブルはいきなり起こるものです。速やかにエスカレーションするのも重要ですが、慌てて無意味な情報を送られても報告者は困ってしまいます。

「ネットワークがなんかおかしくなっちゃいました！」なんて報告を聞いたこともあります。

経験が少ないとしょうがない部分もありますので、ちゃんと事実と推測についての話をした上で、問診票を作りましょう。

ありきたりですが 5W2H (誰が,いつ,どこで,何を,なぜ,どのくらい,どのように) を中心に事実を抑えつつ、推定される所感があればその理由を添えて(理由は必ずある。自身の過去の経験ならそれも正直に言う。)伝えられるシートにしましょう。

トラブルは緊急のケースも多いので、現場でシートを書く必要はありません。(余裕があればそうしてもらいたい。)

電話でお互いこのシートを見ながら会話し、センター側でメモを取る、というのが良いかもしれません。

パケットキャプチャとログは重要な「事実」

私は原因究明が長引きそうなときは必ず「パケットキャプチャ」と関連機器の「ログ」の2つを取得します。

この2つは重要な「事実」を示したものであり、これらから直接的な原因が判明することが多いです。

過去の例でいうと、こんなことがありました。

あるシステムサーバへのhttpコンソールアクセスが途中まではうまく動作するが、途中から応答が無くなる
特定の機器からはアクセスすると問題ない

パケットキャプチャを見てみたところ、そのシステムサーバからの http のペイロードの中にプロキシの IP が含まれていました。

このシステムサーバの http コンソールは送信元 IP を IP ヘッダだけでなく http 内でも送ってクライアントを識別する仕組みになっていましたが、途中経路で透過プロキシによって送信元IPが変更されていました。(当然、そのシステムにはプロキシや NAT を経由してはいけない旨の注意書きがありました。)

パケットキャプチャは思わぬ事実を私たちに教えてくれます。

プロキシを使っていないと思っていたのに実は使っていた、とか、そもそも ARP が送信されていないからまずそこが問題だ、とか、https の証明書エラーが発生している、とか。

ログもまた然りです。

例えば、運用している Web サーバについて「水飲み場攻撃されてる」というクレームがありました。そこで、クレーム側がアクセスしたという時間のアクセスログを見てみると、そのクレーム側の IP は記録されておらず、その代わりに某国の IP からのアクセスが記録されていた、ということもありました。(つまりクレーム側かウィルスに感染し、通信を某国のプロキシ経由にさせ、そのプロキシから本来のページに加え、悪意あるデータを載せていた、と思われる)