株式会社TECH LUCKという会社で代表兼エンジニアをしている齊藤です。
DXプロジェクト、開発プロジェクト、Rails開発などでお困りごとがありましたら弊社HPからご相談をいただけますと幸いです。
以下のような問題に対応することが可能です。
- プロジェクトでRailsエンジニアが足りなくて困っている
- Railsのバージョンアップをしたいがノウハウ・リソースが足りなくて困っている
- オフショア開発をしているが、要件の齟齬やコード品質が悪いので改善したい
また、Railsエンジニアも募集しておりますので、興味がありましたら弊社HPからご連絡いただけますと幸いです。
前提
この記事を3行でまとめると以下になります。
エラー通知を設定する際には以下の2つを考慮しよう。
- 誰のどのようなエラーを検知したいのか？
- エラーを検知してどのようなアクションに繋げたいのか？
背景
すでに本番環境で稼働しているWebアプリのプロダクト開発にエンジニアとして加わることになりました。
しかし、本番環境で何かしらのエラーが起き多彩にエラー通知をして、エラーが起きたことを誰かが把握することはしていない状況となっていました。
このような状況だったので
「リリース前の動作確認やテストコードでは捉えられていないエラーが起きているかもしれない、、、。」
という不安がありました。
そのため、エラー通知をするようにすればいいのではないかと考え、エラー通知をするように実装・設定しました。
チーム内でのコミュニケーションはSlackを使っているため、Slackに #error チャンネルを作成し、そこに通知を流すように設定し、チームメンバーの招待をしました。
これで一安心だ、と思いきや初日から地獄に陥りました。
通知地獄の始まり
エラー通知と行ってもエラーには種類があります。503エラー、500エラー、404エラー、403エラー、etc...。
あまり深く考えていなかったため、あろうことかをすべてをエラー通知する設定にしていました。
勘のいい方だとお気づきだと思いますが、400系のエラーもすべて補足するためbotによる不正なURLアクセスのエラーもすべて通知することになります。
そのため #error チャンネルは、botによる不正なURLアクセスのエラー通知で埋まってしまい、メンバーが通知をオフにするという状況になってしまいました。
画像はbotによる不正なURLアクセスのエラーとなっている様子です。（Slackの通知音が1日中鳴り止まなかった。）
エラー通知はなぜ必要なのか？
このままではエラー通知を設定した意味がないということで、エラー通知の目的を改めて見直すことにしました。
「botによる不正なURLアクセスのエラーって検知したいの？」「エラー通知を受け取ったらアクションを起こすようにしないと意味がないよね？」など、さまざまなことを考慮した結果、軸となるのは以下の2つだということがわかりました。（記事の冒頭にも書いた２つです。）
- 誰のどのようなエラーを検知したいのか？
- エラーを検知してどのようなアクションに繋げたいのか？
そこから、私たちのチームは以下のような目的でエラー通知の設定することにしました。
プロダクトを適切に使っているユーザーが、開発の実装の不備でエラーが起きていないか検知したい。それによって、重要度の高いエラーであれば、通知を受け取ってすぐに修正をする。緊急でなければどこかのタイミングで修正をする方針を立てる。
そこで、500エラーだけに絞り、他のエラーバッサリと捨ててエラー通知をしないようにしました。
地獄からの脱出
500エラーだけに絞ると、1日中通知されていたエラー通知は2日に1件ほどになりました。
そのような状態になると、エラー通知がきたら必ずアクションにつなげることができるようになり、「エラー通知きたので作業止めて一旦見てみます」というアクションを各自の判断で取れるようになりました。
知り合いの企業では、「通知が多すぎて、エラー通知がきても誰も何もしようとしない。」という、エラー通知のオオカミ少年的な状況になっているところもあると聞きます。
そうならないように、適切なエラー通知を設定することが大事ですね。