エラー運用物語〜オオカミ少年編〜

導入・前提

ソフトウェアエンジニアリングは「作って終わり」というわけにはいきません。
特にDevOpsなどが広まってるいま、作るだけでなくその後の運用も重要かと思います。

今回は、そんな運用におけるエラー監視やその対応について起きた問題と行った対策について簡単に紹介したいと思います。
※インフラ面の監視ではなく、ソフトウェアのアプリ上のエラーの監視と対応の話になります！

前提

今回の内容はLaravelで開発している越境ECサービスの運用中にて起こった話です。
エラー監視ツールとしてはBugsnagを利用しています。
例外やwarning以上のログはSlackの#xxx-errorsというチャネルに通知されるようになっていました。
（xxxにはサービス名が入ります）

課題

サービスを運用しているうちにエラー通知が増えていき、一日数十件と大量の通知が飛んでくる状態になってしまいました。
その中には対応が必要なもの/不要なものが混じっています。
対応の要不要の判断は経験頼りに行うしかなく、「新しくチームにジョインした人には何て説明したらいいの？」という状態でした。

また、チーム内でエラー通知をスルーする人が出てきてしまいました。
対応の要不要が分かりづらいため、「誰かが見てくれるだろう」の精神で責任所在が不明瞭でした。
典型的なオオカミ少年のアンチパターンになっていました。

エラーとは？

エラー通知が多すぎるのが問題だったのですが、そもそもエラーとはなんなのでしょう？
ISTQBには間違った結果を生み出す人間の行為と定義されています。

これによると、実はシステムではなく人間の行為のことを指すようです。
（システム側の問題のことは「欠陥」という言葉を使ったりします）
確かに、バリデーションエラーもエラーの一種ですね。

こう考えると、エラーは通知や対応が必要になるとは限らず、むしろ通常通りに運用していても発生するものです。

対策

では、一体何を通知すれば良いのかと考えた時、チームではログレベルをベースにしました。PSR-3をはじめ、ログレベルは一般的に以下のものがあります。

• emergency
• alert
• critical
• error
• warning
• notice
• info
• debug

チームではログレベルに応じて以下のような運用ルールを定めました。

ログレベル	説明	緊急性	通知先
emergency	システムの利用が不可能	夜間休日でも対応する必要がある	#xxx-emergency
alert	アクションをすぐに起こさなければいけない	休日でも数時間以内に対応する必要がある	#xxx-alert
critical	致命的な欠落がある状態	当日中または翌営業日に対応する必要がある	#xxx-critical
error	エラーが起こっている状態	障害起票をし優先度を決定後対応する	#xxx-error
warning	警告されている状態	内容を確認し障害起票するか判断する	#xxx-warning
notice	正常ではあるが重要な情報	緊急性はないが定期的に確認を行う	#xxx-notice
info	情報メッセージ	なし	クラウドサービス上のログ関連機能（CloudWatchなど）
debug	デバッグ用のログ	なし	ローカル環境などのログ

ログレベルにも「エラー」という言葉が登場しますが、ISTQBとは別のコンテキストでの別の意味で捉えてください。
ログレベルに応じて通知先のチャネルを分け、いつまでに対応が必要かのルールを定めました。
Bugsnagの通知先も別チャネルにしており、そちらは基本的にerrorと同様の対応をするようにしました。

これにより対応が必要なものはすぐにわかるようになり、「何を責任持って対応すべきか？」がわかるようになりました。
チャネルを分けているので、レベルごとにSlackの通知設定を変えることもできます。
おかげで問題にいち早く確実に対応することができるようになりました。

以上、今日はエラー監視のオオカミ少年アンチパターンのお話でした！
次回はチーム運用の話をしたいと思います！