こんにちは。株式会社パイプラインの濱田です。
前回は障害発生時の初動に観察力が大事であると述べました。
今回は、観察力とセットで非常に大事な検索力について取り上げます。

なぜ検索力が大事なのか

なぜ障害発生時に検索力が大事なのでしょう。決まった作業手順書に従って対応してはいけないのか？という声もあるのは重々承知です。しかし、毎度毎回障害が発生するたびに原因究明もせず同じ手順で“なんとなく”復旧したように見えて、それは根本解決なのだろうかと、私は逆に問いたいのです。

WEBサーバーやDBサーバーをはじめ、あるプロダクトへの機能 非機能に対する期待は非常に大きくなっています。
例えばnginxの機能一覧だけでも、こんなにあるのです。しかも多数のパラメータが設定できるとなると、あらゆる機能すべてから原因究明を行うのは非現実的で、何かしらの絞り込みを行う必要があります。そもそも、WEBサーバーの障害でメールプロキシの機能を最初に疑うことはほとんどないでしょう(絶対ないとは言いません)。

バイナリサーチで外堀を埋めよう

単純に「はい」「いいえ」で状態を表現できない、例えばあるプロセスが起動している、停止しているだけでは原因を特定できない障害、障害原因が複数想定される場合は、バイナリサーチ(二分探索)の手法を用いて絞り込むのが最適です。

あるパラメータが最適なのかどうか、半分ずつに範囲を絞ってプロファイリングすることによって、その値より大きくすべきか、小さくすべきかの正解を素早く求めることができます。
いく度かのトライアンドエラーを繰り返すバイナリサーチは一見遠回りに見えて、決して当てずっぽうや可能性の無用な拡大ではなく、収束の方向に向かっていますので、あらゆる可能性を検証する場合においては、もっとも解決の早い手法と言えるでしょう。

ログは口ほどに物を言う

世の中でメジャーなアプリケーション、多数のユーザーに広く使われているアプリケーションは、必ず何かしらのログを出力します。WEBサーバーの場合、WEBサーバー自身のログやバーチャルホストのログを出力することが多く、ログの種類もアクセスログとエラーログに二分されることがほとんどです。

障害発生の申告を受けた場合、おおよそで構いませんので、必ず「いつ」発生したのか、再現性があるのかをヒアリングしてください。
WEB障害の場合は、アクセスしようとしたURL または画面遷移の順番をあわせてヒアリングしましょう。
メール障害の場合、送信ボタンを押した時刻と送信元・送信先両方のメールアドレスをセットでヒアリングしましょう。(余談ですが、送信ボタンではなくメールを書き始めた時刻を言ってきた人もいました。。。)

障害発生の日時がおおよそ絞り込めたら、あとはログファイルから該当時刻付近のエラーを調査します。
既知のエラーであれば対応の道すじが開けますし、そうでなくても、エラー発生時のステータスコードやエラーメッセージからヒントを得ることも可能です。

また、検索エンジンでエラーメッセージから検索するのも手法としては有用です。そのプロダクトの開発元がそのものズバリの解決方法を開示していることもありますし、そうでなくても、「こうしたらこんなエラーが発生した」という類似事例が検索結果に表示されることもあります。
ただし、この手法で検索するには、以下のことに気をつけましょう。

• エラーメッセージは原則として該当行すべてを検索すること
  ⇒「ここは不要だろう」と勝手に判断しないこと
• 業務情報や個人情報などの機密情報を検索クエリに含めないこと
  ⇒業務情報や個人情報に該当する部分は削らずに「伏せ字」にすること
  ⇒特に個人ブログなどの検索フォームで機密情報を検索しないこと
• 検索結果を鵜呑みにしないこと
  ⇒検索結果をエビデンスにするのは「誰それが言っていたから～」という人と一緒です
  ⇒検索結果はあくまで“仮説”です。必ず検証しましょう。
  ⇒あなたが得たいのは根本原因ですか？不安解消ですか？

観察力と検索力を身につけることで、障害対応に慣れていきましょう。
次回は、障害対応に有用なコマンドラインについて取り上げます。

まずはエンジニアデビューしたい、という方は、3ヶ月間学びながらお給料が貰える AltX キャリテク!の門を叩いてみてはいかがでしょう。