顧客サイトの死活監視は自動化する

📞「電話で気づく」がいちばん遅い

サイトの異常を最初に見つけるのが「お客さん」だと、気づいた時点でもう手遅れです。順番を逆にしたい。

サイトが落ちたとき、誰が最初に気づくか。ここが監視の設計のすべてです。 いちばん避けたいのは、お客さん（あるいはそのお客さんのお客さん）が最初に気づく形。電話が鳴って初めて知る、というのは、対応として最も遅い入り口です。

目指すのは逆です。お客さんが気づく前に、こちらが気づいて、 できれば連絡が来る前に直しはじめている。この順番を作れるかどうかが、 預かる側の信頼を左右します。そのために、人ではなく機械に見張らせます。

🤖機械が定期で見て、異常だけ人に上げる

監視の肝は「毎回知らせない」こと。正常なときは黙り、おかしいときだけ人を呼ぶ。ここを守らないと通知に慣れて麻痺します。

やっていることはシンプルです。機械が一定間隔でサイトを見に行き、正常に開けるかを確かめる。開けなければ、そのときだけ人に知らせる。これだけです。

大事なのは、正常なときは何も言わせないこと。毎回「生きています」と通知が来ると、人はすぐ慣れて、 本当に大事な一通を見逃します。異常のときだけ声を上げる—— 監視の世界でも、通知は「必要なときだけ・人が動ける形で」出すのが基本とされています（Google の SRE 本 “Monitoring Distributed Systems”）。私たちの監視も、この考え方に寄せています。

私たちは自社の運営そのものを AI に任せていて、 社内向けにも「機械が定期で回って、変なときだけ知らせてくる」小さな見張り役を いくつも走らせています。顧客サイトの死活監視も、発想はまったく同じです。 特別な話ではなく、日常の道具を横に伸ばしているだけです。

🔎「開いた」と「ちゃんと開いた」は別物

ページが返ってきても、中身が白紙かもしれない。監視は「反応があるか」だけでなく「まともな中身か」まで見たい。

監視でつまずきやすいのが、「反応があった＝正常」と早合点することです。 サーバーは生きていて反応は返すのに、中身は真っ白、あるいはエラーの文字だけ、 ということは起こります。反応があることと、お客さんが見たときにちゃんと成り立っていることは、別物です。

なので、ただ「つながるか」を見るだけでなく、 トップページに本来あるはずの言葉が入っているか、といった中身の手がかりまで見るようにしています。空っぽの応答を「正常」と数えない。 これは AI 運営でも痛い目を見て学んだことで、 「出力が空なのに 0 件と決めつけない」という戒めと、根っこは同じです。

もう一つ、見落としがちなのが証明書の期限切れです。サイトの中身は元気なのに、通信を守るための証明書が切れると、 ブラウザが「このサイトは危険かもしれません」と警告を出します。 お客さんから見れば、実質「開けない」のと同じ。しかも、ある日を境に いきなり起こります。だから私たちは、生死だけでなく期限が近づいているものを、切れる前に知らせる対象にも入れています。落ちてから気づくより、切れる前に手を打つ方がずっと楽です。

🧯誤報が多い監視は、いずれ無視される

一瞬のつまずきで毎回呼ばれると、人は通知を切ります。だから「続けて何回かダメなら鳴らす」くらいの余白を持たせます。

監視でいちばん怖いのは、じつは見落としより誤報かもしれません。ネットワークが一瞬ゆらいだだけで「落ちた!」と鳴ると、 人はやがてその通知を無視するようになります。オオカミ少年です。

だから、一度の失敗で即座に人を叩き起こすのではなく、続けて何回か確かめてもダメなら鳴らすくらいの余白を持たせます。監視は「敏感すぎず・鈍すぎず」の調整が肝で、 ここのさじ加減が、通知を信じてもらえるかどうかを決めます。 信じられない通知は、無いのと同じです。

🧭これから監視を持ちたい人へ

最初から立派な仕組みは要りません。「落ちたら自分がいちばんに気づく」——この一点だけ、まず機械に持たせてください。

もし今、サイトの生死を人の気合いで見張っているなら、 まず一つだけ機械に持たせてみてください。落ちたときに、自分がいちばん先に気づく仕組みです。凝った作りは要りません。定期的に見に行って、開けなければ知らせる。 それだけで、対応の入り口が「電話」から「通知」に変わります。

そのうえで、正常時は黙らせる、中身まで軽く確かめる、誤報に余白を持たせる。 この三つを足していけば、監視は「気にし続ける負担」から 「気にしなくていい安心」に変わっていきます。

あなたが預かっているサイトは、落ちたとき、誰が最初に気づきますか。 その答えが「お客さん」なら——今日、順番を入れ替える準備を始めてみてください。