左移可靠性

It looks like the text you’d like translated wasn’t included in your message. Could you please paste the content you want translated (excluding the source line you already provided)? Once I have the text, I’ll translate it into Simplified Chinese while preserving the formatting and technical terms.

悖论

我们在事件响应方面已经变得异常出色。现代团队能够快速恢复服务，进行深思熟虑的事后分析，并通过纠正措施对自己负责。

然而……

一个团队发布了一个通过所有测试、获得所有必需批准的变更，却仍然导致结账功能宕机 47 分钟。事后分析的结论是？“我们本应该在部署前就知道我们的延迟 SLO 已经下降到 94 %。”

许多事后分析都指向相同的根本原因：我们自己引入的变更。不是硬件故障，也不是随机的宕机。只是软件完全按照我们的指示运行。

我们仍然把可靠性视为在这些变更已经上线之后才去评估的事情。这并不是工具或流程的失败，而是我们决定系统是否准备就绪的时机问题。

可靠性决策实际发生的地方

我见过多个团队使用完全相同的技术栈，却拥有截然不同的 SLO、指标和告警。没有人告诉他们该实现什么、最佳实践是什么，或者如何调优告警。他们想成为可靠性优秀的公民，但要把手册中的理论付诸实践并不简单。

• 服务经常在投入生产后才几个月后才创建 SLO，甚至根本不创建。
• 仪表盘缺失、不足或不一致。
• 在 PR 评审时常出现“我看起来没问题”。
• 部落式知识以及团队之间理解程度的差异。

可靠性本质上是定制化且缺乏治理的。这就是核心问题。

缺失的层

GitHub 为我们提供了代码的版本控制。Terraform 为我们提供了基础设施的版本控制。安全已经通过左移转变——在编写代码时发现缺陷，而不是部署后。

我们仍然缺少 可靠性版本控制。

我们需要一个规范，能够：

1. 定义 需求。
2. 验证 这些需求是否符合实际。
3. 生成 人工制品：仪表盘、SLO、警报、升级策略。

如果规范已通过验证并且制品已生成，同一工具即可实时检查服务是否违约——并在 CI/CD 中阻止高风险的部署。

什么是左移可靠性

左移可靠性并不意味着更多的警报、更多的仪表盘、更多的事后分析，或是更多的人在现场。它意味着：

• Spec – 将可靠性需求在生产部署 之前 定义为代码。
• Validate – 将这些需求与实际情况进行测试。
• Enforce – 通过 CI/CD 对部署进行把关。

工程师不再编写 PromQL 或 Grafana JSON——他们声明意图，可靠性变得可确定。结果可预测、一致、透明，并遵循最佳实践。

Source:

可执行的可靠性合约

保持简单。团队创建一个 service.yaml 文件，声明他们的可靠性意图：

name: payment-api
tier: critical
type: api
team: payments
dependencies:
  - postgresql
  - redis

完整的 service.yaml 示例可在此处找到。

工具会验证指标、SLO 和错误预算，并自动生成这些制品。这是我正在用一个名为 NthLayer 的开源项目探索的方法。

NthLayer 可在任何 CI/CD 流水线中运行——GitHub Actions、ArgoCD、Jenkins、Tekton、GitLab CI。目标不是成为一个僵硬的阻断器，而是让风险可见、决策明确。当覆盖是有意为之、已记录并有负责人时，覆盖是可以接受的。

当尝试部署时，规范会与实际情况进行评估：

$ nthlayer check-deploy -service payment-api
ERROR: Deployment blocked
 - availability SLO at 99.2 % (target: 99.95 %)
 - error budget exhausted: -47 minutes remaining
 - 3 P1 incidents in last 7 days

exit code: 2 (BLOCKED)

为什么现在？

SLO 已经有 8 年以上 的时间得以成熟，并从 Google SRE 手册走向主流实践。GitOps 已经让声明式配置成为常态。平台工程作为一门学科也日趋成熟。概念已经准备就绪，但工具仍相对滞后。

这是一种有意的转变方式。可靠性不再在事故处理中成为争论点。服务拥有明确的负责人和确定性的标准。我们可以停止在每次新服务上线时重新发明可靠性轮子。如果需求发生变化，只需更新 service.yaml，运行 NthLayer，所有服务即可受益于新的标准。

这 不 替代

NthLayer 并不取代服务目录、开发者门户、可观测性平台或事件管理。它也不会预测故障或消除人工判断。它位于所有这些系统的上游。

目标： 一个可靠性规范、自动化部署门以及降低实施最佳实践的认知负荷。

未解答的问题

我并没有所有答案，但我一直在反复思考的两个问题是：

1. 合同漂移（Contract Drift）： 当规范要求 99.95 % 的可用性，而实际已经连续数月只有 99.5 % 时会怎样？是合同本身有误，还是服务出现了故障？
2. 紧急覆盖（Emergency Overrides）： 在必须在可靠性检查失败的情况下紧急推进部署时，我们应如何处理？

欢迎分享想法、经验或建议，帮助我们把“左移可靠性”落到实处。

他们应该如何工作？谁批准？如何防止它们成为默认？

时间问题

在你的组织中，可靠性决策到底在哪里做出？
在部署之前决定就绪状态会是什么样子？
有哪些可靠性规则是你希望能够自动强制执行的？

时间问题不会自行消失。唯一的问题是，你是在 部署之前 解决它，还是在事后回顾时才发现它。

NthLayer – 开源项目，寻找早期使用者

如果你已经厌倦了把可靠性当作事后考虑：

pip install nthlayer
nthlayer init
nthlayer check-deploy --service your-service

→ github.com/rsionnach/nthlayer

给仓库加星，提交 issue，或者告诉我我错了。我想了解可靠性决策在你的组织中是如何进行的。

---

Rob Fox 是一名专注于平台和可靠性工具的高级站点可靠性工程师。他正在探索如何让可靠性工程更早介入软件交付生命周期。可在 GitHub 找到他。