全周期开发者是什么？从 DevOps 实践看开发运维一体化模式

2012 年，在海外某大型流媒体平台，运营一项关键服务是一件异常艰难的事。部署过程缓慢而沉重，仿佛在湿沙中跋涉。所谓“金丝雀测试”也逐渐偏离了原本验证功能正确性的目的，变成了一种耐久性检验：“连续跑了一周都没出问题，那就继续推进吧。”问题排查更像是在不同团队之间来回传球：找到根因很难，更难的是避免问题在团队之间反复流转。所有这些迹象都表明，改变已经势在必行。

本文将围绕“全周期开发者”这一 DevOps 实践模式展开，讨论开发团队如何从单纯负责代码开发，逐步扩展到覆盖设计、开发、测试、部署、运营和支持的完整软件生命周期。对于关注开发运维一体化、持续交付、SRE、可观测性和研发效能的团队来说，这种模式具有重要参考价值。

时间来到 2018 年。该海外流媒体平台的全球会员数量已达到 1.25 亿，每天观看时长超过 1.4 亿小时。为了改进工程团队的开发与运维流程，公司投入了大量资源。在这一过程中，我们尝试了多种构建和运营服务的方式。本文将介绍一种在该公司内部较为常见的模式，并分析它的优势与不足。我们希望这些经验能够启发更多团队思考不同方案，也帮助他人从我们的探索中获得借鉴。

一个工程团队的转变之路：从独立运维到开发运维一体化

边缘工程团队负责支撑该流媒体服务正常运行所需的第一层公有云服务。过去，这个团队中既有专门负责运维的团队，也有 SRE 专家，他们主要承担软件生命周期中的部署、运维和支持工作。

在当时的模式下，发布一个新功能，意味着开发人员需要先与运维团队协调指标、告警、容量等方面的事项，然后再将代码移交给运维团队，由后者负责部署和后续运营。为了高效运行这些代码，并为合作伙伴提供支持，运维团队还必须持续了解每一个新功能和每一次缺陷修复。独立运维团队的主要优势在于：当一切顺利时，开发人员受到的干扰更少，可以更专注于功能开发。

但一旦事情不顺利，成本就会迅速累积。开发人员与运维/SRE 团队之间的沟通和知识传递效率并不高，调试问题或回答合作伙伴问题时，往往需要多轮往返。由于运维团队对所部署的变更了解有限，部署问题的发现时间和解决时间都会被拉长。从代码完成到真正上线之间的间隔也比现在长得多，发布周期通常以周为单位，而不是以天为单位。与此同时，运维人员会直接承受告警和监控不足、性能问题、延迟升高等痛点，而开发人员对这些问题的感知却往往是间接的。

为了改善这种状况，边缘工程团队尝试了一种混合模式：开发人员可以在需要时自行提交和部署代码，同时也要负责非工作时间的生产问题和支持请求。这种方式改善了开发人员的反馈和学习周期，但“只承担部分责任”的模式也暴露出一些不足。例如，尽管开发人员可以自行部署，并调试流水线故障，但他们通常仍会依赖专门负责发布的运维人员。对于专注运维的成员来说，他们有动力完成日常工作，却很难优先投入自动化建设，从根本上减少其他人对自己的依赖。

为了找到更好的方式，我们决定后退一步，重新审视最根本的问题：我们究竟想实现什么？此前的方式为什么没有成功？

软件生命周期：为什么端到端交付比局部效率更重要

软件生命周期的目标，是优化“价值交付时间”，也就是尽可能高效地把想法转化为客户真正可用的产品和服务。开发和运行软件服务涉及一整套完整职责：

SDLC 组件

长期以来，我们一直在拆分这些职责。在极端情况下，每个职能领域都会由不同的人或不同角色负责：

软件开发生命周期专家

这种专业化分工能够提升单个环节的效率，却也可能降低整个软件生命周期的整体效率。专家专注于特定领域，并不断优化该领域所需的一切；他们往往能更高效地解决自己负责的那一部分问题。然而，软件只有贯穿完整生命周期，最终交付到客户手中，才真正创造价值。

如果每位专家只负责生命周期中的某个局部环节，就容易形成信息孤岛，拖慢端到端的交付速度。把不同领域的专家放进同一个团队，确实可以减少部分信息孤岛；但如果不同的人仍然分别承担不同角色，沟通成本、流程瓶颈以及反馈机制失效的问题依然会存在。

运营你所构建的一切：全周期开发者的核心原则

