【クラウドネイティブ会議】最高のアラート通知とは何か ―― ノイズを減らし、対応につながる監視運用を考える

夜中にアラートで起こされたものの、確認すると一瞬だけ閾値を超えただけで、すでに自然回復していた。あるいは、Slackに大量のアラート通知やエラー通知が流れ続け、どこから手を付ければよいかわからない。このような通知疲れを減らすには「何を監視」し「誰に」「どのように届ける」べきなのか。クラウドネイティブ会議に登壇した株式会社フライルのソフトウェアエンジニア、髙石諒氏が、通知手法の変遷と自社での実践を振り返り、「通知再考 ～最高のアラート通知を今改めて考える～」と題して、改善の指針を示した。

3つの通知タイプから監視メソッドの変遷を振り返る

髙石諒氏はまず、通知を大きく3つのタイプに整理した。1つ目は「Event-based」である。例外やスタックトレース、ログなど、1つのイベントに対して1つの通知を発生させ、主にコードの異常を検知する。

通知には3タイプありそう

2つ目は「Metric-based」である。CPU使用率、メモリ使用量、エラー率などの時系列データが閾値を超えた場合に通知し、リソースやサービスの異常把握に利用する。そして3つ目は「Symptom-based」である。システム内部の状態ではなく、ユーザーが体験する症状を基準に通知を発生させる。SLO ^※バーンレートなどが例であり、個々のメトリクスだけでは見えにくいユーザーの困りごとを検知する。

SLO：Service Level Objective、サービスレベル目標
提供されるサービスが達成すべき目標値

「通知は大きく、コードの異常に気付きたいEvent-based、リソースやサービスの異常に気付きたいMetric-based、そしてユーザーの困りごとに気付きたいSymptom-basedの3種類に整理できます」と髙石氏は説明する。

続いて、通知の前提となる監視手法の系譜が紹介された。2010年ごろまでは、外形監視や死活監視、メトリクスに対するOK、WARNING、CRITICALといった判定が中心であった。

2012年には、Brendan Gregg氏がリソース指向のUSE Methodを提唱した。Utilization（利用率）、Saturation（飽和）、Errors（エラー）の観点から、サーバーなどの状態を確認する手法である。2016年には、GoogleのSRE BookでLatency、Traffic、Errors、Saturationを見るFour Golden Signalsが示された。

2018年には、Tom Wilkie氏によるサービス指向のRED Methodが登場した。Rate（単位時間あたりに処理できたリクエスト数）、Errors（失敗したリクエスト数）、Duration（リクエスト処理時間）を確認する手法である。同年には、時間軸を加味してエラーバジェットの消費速度を判断するSLOバーンレートも示された。近年ではSLOの設定や維持に伴う負担を踏まえ、SLOそのものを再考する動きも現れている。

通知先も、Emailやポケベル、任意のスクリプトから、PagerDutyなどのオンコールSaaSへと発展した。Severity、ローテーション、エスカレーションをサービス上で管理でき、SMSや電話、スマートフォンアプリのプッシュ通知も利用できる。

業務チャットでは、IRCからSlackやMicrosoft Teamsへと移行し、Hubotの登場によってChatOpsも定着した。近年では、AIOpsやLLMを通知の前後で活用し、トリアージする仕組みも登場している。

ただし新しい手法は古い手法を完全に置き換えるわけではない。死活監視が現在も必要なシステムはある一方、すべてのサーバーに一律でCPU使用率のアラートを設定するような運用は減っている。「自分たちのシステムで何を使うかは文脈次第です。各プラクティスやメソッドが何を目的としているのかを理解して採用することが重要です」と髙石氏は最初の章をまとめた。

サービスと組織の成長で複雑化する通知の難しさ

次に髙石氏は、フライルにおける通知の変遷を紹介した。フライルは、顧客から寄せられる膨大なフィードバックを分類・要約し、プロダクトやサービスの改善につなげるSaaSを開発している。

創業した2020年当時は、AWSのCloudWatch LogsからSlackへエラーを送る、素朴な通知の仕組みから始まった。髙石氏が入社した2023年には、1つのSlackチャンネルに多くの通知が集まり、どの通知から対応すべきかわかりにくい状態になっていたという。

そこでSLOの導入が検討されたが、当時は見送られた。2024年にはDatadogを導入し、監視対象のメトリクスを増やすとともに、コンポーネントごとにSlackの通知チャンネルを分割した。2025年にはマルチプロダクト化に合わせ、緊急度ごとのチャンネル整備も進めている。

