可执行的操作规范如何使软件自动化过程具备可验证性

以一个部署脚本为例来说：

这告诉Kubernetes应该如何执行某个操作，但并没有完全解释为什么这个操作是可行的。

其实，这种操作意图更类似于以下内容：

部署版本为2026.09.19的Orders服务。

约束条件：
- 生产环境至少需要保留3个可用的副本
- 错误率必须低于1%
- p95延迟时间必须低于400毫秒
- 该部署只能在us-east-1地区进行
- 在30分钟内必须能够执行回滚操作

命令与操作意图是相关的，但它们并不是完全相同的概念。

这种区分很重要，因为不同的执行器可能都能实现同样的操作意图。

例如：

Kubernetes
Nomad
一种云部署服务
一个自定义的部署控制器
一个由人工智能驱动的平台

如果操作目标被独立地表述出来，那么相应的执行器就可以被替换掉。

但如果目标被嵌入到特定于某个执行器的代码中，那么更换执行器可能意味着需要重新确定原来的操作意图。

什么是可执行的操作规范？

可执行的操作规范是一种机器能够理解的描述，用于说明具体的操作目标，并且可以根据实际观察到的结果来评估这些目标的实现情况。

至少来说，这样的规范应该能回答以下问题：

我们想要达成什么目标？
需要遵守哪些约束条件？
应该收集哪些证据？
如何判断操作是否达到了预期效果？

例如：

operation: deploy-orders-service

target:
  service: orders
  version: 2026.09.19
  environment: production

constraints:
  minAvailableReplicas: 3
  maxErrorRate: 0.01
  maxP95LatencyMs: 400
  region: us-east-1

evidence:
  - deployedVersion
  - availableReplicas
  - errorRate
  - p95Latency
  - region

这里的示例故意设计得比较简单，因为真正重要的是规范的内容本身，而不是YAML语法。

关键在于，这种规范能够独立于具体的部署机制来定义成功的标准。

这样一来，我们就得到了如下这样的结构：

操作意图
        ↓
操作规范
        ↓
执行器
        ↓
执行过程
        ↓
收集的证据
        ↓
评估结果

这种规范就成为了一个稳定的参考依据。

一个简单的部署示例

假设我们想要部署版本为2026.09.19的Orders服务。

只有满足以下条件，操作才能成功：

运行的是正确的版本
至少有3个副本可用
错误率低于1%
p95延迟时间低于400毫秒

我们可以用代码来表达这些要求：

type DeploymentSpec = {
  service: string;
  version: string;
  minAvailableReplicas: number;
  maxErrorRate: number;
  maxP95LatencyMs: number;
};

例如：

const spec: DeploymentSpec = {
  service: "orders",
  version: "2026.09.19",
  minAvailableReplicas: 3,
  maxErrorRate: 0.01,
  maxP95LatencyMs: 400,
};

现在假设执行过程产生了相应的证据：

type DeploymentEvidence = {
  deployedVersion: string;
  availableReplicas: number;
  errorRate: number;
  p95LatencyMs: number;
};

例如：

