こんにちは、株式会社スマートバンクでサーバサイドエンジニアをしているnagasawaです。 皆さんアプリケーションのエラートラッキングを何かしらのツールで行っていると思いますが、日々多くのアラートが届き以下のような悩みをお持ちではないでしょうか。
- どれが今すぐ確認すべきアラートなのか見分けがつけにくい
- 件数が多く対応状況が把握しづらい
- アラートがオオカミ少年に近い状態になっており、重要なアラートが見逃されてしまうことがある
下図のように、株式会社スマートバンクでも多い日は10~20件ほどアラートが届いていました。決済系の機能群など一度でもエラーが発生したらすぐに対応したいアラートに反応しやすくするためにも、上記の課題を解決したいと考えました。
一応クリティカルなエラーは捕捉できていたのでアラートの対応はシステム運用上問題なく行えていましたが、理想的なアラート管理を行えている状態ではありません。
このアラート改善の取り組みは、現在株式会社スマートバンクで行っている委員会制度で立ち上げた品質委員会のチームで行っています。制度の目的や詳細については以下の記事をご参照ください！ blog.smartbank.co.jp
前提
- モニタリングツール：Sentry
- トラッキング対象：モバイルアプリ向けのバックエンドAPIサーバ
- 技術スタック：Ruby + Ruby on Rails
- 過去アラートを減らす取り組みとして、通知が不要な例外はそもそもSentryに送信しないよう工夫を行っていたがそれでも流通量が高い状態となった…
関連技術スタック等の前提は上記となりますが、ノイズとなるアラートを減らすための考え方や運用の移行方針については他の技術スタックでも共通の部分があると思いますので何か参考となれれば幸いです。
目指したゴール
今回アラート疲れから脱却するにあたり以下をゴールに運用の見直しを行いました。
- アラートが届いたら「誰か」が「至急」チェックしなければいけない風土を作る
- 対応すべきIssue*1について対応優先度の管理をできている
このゴールを達成するためには現状のアラート発生頻度を減らし、発生したエラーに対応優先度を割り振るようにする必要があります。そのために、以下の道のりでアラートの運用ルール整備を行っていきました。
アラートの運用ルール整備の道のり
ステップは以下の2つです。
- 対応優先度の高いIssueのみアラートされるようにする
- アラートのトリアージガイドラインを定める
- アラートを飛ばす条件(Alert Rule)を再構築する
- 運用方針に基づき、アラート運用の移行作業を始める
それぞれ具体的に何を行ったか詳細を説明します。
1. 対応優先度の高いIssueのみアラートされるようにする
この方針は、SentryのAlert Best Practicesを参考に策定しています。このガイドにはノイズとなっているアラートを削減し、アラート疲れの状態を回避するためのプラクティスが記載されています。アラートのノイズを減らす方法はいくつか紹介されていますが、株式会社スマートバンクでは紹介されている手法のうち「Issueの優先度」を軸に対応優先度の高いIssueのみアラートが飛ぶよう整備を行いました。そのために行ったことは以下の2点です。
- アラートのトリアージガイドラインを定める
- アラートを飛ばす条件(Alert Rule)を再構築する
Issueの優先度を軸とした理由は、現状のアラートを収集し分析したところ以下が判明したからです。
- 発生しているアラートの大半は管理画面の誤操作や正常にバリデーションで弾けているケース等など確認が不要なもの
- 逆に、決済エラーのような一度でも発生したら状態不整合の確認が必要なアラートはごく少数
そのため、Issueの優先度を軸に本当に確認が必要なエラーのみアラートを飛ばすよう整備すれば、アラート発生頻度が減りアラート疲れを緩和できると考えました。
アラートのトリアージガイドラインを定める
アラートが飛んできた際にどのようなアクションを行う必要があるかガイドを作成しました。適切なトリアージの実施と後述するAlert Ruleを整備することで以下のような状態を実現できます。
- 優先度の高いIssueのみアラートを行える
- Issueの対応優先度の管理ができる
話がSentry独自の部分に寄りますが、新規のアラートが飛んできた際のガイドラインとして具体的には以下を定めました。
Issue Priorityを設定する
https://docs.sentry.io/product/issues/issue-priority/#how-priority-works Issueの対応優先度を管理するために設定を行っています。
- High: 即座(数日以内)に対応が必要な重要なIssue
- Medium: 近い将来(数ヶ月以内)に対応が必要なIssue
- Low: 即座の対応は必要としないIssue
※ Issue の Priority はあくまで優先度を管理するための目的で運用しています。 どの時期感で動いていくか等は適宜担当するチームに判断を任せています。
IssueのStatusを決定する
https://docs.sentry.io/product/issues/states-triage/#manually-triaging-issues IssueのStatusの管理を行い、想定外のStatusに変わった際にアラートを飛ばせるようにするために設定を行っています。 SentryではStatusを変更するアクションとして主に以下の2つを行えます。
Resolve
Issueの原因を解消し、同一のIssueが発生しない状態にした際に使っています。 ※ Issueを発生させている原因を解消していないならResolveしない
Archive
優先度が低くノイズになっているIssueのアラートを取り除くために使っています。 ArchiveしたIssueがどのような条件で再度アラートを飛ばすかは5つオプションがあり、アラートを再発させたい要件に合わせ使い分けています。
https://docs.sentry.io/product/issues/states-triage/#archive
アラートを飛ばす条件(Alert Rule)を再構築する
Alert Ruleとは、どのようなIssueが発生したらアラートを行うかのルールです。 https://docs.sentry.io/product/alerts/create-alerts/issue-alert-config/
上記のトリアージガイドラインでIssueの優先度やStatusの管理が行えるようになったため、以下のようなAlert Ruleを設定することで、ざっくり説明すると想定外の確認すべきエラーが発生した場合のみアラートを鳴らすことができるようになりました。
Sentry marks a new issue as high priority
→ 未知のエラーが発生した場合のアラートトリガー
SentryはFatal・Errorレベル以上のIssueは自動的にHigh Priorityに設定するため、基本的に新規のエラーが発生した場合はこのトリガーが発火します。
Sentry marks an existing issue as high priority
→ 既知のエラーが大量発生した場合のアラートトリガー
The issue changes state from resolved to unresolved
→ 解決したはずの既知のエラーが再発した場合のアラートトリガー
The issue changes state from archived to escalating
→ 既知のエラーが無視していい基準を超えた場合のアラートトリガー
ちなみにですが、変更前のAlert Ruleはこのようなものでした。
- Error LevelがError以上のIssueが1度でも発生したらアラートする
これはアラートの中でも最も頻度が高いものであり、優先度の有無等に関わらずアプリケーション上で発生したエラーが全て飛んでくる状態です。サービスリリース初期などはいいかもしれませんが、アクセス数と機能数の増加等に伴いアラートが届きすぎてしまいアラート疲れを起こしかねないものです。
また余談として、Best Practicesの方針としてFrequency Based(エラーの発生頻度に応じて)通知を行う手法も紹介されていますが、株式会社スマートバンクでは特に決済系の機能群など1度でもエラーが発生したらアラートを鳴らしたいドメインが存在するためState Basedを採用しています。 Alert Ruleをより詳細に整備すればドメインに応じて通知の基準を変更することも可能ですが、module毎に判断するコストや運用が重く、また現状のエラー発生数であればState Basedで管理してもアラート頻度はそこまで高くならず、確認コストは増大しない見込みだったため採用は見送っています。アプリケーションの性質や、エラーの発生母数に応じて採用する方針を判断することをおすすめします。
2. アラート運用の移行作業
新規のIssueについてのトリアージガイドラインやAlert Ruleの方針は立てたものの、既存のIssueはトリアージが行われておらず、Alert Ruleを適用しても理想的な環境にはならない状態でした。そこで、以下のステップで移行を進めました。
- Alert Ruleは変更せず、アラートが発生する度にIssueの対応優先度とStatusを決定する
- Issueのトリアージが大方進みアラートの件数が減ってきたら、新Alert Ruleを適用する
当たり前の話ですがガイドをせっかく定めても運用が意図通りに行われていなければ効果を発揮することはできません。今回定めたガイドはトリアージの判断が初めは難しい性質であり、かつトリアージしないといけないアラート数も多くガイドを元に運用をお願いする形式で組織に浸透させていくのは難しいと判断したため、まずはルールを整備した品質委員会側でアラートのトリアージの旗振りを2~4週間ほど泥臭く行い、目指している状態の効果をいち早く得られるよう移行を進めました。
エンジニア全員の協力もあり既存Issueのトリアージの大半が進んだため、現在は新Alert Ruleを適用して日に数件ほど優先度の高いIssueのみアラートが飛ぶ状況を実現できました。 まだいくつか取り切れていないノイズとなる優先度の低いアラートはありますが、改善前と比べ約80%ほど減らすことができたため、アラート疲れの状態を緩和することができました。
また、アラートが来た際の対応も直近改善が行われています。冒頭で触れた委員会制度の枠組みでチーム連携最大化委員会が行った取り組みとして、アラートチャンネルのエラーに特定のスタンプを付けるとRunbookがサジェストされるようになっているので、エラーに伴う運用作業を誰でも行えるような状態にもなっています！
まとめ
これまでご紹介したアラートのトリアージ方法とアラートを飛ばす基準を見直すことで、優先度の高いアラートのみが届く環境を実現しアラート疲れが起きづらい状態を作り上げることができました。移行期間含め運用を始めて実はまだ1ヶ月ほどなため、完全にノイズとなるアラートを取り切れていない面はあるのですが短期間で十分にアラートの量を減らすことができています。
このトリアージの活動を継続していくことで徐々にノイズとなるアラートは減ってくるため、活動を維持していき最終的に優先度高く即座に確認すべきアラートのみが届く環境を作り上げたいと考えています。
同じ悩みを抱えているエンジニア組織のアラート運用の改善の一助となれば幸いです！
*1:アプリケーションのエラーがSentryに通知された際に起票されるアイテムのことhttps://docs.sentry.io/product/issues/
