目撃したアラートメッセージ、全部対応できていますか？
自分の担当ではないアラートや発生しても問題ないアラートもあるかもしれません。今回はアラート対応をより効率的に行えるアラート設計のポイントを紹介します。
この記事は エムスリー Advent Calendar 2023 の 16 日目の記事です。
Unit1（製薬企業向けプラットフォームチーム）の佐野がまとめさせていただきます。
アラート対応の価値と向き合い方
まずはアラート対応について考えを整理しましょう。
アラート対応は非常に重要です。システム障害をいち早く検知しビジネスやユーザーへの影響を最小限にできます。 障害が発生してしまうと障害対応工数や遺失利益、顧客対応、提案機会の損失など、影響は多岐にわたります。
また、実際にアプリケーションを利用されるユーザーにもご不便をおかけしてしまいます。いち早く復旧することで気持ちよくサービスをご利用いただけるようになります。
アラートはシステムの異常を検知するために非常に有効ですが、多く出すぎているとどれが本当に対応すべきアラートなのか分かりづらくなってしまいます。オオカミ少年になってしまわないようアラートの削減も重要です。
そのため、アラートに対する姿勢としては
- 本当に必要なアラートに絞り込む
- アラート内容に対応しやすくなる情報を盛り込む
- アラートが発出される前にアラートを予見する
という対応が必要だと考えます。
この章のまとめ
- アラート対応はユーザ体験、利益を守る大切な行動である
- アラート内容やルールを整備し日々の運用コストを下げる事も同時に重要となる
本当に必要なアラートに絞り込む
本当に必要なアラートとは何かを考えるために、実は不要なアラートを洗い出します。
- 単発では問題ないが、頻出したり連続で出ると問題となるもの（しきい値チェックなど）
- ビジネス上の理由で「今回は」問題がないようなもの
アラートを絞り込むために削減すべきものの多くは基本的に1点目の理由か思います。使っているアプリケーションの種類によりますが、これはSentryのAlertRuleで制御可能です。
https://sentry.io/resources/alert-rules/
こちらの公式サイトのマニュアルにある通り、一定期間のうちに何回以上アラートが検知されたら通知するという設定が可能です。Webアプリケーションやバッチのエラー出力ロジックで制御するよりもSentryで一括対応したほうが集約されるので良いかと思います。Web UI上で柔軟に変更可能なのでリリースせずに対応できる点もスピード感があって良いと思います。
この章のまとめ
- SentryのRuleでアラートの発出数を制御し、本当に問題があるときのみアラートが出るようにする
アラート内容に対応しやすくなる情報を盛り込む
アラート対応しやすくなる情報とは何かを考えます。この時に非常に重要なのが、実際に対応する時に必要な情報は何かということです。
- 対応が遅れたときのビジネス、ユーザーへ影響
- デッドライン
- アラート対応すべきか否かを判断できる責任者（部署）
- 前回対応時の記録（チケットやドキュメントなど）を即参照できるURLなど
原因箇所を特定し、素早く対応することも非常に重要ですが、それよりもまずビジネス、ユーザーに現在どのような影響が及んでいるかを考えるべきです。優先順位や対応方針（根本原因の特定、対応 or 暫定的な対応）を決めることができます。デッドラインも同じように対応方針を決める上で非常に重要な情報です。
実際に対応を進める際、対応する人は前回対応したメンバーとは異なると考えたほうが良いです。
この時にとても助かるのが「前に対応したときの記録」です。まとまってくなくて雑でも良いので、何かしら情報を残しておけば次の世代（未来の自分含む）に繋がります。Slackのスレッドに独り言でも良いので記録を残しておくと良いです。*1
この章のまとめ
- 優先順位と対応方針を決めるためにビジネス、ユーザーへの影響を考える
- アラートに情報を盛り込むことで対応が高速化される
- アラート → 影響判断 → 優先順位決定 → 過去対応に従って対応。という流れを作る
アラートが発出される前にアラートを予見する
多くの場合、アラートの予見はある程度可能だと思います。すべてのアラート（エラー）を予期する必要はなく、ビジネスロジックを書いている時に例外パターンを思いついたときがアラートの予見です。
必要に応じてExceptionやErrorを発火させるのも良いですし、catchして情報を付加して投げ直すのも良いと思います。サービスの機能追加やクラウド化等でアプリケーションも成長しているため、日々新しい種類のエラーが発生すると思いますが、草の根活動で1つずつ対応していくことでキレイな世界が待っているはずです。
チームでこの観点を持ちながら対応をしていくと、いつか「ここはこの情報を盛り込んでアラート出しましょう」とか「ビジネス側に影響を確認しておきますね」といったコメントも生まれるかもしれません。
この章のまとめ
- アラート運用をチームで理解する
- コードレビューやコーディング時にアラート発出後の運用まで考えておくという文化を作る
まとめ
今回はアラート運用についてまとめさせていただきました。日々発出されるアラートについて少し整理してみようという気持ちが湧いていただいたら嬉しいです。
かくゆう私も数年前まではアラートメールや通知にうまく対応できていませんでしたが、その後エラー対応を何度も経験するうちに向き合い方が変わり、アラートが発出される前に事前に手を打っておくようになりました。
エムスリーでは既存のサービスをクラウド化したり、機能開発が活発に行われているため新しいアラートが生まれるスピードも早いですが、先手を打っておくことで日に0〜数件のアラート対応で済んでいます。
これから年末年始という長い休みを迎えると思いますが、みなさんが無事に過ごせるよう祈っています。
We are Hiring!
エムスリーではエンジニアを募集中です。
運用系のエンジニアも日々工夫をしながら業務に当たっています。業務改善が好きな方、是非一緒に働きましょう。そしてアラートやエラーが0になる世界を目指しましょう！
また、運用系のチームでもPython、Terraform、AWS、Dockerなどの技術を使う機会も多くあります。私でも力になれるのでしょうか、というお気持ちもあるかもしれませんが少しでも興味をお持ちいただけましたらカジュアル面談もありますので一度お話をさせてください。ご応募お待ちしています。
*1:キレイなドキュメントにするのは非常に難しいため、他のメンバーにも手伝ってもらうのも良いと思います
