一条推特燃炸情绪：开发者并不想做运维！

编译 | 云昭 软件开发的工作正在难以想象的速度变得越来越复杂。 从在服务器上的单体架构中构建应用程序，到将它们分解为多个微服务、打包到容器中、与 Kubernetes 编排并托管在分布式云环境中，再加上消费者功能丰富、追求体验的预期，设计上又需要安全且有弹性，软件复杂度正在以一种非常快的速度攀升。如果说软件正在吞噬世界，那么云正在吞噬软件，而无处不在的“云”端之下，则是运维工作正在慢慢把开发者拖垮。​ 新带来的复杂性正在折磨开发人员。开发和运维专家也许到了重新分开的时刻了。但是，在不重复过去的错误的情况下可以做到这一点吗？

用过了的 DevOps

​随着敏捷方法和云计算的兴起，随着软件开始吞噬世界， DevOps 出现了。作为“开发”和“运维”的简洁组合，DevOps 试图将两个先前独立的负责构建和部署软件的团队聚集在一起。这也恰逢软件工程师需要收紧用户反馈循环并更频繁地将更新推送到生产环境，甚至无意中推动了这一点。 虽然许多组织抓住这个机会，将两组专家聚集在一起，以前所未有的速度解决常见问题，但也有一些组织将 DevOps 的兴起作为开发人员负责运维任务的许可证，并试图建立一个半神话般的超级全栈的开发团队。

一条推特燃炸情绪

​“在大多数情况下，开发人员不想处理运维问题，”《DevOps for Dummies》一书的作者、AWS 网络服务社区参与负责人 Emily Freeman 在推特上写道。 这一条推特显然触动了全球软件开发者的神经，数百条同样不想做运维的开发人员的回复纷至沓来。“我是一名开发人员，我不想处理运维问题，”快餐公司 Chipotle 的软件工程师 Scott Pantall 回答说。 “开发人员和运维人员应该密切合作，同时扮演不同的角色。团队之间的同理心才是真正的重点，”SUSE 的开发人员布道师 Andrew Gracey 表示。 虽然将更多的运维和安全问题“左移”到软件开发侧这种做法有着明显的优点，比如可以提高测试效率并提高交付质量，但它也有可能成为带来危险的瓶颈。 “如果你把开发者拉到太多与他们不匹配的领域，最终会自食苦果。他们拥有不同的技术栈。”Kubernetes 存储专家、Ondat 的产品负责人 James Brown 。 或者正如 Harness 的现场首席技术官 Nick Durkin 所说，“人们开始意识到我们不会聘请电工来做我们的管道工。”

负荷“大量”增加

​相信连开发者都想不到，时至今日，同行的“存量”已经变得如此之高，但他们的工作负担非但没有下降，反而一路飙升。与之形成鲜明对比的是，技术运维的专业知识在某种程度上已经淡出人们的视线。 正如 DevOps 工程师、前系统管理员 Mathew Duggan在《运维部不是IT研发部》一文中所提及的，虽然运维人员“仍然承担着以前的所有职责，确保应用程序可用、受监控、安全和合规”，但他们还负责构建和维护软件交付管道，“在开发人员即使在没有我们参与的情况下，为快速安全地发布代码奠定基础。” ​图：传统IT部门由开发、QA、运营团队组成每个团队专注于不同的分工和角色。 这些不断扩大的职责涉及到大规模的再培训工作，尤其是云工程和基础设施作为代码技能变得至关重要。

管理层过高预期

​“在我看来，情况从未像现在这样惨淡，”Duggan 写道。“开发者的职责范围 (RIP QA) 大幅增加，但管理层对效率的期望却不切实际，现已变得不堪重负。”下面这个对话体现了这种情况——我：领导，我已经厌倦了，到处都是“钥匙孔”，太累人了！ 领导：我们希望你做开发工作，但这一切都需要放在墙后面，所以你必须跳过障碍才能得到。哦，我们也不会为你提供一种标准化的方式来获取。 领导：为什么要花这么长时间？我：这不是真正的 DevOps！领导：不要那么消极。与任何宏大的想法一样，当应用于高度复杂的企业时，这通常都会落空，因为有数百种产品或服务以及各种团队为每个产品或服务提供自己独特的流程和技术栈。戴尔科技资本（Dell Technologies Capital）总经理 Tyler Jewell 在一份研究报告中写道：“要建立一个能够实现可持续发展组织，是非常具有挑战性的。随着系统复杂性的增加和最终用户反馈的增多，我们越来越难以预测一个改动对于系统可能产生的影响。”

认识到问题