为了重新思考我们的方法，我们从 DevOps 运动的原则中获得了启发。通过打破信息孤岛，并鼓励团队对整个软件生命周期共同负责，我们可以优化学习与反馈机制：

基于DevOps原则的软件开发生命周期

“运营你所构建的一切”（Operate What You Build）正是 DevOps 原则的一种实践方式：由构建系统的团队同时负责系统的运营和支持。把责任留在开发团队内部，而不是外包给其他团队，可以建立更直接的反馈机制，也能让激励机制更加一致。

如果团队在运维上遇到困难，他们有权通过调整系统设计或修改代码来解决问题；同时，他们也对这两件事负有责任。每个开发团队都需要负责部署问题、性能缺陷、容量规划、告警缺口、合作伙伴支持等事项。这也是全周期开发者模式区别于传统开发运维分工模式的关键所在。

通过开发者工具实现规模化

让开发人员负责完整的软件生命周期，会显著增加他们的工作负担。因此，能够简化并自动化常见开发需求的工具，就成为平衡这种负担的关键。

例如，如果要求软件开发人员管理服务回滚，就必须为他们提供足够强大的工具。这些工具不仅要能检测问题并发出告警，还要能协助开发人员完成回滚操作。

为此，该海外流媒体平台建立了多个集中式团队，例如云平台团队、性能与可靠性工程团队、工程工具团队等。这些团队的使命，是开发通用工具和基础设施，用来解决各个开发团队都会遇到的问题。它们通过把自身专业知识转化为可复用的构建模块，发挥了倍增器的作用。

专家们创建可重复使用的工具

借助这些工具，开发团队可以把更多精力放在各自产品领域的问题上。随着新的工具需求不断出现，集中式团队会评估这些需求是否具有普遍性，是否适用于多个开发团队。如果答案是肯定的，集中式团队就会与相关团队展开协作。有时，某些本地需求过于具体，并不值得进行集中式投入。在这种情况下，开发团队需要自行判断这些需求是否足够重要，是否值得自己投入解决。

在本地投入与集中式投入之间取得平衡，是这种模式中最困难的部分之一。根据我们的经验，探索满足开发者需求的新解决方案所带来的收益，远大于多个团队各自开发相似方案、最终又不得不整合这些方案所带来的风险。沟通与协调是成功的关键。只要从一开始就对需求及其普遍性达成共识，我们就能更好地让投入与各开发团队的收益相匹配。

对于希望降低自研工具门槛的团队，也可以借助 PingCode 这类智能化研发管理工具，将团队目标、客户反馈、需求清理、评审排期、开发测试、发布上线和 Wiki 知识沉淀串联起来，并打通现有研发工具链，让数据在整个软件生命周期中持续流转。

全周期开发者如何工作

把上述想法结合起来，我们形成了一种模式：一个配备强大开发者生产力工具的开发团队，负责整个软件生命周期，包括设计、开发、测试、部署、运营和支持。

赋能全周期开发人员

全周期开发者需要理解软件生命周期的各个环节，并能够在这些环节中高效工作。对于许多刚加入该公司的开发人员来说，这意味着他们需要快速补足过去未曾深入接触的领域。为此，公司开设开发训练营，并提供其他形式的持续培训，帮助他们掌握相关知识和技能。

当然，知识本身还不够。要有效掌控整个生命周期，还需要易于使用的部署流水线工具，也需要强大的监控工具。

全周期开发者会把工程原则应用到生命周期的每个环节。他们会从开发人员的视角审视问题，并提出这样的问题：“运行这个系统所需的操作，哪些可以自动化？”“有哪些自助服务工具可以让合作伙伴不需要找我，也能自行获得答案？”

这种思维方式有助于团队规模化发展。因为团队会更倾向于以系统为中心，而不是以人为中心来思考问题；更倾向于通过自动化解决问题，而不是依赖人工操作。

转向全周期开发模式，需要思维方式上的转变。有些开发人员会把设计和开发，有时也包括测试，视为创造价值的主要方式。这容易导致一种反模式：他们把运维视为干扰，倾向于对运维和支持问题做短期修补，以便尽快回到所谓“真正的工作”中。

但对于全周期开发者来说，“真正的工作”就是运用自己的软件开发专业能力，解决贯穿整个生命周期的问题。全周期开发者的思考和行动方式，兼具软件工程师、软件开发测试工程师和站点可靠性工程师的特点。他们有时编写解决业务问题的软件，有时编写相应的测试用例，有时则自动化系统的运维环节。

全周期开发模式的落地条件

