如何在运行漂移演变为事故之前将其检测出来
内容提要
文章讨论“运行漂移”：系统在某一时刻符合运行规范，但随时间推移可能偏离预期边界。它不同于配置漂移，即使配置未变，延迟上升、错误率恶化、副本减少或证据缺失也会造成漂移。作者主张以已知合规状态为基线，持续采集证据，用时间窗口而非单点样本判断，区分临时波动与持续退化，并显式建模稳定、退化、违规、未知四种状态，结合严重程度与持续性，保留证据，将检测与响应分离。
延伸解读
运行漂移与配置漂移：行为先于配置的失效信号
文章强调运行漂移不同于配置漂移：即使配置未变，延迟上升、错误率恶化、副本减少等行为变化也会导致系统偏离预期边界。这意味着生产故障往往先表现为行为异常，而非配置差异。因此，仅检查配置一致性不足以提前发现风险，需要持续观察运行证据，将行为趋势纳入监控范围。
用时间窗口和方向性趋势识别早期退化
单点样本容易受噪声干扰，文章建议用时间窗口平滑临时波动，并计算趋势斜率来捕捉持续移动。例如错误率从0.2%逐步升至0.8%，虽未超限但方向明确。这种方向性漂移能在阈值被突破前发出预警，为调查和干预争取时间，比传统阈值告警更早发现潜在问题。
显式建模未知状态，避免证据缺失被误判为稳定
文章将漂移状态分为稳定、退化、违规和未知四种，并强调证据缺失时应返回未知而非稳定。这一设计防止可观测性系统自身降级时产生虚假安全感。结合严重程度和持续性（如连续窗口数），可以区分短暂波动与需要干预的持续退化，为响应策略提供更细粒度的依据。
检测与响应分离：漂移信号不直接触发自动化
文章主张漂移检测只负责产生证据和分类，具体行动由策略决定。例如低严重度退化可观察，持续退化需调查，违规且关键才触发回滚。这种分离避免了过度自动化，尤其对于数据库迁移等高风险操作，保留人工判断空间，同时确保观察、评估、决策和执行各环节职责清晰。
Q&A
运行漂移和配置漂移有什么区别？
配置漂移关注声明配置与实际环境是否一致，例如期望副本数为3但实际只有2。运行漂移则关注系统行为是否仍在预期边界内，即使配置完全没变，延迟上升、错误率恶化、副本减少或证据缺失也会造成漂移。两者可能重叠，但运行漂移范围更广，且生产故障往往先表现为行为异常而非配置异常。
如何为运行漂移检测建立基线？
选择一个已知符合运行规范的时刻（如部署刚完成时），保存当时的证据快照作为基线。基线提供两个作用：确认系统当时满足规范，并作为后续观察的比较参考。后续证据不必与基线完全一致，而是从两方面评估：是否仍满足规范，以及相对基线如何变化。
为什么检测运行漂移要用时间窗口而不是单点样本？
生产系统有噪声，单次慢请求或临时尖峰不代表漂移。使用时间窗口（如最近5个延迟观测的平均值）可以平滑临时波动，并与早期窗口比较，判断整个信号是否发生偏移。窗口大小应依运营上下文而定，例如延迟用5分钟窗口，存储增长用1天窗口。
运行漂移检测中如何区分漂移和证据缺失？
证据缺失不应被视为稳定或违规，而应归类为UNKNOWN。例如延迟证据消失时，不能推断延迟稳定或超限，只能标记为未知。评估函数应优先检查基线或当前观测是否缺失，缺失则返回UNKNOWN，避免在证据不足时做出错误判断。
运行漂移检测结果如何指导响应动作？
根据漂移状态、严重程度和持续性决定响应：STABLE不动作；DEGRADING且低严重度则观察；DEGRADING且持续则调查；VIOLATED且警告则告警；VIOLATED且严重则回滚/修复/升级；UNKNOWN则收集证据或阻止高风险自动化。检测应产出证据和分类，策略决定允许的动作，保持检测与响应分离。
运行漂移检测有哪些局限性？
运行漂移检测不能自动告诉你系统变化的原因，它只是检测机制而非根因分析。此外，基线可能选错（如取自异常良好时期），导致正常行为被误判为退化。漂移质量依赖于良好的规范、证据、基线、窗口和规则。
