トラブルが起きたとき、最初に何から確認していますか？
通信できない。
サービスが落ちた。
想定通りに動かない。
現場では、こうしたトラブルが突然発生します。
その瞬間、多くのエンジニアがやってしまいがちなのが
「とりあえず設定を見る」「怪しそうなところを触る」ことです。
しかし実は、
トラブル対応の成否は最初の数分の考え方でほぼ決まります。
闇雲な調査がトラブルを長引かせる
よくある失敗パターンは次のようなものです。
- ログを大量に眺めるが、何を見ているか分からない
- 以前直した設定を参考にするが、状況が違う
- 一部を直したら別の問題が出る
これは技術力の問題ではありません。
「最初の整理ができていない」だけです。
トラブル対応で最初に確認すべき3つのポイント
私がトラブル対応で必ず最初に確認しているのは、次の3点です。
① 事象は「何が」「どこで」起きているか
まずやるべきは、原因探しではありません。
事象の定義です。
- どの通信が
- どこからどこまで
- どうなっているのか
これを曖昧なまま進めると、
調査は必ず迷走します。
「つながらない」ではなく
「AからBへのHTTPS通信がタイムアウトする」
ここまで落とし込めるかが重要です。
② 正常時と「何が違うのか」
次に確認するのは、
正常時との差分です。
- 直前に変更した設定は何か
- 追加された機器・経路はあるか
- 時刻や負荷条件に依存していないか
多くのトラブルは
「何かが変わった結果」として起きます。
差分を意識せずに調査すると、
関係ない情報に時間を奪われます。
③ 自分はいま「何を仮説として見ているか」
最後に、これが一番重要です。
いま自分は
- ネットワークを疑っているのか
- サーバを疑っているのか
- 設計そのものを疑っているのか
仮説を言語化することで、
次に取る確認作業が明確になります。
仮説のない調査は、
ただの作業になってしまいます。
トラブル対応は「技術」より「整理」
もちろん、
プロトコルや製品知識は重要です。
しかし、現場で差が出るのは
「最初にどれだけ整理できるか」です。
- 事象を定義する
- 差分を見る
- 仮説を立てる
この順番を守るだけで、
トラブル対応のスピードと精度は大きく変わります。
この思考を残しておく意味
トラブルが解決すると、
多くの場合そのまま次の作業に移ってしまいます。
ですが本当にもったいないのは、
「どう考えて切り分けたか」を残さないことです。
次に同じような事象が起きたとき、
その思考ログがあれば、判断は格段に速くなります。
最後に
トラブル対応は、
場数を踏むほど上手くなります。
ただし、
考えたことを振り返らなければ、成長は蓄積されません。
このブログでは、
そうした「現場での思考」を言葉として残していきます。
次のトラブル対応の前に、
一度立ち止まって考えてみてください。
— たくはん
コメント