辞書: トラブルシューティング

投稿日: 更新日:

トラブルシューティングとは

問題の解決するための手法です。

心構え

  • 「分からない」問題はほとんどない。
    • 「分からない」問題のほとんどはただの情報不足。
    • 逆に言えば、情報不足で分からない場合は諦めも肝心。
      • その場合でも単に「再現待ち」ではなく、ログを入れるなどの改善は行う。
  • 自分が間違っていると思え。
    • OSSの品質は基本的には高い。ただし、メジャーリリース直後はバグが出ることも多い。
  • 「正しいこと」を知る。
    • Web標準を最も忠実に実装しているのはMozilla Firefox
      • WebKit系が悪いわけではないですが、IEは間違っていることが多い。
    • セキュリティを理解する。
      • 例: サードパーティCookie
  • 緊急度を見極める
    • 基本は「すぐ」「今日中」「明日」のどれか(マニャーナの法則
    • 「すぐ」対応しないといけないものでも、作業の区切りが待てないほど緊急なものはほとんどない。
    • 本当に「すぐ」対応しないといけないなら、事前に通知されているべき。
  • メモを取る
    • 作業した内容、見つけたログ、打ち込んだコマンドをメモに取る。
    • ログは「そのまま」記録する。
    • 実行してからメモを取るのではなく、メモを取ってから実行する。

基本

トラブルシューティングの基本は以下の点です。 (少しずつ書いていきます)

  • 正確な情報
  • 再現性
  • 問題の切り分け
  • 仮説を立てる

正確な情報

エラーメッセージやログなど、正確な情報が必須です。

ここで注意すべきことは、 相手の言うことを鵜呑みにしないということです。 よく言われるのが「何もしてないのに壊れた」ですが、もちろんそれはまずあり得ません。 何もしてないのに突然電源が落ちたとかはありますが。 聞き取り調査は重要です。

また、「何が出ているか」だけではなく、「何がでていないか」が重要な情報になることがあります。 例えば、出るはずのログが出ていない、作成されるはずのファイルが作成されていないなど。

再現性

100%が基本です。 再現できないまま闇雲にあたりをつけていっても、 だいたいは無駄に時間を使ってしまいます。

問題の切り分け

確率の高い、よく発生する問題から進めるのは常套手段ですが、 難しい問題の場合は闇雲に進めるのではなく、 問題を切り分けるのが重要です。

考慮すべき点

  • 環境による違いはあるか
  • どのレイヤで問題が出ているのか
    • Webの場合はフロントエンド・サーバサイドのどちらか
  • 他のデータやソフトの場合はどうか
    • Webならブラウザを変えてみる、フォームなら送信するデータを変える、など

過去にあったトラブル

  • Cookieが送信されていなかった
    • Cookieの保存、送信の切り分けをしたところ、実は保存されていなかった。

仮説を立てる

ある程度情報が集まったら、仮説を立てます。 「こういう操作でこういうデータを入れたら落ちる」のような感じで。 仮説を立てたら、以下の2点を確認します。

  • その仮説のとおりにすれば再現できるか
  • その仮説と矛盾する情報はないか

再現するための情報を最小化

例えば、あるテキストでプログラムがおかしくなるとします。 しかし、そのテキストをそのまま解析のために使うのではなく、 最小のデータを洗い出します。

特定の文字が保存できない場合は、1文字まで、 サイズが大きいと保存できない場合は、その境界値を探すのが重要です。 まあ、再現性がはっきりすれば原因が分かる場合も多いので、 ここは必要に応じてです。

情報を検索

公式情報が確実です。 それ以外でも、出てきたエラーログなどをググってください。 出てきたサイトが英語でも、Google翻訳などを使って読んでください。 (読もうと努力してください)