こんにちは Enabling SRE teamに所属しているSREのchoreです！
この記事は freee 基盤チームアドベントカレンダー の17日目になります。
今回は freeeにおけるモニタリング運用の話をさせて頂きます。
背景
freeeではインフラやプラットフォーム周りのエラーをDatadogに集約していて、問題が起きた際には アラートが鳴ってエンジニアが実際のシステムに問題がないかを確認しています。*1
freeeにおけるDatadogのアラートの通知先
freeeにおけるDatadogのアラートは大きく分けて2つのSlackチャンネルに通知されています。
| 通知先チャンネル | アラート内容 |
|---|---|
| alert | 緊急度の高いアラート |
| alert-ntf | 緊急度の低いアラート |
アラートの問題点
しかし、現状のアラートには以下の問題がありました。
- 作成された経緯が不明なアラートがあり、どう対応すればいいのかが分からないものがある
- アラートの数が多く全てのアラートに万全に対応することが難しい
- alertとalert-ntfチャンネルに通知されるアラートが本当に緊急度で分けられているかが不明瞭(アラート作成者が恣意的に決めていた)
アラーティングガイドラインで秩序を取り戻そう！
これらのアラートの問題を解決するためにどうしようかと考えていた際に、SRE Next 2023 での GREE さんの発表を聞く機会がありました。 発表の詳細はぜひリンク元を見て欲しいのですが、この中で紹介されていたアラート追加ガイドラインの策定という取り組みは素晴らしかったので、 freeeでも適用可能な形で以下のようなアラーティングガイドラインを作成しようと考えました。
目的
- アラート疲れの軽減
- 不要なアラートを整理し、対応しないといけないアラートのみ通知がいくようにしたい
- アラートが発火した際のアクションの明確化
- どのタイミングで、どのようなアクションを取るのかを誰でもわかる状態にしたい
対象
Datadogアラート
アラーティングルール
通知設計
- 全てのアラートはSlackチャンネルに流すようにする
- アラートをfreeeのプロダクトの名前がついているSlackチャンネルに通知させる
- イメージとしては以下を想定
| 通知先Slackチャンネル | アラート内容 | 対応組織 |
|---|---|---|
alert-critical-<service-suffix> |
人手による即時対応が必要な緊急アラート | <service-suffix>の担当 |
alert-warning-<service-suffix> |
人手による対応は必要だが、緊急性の低いアラート | <service-suffix>の担当 |
alert-experimental-<service-suffix> |
alert-critical、alert-warningに設定する前の試験的なアラート、チューニング前の閾値設定が必要なアラート | <service-suffix>の担当 |
sys-info-<service-suffix> |
人手で対応しない通知。システムの状態やメトリクス等 | <service-suffix>の担当 |
- メンションを行うかを必ず決めて、行うのであればどのようにするのかを決める
- alert-critical-<service-suffix>チャンネルに送るものは@channelでメンションし、オンコール対応*2をしていく
- alert-critical-<service-suffix>チャンネル以外のチャンネルに送信するアラートにはメンションはしない。対応方法はチケットを作成し、後日対応をしていく
アラートメッセージ設計
- アラートのメッセージにどう対応すればよいかを明記するようにする
- まずはどこを見るべきなのかをアラートのメッセージに記載する
- その中でアラートの対処法が毎回決まっているものについては、自動化を必ず検討する
- すぐに自動化できないようならチケットを切る
- アラートの対処法が固定されておらず、緊急度が高いものについてはオンコール対応を行う
- アラートの対処法が固定されておらず、緊急度が低いものについてはチケットの作成を行う
- ただし、すぐの対応が難しい場合はアラートのミュートも検討する
- アラートメッセージに目的を明記する
- このアラートがどういった目的で通知をしているものなのかをメッセージに記載する
- アラートのオーナーを決定するようにする
- teamというタグを作ってそこにアラートのオーナーとして定義する
- 基本的にはアラートを作成したチームが、対応のオーナーにしていく
新規アラートを作成する際のルール
- 新規アラートが本当に有効かどうかをアラート作成者は検証するようにする
- 偽陽性の可能性やデータが取得するメトリクスが正しいのかを確認するため
- alertチャンネルに入れる前に検証用のチャンネルを使って検証する
- 長くても1ヶ月様子を見て有効でない場合はアラートを修正もしくは削除する
- 偽陽性の可能性やデータが取得するメトリクスが正しいのかを確認するため
- アラート作成したチームは有効にした際に関係者全体に周知を行うようにする
- 通知を行うチャンネル内で周知を行う
おわりに
ここまでアラーティングガイドラインを紹介しましたが、当然このガイドラインを作成するだけで秩序が変わるわけではありません。 現状は以下のような取り組みを行なっていきたいと思っています。
- アラーティングルールに沿うように既存のアラートを整理する
- アラートの作成・更新時には自動でSlack通知がされ、エンジニア全体に周知される状態にする
- アラーティングルールに適合したアラートを簡単に生成できるような仕組みを作る
また、freeeでは「アラート振り返り会」という各プロダクトでどういったアラートが出たか、どういう対応をするかというのを話し合う定例を毎週開催しています。
この定例の中で現状の運用が回っているかどうかをチェックしているので、紹介したもの以外にも改善できる点に取り組みたいと考えています。
まとめ
今回は freeeでのアラーティングガイドラインを作って、アラート疲れをなくしていくEnabling SRE teamの取り組みを紹介しました。 まだアラートの秩序を取り戻す試みは始まったばかりですが、よりよいプロダクトを顧客に届けていけるように頑張っていきたいと思います！
明日の記事は SRE Cloud Governance チーム の sakaki さんになります。是非お楽しみに！
