Link and Motivation Developers' Blog

リンクアンドモチベーションの開発者ブログです

初心者でもできる！障害解析の勘所 〜プロセス編〜

こんにちは、リンクアンドモチベーション SREグループの久原です。今回は2記事 (プロセス編・実践編) にわたって、障害解析経験の浅い初心者に向けた障害解析の実践方法についてお話しようと思います。

この記事は上記の第一弾、「 〜プロセス編〜」です。 第二弾の記事は「〜実践編〜」になりますので、よければ合わせて読んで頂けると幸いです。

目的

WEBアプリケーション開発やその保守運用をしていると、トラブルやインシデントの対応はつきものです。 しかし、特に障害原因の解析フェーズにおいては緊急性が高かったりケース・バイ・ケースであったりすることが多く、標準化された考え方やフローといったものはあまり確立されていません。その道に熟練したプロの属人性によって解決され、初心者の参入障壁が高いことが多いです。 そのような課題を解決するために、以下を達成することを目的としてこの記事を執筆してみようと思います。

  • 障害解析に慣れていなくとも「障害っぽいんですけど、ちょっと分からないので解析してもらって良いですか？」と言われたときに何から着手すれば良いかが分かる
  • そこまで解析対象のアーキテクチャに詳しくなくとも、時間をかければ問題の特定を独力で完了できる

障害解析で常に意識すべきこと

この記事の結論です。障害解析においては常に以下の2つを意識して取り組むことが大事です。

  • 障害解析の基本は 仮説検証を繰り返して障害が混入している範囲を狭めていく こと
  • 仮説を立てるためには、 今分かっていないこと を言語化する必要がある

①障害解析の基本は 仮説検証を繰り返して障害が混入している範囲を狭めていく こと

以下の図のように、障害解析を始める前は障害混入原因混入の候補はかなり広いです。 その状態で手当たり次第に調査しようとしても障害解析は永遠に終わりません。

大事なことは「仮説検証」をすることで障害混入の可能性がある範囲を狭めることです。 例えば「インターネットに接続できなくなった」という障害が発生した際に、「自分のPCと家のルーターまでは接続が成功している」という検証ができれば、障害混入の可能性がある範囲はだいぶ狭めることができます。

②仮説を立てるためには、 今分かっていないこと を言語化する必要がある

とはいえ慣れないうちは、いきなり「調査してね」と言われてもどんな仮説検証をすれば良いか思いつかない場合が大半だと思います。その原因は 今分かっていないこと を言語化できていないことです。 例えば「インターネットに接続できなくなった」と一口に言っても、分かっていないことは沢山あります。

いきなり上記のように沢山羅列することは難しいかもしれません。しかし、errorのログを見たりググったりする中で 分かっていないこと を1つでも言語化できない限りは、前には進めないのです。

障害解析の流れ ~概要~

上記を踏まえて、「xxさん、障害っぽいんですけど、ちょっと分からないので対応してもらって良いですか」と言われた時の大枠の流れは以下になります。

  1. 初期材料集め
  2. 障害混入の可能性がある範囲を狭めていく
  3. 根本原因を突き止めるまで 2 を繰り返す

①初期材料集め

このフェーズは一言で言うと 障害混入の可能性がある範囲を定義し、最初の仮説の候補を洗い出すこと です。 図で表すと、オレンジ全体を定義し、赤い矢印の候補を洗い出すことになります。

まず初めに取り掛かる作業は以下の2つです。

報告された障害ログの調査

例えば「アクセスしたら 502 Bad Gateway という画面が出てきました」とか「ずっと接続中になって画面が動きません」とか「xxxxxxx という errorログ が出てきました」とか、報告者によって粒度は違うと思いますがそこには必ずヒントがあります。 502 Bad Gateway であれば、MDNの説明を見るとゲートウェイまたはプロキシとして機能しているサーバーが上流のサーバーから無効なレスポンスを受け取ったことを示しています。という説明があるため、「このerrorは一番下層にあるアプリケーションサーバーが出している訳では無さそうだな」ということがわかったりします。 また、報告された障害が発生した時間帯のサーバーやネットワークのログを確認しておかしなログが出ていないかを確認しにいくことで手がかりがつかめることが多いです。

報告された障害の再現

基本的に障害解析は本番での障害に触れることが多いので容易にできないこともありますが、開発環境で同様の条件で再現するかを試すことで手がかりを得ることができます。 もし障害の再現に成功した場合は、細かにその条件を調査したり特定の条件を変えても再現するかを検証することができるため障害解析の自由度が高まります。

②障害混入の可能性がある範囲を狭めていく

このフェーズは一言で言うと 仮説検証を繰り返し、障害混入の可能性がある範囲を狭めていくこと です。 図で表すと、灰色の範囲から赤色の根本原因の範囲まで狭めていくことを行います。

今分かっていることと今分かっていないことを書き出す

初期材料集めフェーズである程度情報が集まってくると思いますが、それだけだと障害の特定は難しいパターンが多いです。 その際は、今分かっていること と 今分かっていないこと を箇条書きで書き出してみます。例えば以下の通りです。

障害内容：「インターネットに接続できない」
<今分かっていること>
- PCとルーターが無線LANで接続されていることは確認できた
- ルーターの電源は入っていた
- ルーターは光回線等でインターネットと接続されていた

<今分かっていないこと>
- ドメインは正しく名前解決されているのかが不明
- 接続先IPアドレスのサーバーは起動しているのかが不明

今書き出せる範囲で良いので、全て書き出してみることが大事です。 今分かっていることを書き出すことはできるが、今分かっていないことを書き出すことは難しいかもしれません。その際は、「初期材料集めフェーズで集めたerrorログの内容から考えること」と「周辺知識をググってみること」でヒントが得られることがあります。

今分かっていないことから仮説を立て、検証する

上記ができたら、以下のようにツリーの構造にするとより仮説立てがしやすくなります。

ここまで整理すると、一旦最初の仮説検証は開始できそうですね。 ここからはこのツリーに従って検証をしていくことになります。4,5番目の仮説も違った場合は新たな仮説を立てる必要がありますが、最初よりは圧倒的に範囲が狭められているので仮説立てがやりやすくなっているはずです。

障害解析の流れ 〜実践編〜

「〜実践編〜」の記事に記載しているので、良かったらこちらも読んでみてください。

最後に

私自身、初めのうちは障害が起きた時に対応することが怖かったです。 「早くしないと誰かに迷惑をかけちゃう、でもどうすればいいんだ」と焦って何もできない、みたいなことが多くありました。 しかし、まず初めにとりあえず何をすればいいのか、どういう全体像で解析を進めていけば良いかを言語化することである程度は「よし、やってやるか」というメンタルに持っていけたのも事実です。最終的には場数が物を言う領域なので、そういうメンタルで熟練のプロに任せきりにせず果敢にチャレンジしてみるのが一番良いのかもしれません。