こんにちは！
人事評価機能を開発しているプロダクトエンジニアのnekoです。
現在、人事評価チームでは、システム障害アラートの運用改善を行っています。
今回は、現在の課題感や具体的な改善活動、目指す姿を紹介します。
現在の課題感
人事評価チームではSentryというエラーやパフォーマンスのモニタリングができるSaaSを利用しています。
エラーが発生するとSentryが検知し、Slackにエラーアラートとして投稿される仕組みです。
この仕組みをより良いものにするために、改善活動を行っています。
主な課題は以下の二点です。
- アラートが多すぎる
- 運用が属人化している
この課題を解決することで、エラーのアラートに迅速に対応できるようになります。
これらの課題を少し深堀りしてみましょう。
アラートが多すぎる
現状では、対応の必要がないアラートが数多く発生しています。
サードパーティーライブラリのエラーなど、アラートとして上がってきてもこちらで対処できないものや、対処する必要がないものもSlack上に出てきてしまっている状態で、一つ一つ確認作業を行うため、対応要否の確認コストがかかっています。
この状態では、本来検知したいエラーに対して、迅速な対応が難しくなります。
必要なエラーだけがアラートとして上がり、今まで以上に迅速な対応ができる状態を目指したいです。
運用が属人化している
対応要否に関連する課題ですが、「このエラーは過去に調査して問題なかったので対処しない」「このエラーは対処が必要」など、職人技のようなものが生まれつつあります。
アラートの運用が定まっていないため、過去に発生した物と同じ事象で、対応が不要にも関わらず調査コストをかけてしまうという課題があります。
エラーを適切にアーカイブし、調査時の記録を残しておくことで、コスト削減に加え、属人化を防ぎ、誰でも回せるシステムアラート運用にできると考えています。
また、新メンバーのオンボーディング等に関しても、誰でも回せる運用ルールにすることで、働きやすい環境かつ安全なアラート運用ができると思います。
改善活動
現在、上記の課題に対して毎週アラート改善ミーティングを行い、以下の内容を実施しています。
エラーのアーカイブ
既に大量に出ているエラーを地道に調査し、アーカイブしています。
アーカイブ時は単に無視をするようにするだけでなく、1日に10回以上発生したら再度アラートを出すなど、内容に応じて議論しています。
アーカイブするとアラートが上がってこなくなるため、今後対応する必要のないエラーにリソースを割かずに済むようになります。
また、アーカイブ時に原因調査した内容を記録しているため、一度アーカイブしたエラーが多発した場合の調査においてもコストを削減することができます。
エラーのグルーピング
アラートが多すぎる要因の1つに、原因は同じだが発生箇所によって別のエラーとして認識されてしまうということがあります。 例として、以下のケースがあります。
- UsersControllerでDB接続エラーが発生した
- PostsControllerでDB接続エラーが発生した
どちらも「DB接続エラー」ですが、コントローラーが別なのでSentryでは2つのエラーが作成されます。
もちろん、発生箇所の数だけアーカイブすることも可能ですが、効率的とは言えません。
そこで、Fingerprint Rulesを使うことでエラーのグルーピングを行います。
グルーピングを行うことで、本質的なエラーを軸としてSentry上にエラーが作成されるため、一度アーカイブしたが、発生箇所が異なるので再びアラートに上がってくるということを避けられます。
最終的に目指す姿
最終的には、アラートが発生してから対処まで、最速でできる状態を作り上げたいです！
そのために、まずは辛くないアラート運用ということで少しずつ改善できていると思っています。
更に踏み込んで、アプリケーション側の話まで入れると
- 適切に対処できるよう、例外設計を行う
- システムエラーとして適切ではないものは、そもそもエラーにしない（アラートを出さない）
- エラーとして対処できないものやアプリケーション側で対処すべきものを適切にハンドリングする
- 単発の接続エラーなどは、アプリケーションでリトライすることができる
などなど...アプリケーション側でのアプローチもできると思っているので、今後もどんどん改善を続けていこうと思っています！
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
今後もプロダクト改善を積極的に行っていきますので、少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
