この記事ではトラブルシュートに使っている手法を紹介します．トラブルシュートの参考になれば幸いです．
システムの構成要素を理解し，原因範囲を切り分ける
トラブルシューティングには，システムがどのようなアーキテクチャで構成されているのか把握する必要があります．アーキテクチャを構成するコンポーネントそれぞれが正常か異常かを調査していきます．正常な範囲を調査対象から除外していき原因を明らかにしていきます．
エラーメッセージやログメッセージを読む
ログメッセージに含まれるエラーを理解します．なぜその事象が発生しているのか理解する必要があります．例えば 「No such file or directory」と表示される場合は，ファイルやディレクトリが存在しないにも関わらずアクセスを試みているとわかります．
関連した事例がないかをGoogleで検索したり，組織内のWikiで探してみるのも1つの手段です．同様の問題が発生していれば解決策がわかる場合があります．
ログの比較により原因を調査する方法があります．まず，正常な環境をつくりログを取得します．次に異常な環境でもログを取得します．最後に，両方の環境のログを比較して異なる箇所を探すことで，異常の原因を明らかにできます．
ログレベルやデバッグレベルを上げることも方法としてあります．ソフトウェアにはログレベルをもつものがあります．ログレベルはソフトウェアの動作を詳細に解析する場合に使います．設定ファイルやコマンドラインで与えるオプションからこれらは変更できます．ログレベルを上げてソフトウェアから出力されるログの情報量を増やすことで，詳細な動作を把握できます．これにより異常の原因を明らかにできます．
パケットを送信し疎通性を検証
curlやnc, pingを使って疎通性を検証することもトラブルシューティングの方法の一つです．応答がないことからシステムが動作していないことを判断したり，ファイアウォールの設定を検証したり，どのネットワークレイヤが異常の原因かを明らかにしたりできます．例えばHTTPサーバが起動しているのかを判断するためには， curl コマンドを使うことができます．
プロセスやポート，リソースの使用状況を調査
プロセスの起動状態やポートの使用状態もシステムのトラブルシュートに役立ちます．コマンドには，例えばpsやss，lsofがあります．また，リソース（例：CPUやメモリ）の消費状況から異常の原因を調査することもあります．ほかにも df コマンドでディスクの消費量を調査したり，ulimitでファイルディスクリプタの上限を確認することも手段のひとつです．Datadogに代表されるモニタリング向けのSaaSもメトリックの推移を確かめる場合に有用です。
デバッガの利用やソースコードの解析
これは最終手段として使う方法です．例えばソフトウェアの発行するシステムコールを strace コマンドを使って追跡し，ソフトウェアの挙動を確認することがあります．例えばnsswitch.confが参照されない原因をstraceを使いシステムコールからファイルへのアクセスがないことを調査したことがあります．また，デバッガでブレイクポイントを設定し，変数の値やソフトウェアの内部状態を確かめることで，異常の原因を明らかにすることもできます．ほかには，ソースコードを読むことにより動作を解析することもあります．セキュリティのドメインでよく聞く静的解析や動的解析に近いと思います．
おわりに
この記事では簡単にトラブルシュートのテクニックを紹介しました．トラブルシュートの参考になれば幸いです．