たとえば、夜中に「ディスク使用率が80%を超えました」という通知が鳴ったとします。朝に確認すると、業務には何の影響もなかったとします。こういう通知が週に何度か続くと、人は通知を見なくなります。そして本当に止まった日に、その通知も同じように流されてしまいます。

少人数の運用チームにとって、監視の敵は「見逃し」と同じくらい「鳴りすぎ」です。担当が1〜2人なら、全部を拾う設計は続きません。この記事では、監視のやり方を3つに分けて比べ、読み手が抱きそうな問いに順に答えます。結論を先に言うと、通知の基準は「サーバの数値」ではなく「利用者が困っているか」に置くのが、小さなチームには向いていると考えています。

3つのやり方を、4つの軸で比べる

まず比べる軸を決めます。小さなチームで効いてくるのは、次の4つです。

比べる対象は3つです。Aは、死活・外形監視だけのやり方です。応答があるか、画面が開くかを定期的に確かめます。Bは、機器の数値にしきい値を置くやり方です。CPU、メモリ、ディスクなどが一定を超えたら通知します。Cは、利用者の症状を基準に通知するやり方です。主要な操作が通るかを見て、機器の数値は記録して画面で見るだけにします。

やり方手間見逃しにくさ誤報の少なさ原因の絞りやすさ
A：死活・外形だけ小さい中（動いているが遅い、一部の機能だけ壊れている、は見逃す）高い低い（止まったことしか分からない）
B：機器の数値にしきい値大きい（しきい値の調整が続く）中（数値が正常でも壊れることがある）低い（鳴りすぎやすい）中
C：利用者の症状で通知、数値は見るだけ中（最初に操作の流れを決める必要がある）高い高い中（数値の画面を見て絞る）

表のとおり、どれも一長一短です。Aは楽ですが、「ログインはできるのに保存で失敗する」といった半分壊れた状態に気づけません。Bは直感的ですが、しきい値は環境が変わるたびに合わなくなります。調整を続ける人手がないチームでは、そのうち誰も触らない古い設定が残ります。Cは最初に少し考える手間がありますが、鳴る回数が少なく、鳴ったときは本当に困っている可能性が高い形です。

読み手が抱きそうな4つの問いに答える

問い1：結局、何を測ればよいですか

測るものは、3つの層に分けると整理できます。

1つ目は、利用者の操作が通るかです。たとえば、社内向けの業務システムなら「ログインできる」「主要な画面が表示される」「保存できる」の3つです。メールやファイル共有なら、送受信やアップロードが成功するかを定期的に試します。ここが監視の中心です。

2つ目は、放っておくと時間切れになるものです。証明書の期限、ドメインの期限、ディスクの空き容量、バックアップの成否が当てはまります。これらは突然壊れるのではなく、静かに期限が近づきます。人間が忘れやすいので、機械に見張らせる価値が大きい対象です。

3つ目は、原因を調べるための数値です。CPU、メモリ、ネットワーク量、プロセスの数などです。これらは取っておく価値がありますが、通知の条件にはしません。障害のあとに「何が起きていたか」を振り返る材料として、記録だけ残します。

問い2：何を知らせるべきですか

判断の基準は1つです。「いま起こされて、その場でやることがあるか」を考えます。やることがあるものだけを、すぐ届く通知にします。

通知は2段に分けるのがおすすめです。1段目は、すぐに人を呼ぶ通知です。主要な操作が連続して失敗しているときなどが当てはまります。2段目は、1日1回のまとめです。バックアップが1回失敗した、証明書の期限が30日を切った、といった「今日中か今週中に直せばよい」ものを入れます。

ディスクのように数値で見る対象は、使用率より「このままだと何日で埋まるか」で知らせるほうが役に立ちます。使用率85%でも、増え方がゆっくりなら半年は余裕があります。逆に使用率60%でも、急に増えていれば数日で埋まるかもしれません。残り日数が数日になったら1段目、2週間を切ったら2段目、というように分けます。

問い3：あえて知らせないものは何ですか

