【SREチーム ブログリレー4回目】
こんにちは、SREチームの後藤です。
障害が発生した時、魔法のように原因を特定し颯爽と解決していくスーパーな同僚は皆様の周りにもいませんか? その姿に憧れてそうなりたいと思ったことが誰しも一度はあるはず。
ですが、話を聞いてみると「なんとなく怪しそうだった」「勘でここかなと思った」と言われたりして、まったく参考にならなかったこともあるのではないでしょうか。 そこで今回は私が考える障害調査において意識すべきポイントを、なんとなくではなくしっかりと言語化してまとめたいと思います。
題して「なんとなくで終わらせない、言語化すると見えてくる障害調査の5つのポイント」
前提として、本記事における障害調査のスコープは「ある障害について、その原因を調査して特定すること」とします。 通常の障害対応では、関係者とのコミュニケーションや早期復旧に向けた対応などたくさんの要素が絡みますが、本記事ではこれらは扱いません。
1. 調査できるように備えておく
平常時からできる備えとして、ある情報が欲しい時どこを見ればわかるのか把握しておくことが重要です。 例えばアプリケーションログはこのファイル、CPUやメモリのリソース使用量はこのモニタリングツールといったように、必要な情報を素早く確認できるようにしておきましょう。
地味ですが気をつけるべきなのが、見ようと思ったけど権限がなかったというケースです。 権限をつけてと言い出し辛いほどドタバタしている状況も考えられますので、事前にちゃんと確認しておきましょう。
2. 事象を正確に把握する
障害を検知した時点では、何かエラーがでている、どうやら挙動がおかしいといったように曖昧な状態であることが多いです。 このようなケースではぼんやりとした認識のまま調査を進めるのではなく、起きている事象を掘り下げ、解像度を上げて正確に把握することをまず目指しましょう。
例えば、「Web画面にアクセスするとエラーになる」という問い合わせを受けた場合を考えると以下のような情報を把握しておくと後の調査に役立つでしょう。
- エラーの具体的な内容 (エラーの画面表示、エラーの内容、HTTPステータスコード)
- 発生した時刻
- 発生件数
- 発生した環境
- 再現方法
3. 事実と推測を区別する
実際に起こっていることや調査によって確認した「事実」と、そこから導いた未確認の「推測」はしっかりと区別するべきです。 自分の中で区別がしっかりしていないと、推測でしかない情報を前提として誤った方向に調査を進めてしまう危険性があります。
また、リモートワークでの活字コミュニケーションでは自分の意図に反して情報が広がるケースもあるのでそこにも注意が必要です。
A 「アプリケーションでエラーです。アクセス増かも」 (前半は事実、後半は推測)
B 「アクセス増が原因らしいです」
C 「アクセス増のせいです!!!!! 」(いつのまにか事実と混同)
といったようにコミュニケーションの中で区別が曖昧になってしまうケースもあります。 伝える側は「事実」「推測」「確認」「未確認」といった言葉を明示的に加えるなど正確に伝わる書き方を意識し、受け取る側はどこまでが事実でどこからが推測なのかを整理しながら読み取りましょう。
4. 先入観を排除する
特に調査の初期段階の話になりますが、「今日リリースをしたらからそれが原因に違いない」「この間のエラーと同じ症状なので同じ原因だ」と先入観をもって決めつけてしまうことは良くありません。 調査に着手してすぐの段階は問題の全体像がみえていないことがほとんどなので、思い当たる原因があったとしてもまずは視野を広く持ちあくまで1つの仮説として扱いましょう。
稀にはまってしまうケースとして、起きている問題にたいして原因が1つだと思い込んでしまっていることがあります。 実際には原因は1つのケースが多いので先入観を持ってしまいがちですが、これだと複合的な障害の時に行き詰まってしまいます。
5. 問題を局所化する
さきほど視野を広く持つべきということを述べましたが、脳内メモリも調査に割ける時間も限界があるので全ての可能性を考慮したまま調査は進められません。 列挙した仮説を検証しながら問題を切り分けて局所化していくことで、調査対象の範囲を狭めて素早く効率よく原因を特定できます。
状況によって切り分けの軸は変わりますがよくあるものを例示すると下記のようなものがあります。
- 時間で切り分ける
- 障害発生時間が特定できていればそれ以外の時間は調査対象から除外する。
- 発生条件で切り分ける
- 特定のサーバやユーザのみで発生するなど、何かしら条件が判明していれば条件を満たさないケースは除外する。
- システムの構成で切り分ける
- 障害の内容から関連するリソースを限定し、無関係なリソースは調査対象から除外する。(アーキテクチャの深い理解が必要)
まとめ
障害調査の時に私が意識しているポイントを紹介させて頂きました。 言語化したものをベースに「こういう風にするといいよ」とアドバイスをしたり逆に「こういうことはしてないのか」とフィードバックをもらったり、周りとコミュケーションがとれるのが非常によいと思っています。
普段無意識にしていることが多いですが改めてまとめてみることで、自分の考えを再認識できて自分にとってもプラスでした。
We are Hiring!
エムスリーではエンジニアを募集中です。
障害はないのが一番ですが、もしもの時のために一緒にスーパーなエンジニアを目指しましょう!!
ご応募お待ちしています。
