トラブルシュートの進め方 - まつざっきブログ

本記事は社内wiki向けに書いたのですが、反応がよかったので本ブログにも転載します。

仕事柄トラブルシュートをする機会が多いのですが、いけてないトラブルシュートに膨大な時間を溶かした結果、「こういうやり方がいいんじゃないか？」と思いに至りました。以下にその手順をまとめます。

1. エラーが出たらまず記録する

作業中に想定外のエラーに直面した場合、脊髄反射的にググって秒速で解決したくなるかもしれませんが、 グッと我慢 して、まずはローカル環境のNoteまたはWikiなど、永続化が可能な場所に 何をした結果⇒何が起きたのか？ を記録しましょう。

具体的に書くといいこと
- トラブルの概要(20-30文字程度)
- トラブルの発生日時
- トラブルの内容
- 前提となるシステムや周辺環境の事前状態

そうすることで、

※ 注意!! このタイミングで適当にググって、解決方法を理解しないままに適当にたくさん試して、対象システムも頭の中もぐちゃーっとなると、アンチパターンルートに突入します

※ 既に原因がわかっていて本当に秒速で解決できるものについては、この限りにあらずです

↑の記録で忍耐力を既に使っているあなたは、記録が終わった瞬間ググって秒速でエラーを解消したい衝動にかられるでしょう。が、ここもグッと堪えて1分だけ原因に関する予想を立てる時間をとりましょう。

ここで言う「予想」とは「このエラーメッセージは、〇〇が△△して□□した結果、出力されているのかもしれない」的な推測を指します。若干ぼんやりとしていてもいいので、とにかくまず一度考えてみましょう。

→ 1分考えて「なんもわからん！」となる場合はステップ3へ

→「予想が合っているか確認のため、これ試したい！」となったらステップ4へ

参考

ググる場合はエラーメッセージを検索キーワードに、Stackoverflowの記事などを読み漁ることが多いと思います。この際ですが、閲覧したページの中で有益と感じたURLもメモに残しておくといいです。

※後日「あのページ見返したいかも！」となった時に幸せになります。

さて、いよいよ解決方法を試すフェーズです。あなたの頭の中には沢山の「これを試したらfixできるのでは！？」的なアイデアが浮かんでいるかもしれません。猿のように大量の打ち手を矢継ぎ早に試したい気持ちになっているかもしれません。

が、ここでもグッとこらえて まずは一つだけ試す。試したら結果を記録する を徹底しましょう。

こうすることで、「いろいろ試したけど、頭の中も環境もぐちゃぐちゃでなんもわからん」となるリスクが大幅に低減できます。

※このTIPSが本ナレッジの中で最重要です。とりあえずこれだけやっておけば、トラブルシュート中の遭難リスクを大幅に減らせます。この工程は本当に大事なので、辛いですが気合いでやりましょう。

試行錯誤の結果、事象がついに解消されました！（やったあ！）

問題が解消されたことで、緊張が解けほっとした気持ちになり脱力感が訪れます。「疲れたしもういいかな」という気持ちになってることと思います。

が！業務時間に余裕があれば(というか気合いで余裕を作って) 、 最終的に何をして解決したのか？その背景にはどんなメカニズムが推定されるのか？ を書き残しておきましょう。

そうすることであなたの成長のスピードが倍化します。後日、類似の問題を引いた時の有益な情報源になります。辛いし面倒ですが、頑張ってやりましょう！

デバッグをしていて頭がぼーっとしてきて「あ、自分疲れているな」と感じた時は、迷わず休みをとり、次の日以降またフレッシュな頭で再挑戦しましょう。経過を文章化できていれば、コンテキストのキャッシュが脳内から消失する恐怖もだいぶ少なくなっているはずです。
通信の到達性などのNW絡みの問題に取り組んでいる時は、紙とペンでわかったことを図にまとめながら調査を進めるととても捗ります。
色々やっていて頭が混乱してきたときは「アヒルに話しかけるメソッド」や他の人と画面を共有して「モブトラブルシュート」をやることをお勧めします。人は物理的に声を出していると頭が整理される生き物なのです。