SRE 与可靠性工程理论

第三章的追问#

第三章让我们看到了一个诱人的图景：Harness 把 DevOps 的反馈环从小时级压缩到了分钟级，Generator 和 Evaluator 可以在几十分钟内完成多轮编码、评估、修正的循环。但这个图景里藏着一个没有被直视的问题：速度不等于可靠。

一个典型的场景是，Generator 经过 15 轮迭代后通过了 Evaluator 的所有验收标准，代码被部署到预发布环境。但上线两小时后，监控告警响起——某个边界条件下的内存泄漏导致服务逐渐失去响应。问题不在 Harness 的反馈环本身，而在于反馈环的验收标准是否覆盖了生产环境的真实风险。

这就引出了 SRE（Site Reliability Engineering，站点可靠性工程）的核心问题：如何定义足够好？

SLO：Evaluator 验收标准的另一个名字#

SRE 中有一个核心概念 trio：SLI、SLO、SLA。

SLI（Service Level Indicator，服务等级指标）是我们测量什么——比如请求响应时间、错误率、可用性百分比。SLO（Service Level Objective，服务等级目标）是我们要达到什么水平——比如"99.9% 的请求在 200ms 内返回"。SLA（Service Level Agreement，服务等级协议）是如果没达到，我们赔什么——通常是面向客户的违约条款。

这套体系的关键洞察是：100% 的可靠性是不可能的，也是不值得追求的。 Google 的 SRE 团队有一个著名论断：如果一个系统的可用性目标是 99.999%，那么它每十年只能停机 5 分钟——要达到这种级别的可靠性，所需的工程投入是指数级增长的。SRE 的智慧在于，先承认不完美是常态，然后用 SLO 来量化可接受的不完美究竟是多少。

Harness 的 Evaluator 验收标准，本质上就是代码质量的 SLO。

当 Generator 和 Evaluator 在编码前协商验收标准时，他们实际上在做一件事：为这一轮 sprint 的代码质量设定 SLO。“API 响应时间不超过 200ms"是一个 SLI，“必须达到"是一个 SLO。Evaluator 不是追求完美代码，而是追求达到 SLO 的代码——这和 SRE 的理念完全一致。

但这里有一个关键差异：传统 SRE 的 SLO 是针对线上系统的运行时指标，而 Harness 的 Evaluator SLO 是针对代码交付时的质量指标。两者的量化对象不同，但底层逻辑相同——都是足够好的定义。

错误预算：Harness 的成本权衡有了理论名字#

SRE 中另一个核心概念是错误预算（Error Budget）。

它的含义很简单：如果你的可用性 SLO 是 99.9%，那么你的错误预算就是 0.1%——你允许系统在一年内出现 0.1% 的不可用时间。当错误预算被消耗完时，团队必须停止发布新功能，优先修复稳定性问题。

错误预算的妙处在于，它把可靠性从一个抽象的道德要求，变成了一个可量化的资源。你可以像管理金钱一样管理可靠性：有预算时可以花，预算花光了就得省。

Harness 的评估迭代机制，本质上也在管理一种预算——只不过不是时间预算，而是 token 成本预算。

第三章提到，运行一次完整 Harness 流程的成本约为 200 美元，而同等任务由单个 AI 独立完成的成本仅为 9 美元。前端任务通常经历 5 到 15 轮评估迭代，每轮都消耗 token。这个成本结构本身就是 Harness 的错误预算：你为每一轮 sprint 分配了一定量的预算，Evaluator 的每次评估都在消耗这个预算。

SRE 说错误预算耗尽就停止发布，Harness 说token 预算耗尽或进入平台期就停止迭代——两者都是在资源有限的前提下追求最优产出。SRE 的硬约束是年度不可用时间不超过 X 小时，Harness 的硬约束是某项验收标准始终无法达标就判定 sprint 失败。这两套约束虽然领域不同，但精神完全一致：自动化不是无节制的，它受限于一个预设的预算边界。

当某项验收标准反复无法通过、评估分数进入平台期时，Harness 选择停止循环——这不是放弃，而是错误预算耗尽后的理性决策。 此时需要人类介入，重新审视验收标准是否合理、需求是否需要调整，而不是让 AI 在死胡同里无限消耗资源。

flowchart LR
    subgraph 迭代质量曲线
        direction LR
        R1[第1轮 45分] --> R2[第2轮 62分]
        R2 --> R3[第3轮 74分]
        R3 --> R4[第4轮 81分]
        R4 --> R5[第5轮 86分]
        R5 --> R6[第6轮 89分]
        R6 --> R7[第7轮 91分]
        R7 --> R8[第8轮 92分 平台期]
    end

    HT[硬阈值 90分]

    style R1 fill:#ffcccc,stroke:#cc0000
    style R2 fill:#ffcccc,stroke:#cc0000
    style R3 fill:#ffcccc,stroke:#cc0000
    style R4 fill:#ffcccc,stroke:#cc0000
    style R5 fill:#ffe6cc,stroke:#cc6600
    style R6 fill:#ffe6cc,stroke:#cc6600
    style R7 fill:#ccffcc,stroke:#009900
    style R8 fill:#ccffcc,stroke:#009900
    style HT fill:#ff9999,stroke:#cc0000,stroke-width:3px