要让这种模式成功，团队必须认同它所带来的价值，也必须充分理解它的成本。团队需要有足够的人员配置，并预留足够空间来管理构建和部署、处理生产问题，以及响应合作伙伴的支持请求。团队需要投入时间进行培训，需要充分利用并持续投资工具，也需要与集中式团队建立合作关系，共同创建可复用的组件和解决方案。

在规划和复盘过程中，团队需要考虑软件生命周期的各个方面。诸如自动化告警响应、构建自助式合作伙伴支持工具等投入，也需要与业务项目一起进行优先级排序。只有在人员配置、优先级排序和合作关系都适当的情况下，团队才能成功运营他们所构建的产品。否则，团队就会面临工作过载和精疲力竭的风险。

如果要把这种模式应用到其他公司，还需要做出一些调整。许多开发团队可能也会面临类似的问题，例如持续交付流水线、监控和可观测性等。但大多数公司既没有足够人员投入到这种规模的集中式团队中，也不需要与超大规模业务相匹配的复杂性。

一些成熟工具可以作为起点，但其他开源方案和 SaaS 解决方案也能满足大多数公司的需求。关键是先分析潜在价值，再计算实施成本，然后推动思维方式转变。团队应从自身需求出发，尽量避免引入不必要的复杂性。如果团队当前的重点不是复杂研发治理，而是跨部门项目协作、任务推进、文档沉淀、日程安排、审批流转和工时管理，也可以使用 Worktile 这类通用项目协作系统，为后续研发效能提升打好协作基础。

全周期开发者模式的权衡取舍

科技行业中，解决开发和运维需求的方式有很多种。本文介绍的全周期开发者模型在该海外流媒体平台较为常见，但它并非没有缺点。在选择任何一种开发运维模式之前，先充分理解其优势与不足，会显著提高成功概率。

在全周期模式下，团队优先追求的是更广泛的所有权，以及通过工具在更大范围内提升效率。广泛的职责要求开发者对多种技术都有兴趣，并具备相应能力。但有些开发者更希望专注于某个细分领域，成为该领域的顶尖专家；而行业在某些领域也确实需要这样的专家。

对于这类专家来说，既要在每个领域都具备一定深度，又要保持广泛知识面，可能会让他们感到不适，有时甚至会觉得缺乏成就感。该公司的一些员工更喜欢在需要深厚专业知识、但不要求持续拓展职责边界的领域工作，公司也会支持他们寻找这样的岗位；另一些员工则乐于承担更广泛的责任。

根据构建和运维云系统的经验，那些重视全生命周期管理所需广度的开发者，往往能够取得更高效率。但这种广度也增加了每位开发者的认知负荷，意味着团队每周需要平衡的优先事项，会比只专注于单一领域时更多。

我们通过轮值待命机制来缓解这个问题：开发人员轮流负责部署、运维和支持工作。如果轮值安排得当，就能为其他开发者释放出时间，让他们专注于需要沉浸式思考的工作。但如果轮值安排不当，团队就可能陷入一种状态：每个人都在疲于应对生产问题等高干扰性工作，最终导致精疲力竭。

工具和自动化可以提升专业能力，但没有任何工具能够解决开发者生产力和运维领域的所有问题。该公司拥有一套“铺好的道路”：也就是一系列经过验证的工具和实践，并由集中式团队提供正式支持。公司并不强制团队采用这些“铺好的道路”，而是通过确保使用它们时的开发和运维体验明显优于不使用时，来鼓励团队自然采纳。

这种方式的不足在于，理想状态很难完全实现。所谓理想状态，是每个团队都能充分使用每个工具的每项功能，并恰好满足自身最重要的需求。要让集中式团队的解决方案真正获得投资回报，需要持续投入、协调一致，并不断调整。

结语：全周期开发者对研发效能的启示

从 2012 年至今，我们一路经历了尝试、学习和调整。边缘工程团队早期的经验，推动他们寻找更好的模式。如今，他们正在积极实践全周期开发者模式。

部署已经变得常规而频繁；金丝雀测试只需数小时，而不是数天；开发者可以快速定位问题并做出修改，而不必在团队之间来回奔波。其他团队也获得了类似收益。

与此同时，我们也清楚地知道，今天的成果离不开对其他方法的借鉴和学习。未来的需求仍将持续变化，而这些变化也会继续推动我们演进。对于希望提升研发效能、推动 DevOps 落地、实现开发运维一体化的团队而言，全周期开发者模式提供了一种值得参考的实践路径。