はじめに

システム開発をしていると、避けて通れないのが障害対応です。

ログを確認したり、処理の流れを追ったりしながら原因を探っていくわけですが、実際の調査では最初から原因が分かることはあまりありません。

多くの場合は

「もしかするとこの処理が影響しているのでは？」
「このデータ状態が関係しているのでは？」

といった 仮説を立てながら調査を進めていきます。

今回は、ある障害対応の中で改めて感じた
「仮説」と「事実」を分けて考える大切さについて書いてみます。

障害調査は仮説から始まる

あるとき、本番環境で「想定通りに動作しない」という問い合わせがありました。

まずはログを確認し、関連する処理を追いながら原因を探していきます。

調査を進める中で、

「この処理が影響しているのではないか」

という仮説が出てきました。

ただ、この時点ではまだ
ログなどで原因が確認できていたわけではなく、
あくまで 「可能性がある」段階でした。

仮説がそのまま前提になりかけた

障害対応ではスピードも求められるため、仮説を元に議論が進むこと自体は珍しくありません。

ただ、このとき気づいたのは

いつの間にか

「この処理が原因」

という前提で話が進みそうになっていたことでした。

このまま進めてしまうと、もし仮説が外れていた場合、
調査の方向がずれてしまう可能性もあります。

事実と仮説を整理してみる

そこで一度立ち止まって、

  • 事実として確認できていること
  • まだ仮説の段階のこと

を整理してみました。

事実

  • 実際に発生している現象
  • ログから確認できる内容

仮説

  • この処理が影響している可能性
  • このデータ状態が関係している可能性

このように整理すると、

  • どこまでが確認済みなのか
  • どこからが推測なのか

がはっきりします。

結果として、調査の進め方も整理しやすくなりました。

障害対応では「認識合わせ」がとても大事

今回の件で改めて感じたのは、
障害対応では チーム内の認識合わせがとても重要だということです。

プロジェクトにはPM、エンジニア、運用担当者など、さまざまな役割のメンバーが関わります。

それぞれの立場や専門が違うため、

「いま分かっていること」
「まだ仮説の段階のこと」

を整理して共有しておくだけでも、調査の進み方がかなり変わると感じました。

まとめ

障害対応では、どうしても仮説を立てながら調査を進めることになります。

ただ、

  • 事実として確認できていること
  • まだ仮説の段階のこと

を意識して整理することで、
チーム内の認識が揃い、調査の方向も見えやすくなります。

スピードが求められる場面だからこそ、
こうした整理が大事だと感じた出来事でした。