情况可能不像 Duggan 和其他人认为的那样绝望，但解决问题的前提是意识到这个问题，尽管它可能需要对工程团队及其职责进行重大调整。 “目的不是要给开发者增加负担，而是在正确的时间为开发者提供正确的信息，”Harness 的 Durkin 认为。“他们不想配置所有东西，但他们确实希望在正确的时间从这些系统中获取信息，以使运营、安全和基础设施团队能够正常工作。除非出现问题，否则开发人员不用关心。”沃尔特·迪斯尼公司（Walt Disney Company）的前董事奈杰尔森（Nigel Simpson）希望公司能认识到这个问题，“应该努力让开发人员摆脱‘担忧机器如何工作’的状态，并回归到构建软件，这是他们最擅长的。”重要的是，DevOps 是一个统一体，其实施应该因组织而异。开发人员现在可以做一些运维的工作并不意味着他们应该把运维的活也做了。

开发和运维如何平衡

​正如Gartner 分析师 Lydia Leong 所言：“开发人员对基础设施的控制并不是一个全有或全无的命题。”“在软件生命周期中做好职责划分，这样采可以从‘构建它，然后运行它’中获益，而不必将开发人员空降到一个未驯服、未知的荒野，然后祝他们好运，因为这已经不是一个‘基础设施和运维团队’的问题了。”换句话说，“允许开发人员完全自助访问开发和测试环境，并将基础设施构建为生产代码模板的能力，而不是让开发者完全负责生产，”Leong 写道。事实上，根据VMware 的《2022 年 Kubernetes 状况》报告，776 名受访者中有 54% 的人表示，更高的开发人员效率是采用 Kubernetes 的关键原因，超过三分之一（37%）的人表示他们希望提高运维人员的效率。 Ondat 的 Brown 认为，Kubernetes 的容器编排正在成为这两个团队之间的分离层，将两者的关注点剥离开，以便开发人员可以专注于他们的代码，而运维可以确保底层基础设施和管道经过优化以运行它。“让我们不要回到那些不互相交谈的团队，”Brown 说。Humanitec 的创始人 Kaspar von Grunberg曾在他的电子邮件中写道：不要相信试图让每个人都成为专家的谬论。在高绩效团队中，很少有 Kubernetes 方面的知名专家，并且让其他成员尽量保持低认知负荷。​​

DevOps已死，SRE接力

如果 DevOps 的时代真的走到了尽头，或者其光彩刚刚出现褪色的迹象，那接下来会发生什么？ 我们之前在《​​DevOps失败了​​​》一文中，提到了“SoftOps”的概念，但目前更为被大家认可的是“SRE”（站点可靠性工程）。SRE 是在 Google 遭遇与 DevOps成长的阵痛中诞生的，它已被证明是一种流行的解决方案。 “从根本上说，当你要求软件工程师设计一个运维功能时，就会发生这种（痛苦的）情况，”谷歌工程副总裁、SRE 教父 Ben Treynor 这句话经常被引用。 以两家大型金融机构Vanguard 和摩根士丹利为例，它们在向更多云原生实践过渡时发现难以平衡开发和运维之间的职责。 在中央运维层和单个开发人员之间插入 SRE 安全缓冲带，能够帮助在两家公司建立信心，在开发人员效率和运维稳定性之间做到恰当的平衡。 然而，SRE 功能也受到了一些批评。正如摩根士丹利的 DevOps和企业技术架构负责人 Trevor Brosnan 所说，建立 SRE 原则“有时被误解为对运维团队的品牌重塑”。 “这是一个需要解决的细节问题，”Vanguard 的站点可靠性工程师 Christina Yakomin 说。“引入 SRE 确实会让人觉得，我们正在再次将运维孤立到这个角色中。” 相反，Yakomin 希望鼓励 Vanguard 开发人员和运营专家分担安全责任，并确保拥有共享平台的团队为他们承担全部运营责任。

平台工程：让人直呼万岁

“内部开发人员平台”或“平台工程学科”的想法也已成为组织为开发人员提供所需工具的一种方式，并配有适当的组织护栏以保护开发人员能够承担最合适的工作。 内部开发人员平台通常由代码投入生产所需的 API、工具、服务、知识和支持组成，并将其结合到由专门的专家团队或产品所有者维护的公司标准平台中。“DevOps 已经死了，平台工程万岁，”软件工程师和 DevOps评论员 Sid Palas 在推特上写道。“开发人员不喜欢与基础设施打交道，公司在成长过程中需要控制他们的基础设施。平台工程使这二者能够和谐共存。”软件咨询公司 Thoughtworks 的技术主管布兰登·拜尔斯（Brandon Byars）表示，他经常“看到该部门在平台工程团队中运作良好，这些团队为开发人员消除摩擦，同时让他们可以良好地运转。” 然而，有利必有弊。他补充说，“缺点是需要开发人员在没有集中的专业知识和工具支持的情况下完成所有这些工作。”在其工程团队中，任何致力于实施 DevOps 原则的组织，都将熟悉软件开发团队和运维团队之间的平衡做法。在云原生复杂性时代下，做到这种平衡的难度无异于“高空走钢丝”。