在客户发现之前，先发现问题

小环境，越来越多的盲点。 最初只有少量服务器和分析日志的脚本。随着平台增长，这种方式既难以扩展，也难以应对复杂度。更重要的是，它是被动的：反映的是已经发生的事情。

老板和客户不是监控工具。 为什么要等故障发生后才发现？如果最先报告问题的是管理者或客户，运维响应就已经晚了一步。故障之外，团队在公司内部和客户心中的信任也会受影响。

典型例子：即将到期的 TLS 证书。 2000 年还没有今天这样的自动续期工具，Let’s Encrypt 到 2015 年才出现。我们需要提前监控证书到期时间，而不是等连接失败才发现。即使后来使用了自动续期，证书要求和签发机构可能各不相同，监控仍然不可少。

发现、通知并保留数据。 最初我们选择了 Nagios 和 Zabbix。检查要能发现问题，告警也必须送达有能力处理问题的人，尤其是全天候待命的 24/7 值班响应团队。当时出于成本考虑，网站还没有高可用架构，及时发现和快速响应就格外重要。当然，监控本身不能消除停机风险。后来，通知渠道逐渐包括短信、WhatsApp 和 PagerDuty，并不是说这些工具在 2000 年就已全部使用。

从单次告警到趋势。 记录性能指标，可以研究负载、延迟和可用容量如何随时间变化，而不仅是看一个告警。后来，Grafana 和 Checkmk 也加入工具集。目标始终是更早发现恶化，并用数据理解系统的发展方向。

不变的原则。 监控不仅是一组仪表盘。它应该让团队有机会在别人必须指出问题之前采取行动。

历史来源：Let’s Encrypt 首个公开证书公告（2015 年）。