知らせないものを先に決めておくと、通知の質が安定します。数分で収まるCPUやメモリの一時的な上昇は、通知にしません。再試行で自動的に戻った失敗も同じです。1回だけの失敗も通知にせず、たとえば3回連続で失敗したときだけ知らせます。夜中に対応しても結果が変わらないもの、たとえば翌朝の対応で済む社内向けの機能も、夜間は鳴らさないほうが賢明です。

ここで注意したいのは、「知らせない」と「消す」は別だということです。通知はしなくても、記録は残します。あとから「実は前の週から何度か失敗していた」と気づけるからです。見えなくしてよいのは通知であって、データではありません。

もう1つあります。受け取っても最初に何をすればよいか書かれていない通知は、やめる候補です。対応の手順が思いつかない通知は、受け取った人を不安にさせるだけです。手順を書けないなら、その通知は条件が粗いか、そもそも不要かのどちらかです。

問い4：少人数でも続けるには、何を決めておけばよいですか

続けるために決めておきたいことは3つあります。

1つ目は、通知の受け手と当番です。2人のチームなら、通知先を1か所にまとめて、誰が最初に見るかを週ごとに決めます。全員に同じ通知が飛ぶと、「誰かが見るだろう」という状態になりがちです。

2つ目は、通知ごとに「最初の一手」を1行だけ書いておくことです。たとえば「ログイン失敗の連続：まず認証基盤の状態画面を確認し、変化がなければ再起動の手順書を開く」のような書き方です。長い手順書は要りません。深夜に寝ぼけた頭で最初の動きが決まれば足ります。

3つ目は、定期的な棚卸しです。月に1回、「鳴ったが何もしなかった通知」を数えます。それが複数あれば、条件を緩めるか、2段目のまとめに移すか、通知をやめます。逆に、通知が来なかった障害があれば、その症状を見る項目を足します。この見直しを続けるだけで、監視はチームの実態に合っていきます。

加えて、監視そのものが止まったときの備えも必要です。監視が止まると、通知は静かになります。静かなのは平和だからなのか、壊れているからなのか区別できません。そこで、監視の仕組みが生きていることを別の経路で毎日知らせる仕組みを1つ置きます。「今日も監視は動いています」という通知が来なくなったら異常、と考えます。

どんなときにどれを選ぶか

最後に、3つのやり方の選び方です。

Aを選ぶのは、まず今日から最低限の守りが欲しいときです。サービスが数個で、担当がほかの業務と兼務なら、外形監視だけでも「止まったのに誰も気づかなかった」という最悪の状態は避けられます。ただし、Aは出発点と考えたほうがよいです。半分壊れた状態には弱いので、いずれ主要な操作を試す項目を足すことになります。

Bを選ぶのは、機器の数が限られていて、数値の傾向をよく知っているときです。たとえば、物理機器の温度や容量のように、数値そのものが障害の直接の原因になる対象には向いています。ただし、しきい値を保つ人手がなければ、鳴りすぎる通知か、誰も直さない古い設定になりやすいです。使うなら対象を絞り、2段目のまとめに寄せるのが無難です。

Cを選ぶのは、人手が少なく、夜中に起こされる回数を減らしたいときです。たとえば、情シスが2人で、社員が数十人から百人ほどの会社だとします。利用者が困るのは「ログインできない」「保存できない」「メールが届かない」といった症状です。そこを見張り、数値は記録に回す形なら、通知の数は少なく、鳴ったときの意味が明確になります。少人数の運用ではCを基本にして、Aを土台に敷き、Bの一部（ディスクの残り日数など、期限があるもの）を足す組み合わせが現実的だと考えています。

始めるときは、全部を一度に作らないほうがうまくいきます。まず、主要な操作を3つ決めます。次に、それが連続して失敗したときだけ通知します。そのうえで、期限があるものを1日1回のまとめに入れます。ここまでで、通知の数は大きく減ります。あとは月1回の棚卸しで、少しずつ磨いていけば十分です。