监控是拐杖，不能替代修复系统本身

面对一个反复出故障的服务（例如代码质量差、难以理解的遗留应用），团队常见的直觉反应是不断叠加更多监控，这看似是在”加强防护”，实际上对解决根本问题几乎没有帮助。监控的作用始终只是提醒你注意到问题的存在，而不是解决问题本身；如果持续依赖增加监控来应对一个本质不稳定的服务，正确的应对是停下来，把精力转向提升该服务自身的稳定性与弹性，而不是继续投入监控这一”拐杖”。发散：这是”用可观测性掩盖脆弱性”的陷阱——看得更清楚不等于问题变少，团队需要警惕把监控投入当成工程投入的替代品。