上图展示了 Harness 评估迭代的典型曲线。前几轮质量评分快速提升，但随着迭代深入，改进幅度逐渐收窄，最终进入平台期——此时继续投入更多轮次的收益递减。图中的水平线代表硬阈值（如 90 分），如果平台期低于该阈值，sprint 会被判定为失败。这个模式与 SRE 的错误预算管理如出一辙：你有一个有限的资源池，需要在资源耗尽前达到目标，否则就停止并重新评估策略。

可观测性：Harness 反馈环的感官系统#

SRE 区分两个概念：监控（Monitoring）和可观测性（Observability）。

监控是我知道我要看什么，所以我设了告警。 可观测性是我不知道会发生什么，但系统暴露的内部状态足够丰富，以至于出现问题时我能反向推导出原因。 监控回答有没有问题，可观测性回答为什么有问题。

第三章提到，Harness 的反馈环不止于编码阶段——代码部署后，运行时的监控数据、日志、性能指标会回流到系统，Generator 基于这些反馈自动修复。但这个描述还停留在监控层面：系统发现问题，然后修复。

从 SRE 的视角提升，Harness 的部署后反馈环实际上是在构建可观测性。关键不在于有没有告警，而在于Generator 能否从监控数据中理解系统的内部状态。 如果日志只告诉你请求失败了，Generator 无法定位原因；但如果日志包含调用链追踪、内存使用量变化、数据库连接池状态，Generator 就能像人类 SRE 一样排查问题。

这意味着，Harness 对部署环境有一个隐性要求：可观测性基础设施必须足够丰富。 没有分布式追踪，Generator 就无法分析性能瓶颈；没有结构化日志，Generator 就无法理解错误上下文；没有指标暴露，Generator 就无法判断资源消耗趋势。Harness 不替代可观测性系统，它依赖可观测性系统提供的感官输入来运作。

混沌工程：让 Evaluator 更狠一点#

混沌工程（Chaos Engineering）是 Netflix 提出的一套实践：主动在生产环境中注入故障（如随机关闭服务实例、模拟网络延迟），验证系统在异常条件下的韧性。核心理念是不等到故障发生才学习，而是主动制造故障来验证。

这个概念对 Harness 的 Evaluator 设计有直接的启发。

当前 Evaluator 的验收标准通常聚焦于正常路径——功能是否正确、性能是否达标、边界条件是否覆盖。但混沌工程提醒我们：系统的可靠性不是由正常行为定义的，而是由异常行为定义的。

Harness 的 Evaluator 应该向混沌工程看齐。验收标准中除了功能测试，还应当包含韧性测试：如果数据库连接突然断开，代码是否优雅降级？如果依赖服务响应超时，是否不会无限等待？如果输入数据格式异常，是否会安全拒绝而不是崩溃？

这些测试传统上由 QA 或 SRE 团队手工设计，但在 Harness 框架中，Evaluator 可以自动生成和执行这些场景——只要它的验收标准中明确包含了异常条件下的行为要求。混沌工程的理念告诉我们：验收标准不应该是验证它工作，而应该是验证它在各种不工作的条件下依然安全。

程序员：SRE 的最终责任人#

SRE 有一条铁律：人对线上系统的最终责任不可转移。 无论自动化程度多高，on-call 的工程师是故障的第一责任人，管理层对服务可用性负责。

Harness 没有改变这一点。

第三章提到，代码通过 Evaluator 验收后会进入程序员门禁环节——程序员审查设计文档、代码、测试、监控配置。在 SRE 的语境下，这个环节不是可选的质量提升，而是可靠性的最终防线。

原因很直接：AI 可以生成代码、运行测试、分析日志，但 AI 不会承担责任。当凌晨三点生产环境出现故障、客户数据面临丢失风险时，站出来解决问题并承担后果的，只能是人。Harness 可以压缩从编码到上线的周期，但从上线到故障的责任链，终点仍然是人。

这也是为什么 SRE 实践强调可观测性和错误预算——这些工具不仅服务于自动化系统，更服务于人类决策者。当 Harness 的 sprint 因为错误预算耗尽而停止时，需要人类来判断：是验收标准设得太高？还是 Generator 的能力确实不足？是继续投入预算？还是调整需求范围？这些决策涉及业务判断、成本权衡和风险承受度，AI 无法替代。

本章内容说明

论文原意：Harness 三角色（Planner / Generator / Evaluator）、评估迭代机制、硬阈值停止条件、平台期现象、部署后监控反馈回流，源自 Anthropic《Harness Design for Long-Running Application Development》。成本数据（Solo run $9、Full harness $200、前端 5-15 轮迭代）同样源自该论文。
行业共识：SRE 核心概念（SLO / SLI / SLA、错误预算、可观测性、混沌工程）为 Google SRE 和 Netflix 等行业实践公开总结的理论体系，非 Harness 论文内容。
作者分析：SLO 与 Evaluator 验收标准的类比、错误预算与 Harness token 成本预算的映射、可观测性基础设施作为 Harness 感官输入的论述、混沌工程对 Evaluator 验收标准设计的启发，为本文作者基于 SRE 理论与 Harness 框架的关联推导。
工程扩展：程序员作为 SRE 最终责任人的论述、Harness 对可观测性基础设施的隐性要求、韧性测试纳入 Evaluator 验收标准的建议，是基于 SRE 工程实践与 Harness 落地场景结合的推导，非论文原文。