意義のあるアラート通知文について考える

この記事は何？

昨今ではサービスに対する監視ツールは多くのSaaSやOSSが存在しており、多くの組織が何らかのツールを導入していると思います。
一方で監視は入れたが、単にアラート通知を投げるだけになっていて障害対応の際に困る・そもそも対応がスルーされてしまうケースも世の中には多いのではないかと思います。
今回はどういった考え方で監視のアラート文を運用していくとより組織が効率的に機能するかについてまとめてみました。

あなたは誰？

株式会社グロービスのデジタルプラットフォーム部門（以下、GDP）でSite Reliability Engineerをしており、AWS,K8s(EKS)周りを中心に扱っています。クラウドインフラ分野を主軸と置きつつ、プロダクト開発チームと一緒に運用・監視の改善やインフラリソースへの扱いに対する心理的ハードルを下げる取り組みをしています。
https://speakerdeck.com/globis_gdp/globis-sre-team-is-hiring

よくある課題感

DatadogやNew Relicなどのモニタリング関連のSaaSを使って監視設定をするが、以下のように実運用がきちんとできていない環境は意外とありがちかなと思います。

• アラートメッセージに具体的な情報が付帯されておらず、どんなアクション取っていいのかわからない
  • プロダクトに長く携わる人のみが対応できるため属人化する
• アラートに対するオーナーシップが曖昧である
  • とりあえずアラート通知用のSlackチャンネルに @here のアラート通知が投下される
• 偽陽性を含む大量のアラートがSlackチャンネルに通知されるため、監視の確認に疲弊する/確認を諦める
  • 割れ窓の嵐で運用としてのテイをなせていない

たとえば以下のようなアラートが流れてきても、それがどれくらい重要なもの（ユーザーにどの程度クリティカルなもの）であり、どのように対応するべきかが分からないため、なかなかアクションが取りにくいのが現実かと思います。

どうするとより幸せになるか？

心配だからという理由だけで何でもかんでもアラート通知を出しても、実際に通知が出た際にうまく対応できなかったりスルーされて実りある運用にはなりにくいです。
監視を導入することの目的を組織で明確化し、その目的の達成に集中することが重要であると思います。
特に事業会社においては、究極的にはサービス利用者への影響がなければ対応は不要になります。アラート通知を通してサービスのどのような状態に気づき対処をしたいのか、サービス運用において担保したいことは何かについての組織内で共通認識を築くことが大切です。

これらの前提の元、より具体的にどのような点について意識するとよりよいアラートメッセージになるかを考えてみます。

そのアラートを通してサービスがどんな状態であるかが分かる

あるアラートが発報されたとして、 それがサービスに対してどのようなことを意味するのか？ が端的に分かることは初動に向けて重要です。
上記に添付されたアラートのように、検知条件のqueryだけが表示されるだけでは、サービスが具体的にどのような状態であるか分かりにくいです。

アラートと言っても以下のようにサービスへの影響度は異なります。そのため特にサービスがエンドユーザーに対して具体的にどのような状態であるか・どのような影響があり得るかがわかると対応の温度感も変わってくると思います。

• サービスがダウンしたりユーザーが登録処理を行えないなどの致命的な事象であるか？
• サービスは動いているが極端にパフォーマンスの低い処理がありユーザーのUXを損ねているのか？
• 直ちに問題にはならないが中長期的に問題となりそうなスメルが検知されたのか？

アラートに対して第一アクションどうすればよいか分かる

そのアラートを通してサービスがどんな状態であるかが分かる によりアラートの緊急度が分かったうえで、初動の対応方針・手順が分かる必要があります。特にサービスダウンに関わる事象の場合には刻一刻を争います。
サービスダウンなどのユーザーに影響する問題に関するアラート通知の場合には、根本対応よりも目先のサービス復旧がより重要になります。そのため暫定対応と根本対応は分けて記載することで、ユーザーへのサービス提供というより優先度の高いことに集中して取り組むことに繋がります。

ただし暫定対応についてどこまで精緻な情報をアラート通知文に盛り込むかは組織の役割分担や習熟度などの前提に左右されるところが大きいため、組織内での共通認識を持ったうえで定める必要があります。
※具体的な対応をアラート通知文に直接記載するか、はたまた手順を記載したドキュメントのリンクを添付するかはどちらでも良いかなと思います。メンテナンスしやすい方法を組織で決めるのが良いと思います。

具体的な例

上記を踏まえてK8s PodでOOM Killedが発生した場合のエラー通知文を以下に考えてみます。

*サマリー*
K8s PodのOOM Killedが発生しました。
現在既にサービスに影響を及ぼしている可能性が高いため、速やかに復旧対応をお願いします。

• Pod名: xxxxxx
• Datadog error logs: <https://example.datadoghq.com/logs?query=xxxxxxxxxx>
• Argo CD: <https://argocd.example.com>

*対応方針・手順*
サービス安定化のための暫定対応としてPodのMemory (requets/limits) の値を引き上げてください。
※Memory利用量を大幅に上げる場合にはSRE側のリソース設定にも影響を及ぼす可能性があるため、SREと相談してください。

そのうえで、Datadog APMやログなどからMemortを大きく消費している処理を調査し、根本対応を行ってください。

障害対応が必要な場合には、こちらに沿って状況確認やエスカレーションの手順を踏んでください。
${document_link}

そのアラートを通してサービスがどんな状態であるかが分かる については サマリー に記載し、 アラートに対して第一アクションどうすればよいか分かる については 対応方針・手順 にそれぞれ記載しています。
アラートに伴うプロダクトの状態と、それを受けて1stアクションとしてどうするべきかが分かるため、初動がとりやすくなりそうです。

まとめ

サービス監視の目的を明らかにしたうえで、アラートが実際に発報された際の具体的なアクションに落とし込めるようなアラート文を定めることで、組織としてより実りあるサービス監視となるのではないかと思います。