2025年9月29日·1 分钟
Werner Vogels 的“你构建，你运行”详解
了解 Werner Vogels 所说的“你构建，你运行”是什么意思以及如何落地：所有权、值班、SLO、事故响应与更安全的发布实践。
了解 Werner Vogels 所说的“你构建，你运行”是什么意思以及如何落地：所有权、值班、SLO、事故响应与更安全的发布实践。
“你构建它，你运行它”这句台词之所以让人记住，是因为它直白。它不是励志海报或“更DevOps”的口号，而是关于责任的明确声明：交付服务的团队，也要对该服务在生产环境中的表现负责。
在实践中，这意味着同一个产品团队既设计功能和写代码，也要：
这并不意味着每个人一夜之间都成为基础设施专家。它意味着反馈回路真实存在：如果你发布的改动增加了宕机、告警噪音或客户痛点，团队会直接感受到——并快速学习。
除非把它当作一套带有明确期望的运行模型，否则这套理念容易被口头化但难以实施。“运行它”通常包含值班（某种形式）、负责事故响应、编写运行手册、维护仪表盘和持续改进服务。
这也暗含约束：不能要求团队“运行它”却不给他们修复问题的工具、访问权限和权限——以及路线图中用于这类工作的时间。
在“你构建，你运行”出现之前，很多公司把软件开发组织成接力赛：开发写完代码，然后把它“扔给”运维团队来部署并维护。
这种交接解决了短期问题——有人经验丰富地盯着生产——但也制造了更大的问题。
当独立的运维团队拥有生产时，开发人员往往很晚（甚至根本）才知道问题。一个错误可能会以含糊的工单形式出现，几天后才被发现：“服务很慢”或“CPU 很高”。到那时，上下文丢失，日志已经轮转，做出改动的人也可能已经离开。
交接也会模糊所有权。如果发生故障，开发可能以为“运维会接手”，而运维可能认为“是开发放了有风险的改动”。结果可预见：解决事故更久、重复的故障模式增多，团队为了局部最优而非客户体验做出选择。
“你构建，你运行”缩短了回路。发布改动的同一团队要对其在生产中的表现负责。这会把实用改进推到上游：更清晰的告警、更安全的发布、更好的仪表盘和更易于运行的代码。
反而，这通常能加快交付。当团队信任他们的发布流程并理解生产行为后，他们可以更频繁地发布更小的改动——减少事故影响范围并使问题更易诊断。
并非所有组织在人员配置、合规要求或遗留系统上起点相同。这个理念是一个方向，而不是开关。许多团队会逐步采用：先从共享值班、更好的可观测性和更清晰的服务边界开始，再走向完全的端到端所有权。
亚马逊 CTO Werner Vogels 推广了“你构建，它就由你运行”的说法，用来描述亚马逊（以及后来的 AWS）希望团队如何看待软件：不是一个交付后就完结的项目，而是一个需要持续运营的服务。
关键转变既是心理上的，也是技术上的。当团队知道自己会因故障被叫醒时，设计决策就会改变。你会关心合理的默认值、清晰的告警、优雅的降级以及可回滚的部署路径。换言之，构建也包含为现实世界中混乱的部分做计划。
AWS 时代的服务思维让可靠性与速度成为不可谈判的要求。云客户期望 API 全天候可用，也期望持续地获得改进——而不是季度性的“大版本”更新。
这种压力促成了：
该理念与更广泛的 DevOps 运动有重叠：缩小 “开发” 与 “运维” 的差距，减少交接，并把可用性、延迟和支持负载等结果纳入开发循环。它也契合能独立发布的小型自治团队的理念。
将亚马逊的方法当作模板照搬很诱人，但“你构建，你运行”更多是一个方向而不是死板的组织结构。你的团队规模、监管约束、产品成熟度与可用性需求可能需要调整——比如共享值班、平台支持或分阶段采纳。
如果你想把这个心态转为可执行步骤，请跳转到 /blog/how-to-adopt-you-build-it-you-run-it-step-by-step。
“你构建，你运行”本质上是关于所有权的声明。如果你的团队交付了一个服务，你的团队就要对该服务在真实世界中的表现负责——不仅仅是发布当天是否通过了测试。
运行一个服务意味着对端到端的结果负责：
在常态周里，“运行它”更多是常规操作而非英雄行为：
这个模型只在把责任理解为“我们来修复”而非“找人惩罚”的前提下才有效。发生故障时，目标是理解系统中允许故障发生的条件——缺失的告警、不清晰的限制、风险的发布流程——并改善这些条件。
当服务模糊不清时，所有权就会混乱。定义服务边界（它做什么、依赖什么、承诺什么）并指派明确的责任团队。这种清晰能减少交接、加速事故响应，并在可靠性与功能竞争时让优先级显而易见。
值班是“你构建，你运行”的核心，因为它封闭了反馈回路。当同一团队既发布变更又感受运营影响（延迟峰值、发布失败、客户投诉）时，优先级变得清晰：可靠性工作不再是“别人的问题”，而让系统更平静通常是更快交付的途径。
健康的值班主要关乎可预期性与支持。
定义严重级别，避免系统为每个不完美都发页。
一个简单规则：如果叫醒某人不会改变结果，那就应该建工单而不是发页。
值班不是惩罚，而是信号。每一个噪音告警、重复故障或人工修复都应反馈到工程工作中：更好地告警、自动化、更安全的发布和移除需要人工干预的系统修改。
如果“你运行它”是真实的，团队需要一种共享的方式来讨论可靠性，而不是把每次讨论变成意见分歧。这正是 SLI、SLO 与错误预算的作用：明确目标，并在快速迭代与保持稳定之间提供公平的权衡。
记忆方法：SLI = 指标，SLO = 目标，SLA = 对外承诺。
好的 SLI 与用户体验直接相关，例如：
错误预算是指在仍能满足 SLO 的情况下允许的“坏的量”。例如，若 SLO 是 99.9% 可用性，则月度错误预算为 0.1% 的不可用时间。
当服务健康且在预算内时，团队可以承担更高的交付风险（发布功能、试验）。当预算被快速消耗时，可靠性工作必须优先。
SLO 把可靠性变成规划输入。如果你的错误预算很少，下个冲刺可能会着重做限流、更安全的发布或修复不稳定的依赖——因为错过 SLO 有明确成本。如果预算充足，你就可以更自信地优先产品工作，而不用猜测“运维能否应付”。
“你构建，你运行”只有在把发布常态化、而不是高风险事件时才行得通。目标是上线前减少不确定性，上线后限制冲击面。
在把服务视为“就绪”之前，团队通常需要一些运营基础设施：
与其一次性对所有人发布，不如分步限制影响：
如果团队把回滚标准化，把它当成一项核心能力：回滚越快越安全，“你运行它”就越可行。
两种测试能减少“未知的未知”：
保持轻量：在仓库或工单模板中放一页清单（例如“可观测性”、“值班就绪”、“数据保护”、“回滚计划”、“容量测试”、“运行手册链接”）。把“未就绪”看作正常状态——远比在生产中学习要好得多。
事故是“你运行它”真正变现的时刻：服务降级、客户感知并且团队需要迅速且清晰地响应。目标不是英雄主义，而是可复用的工作流来降低影响并产出改进。
大多数团队会收敛到相同的阶段：
如果需要实用模板，可准备一份轻量清单（见 /blog/incident-response-checklist）。
无责备的事后分析并不意味着“没人犯错”。它意味着把注意力放在系统与流程如何允许错误到达生产，而不是羞辱个人。这能让人们尽早共享细节，这是学习的关键。
记录内容：
好的事后分析以具体且有归属的后续工作结尾，通常分为四类：工具改进（更好告警/仪表盘）、测试（回归与边界情况）、自动化（更安全的发布/回滚、护栏）和文档（运行手册、清晰的操作步骤）。给出负责人和截止日期——否则学习就只是理论。
工具是把“你构建，你运行”变成可持续实践的杠杆——但它不能替代真正的所有权。如果团队把运维当成“别人的事”，即便最花哨的仪表盘也只能记录混乱。好的工具降低摩擦：让正确的行为（观察、响应、学习）比错误的行为（猜测、指责、忽视）更容易实现。
至少，服务所有者需要一致的方式来查看生产中的软件运行状况并在异常时迅速采取行动：
如果监控体系碎片化，团队就会把时间花在追查而不是修复上。统一的可观测性策略能起到帮助，见 /product/observability。
组织增长时，“谁负责？”成为可靠性风险。服务目录（或内部开发者门户）能把所有权与运营上下文集中起来：团队名称、值班轮班、升级路径、运行手册、依赖关系与仪表盘链接。
关键是所有权元数据要保持最新。把它纳入工作流：新服务上线前必须有负责人，变更所有权像代码变更一样被审核与记录。
最佳实践会推动团队朝健康行为迈进：运行手册模板、与 SLO 绑定的自动告警、能在几秒内判断“用户是否受影响”的仪表盘。但人的因素依然重要——团队需要时间去维护这些工具、修剪告警并持续改进服务的运行方式。
平台团队能让“你构建，你运行”更易于落地。他们的工作不是为所有人运行生产环境，而是提供一条明亮的路径（“铺好的道路”），使产品团队无需在每个冲刺都重做运维工作就能拥有自己的服务。
好的平台提供难以出错且容易采用的默认方案：
护栏应该阻止高风险行为但不阻碍发布。想想“默认安全”，而不是“提交工单然后等待”。
平台团队可以运行共享服务——但不该替代产品服务的所有权。
边界很简单：平台团队负责平台自身的可用性与支持；产品团队负责如何使用该平台并对结果负责。
当团队不用在第一天就精通 CI/CD、认证或密钥管理时，他们可以更专注于服务行为和用户影响。
能减少重复工作的示例：
结果是更快的交付、更少的“定制运维孤岛”，同时保持核心承诺：构建服务的团队仍然运行它。
“你构建，你运行”能提升可靠性和速度——但前提是组织要改变支撑团队的条件。很多失败看起来像是口号被采纳了，但支撑的习惯并未跟上。
一些反复出现的模式包括：
某些环境需要定制化方法：
当可靠性工作被视为“额外任务”时，这一理念会最快失败。领导必须明确保留容量用于：
没有这种保障，值班会成为一项税负——而非能改进系统的反馈回路。
最好把推广作为分阶段变更，而不是一次公司层面的通知。先小范围试点、使所有权可见、然后再扩展。
选择一个单一、界定清晰的服务（最好有明确用户且风险可控）。
定义：
关键是：发布变更的团队也要对该服务的运营结果负责。
在向更多服务推广前，确保试点团队能在不靠英雄主义的情况下运行：
用一小组指标展示所有权是否提升了交付速度与稳定性：
在你采用“你构建，你运行”并试图加速交付时，瓶颈通常是相同的：如何把想法变成带有明确所有权与安全回滚能力的生产就绪服务。
Koder.ai 是一个以对话为中心的编码平台，帮助团队通过聊天界面构建 web、后端与移动应用（Web 上 React、后端 Go + PostgreSQL、移动端 Flutter）。对于倾向于服务所有权的团队，它的若干功能与运行模型吻合：
本周挑选你的试点服务，并安排 60 分钟的启动会以设定首个 SLO、值班轮班与运行手册负责人。如果你正在评估用以支撑（发布、回滚与围绕所有权的工作流）的工具，请参见 /pricing，了解 Koder.ai 的免费、专业、业务与企业版本——以及托管、部署与自定义域名等选项。
它意味着设计、构建并部署某个服务的团队，也要在服务上线后承担其发生的后续责任：监控、值班响应、事故跟进和可靠性改进。
这是一个责任模型（明确的归属），而不是某个工具或职称的简单变化。
这并不要求每个工程师都必须成为全职的基础设施专家。
它意味着：
当生产由独立的运维团队负责时，反馈常常延迟且责任模糊：开发者可能感受不到生产的痛点，而运维也不清楚最近的变更背景。
端到端的归属通常会改善：
“运行它”通常包括：
从人性化设计开始：
优秀的值班体系目标是：下个月减少告警，而不是把英雄主义常态化。
简单规则：如果叫醒某人也无法改变结果，那就用工单而不是页面通知。
实际操作：
它们提供了可度量的可靠性目标：
当错误预算被快速消耗时，应把优先级转向可靠性工作；当预算充足时，可以承担更多交付风险。
采用降低不确定性与冲击面的发布实践：
把事故当成可复现的流程处理：
编写无责备的事后分析（postmortem），关注系统与流程如何允许问题进入生产，并给出具体、有人认领且有时限的改进项。
一个轻量的清单（参见 /blog/incident-response-checklist）有助于标准化流程。
平台团队应提供“铺好的道路”（模板、CI/CD、护栏、共享服务），但不要替代产品团队对其服务行为的责任。
简单边界：