const evidence: DeploymentEvidence = {
  deployedVersion: "2026.09.19",
  availableReplicas: 3,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

我们可以根据这些证据来评估执行结果是否符合规范要求：

function conforms(
  spec: DeploymentSpec,
  evidence: DeploymentEvidence
): boolean {
  return (
    evidence.deployedVersion ===
      spec.version && &
    evidence.availableReplicas >=
      spec.minAvailableReplicas && &
    evidence.errorRate <=
      spec.maxErrorRate && &
    evidence.p95LatencyMs <=
      spec.maxP95LatencyMs
  );
}

那么：

console.log(
  conforms(spec, evidence)
);

将会得到如下结果：

true

现在假设流程在技术上来说是成功的，但只有两个副本仍然可用：

const evidence: DeploymentEvidence = {
  deployedVersion: "2026.09.19",
  availableReplicas: 2,
  errorRate: 0.004,
  p95LatencyMs: 280,
};

执行器仍然可能会报告“成功”结果。

但根据规范要求，这个结果是不合格的：

conforms → false

这就是我们想要区分的地方。

将成功标准转化为证据要求

只有当规范的各项要求能够被验证时，它才具有实际意义。

错误率必须保持在1%以下

至少要有3个副本处于可用状态

每一个操作性要求都应当对应某种可被观察到的证据。

这种关系非常重要，因为模糊的操作目标很难被安全地自动化处理。

请考虑以下情况：

安全地进行部署。

有什么证据能够证明这一点呢？

这个表述实在太含糊不清了。

一个更明确的规范应该将“安全地”这一要求分解成一些可以被验证的条件。

为什么仅依靠可观测性是不够的

此时你可能会问：

这不就是所谓的可观测性吗？

并不完全是这样。可观测性有助于回答的是：

到底发生了什么？

而规范则有助于回答：

应该发生什么才对？

这些都是互补性的问题。

一个仪表盘可能会显示如下数据：

错误率 = 1.4%

这只是一种观察结果而已。

但是，是否可以接受1.4%这个数值，取决于预先设定的预期标准。

规范中可能会明确写明：

最大错误率 = 1%

现在你就可以进行评估了：

实际观测值：1.4%
预期值：≤ 1%

结果：不符合要求

如果没有预期的标准，这些数据仅仅只是一个数字而已；而没有这些数据，规范本身也就无法被验证。两者缺一不可。

从概念上来说：

规范
     +
观测结果
     ↓
评估

规范使自动化过程可被验证

如果没有独立的规范，自动化过程就很难被验证。

以这样一个脚本为例，它执行的任务包括：

扩展服务规模
重启容器
更改路由设置
等待完成
结束操作

如果预期结果也是通过这个脚本来设定的，那么要判断它是否运行正确就会陷入循环论证的境地。

实际上你就是在问：

自动化系统是否真的完成了它应该完成的任务？

而一个独立的规范就能为你提供另一个参考点。

现在你可以这样提问：

最初的目标是什么？
执行者实际做了什么？
执行过程产生了哪些结果？
这些结果是否符合规范的要求？

这样做可以让操作流程更便于审计和测试，也能让出现的故障提供更多有用的信息。

而不是仅仅看到：

部署失败

而是可以这样描述：
保持规范与执行器的独立性
这种模型最显著的特点之一就是规范与执行器之间的独立性。
假设规范中明确写明了：
部署规范版本 2026.09.19

需满足以下要求：
- 复制数量 >= 3个
- 错误率 <= 1%
- p95延迟时间 <= 400毫秒
某个执行器可能会使用Kubernetes，另一个执行器可能会使用托管型云平台，还有的执行器可能会使用自定义的调度工具。
仅仅因为执行器的类型发生了变化，并不意味着规范本身也需要进行修改。
从概念上来说：
                 ┌── Kubernetes执行器
规范         ───┼── 云执行器
                 ├── 自定义执行器
                 └── AI智能体
每个执行器都会生成相应的执行结果，每次执行操作都会根据相同的预期目标来进行评估。
这种区分方式非常有用：
预期的操作结果应该是怎样的
与：
一个最小的TypeScript模型
一个简单的通用模型可能如下所示：
type Constraint = {
  name: string;
  evaluate(evidence: T): boolean;
};

type OperationalSpec = {
  name: string;
  constraints: Constraint[];
};

type Evidence = {
  version: string;
  replicas: number;
  errorRate: number;
};

你可以这样定义这些类型：
const deploymentSpec: OperationalSpec = {
  name: "deploy-orders",
  constraints: [
    {
      name: "correct-version",
      evaluate: (evidence) => evidence.version === "2026.09.19",
    },
    {
      name: "minimum-replicas",
      evaluate: (evidence) => evidence.replicas >= 3,
    },
    {
      name: "error-rate",
      evaluate: (evidence) => evidence.errorRate <= 0.01,
    },
  ],
};

function evaluate(spec: OperationalSpec, evidence: T) {
  return specconstraints.map((constraint) => ({
    constraint: constraint.name,
    passed: constraint.evaluate(evidence),
  }));
}

const evidence: Evidence = {
  version: "2026.09.19",
  replicas: 2,
  errorRate: 0.003,
};

result: [
  { constraint: "correct-version", passed: true },
  { constraint: "minimum-replicas", passed: false },
  { constraint: "error-rate", passed: true }
];

这样的结果比简单的“成功”或“失败”标志要有用得多，因为它能清楚地告诉你哪些操作环节没有达到预期要求。
这一概念在CI/CD中的应用
CI/CD系统本身就已经包含了一些声明性元素。
例如：
steps:
  - test
  - build
  - deploy

但这些步骤主要只是描述了执行的顺序。而规范文件则可以进一步明确这些操作所应满足的条件。
例如：
部署目标：
发布X版本

约束条件：
测试通过
生成的代码与已批准的构建结果一致
至少有一定数量的实例可用
错误率必须低于设定阈值
必须能够执行回滚操作

管道依然会按照这些规范来执行相应的任务，但规范文件定义了管道必须满足的条件。这也使得更换不同的管道变得更加容易。
如果你从：
GitHub Actions
切换到：
GitLab CI
或者：
Argo
执行器也会发生变化。
但操作目标本身并不一定需要随之改变。
这一概念在基础设施管理中的应用
“代码即基础设施”这一理念已经能够帮助我们实现所需的状态配置，而这与我们所讨论的思路也是密切相关的。
例如：
resource "aws_instance" "app" {
  instance_type = "t3.medium"
}

然而，实际的操作需求往往不仅仅局限于配置状态的设定。
你可能还会关心以下方面：
配置应用程序运行环境

要求：
需要3台实例
区域必须为us-east-1
每月预计成本需低于500美元
必须启用加密功能
备份数据必须在24小时以内

执行器可以使用Terraform来完成这些配置任务。
所需的验证信息可能来自：
这一概念在事件响应中的应用
在事件响应过程中，执行步骤与实际操作目标也常常会混杂在一起。
一个运行手册可能会这样规定：
恢复服务的可用性

同时需要确保：
避免重复支付
保持数据操作的顺序不变
将错误率控制在设定阈值以下
这种差异是非常重要的。
如果重启服务并不能真正恢复服务的可用性，那么尽管运行手册上的步骤已经执行完毕，但操作仍然算是失败的。
通过编写可执行的规范文件，就可以明确这些恢复条件。
结账成功率 > 99%  
支付重复情况为0  
排队等待时间低于阈值  
错误率 < 1%  

因此，对事件自动化效果的评估应基于其实际取得的成果，而不仅仅是它所执行的操作。
这一原则在AI代理中的应用
对于AI代理来说，这一点尤为重要。传统的自动化流程通常遵循预先定义的执行逻辑。
而AI代理可以动态选择执行路径。例如，一个操作代理可能会决定采取以下行动：
检查各项指标  
重启某项服务  
调整资源容量  
修改配置参数  
重新路由流量  

具体的执行顺序可能会因不同的事件而有所差异，这使得在执行层进行验证变得更为困难。
你无法总是通过检查代理是否严格遵循了某个固定的脚本来验证它的行为，但你可以确认它的操作意图是否正确。
例如：
目标：恢复API的正常可用性  
约束条件：  
不得禁用认证功能；  
不得丢失排队中的请求；  
错误率 < 1%；  
P95延迟时间 < 500毫秒；  
成本增加幅度 < 20%；  

代理可能会选择不同的行动方式，但其操作目标仍然是稳定的。
这种结构形成了一种非常有用的控制机制：
人类/组织的意图  
        ↓  
操作规范  
        ↓  
代理  
        ↓  
具体行动  
        ↓  
验证结果  
        ↓  
评估结论  

执行的自主性越强，这种分离机制就越显得重要。
操作规范中应包含哪些内容？
一份有用的操作规范通常会涵盖以下几个方面的内容。
目标
最终需要实现什么目标？
例如：
部署Order服务，版本为2026.09.19
适用范围
这项操作适用于哪些环境或场景？
例如：
环境：生产环境  
区域：us-east-1  
服务：Order服务  

约束条件

有哪些必须遵守的限制条件？
例如：
可用副本数量 >= 3个  
错误率 <= 1%  
P95延迟时间 <= 400毫秒  

所需验证的数据

需要观察哪些关键指标？
例如：
当前运行的版本号  
副本数量  
错误率  
延迟时间  

评估规则

如何判断代理的实际执行是否符合规范要求？
例如：
版本号必须完全一致  
副本数量必须 >= 3个  
错误率必须 <= 0.01%  

恢复措施

如果执行结果不符合规范，应该采取什么补救措施？
例如：
停止当前部署流程  
恢复原有的路由设置  
需要人工审核批准  
并非所有的规范都需要包含所有这些内容。
但将它们区分开来，就能使操作目的更加清晰明了。
哪些内容不应该被纳入规范中？
规范不应变成另一份实现脚本，也就是说，应该避免包含那些与具体执行工具相关的细节。
例如，以下这段代码就过于具体地描述了实现过程：
运行 kubectl 命令 X  
等待 10 秒  
调用端点 Y  
运行 shell 命令 Z
这些内容属于执行工具的具体实现细节，规范应该关注的是期望达到的操作结果。
例如：
服务版本 = 2026.09.19  
可用副本数 >= 3  
健康检查通过
一个有用的原则是：

如果改变执行工具会导致规范内容需要重新编写，那么说明该规范中包含了过多的实现细节。

有些与特定执行工具相关的限制是不可避免的，但默认情况下，我们应该将操作目的与具体实现机制分开来描述。
实际的操作流程
如果我要在现有的系统中引入可执行的操作规范，我会从简单的内容开始入手。
1. 选择一项重要的操作
例如：
部署服务  
更新证书  
恢复备份  
调整工作负载规模
2. 明确操作目标
需要思考的是：

成功的标准到底是什么？

而不是：

我们应该运行哪些命令？

3. 识别存在的限制条件
例如：
最低可用性要求  
最大错误率限制  
安全需求  
地域使用限制  
成本控制指标
4>寻找验证这些限制条件的依据

对于每一项限制条件，都需要思考：

什么样的观察结果能够证明或反驳这一条件？

5>将执行机制与规范分开

应该将负责完成具体操作的机制与规范本身区分开来。
6>执行后进行评估

收集实际执行结果的数据，并与规范中的要求进行对比。
7>报告合规性情况

建议采用这样的表述方式：
3项限制条件得到满足  
1项限制条件未通过
而不是：
8>不断完善规范内容

那些缺失证据或描述模糊的限制条件很快就会暴露出来，这样反而有助于我们及时改进规范。
随着操作细节的明确化，规范本身也会逐渐完善。
可执行的规范无法解决哪些问题？
可执行的规范并不能构成一个完整的运营架构。
它们无法自动解决以下问题：
不合理的需求
错误的评估指标
缺乏可观测性
分布式事务处理
安全漏洞
执行器的实现质量不佳
组织职责不明确
业务目标存在冲突
此外，这些规范本身也会带来新的风险：

不合理的规范可能会设定错误的目标。
不完整的规范可能会造成人们产生错误的信任感。
过时的规范可能会成为导致系统偏离预期目标的另一个因素。
并非所有的运营决策都能用简单的阈值来衡量。

人类的判断依然非常重要。我们的目标并不是完全摒弃判断，而是让运营意图更加明确、更便于进行验证。
从自动化运营到可验证的运营
软件运维领域多年来一直在朝着自动化的方向发展，这一趋势将会持续下去。但自动化程度的提高也引发了一个新的问题：

我们如何才能确定自动化操作确实取得了预期的结果呢？
执行日志、流程的执行情况以及代理程序的运行状态这些信息还不够。我们需要某种标准来对比实际操作结果与预期目标。这时，可执行的运营规范就派上了用场。
它为我们提供了以下框架：
预期目标
↓
约束条件
↓
所需证据
↓
执行过程
↓
观察到的结果
↓
评估结论
这种结构使得一个运营活动从“某件事情发生了”转变为“某件事情发生了，我们知道了预期的结果是什么，我们也收集到了相应的证据，因此可以对此进行评估”。
这样的框架为自动化运营提供了更加坚实的基础。
结论
我们越是推进软件运维的自动化进程，就越有必要将“我们的目标”与“工具执行这些目标的具体方式”区分开来。
各种流程、基础设施工具、脚本以及人工智能代理程序都属于执行器，它们都能够执行特定的操作。
但是，运营目标本身应该独立于实现它的具体机制而存在。
可执行的运营规范为我们提供了一种方式，用“预期结果”、“约束条件”、“所需证据”以及“评估规则”这些要素来描述这一目标。
这样一来，执行过程就变成了我们可以验证的内容，而而不仅仅是我们可以观察到的现象。
在当前的部署、基础设施管理和事件响应工作中，这一点尤为重要。
随着运营系统变得越来越自主，这一点的重要性将会进一步凸显。
因为自动化技术可以告诉我们某项操作确实被执行了，但我们真正需要知道的是：系统最终是否达到了预期的目标。