flyleの通知史

サービスが成長すると、コンポーネントが増え、通知先も増える。組織が拡大してチームが分かれれば、通知先の追加や分割も必要になる。また、新しい監視メソッドを導入しても、既存の閾値ベースの監視をすぐに廃止できるとは限らず、複数の仕組みが並走する。

SLOを導入しなかった理由は、当時のプロダクトと組織の流動性にあった。SLOを維持し、その値を見ながら判断するよりも、システムの情報を多く持つ人が直接判断した方が速かったのである。小規模な組織では他の優先事項も多く、監視や通知のメンテナンスに十分な時間を割けなかった。「プロダクトと組織の流動性を考えると、当時は人間が判断する方がよかったと思います。SLOベースで判断する仕組みを作るコストも大きく、メンテナンスの余裕もありませんでした」と髙石氏は説明する。

当時、本当に必要だったのは、アプリケーションエラー発生時の判断の迅速化であった。インフラの異常よりもアプリケーションエラーの方が多く、システム全体のどこで、どのような問題が起きているのかを把握する必要があった。そのため、スタックトレースをすぐ確認できることや、通知先をコンポーネントごとに分けることが優先された。

一方、アプリケーションエラーの通知には固有の難しさがある。まず、正常と異常の境界が曖昧である。404 Not Foundは単発なら正常な場合もあるが、特定のURLで頻発していれば不具合の可能性がある。

同じTimeout Errorでも、情報取得APIであれば影響は軽いが、決済APIで発生すれば重大である。さらに、リリースのたびに新しい例外が現れ、担当者が詳しくない領域から発生したエラーでは、調査自体が難しくなる。

このように、通知の適切な形は技術的な新しさだけでは決められない。対象となるシステム、組織規模、運用の成熟度に合わせて選ぶ必要がある。

動ける通知を育て、時間をかけて改善を続ける

通知を改善する上で、髙石氏が最初に示した指針は「動ける通知がいい通知」である。

通知を受け取っても、何が起きたのかわからず、調査方法も不明であれば対応にはつながらない。通知そのものだけでなく、対応手順をまとめたRunbook、状況を確認するダッシュボード、原因調査を支えるObservabilityなども整備する必要がある。「通知が来たときに、受け取った人が何をすればよいかわかる状態を作ることが大事です」と髙石氏は語る。

重要なのは、通知を設計した人ではなく、実際に受け取る人が活用できるかという点である。高度なSLOやエラーレートを使った仕組みでも、開発チームやオンコール担当者が意味を理解できなければ機能しない。

新しい仕組みを導入する場合には、その効果や活用方法を共有し、チームの足並みをそろえる必要がある。髙石氏は、利用者が本当に必要とするものを作るという観点から、監視や通知も1つのプロダクトとして捉えられると指摘した。

また、監視・通知は一度設定して終わるものではない。運用しながら適切な状態へ近づける「育てる運用」が必要である。

学習・改善の駆動エンジン2つ

そのためには、2つの改善ループを回す。1つは通知の発生履歴を定期的に見直し、繰り返し発生しているが対応不要な通知などのノイズを減らすループである。そしてもう1つが、インシデント後のポストモーテム（振り返り）を起点に、「必要な通知がなかった」「通知が遅かった」「情報が不足していた」といった検知漏れを確認し、監視や通知を追加するループである。不要な通知を減らし、不足する通知を補うことで、より現場に適した状態へ育てていく。

ただし、通知改善に特効薬はない。新しい監視手法、オンコールSaaS、AIによるトリアージなどを一気に導入しても、組織が使いこなせなければ、かえって運用が複雑になる。「一気にやりすぎるのは逆効果かもしれません。足並みをそろえながら、時間をかけて変化を加え続けることが大事です」と髙石氏は強調した。

セッションの最後に髙石氏は、通知にはEvent-based、Metric-based、Symptom-basedの3タイプがあり、どの手法を採用するかは、対象となるシステム、組織規模、成熟度によって異なるとまとめた。

その上で、通知改善に向けた3つの指針として「動ける通知がいい通知」「監視・通知を育てる」「時間をかける」を提示した。通知の数や仕組みを増やすことではなく、受け取った人が行動でき、運用から学びながら少しずつ改善することが重要なのである。