
不通过可观测性扩展系统的经验教训
|
39
假阴性和毫无意义的噪声。告警已转向触发告警较少的模式,仅关注直接影响用户
体验的症状。
•
调试器已经不能再附加到一个特定的运行时上了。一次服务请求现在需要跨越网络,
跨越多个运行时,通常还会引起多次请求。
•
需要手动补救,且可以在运维手册中定义的已知重复性故障不再是常态。故障处理
模式开始转变为可以自动恢复已知重复性故障的模式。无法自动恢复并因此触发告
警的故障可能意味着工程师将面临一个新问题。
这些三级信号意味着,焦点正在发生巨大的引力转移,从前期生产的重要性转移到熟悉
生产的重要性。传统上,在代码投入生产之前强化代码并确保其安全性的做法开始被认
为是限制性的,有些甚至是徒劳的。测试驱动开发和针对预发环境运行测试仍然有用。
但它们永远无法复现该代码在生产中使用时的疯狂和不可预测的性质。
作为开发人员,我们都有一个固定数量的周期来完成我们的工作。传统方法的局限性在
于,它首先关注预生产硬化。任何注意力的剩余部分,如果存在的话,都会集中在生产
系统上。如果我们想在生产中建立可靠的服务,就必须扭转这种顺序。
在现代系统中,我们必须首先将大部分的注意力和工具集中在生产系统上,剩余的注意
力应用于模拟系统和预生产系统。预发系统很有价值,但它本质上是次要的。
预发系统不是生产系统。它们永远无法复现生产中发生的事情。预生产系统的无菌实验
室环境永远无法模拟你服务的真实付费用户在现实世界中测试代码的相同条件。然而,
许多团队仍然将生产视为一座“易碎的玻璃城堡”。
工程团队必须认识到生产系统的价值并调整优先级,继而做出相应的改变 ...