お客様より先に、問題に気付く

小さな構成に、広がる死角。 最初は数台のサーバーとログ解析のスクリプトだけでした。基盤が大きくなると規模にも複雑さにも追い付かず、何より、起きた後のことしかわからない仕組みでした。

上司もお客様も、監視ツールではありません。 問題が起きるまで、なぜ待つのでしょう。上司やお客様が最初に障害を知らせた時点で、運用は後手です。障害そのものに加え、社内外でチームへの信頼も損ないかねません。

典型例は、TLS証明書の期限切れ。 2000年には、今のような更新自動化はありませんでした。Let’s Encryptの登場はずっと後の2015年です。接続エラーで気付く前に、期限を監視する必要がありました。要件や発行元はさまざまで、自動更新も監視が必要です。

検知し、届け、記録を残す。 最初はNagiosとZabbixを選びました。異常を検知し、動ける人へ通知する必要があり、特に24時間365日のオンコールチームへ届けました。当時は費用の制約で高可用性構成ではなかったため、確実な検知と素早い対応が品質維持の要でした。監視自体が停止リスクをなくすわけではありません。年月とともにSMS、WhatsApp、PagerDutyも使いましたが、すべて2000年に使っていたという意味ではありません。

単発の障害から、傾向へ。 性能指標を残すことで、負荷、遅延、余力が時間とともにどう変わるか見られます。後にGrafanaとCheckmkも加わりました。悪化を早く見つけ、向かう先をデータで理解するという目的は変わりません。

変わらない考え方。 監視はダッシュボードを並べることだけではありません。誰かに問題を教わる前に、チームが動ける機会を作るものです。

当時の参考：Let’s Encryptの初の公開証明書発表（2015年）。