こんにちは、デジタルトランスフォーメーション事業部（DXD）の吉倉です。
起きてほしくはないですが、システムに障害は発生してしまうものです。
それでも起きてしまった時のアプローチについて心がけていることについて書きます。
大きく、以下の5点です。
- 事象の確認をする
- ログを集める
- 業務継続のための回避策を練る
- 再現確認→原因調査→一次対応
- 根本原因の解消
事象の確認
何は無くともここから始まります。
- 「エラーが出ました」
- 「思ったとおりの結果にならなかった」
- 「なんかおかしい」
とだけ連絡が来るケースもしばしばありますが、これだけでは先に進めません。
事象を正確に捉える必要があるので、以下の情報を入手します。
- いつ起きた？
- どのユーザで起きた？
- 具体的に何が起きた？（どの画面で、何をした結果、どうなったのか）
- 再現性はあるか？
これらの情報を入手すると、ログでの調査ができるようになります。
特に、「いつ起きた？」の正確な時刻がわかると、ログが追いやすいです。
（時刻まで入ったスクリーンショットとか入手できると嬉しいですね！）
ログを集める
ログを集めるにあたり、システム構成図を見ながら、通信経路上のログを一通り取得します。
一般的なWebアプリケーションであれば、以下でしょうか。
- クライアント（スクリーンショットだったり、HTTP Archive (HAR) ファイルだったり）
- WAF
- ロードバランサ
- Webサーバ
- アプリケーションサーバ
- データベースサーバ
サーバ側のログは、「いつ起きた？」の正確な時刻がわかっていると、集める範囲の絞り込みがしやすいです。
アプリケーションサーバのログで、該当時刻に例外発生時のStack Traceが出ていたりすると、話は早いですよね。
たまにログが出ていないケースもあったりしますので、その場合は仮説を立てつつ、テスト環境で事象の再現確認をせざるを得ないです。ログ大事。
業務継続のための回避策を練る
どんな事象だったのかが正確に把握できたところで、原因調査、と行きたいところですが、ここで一旦立ち止まります。障害が発生しているということは、ユーザの業務が止まっています。
ユーザ目線では、「いつになったら業務の再開ができるかな…？」と気を揉んでいるケースもあるでしょう。
一部の機能でしか該当の障害が発生しないのであれば、縮退運転で業務を継続する方法もありますし、社内システムであれば「その機能は、一時的に使わないでください」と通知を出して業務を継続する方法もあります。
このタイミングで立ち止まり、関係者で情報共有するのはとても大事なことだと思います。
業務の継続ができていれば、このあとの調査についての重圧もある程度緩和できます。
再現確認→原因調査→一次対応
まずは事象を再現させます。
テスト環境やローカル環境で同じ操作をやってみて、同じ事象が再現するかを確認します。
同じ事象が再現すればしめたもの。
あとはデバッグしつつ調査をしていけば、原因にはたどり着けることでしょう。
原因がわかれば、該当箇所の修正等の対応をして解決させることになります。
問題は再現しない時。
事象が発生した環境とデータをそろえて再現確認してみるとか、いろんな仮説を立ててみて調査を進めてみるとかしますが、再現しないとかなり精神力が削られます。（経験談）
複数人でフォローしながらあたると良いです。
余談。
かつて携わっていたシステムがログが十分に取れていないシステムで、障害発生時になかなか事象が再現しなかったのですが、最終的には「LANケーブルの接触不良による瞬断が原因で、根本解決はLANケーブルを取り替えること」ということもありました。これはなかなか再現しなかったため、精神力を削られました…
根本原因の解消
一次対応が完了して業務が再開すれば終わりではありません。
振り返りをして、障害が起きた根本原因の解消や、調査を進めやすくする対策を打つと良いです。
ログが不足していたのであれば、出力するログを追加したり、
データの不整合が発生していたのであれば、発生しないように入力チェックを追加したり。
同じ事象が再度発生しないような対応を行っておくと、安心できる材料が増えます。
障害調査はチームで対応
ここまで、ヘルプデスクとか保守の担当者目線で書いてますが、障害対応はチームで対応が必要です。
担当者が調査に注力するとすれば、以下のような対応・役割も必要になってきます。
- 事象確認ができた時点で障害の重大度に応じて、エスカレーション
- 重大度によっては、調査と並行して障害解消のための改修
- 関係者への報告・調整
重大なものであるほど、「システムを理解している人」の調査とその見解が必要になってくるのですが、一人ですべての役割をこなすことは困難です。
知識を分散させて、プロジェクトにおける単一障害点を作らないような体制を作ってチーム運営していきたいところですね。
さいごに
繰り返しになりますが、システムに障害は発生してしまうものです。
発生してしまった時、エンジニアとしては、再現確認→原因調査→一次対応のところに目が行きがちですが、以下を念頭に置いて対応しましょう。
- 確実な対応を行うこと
- ユーザの業務を極力早く再開してもらうこと
- 発生した根本原因を解消させること
その中でも最優先は「ユーザの業務を極力早く再開してもらうこと」です。
ここまでお読みいただき、ありがとうございました。