Mackerel SRE が実践する監視の育て方

これは Mackerel Advent Calendar 2023 の12/3分です.

昨日は id:rmatsuoka さんの Mackerel で開発中のマイクロサービスを OpenTelemetry のトレースを活用してパフォーマンス改善したでした. パフォーマンス改善でのトレーシング便利でいいですね.

今日は Mackerel の SRE が日頃どのように監視を育てているかについて書きます.

監視を育てる必要性とは

新しいシステムの構築や障害の再発防止など, 様々なことをきっかけに監視は構築されていきます.

監視は一度設定して終わりではなく, 運用しながらより適切な状態に近づけていく必要があります. もし不適切な監視ルールがあると, 不要なアラート通知なので何も行動しないということが常態化したり, 大量のアラート通知により見るべきアラートにたどり着きにくくなったりしてしまいます.

しかし, 適切な監視の設定はそう簡単ではありません. たとえば, ユーザーから見てサービスが期待される状態で提供されているかどうか監視する, のように監視の目的を考える必要があります. それはプロダクトや監視に対する知識や経験も重要になるでしょう. それに, 設定した時には適切な状態であっても, サービスの状況が変化し監視が期待と合わない状態になってしまっている場合もあります.

監視をよりよい状態に保つための監視設定の変更はしばしばあるもので, 監視をより適切な状態に近づけていくことを "監視を育てる" と呼んでいます.

はてなでは定期的にダッシュボードなどでシステムの状態を確認する機会*1を設けているチームが多く, そのコンテンツの１つとして発生したアラートの一覧を見ているところがあります. このように定期的なコミュニケーションの場を利用して監視を育てていくのも１つの手段です.

Mackerel の SRE としては, 新メンバーが自立していくための手段に監視の育成を利用しました.

取り組みの背景

ありがたいことに, 今年開発チームにはアプリケーションエンジニアと SRE で新しいメンバーがたくさん増えました. その新しく加わったメンバーにアラートや障害発生時の調査方法をどのように会得してもらうかについての悩みがありました.

かつての自分を思い出すと, アーキテクチャを把握したり, 先輩が調査している様子や過去の調査ログを見て教えていただいたりしてどのように調査していくのかを理解していったような記憶がうっすらとあります. このような調査方法は初回の導入としてはあってほしいものの, いざというときに素早く調べられるように, 予備動作なく動けるほどに慣れておきたいという思いは個人的にあります.

その前提にある監視ルールも同様に, その監視ルールは必要か, その監視ルールの設定は本当に適切なのかを考えるタイミングをどのように運用に組み込むかが悩みどころでした. 監視は設定して終わりではないため, 定期的に見直すための仕組みを作るのが目的です.

これまでの監視ルールの見直しは, 監視の一斉見直しや有志の行動によるものがほとんどで, 継続的とは言い難いものでした. 特に新規メンバーにとっては, 監視ルールの設定意図やシステムを十分に把握していないとアラート発生時に何を調査すべきかわからず, 監視ルールの変更を行うのもなかなかハードルがあるものでしょう.

このように, 監視ルールの形骸化の予防や現状のキャッチアップのためにも, 継続的な改善を設計するのがよいと考えています.

個人的な反省

監視を育てる体制を作ったきっかけはもう1つあります.

Mackerel である障害が起きたときに, アラートが発生していたのに誰も反応できていなかったというふりかえりがありました. これは, 監視ルールの意図を理解している人しかアラートの意味する状況が把握しづらい状態にあったのだと思っています.

つまり, チームメンバーにはアラートの通知内容だけでは発生しているサービス影響が伝わりにくい監視ルールの設定だったと言えます.*2.

また, 残念なことに, サービスの状態は正常なものの監視ルールに設定された閾値や監視対象のメトリックが適切でないためにアラートの誤報が上がることが慢性化した監視ルールもあり, アラート通知に対して緊急と捉えられない感覚になってしまっていたというのもあると思います.

この障害の再発防止策の１つとして, 緊急度が高いアラート通知*3には日頃からまずリアクションすることで, アラート通知は反応するべきものであるという認識を理解していくというものが上がりました.

しかし, このアクションを決めてから少し経って, アラートが発生しても結局何も変わらない自分にふと気づきました. 重要なアラート通知は把握している(と思っている*4 )ので, 重要ではない通知に何も反応せず気になった時に監視ルールを変更するだけの行動を意識では変えることができませんでした.

アラート通知に対して "いつもの(通知されるだけで対応の必要がないもの)" と呼ぶだけで何も行動しない監視ルールができてしまい, 監視の意図を把握しているひとだけが初動を取れるようなチームの状態であり, 加えて新規メンバーの割合の増加により知識の偏りが顕著になったと考えています.

チームのこの状況を改善するためにも, 監視とその運用体制を育てる施策の必要性を感じていました.

アラート当番を始めました

