「監視業務ってつまらない？」— SREチームで"リソース監視の見直し"に取り組んで見えた景色

こんにちは。あるSaaSサービスのインフラ運用を担当している、エンジニアマネージャーの者です。

監視業務って地味だよね— この言葉、社内でも社外でもよく耳にします。私自身、SREとしてキャリアをスタートした頃は正直、監視は「当たり前に動いている裏方」としてしか捉えていませんでした。

ですが、ここ数ヶ月でリソース監視の設計を1から見直すプロジェクトに取り組む中で、その認識ががらっと変わりました。今回は、Wantedlyという場をお借りして、その3ヶ月の学びを共有します。

これから監視業務に関わるエンジニアの方や、社内で監視の設計を担当することになった方の参考になれば嬉しいです。

なぜ「見直す」ことになったのか

きっかけはシンプルで、アラートが多すぎて、本当に見るべきものが埋もれているという現場の声でした。

私たちのシステムは、この2〜3年でオンプレ中心の構成からAWS＋オンプレのハイブリッド構成へと大きく変わりました。監視ツールも、その過程で増えたクラウドサービスを毎回追加してきた結果、Slack通知が1日100件以上、そのうち本当に対応が必要なものは10件ほど、という状態に陥っていました。

アラート疲労という言葉があります。国内調査でも1日1,000件超のアラートを受信し、その多くが誤検知といった運用現場の実態が報告されているそうで、当時の私たちも例外ではありませんでした。

そこで、リソース監視の項目・しきい値・通知経路をゼロベースで整理し直すことになったのが、今回のプロジェクトの始まりです。

3ヶ月のプロジェクトで学んだこと

学び1: 「何を監視するか」より「どの粒度で監視するか」

見直しを始めた最初の週、私たちは「監視項目を追加する」議論ばかりしていました。ですが、本当に問題だったのは項目の「数」ではなく、「粒度」でした。

たとえばCPU使用率。80%を超えたらワーニング、90%を超えたらクリティカル…と設定していましたが、実際のインシデントを振り返ると、「1分間の瞬間値」で判定していたため、単発のスパイクにも過剰反応していたことが分かりました。5分間の移動平均で見るようにしただけで、誤検知は7割ほど減りました。

「監視は"項目"ではなく、"判定ロジック"で決まる」— これは今回の一番大きな学びです。

学び2: ツールを決める前に、体制を決める

もう一つの気づきは、ツール選定の議論を先行させてはいけない、ということでした。

当初、私たちは「PrometheusかDatadogか、それとも国産のMackerelか」という議論に多くの時間を費やしていました。ですが冷静に考えると、そもそも監視ツールを「誰が」「どの時間帯に」見るのかが決まっていない中でツールを選んでも、運用が回るはずがないんですよね。

チームで話した結果、「日中はSREチーム、夜間・休日は外部の監視パートナーに委託する」という体制方針を先に固めました。ツールはその体制に合うものを選ぶ、という順序に変えたことで、選定基準がぐっと明確になりました。

学び3: 監視は「予兆検知」の仕事だと捉え直す

以前の私は、監視を「障害を検知する仕事」だと思っていました。ですが、リソース監視の本質は「障害の予兆を捉える」ことにあります。

CPU／メモリ／ディスクといった基本リソースは、多くの場合、障害の前に必ず何かしらのサインを出しています。それを数分〜数時間前に検知して手を打つことができれば、そもそも停止に至らずに済みます。

「予兆を捕まえるための監視」だと捉え直した瞬間、監視業務が「地味な裏方」から「事業を守る前線」に変わって見えるようになりました。

参考にした記事

今回の見直しにあたって、私たちがチームで読み込んだ記事があります。

リソース監視の解説記事は、6つの監視項目、4つの実施方法、代表的な7つのツール比較、5ステップの導入プロセスまでが1つの記事に整理されており、社内の共通言語を作るのにとても役立ちました。特にツール7選（Zabbix／Prometheus／Nagios／Datadog／New Relic／Mackerel／CloudWatch）の適用シーンの整理は、私たちの選定議論の下敷きになっています。

書いているKaopizさんは24時間365日の監視代行サービスも提供されているようで、「自社で運用しきれない部分は外部に委託する」という私たちの体制方針とも親和性が高い記事だと感じました。同じテーマで社内議論を始める方には、たたき台としておすすめできます。

チームで大事にしていること

最後に、この3ヶ月のプロジェクトを通じて、私たちのSREチームで新しく共有した価値観を書いておきます。

• 監視は「設計」の仕事である。ツール選定はその後。
• アラートは「届ける相手」を意識する。誰も見ないアラートは、存在しないのと同じ。
• 予兆を捕まえた瞬間の達成感を、チームで共有する文化を作る。

監視業務は、外から見ると地味かもしれません。ですが、その裏で行われている設計の議論や、しきい値の細かな調整は、実は「事業を止めないための、とてもクリエイティブな仕事」だと今は思っています。

同じような役割に取り組まれている方の、何か1つでもヒントになれば幸いです。