合辑|云照的软件开发工作正以难以想象的速度变得越来越复杂。从在服务器上以单体架构构建应用程序，到将其分解为多个微服务，打包到容器中，与Kubernetes编排，托管在分布式云环境中，再加上消费者功能丰富，追求体验的期望，设计需要为了安全和灵活，软件复杂度正在以非常快的速度上升。如果说软件在吞噬世界，那么云就是在吞噬软件，而在无处不在的“云”之下，慢慢拖累开发者的是运维工作。新引入的复杂性正在折磨开发人员。开发和运营专家可能是时候再次分开了。但这能做到不重蹈覆辙吗？使用DevOps随着敏捷方法和云计算的兴起，随着软件开始吞噬世界，DevOps应运而生。DevOps是“开发”和“运营”的巧妙组合，它试图将两个以前独立的负责构建和部署软件的团队聚集在一起。这也与软件工程师收紧用户反馈循环和更频繁地将更新推送到生产环境的需求相吻合，即使是无意间。当许多组织抓住机会召集两组专家以前所未有的速度解决常见问题时，其他组织则将DevOps的兴起视为开发人员负责运维任务的许可证，并试图构建一个半神话般的超级全-堆栈开发团队。推文点燃情绪“在大多数情况下，开发人员不想处理操作，”《DevOps for Dummies》的作者兼AWSWebServices社区参与负责人EmilyFreeman在推特上写道。这条推文显然触动了全球软件开发者的神经，数百名同样不想做运维的开发者纷纷响应。“我是一名开发人员，我不想处理运营问题，”快餐公司Chipotle的软件工程师ScottPantall回答道。“开发人员和运维人员应该密切合作，同时承担不同的角色。团队之间的同理心才是真正重要的，”SUSE开发人员布道师AndrewGracey说。虽然将更多的操作和安全问题“左移”到软件开发端具有明显的优势，例如提高测试效率和提高交付质量，但它也可能成为一个危险的瓶颈。“如果你把开发人员拉到太多与他们不匹配的领域，你最终会吃很多东西。他们有不同的技术栈。”JamesBrown，Kubernetes存储专家和Ondat产品负责人。或者正如Harness现场首席技术官NickDurkin所说，“人们开始意识到我们不会聘请电工来担任我们的管道工。”“存量”变得如此之高，他们的工作量非但没有下降，反而直线上升。与此形成鲜明对比的是，技术操作方面的专业知识在某种程度上已经变得默默无闻。正如DevOps工程师和前系统管理员MathewDuggan在《运维部不是IT研发部》中指出的那样，虽然Ops“仍然负有确保应用程序可用、受监控、安全且合规的所有旧职责”，但他们还负责构建和维护软件交付管道，“为快速安全地发布代码奠定基础，即使我们作为开发人员没有参与也是如此。”图：传统IT部门由开发、QA、运营团队组成，每个团队专注于不同的分工和角色。这些不断扩大的职责涉及大量的再培训工作，尤其是在云工程和基础设施即代码技能变得至关重要的情况下。管理层夸大的期望“在我看来，形势从未像现在这样黯淡，”杜根写道。“开发人员的责任范围(RIPQA)已急剧增加，但管理层已因对效率的不切实际期望而不知所措。”下面的对话就是这种情况的例证——我：领导，我累了是的，到处都是“钥匙孔”，好累！领导：我们想让你做开发工作，但这一切都需要在墙后，所以你必须跳过重重障碍才能得到它。哦，我们也没有为您提供获取它们的标准化方法。领导：为什么要这么久？我：这不是真正的DevOps！领导：别这么消极。与任何宏伟的想法一样，当应用于高度复杂的企业时，这往往会失败，因为有数百种产品或服务，不同的团队为每个人提供自己独特的流程和技术堆栈。DellTechnologiesCapital总经理TylerJewell在一份研究报告中写道：“建立一个能够实现可持续发展的组织非常具有挑战性。随着系统复杂性的增加和最终用户的反馈越来越多，我们越来越难以做到预测变化对系统的可能影响。”认识到问题情况可能并不像Duggan和其他人认为的那样无望，但解决问题需要对问题的认识，尽管这可能需要对工程团队及其职责进行重大调整。“目标不是给开发人员增加负担，而是为了在正确的时间为开发人员提供正确的信息，”Harness的Durkin说。“他们不想配置所有东西，但他们确实希望在正确的时间从这些系统获得信息，以便运营、安全和基础设施团队工作。开发人员不关心，除非出现问题。”华特迪士尼公司华特迪士尼公司前董事奈杰尔·辛普森(NigelSimpson)希望公司能够认识到这个问题，“应该努力让开发人员摆脱‘担心机器如何工作’的状态，重新开始构建软件，这正是他们做得最多。擅长。重要的是，DevOps是一个连续统一体，它的实施应该因组织而异。仅仅因为开发人员现在可以做一些运维并不意味着他们也应该做运维。如何平衡开发和运维正如Gartner分析师LydiaLeong所说：“开发人员对基础设施的控制不是一个全有或全无的命题。”从“构建它，然后运行它”中获益，而不必将开发人员空降到一个未驯服的、未知的荒野，然后祝他们好运，因为它不是一个“基础设施和运维团队不再有问题了”，换句话说，“不是让开发人员对生产负全部责任，”Leong写道，“让开发人员能够完全自助访问开发和测试环境，并将基础设施构建为生产代码的模板。事实上，根据VMware的《2022 年 Kubernetes 状况》报告，776名受访者中有54%表示提高开发人员生产力是采用Kubernetes的一个关键原因，超过三分之一(37%)表示y希望提高运维人员的工作效率。根据Ondat的Brown的说法，Kubernetes的容器编排正在成为这两个团队之间的分离层，将两者的关注点分开，以便开发人员可以专注于他们的代码，而操作可以确保底层基础设施和管道经过优化以运行它。“让我们不要回到那些不互相交谈的球队，”布朗说。Humanitec创始人KasparvonGrunberg曾在邮件中写道：不要相信试图让每个人都成为专家的谬论。在高绩效团队中，Kubernetes方面的知名专家很少，其他成员的认知负荷也尽可能低。DevOps已死，SRE取而代之如果DevOps时代真的要走到尽头，或者它的光彩只是有褪色的迹象，接下来会怎样？我们之前在《??DevOps失败了???》一文中提到了“SoftOps”的概念，但目前大家更认可“SRE”（站点可靠性工程）。脱胎于Google对DevOps的成长烦恼，SRE已被证明是一种流行的解决方案。“从根本上说，当你要求软件工程师设计一个操作功能时，就会发生这种情况，”谷歌工程副总裁兼SRE教父BenTreynor经常被引用。以Vanguard和MorganStanley为例，这两家大型金融机构在过渡到更多云原生实践时发现很难平衡开发和运营责任。在中央操作层和个人开发人员之间插入SRE安全缓冲区可以帮助建立对两家公司的信心，以在开发人员生产力和操作稳定性之间取得适当的平衡。然而，SRE功能也受到了一些批评。正如摩根士丹利DevOps和企业技术架构主管TrevorBrosnan所说，建立SRE原则“有时会被误解为运营团队的品牌重塑”。“这是一个需要解决的细节，”Vanguard的站点可靠性工程师ChristinaYakomin说。“引入SRE真的感觉就像我们再次将操作隔离到这个角色中。”相反，Yakomin希望鼓励Vanguard开发人员和运营专家分担安全责任，并确保拥有共享平台的团队对他们承担全部运营责任。平台工程：“内部开发人员平台”或“平台工程学科”的想法万岁也已成为组织为开发人员提供所需工具的一种方式，具有适当的组织护栏以保护开发人员不能够采取在最好的工作上。内部开发人员平台通常包含将代码投入生产所需的API、工具、服务、知识和支持，并结合到由专门的专家或产品所有者团队维护的公司标准平台中。“DevOps已死，平台工程万岁，”软件工程师和DevOps评论员SidPalas在推特上写道。“开发人员不喜欢和基础设施打交道，企业在成长过程中需要控制自己的基础设施。平台工程让两者和谐共存。”软件咨询公司Thoughtworks（布兰登·拜尔斯）的技术总监布兰登·拜尔斯(BrandonByars)表示，他经常“看到该部门与平台工程团队一起运作良好，这些团队消除了开发人员的摩擦，同时让他们能够很好地发挥作用。”但是，有利也有弊。他补充说，“缺点是开发人员需要在没有集中的专业知识和工具支持的情况下完成所有这些工作。“任何致力于在其工程团队中实施DevOps原则的组织都会熟悉软件开发和运营团队之间的平衡。在云原生复杂的时代，这种平衡可能像“高空走钢丝”一样困难。写于最终云计算的流行与开源软件运动相结合，使得开发者的“性能选项”越来越多：可扩展性、弹性、模块化、可更新性等，这让很多人质疑这种“可选性”是否可行对于普通软件开发人员来说是一个净积极因素。在某些情况下，大量可用服务中固有的复杂性与其说是一种负担，不如说是一种优势。GoogleCloud的首席开发人员倡导者KelseyHightower认为开发人员有“选择水平”作为“礼物和诅咒”。“礼物”是使用几乎无限的技术目录构建软件的能力。泄漏到开发人员的工作流程中”。现在，许多供应商专注于托管服务和抽象。这种托管无异于开发和运维的二次拆分。在此之前，我们是否应该做一个大整合？也许对于开发人员来说，正如Hightower所说：“[开发人员]职业不仅仅是编写代码；它是达到目的的一种手段。也许我们已经构建了足够多的东西，我们可以停下来构建新的东西，以使我们的东西成熟已经有了，让不同的角色回到各自的角色。这可能是我们在过去十年中在DevOps和协作运动中看到的幸福结局。”
