北京
一次部署从执行器角度看可以顺利完成，却依然违反运维契约。一次修复操作可以完成所有计划动作，却把系统留在可接受范围之外。一次恢复操作可以无错结束，却没能恢复所需数据。
这就是为什么一个笼统的状态——success = true——远远不够。我们需要一种方式，把"本应发生什么"和"实际观察到什么"放在一起比较，产出一个明确、可解释、有用的结果。这就是合规性问题。
合规不是执行器说了算
在日常语言里，合规意味着遵守某条规则、标准或要求。在这里，这个词有更具体的含义：运维合规，是评估观察到的执行证据是否、以及在何处满足了运维规格所定义的要求。
证据，是从系统中收集到的、可与规格比对的可观察事实集合。它不是成功判决，而是用来产出判决的数据。这个定义包含三个部分：规格定义"应该为真"的内容，证据描述"实际观察到"的内容，评估则把证据与规格做比对。
所以合规不是执行器的属性，而是证据与规格比对后的结果。概念上就是：规格加证据，经过合规评估，得到结果。
从布尔值到逐条约束
假设有一份部署规格：版本为 v42，最少副本数为 3，最大错误率为 0.01，最大 P95 延迟为 400 毫秒。对应的证据是：版本 v42，副本数 3，错误率 0.004，P95 延迟 280 毫秒。
最简单的评估器可能返回一个布尔值。这能跑通，但有个问题：如果结果是 false，你不知道为什么。这对运维工作来说不够用。
更好的做法是逐条评估约束，而不是压成一个布尔值。给每个检查一个名字和一个布尔结果，一次比对一项观察值与规格中对应的规则。检查部署版本是否精确匹配，副本数是否足够，错误率和延迟是否低于上限。
这样输出就能变成：版本通过、副本通过、错误率通过、延迟通过；或者版本通过、副本失败、错误率通过、延迟失败。一次失败的操作变得可解释。
别把一切都压成通过或失败
二元评估有时还是太简单。假设规格要求错误率不超过 1%，但你的可观测性系统不可用。结果应该是什么？
判为通过显然是错的。判为失败也可能误导，因为它混淆了两种不同情况：系统违反了约束，以及我们不知道系统是否违反了约束。
这两种情况需要被区分开。一个更好的模型，应当允许第三种结果存在——未知。当证据缺失时，诚实地标记为未知，比强行给出一个通过或失败更有价值。
同样的思路适用于基础设施变更、事件响应、备份恢复、数据管道，以及由 AI 操作的系统。核心始终是：合规不是执行器是否声称成功，而是观察到的证据是否满足运维规格。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
