障害切り分け
いつものように後輩へ障害対応方法を指南していたところ、ふと我に返り「そもそも自分はどうやって切り分けているのだろう？」という疑問が湧いてきました。
経験的にこれを確認したほうが良い、そっちは関係ないなどということは分かっているんですが、どういったルーチンを自分が行っているのかは整理されていませんでした。
というわけで自分が普段なんとなくやっている切り分け方法を整理して言語化してみました。障害に遭遇したけど原因がわからず手詰まりになった、もっと効率的に切り分けたいといった場合の一助になれば幸いです。ここでは如何に切り分けていくかということだけに焦点を当てており、障害の検知や再発防止などには触れていません。
障害とは？
ここで言う障害とは、以下のような事象を指します。
- サイトに繋がらない
- エラーでプログラムが落ちる
- PCの電源が入らない
構成情報を把握する
障害が発生している環境の構成を把握しましょう。特にバージョン情報は過去事例と照らし合わせる上で重要な情報となります。
時系列で整理する
発生した現象を時系列で整理しましょう。複数の障害が発生している場合、最初の障害が大元の原因となっていることが多いです。単に障害の発生時刻だけではなく、発生している環境の設定変更・環境の変化も併記するのがお勧めです。
- 障害発生日時
- 障害発生期間
- 設定変更日時
- 構成変更日時
- メインユーザが変わった日時
- ユーザ数が増加した日時
エラー内容をちゃんと読む
エラーメッセージをいきなりググったりせずに、まずはきちんと何を言っているのか読み込みましょう。
現象を分解する
発生している現象をフェーズで分けて、どの範囲まで正常でどこから異常なのか調べましょう。さらっと1行で書いてますがこれは切り分けの上で最も重要な作業であり、きちんと正常動作を把握しているかどうか、より細かく分解できるかどうかが切り分け力=技術力の差に直結します。
再現を試みる
ある程度発生条件の見当がついたら、現象の再現を試みましょう。可能な限りデフォルト環境で、小さい構成で再現を試みるとより効率的です。
他の環境と比べる
もし同じ構成で正常に動いている他の環境があれば、設定などの差分を調べましょう。また以前のバージョンに切り戻すと復旧する場合は、その差分が原因である可能性が高いです。
- 各種設定
- 各種バージョン
- 以前のバージョンとの差分
- システム構成
- データ処理量
- 処理したデータの種類
- 負荷
- 温度
可能であれば正常な環境と同一になるように少しずつ設定を変更して、どの時点で改善するかを調べるのも手です。
規則性を見つける
障害の規則性を見つけると、切り分けの手がかりになります。
- 時間に偏りはないか？
- 朝7時に発生する
- 営業日に発生する
- 現象が続く時間の長さが一定
- 再発するまでの間隔が一定
- 手順に偏りはないか？
- 特定のユーザのみ発生する
- 特定の操作のみ発生する
- 特定の回数繰り返すと発生する
- 特定の接続元からのみ発生する
- 環境に偏りはないか？
- 特定のサーバだけで発生する
- 特定のネットワークを経由したときだけ発生する
- 特定のバージョンだけで発生する
- 特定のブラウザでのみ発生する
- アウトプットに偏りはないか？
- 壊れたファイルのサイズが一定
- ファイルの破損箇所が同じ
- 壊れる部品が同じ
知らない情報があるか調査する
実は自分が知らないだけで他にもエラーが保存されていたり、デバッグ機能があったりするケースがあります。
- OSがcoreを吐いている
- サーバのシステムボードの管理領域にH/Wログが出ている
- 直前の印刷内容をダンプすることができる
- 操作ログが出力されている
- 設定が他にもある
- 設定を反映するための特殊な手順がある
- 利用してるクラウドサービスが仕様変更のニュースを出している
- バグレポートがある
そういった情報が無いか調査をして、新しいヒントを得られることも多いです。
申告された内容を精査する
伝聞された情報は不正確な事も多いので、すべてを鵜呑みにせずに自分自身で確認したものを中心に整理しましょう。ユーザー申告の場合、どこをみて障害と判断して報告してきたのかを知ることは重要です。PCの電源が入らない！という申告があってもディスプレイの電源が入っておらず暗いからそう判断しただけ、といったケースはよくあります。
思い込みを疑う
設定を直したのに改善しない！原因はこれで間違いないはずなのに！と思ったら違うサーバで操作していた、なんて経験はないでしょうか？落ち着いて自分がやった作業を見直してみましょう。
- 違うサーバで作業している
- 違う設定ファイルを開いている
- 設定を編集したが保存していない
- 違うユーザのデータを見ている
- 読んでいるドキュメントが違う
エラー番号を見ただけで過去事例と結びつけ、原因を決めつけてしまうケースもあります。あくまで目の前の事象と向き合って切り分けましょう。原因を特定できたと断定できるのは現象が改善した時のみです。
人に聞く
1人で調査しても埒が明かない時は、同僚やコミュニティに助力を求めましょう。有料サポートを契約しているならもちろん有効活用しましょう。
コミュニティに質問する場合は、事前にドキュメントを読み込んで質問方法、質問場所を確認しましょう。
・・・大体自分がいつもやっていることは出尽くしたと思います。これらはそれぞれ1度行えばよいというものではなく、何度もぐるぐると行ったり来たりして徐々に原因を追い詰めていきます。繰り返しになりますが、原因が確定するのはあくまで障害が改善したその瞬間です。それはエンジニアにとって喜びの瞬間でもあるので、解決を目指して突き進みましょう。