メンバーの育成と監視運用の仕組み化のために, 意識的に監視設定とアラートに向き合う場としてアラート当番という制度を作りました.

自分がアラート当番担当の期間に発生したアラートは, 緊急でないアラートも含めてすべてアラートが発生した原因を調査します. これはシステムや監視設定の把握と改善につなげるのが目的です *5 . 当番にすることによって, そのアラートは本当に必要だったのか, 監視ルールに改善点はないのかを特定の人に偏らせずに日常的に考える仕組みができました.

当番の交代時に自分の担当期間中に発生したアラートとその調査結果を共有することにしています. これで自分の知らなかった調査方法を知ることができたり, 調査に不足があれば必要な背景知識や他の調査方法のレクチャにつなげたりすることができます.

結果としては, 監視設定に今までより意識が向くようになったので, アラートの誤報が減りシステムの状態を改善することができました. アラート当番を始めた頃の調査ログを眺めてみると, 当時発生していた誤報や実は必要ではなかったアラートが, 今は必要な時にアラートがあがり対処方法がわかっている状態になりました.

アラート調査の責任者が明確になることで, 当番ではない期間は他のことに注力でき, 日頃からアラート通知や監視設定は適切なのか考える癖がつきました. また, システムへの理解も深まったと思います.

調査する上で, 監視やメトリックの不足が気になるようになり, mackerel-sql-metric-collector や cloudwatch-logs-aggregator, ラベル付きメトリックなどを利用した可観測性の改善も見られました*6

アラート当番の副作用

一方で, アラート当番の負担は当番期間中に発生したアラートの量や内容に依存し, 時にはそれなりに重い負担となることもあります.

徐々に誤報が減り, 障害を未然に防ぐためのアラートが増えてより良い状態になりつつありますが, 今も負担がなくなったわけではありません. その負担からそのうち "いつもの" として当番交代時の共有が行われてしまう *7 可能性もあります.

ここに対しては, 現状の監視ルール設定が理想的ではないことが主な原因と考えています. 理想の監視を実現するには Mackerel に機能が不足していると感じていて, Mackerel にとって対応すべきテーマとして議題に上げているので今後の開発に期待ですね.

監視ルールの設定は自信を持って行えるときだけではありません. このメトリックでよいのか, この閾値でよいのか, この duration でよいのかなど迷うことも多いです. 当番により定期的に確認される仕組みがあることで, 監視を設定してからの経過観察も組み込まれているため, 監視ルールをとりあえず設定してみるハードルを下げることにもつながっていると考えています.

どのような監視設定にするか迷って設定されないことよりも, 間違っていても設定して改善していくことのほうが運用やシステムにとってメリットが大きいでしょう.

また, アラートの原因調査を日常にするとより効果的な調査方法が欲しくなり, いずれアラート当番の負荷軽減や障害対応の初速改善につながると考えています.

アラートの状況を SRE 以外にも共有する

アラート当番は SRE 中心の施策ですが, アラート当番で確認した内容は SRE 以外にも定期的に共有しています.

監視運用は SRE だけではなく開発チーム全体で考えるべきだと思っていて, アラート当番の内容を SRE に閉じた情報にしたくなかったためです. 具体的には, アラート当番のうち共有するトピックがあるものについて, このような情報をテキストで共有しています.

なにが起きていたのか
なぜそれがおきていたのか
どのような対処を行ったのか
監視ルールをなぜそしてどのように変更したのか

監視を育てやすくする

監視を育てる仕組みを支えるものとして, IaC がとても役に立ちます.

Mackerel の監視ルールは Terraform Provider を利用してコード化することができます. コード化することでその監視ルールがなぜ必要なのかをテキストとして残し, 監視ルールの変更点についてプルリクエストで会話しそれも残すことができるというメリットがあります.

監視ルールを web コンソールで直接変更することは, 特に新メンバーには内容に妥当性があるか不安になることもあるものだと思うのですが, コードでレビューや会話を挟むことで, 安心して行えるものになったと考えています.

まとめ

監視を構築することと監視を育てることは別物であり, 監視を育てるには仕組みをつくることが重要です. また, 育てやすい状態にしておくとより実現しやすいのでおすすめです.

とはいえまだまだ道半ばなのでこれからも Mackerel の監視運用を改善していきます.

[PR] Mackerel Meetup #15 Tokyoを2023年12月19日（火）に開催します

「チームとコミュニティで監視を育てる」をテーマに、監視を育てるスタート地点でもあり、考え方でもある「SRE」の概念やその導入方法、具体的な実装について知ることのできるコンテンツを用意しています。Mackerelをお使いの方も、これから使い始めようという方も、明日から自分たちの監視やシステムを育てるヒントにしていただけたら幸いです。ぜひMackerelチームメンバーに会いに来てください！

詳細とご応募はこちらから！ Mackerel Meetup #15 Tokyo #mackerelio - connpass

明日の Mackerel Advent Calendar 2023 の担当は id:issan883 さんです