最近两年DevOps组织转型带来的新问题

Posted 2021-04-16 敏于思 捷于行

“ 最近两年，不管是集团还是部门，都在如火如荼地进行DevOps组织转型，转型基于DevOps的一些基本原则，出发点都是为了提高交付效率，更快、更好地响应业务部门的需求。但是，由此又产生了新的问题。持续改善是一个没有终点的旅程，谨借此文给大家一些分享和反思。别人的成功不可复制，但别人踩过的坑，你可以绕行。”

01

—

开发/运维一体化

过去我们的开发团队与运维团队是分开的。第一线的运维由整合的运维团队负责，直接面对业务，干着最苦最累的“背锅侠”的活。开发团队集中精力在项目交付和运维部门无法处理的问题上。由于没有参与开发，运维团队的知识积累也存在障碍。基于DevOps中提倡的“谁开发、谁运维”的原则，我们调整所有团队的结构，拆散了整合的运维团队，运维人员按照业务线“插队”到各开发团队中。我们希望籍此可以让业务线团队负责从开发到运维的整个链条，也让原来的运维人员有机会参与到项目工作中，提高他们的工作满意度，原来的开发人员也要参与运维，在开发中更多地考虑到生产环境运行的问题。有重大问题时，整个团队都可以参与运维、解决问题。

但这个模式产生了两个新问题：

1、开发与运维在一起并不会完全实现“谁开发、谁运维”。因为人员是流动的，你今天运维的东西，其开发人员可能早已离开了团队。今天开发的东西，将来出问题的时候该开发人员可能也已经不在团队了。在这样的现实条件下，帮自己“擦屁股”的概率不高。

2、如果我们应对的业务是本地的，这个模式没太大毛病。但如果应对的是全球业务，问题就来了。全球业务涉及到不同的时区，在原来的整合运维团队模式下，可以安排轮班和不同地区的运维人员接力。但是当运维团队拆散分配到各业务线团队时，通常都因人手问题无法实现不同地区接力，而且为了保证交付效率，我们也希望交付团队尽量在同一地点，这会导致轮班和正常工作时间外的运维事件严重影响团队在次日的交付工作。

教训：如果需要支持全球业务，开发与运维在一起是否是好的模式？

02

—

产品团队

传统团队建制都是基于项目的，由于项目都是一次性的活动，对于系统作为一个产品的持续改造、技术债的偿还、DevOps改进等活动，都不是项目关心的事情，便鲜有人员可以投放在这些层面。因此我们把团队按照现有系统的维度重新编制，每个小团队负责一个系统的端到端交付，包括开发与运维，也能满足前面说的“谁开发、谁运维”原则。项目需求以条目化的形式进入产品团队的Backlog排序。

我们想籍此实现的目标有：

• 人员方面——每个人都有机会参与不同的项目，不再有人长期参与重要项目，有人只能负责系统维护，提升了工作热情与士气。

• DevOps方面——从项目视角转化为产品视角，是DevOps进程的开端。每个小分队关注自己的产品，更易于进行持续的产品改进。

• 交付方面——更有效地安排人员满足不同项目的需求。

• 敏捷方面——每个小分队可以管理自己的Backlog和迭代计划。

• 运维方面——每个人都有机会对生产环境进行贡献，参与运维与小交付，并实现“谁开发、谁维护”的原则。

• 职责方面——每个小分队的职责清晰，负责端到端交付，减少交接与中间人角色。

• 技术方面——更利于进行架构重审与重构。

然而，产生的结果却是项目经理与产品团队负责人的严重分歧，IT部门内部窝里斗。本来我们想通过人员与项目的分离，倒逼项目以敏捷方式管理需求，把需求拆细，以条目化的形式进入产品团队的Backlog，而且进入Backlog的应该是已经“就绪”的需求（满足User Story的INVEST原则），产品团队根据运维以及各项目需求的优先级逐个处理。但是由于部分大型的项目的上层管理依然是瀑布模式的，项目经理一定要紧盯计划，而人员已经不在项目经理手上，项目经理没法做这个计划，项目经理和产品团队负责人经常为谁该做计划吵得不可开交。产品负责人认为团队应该聚焦在交付上，但项目经理有来自上层交计划的压力。彼此的目标分化了。

其实在这中间，缺了一个角色，也就是来自业务的PO，由于项目需求都来自业务，这本来就是业务需要协调的事情。但是由于我们新的团队划分是根据IT系统来做的，这样的维度是找不到一个可以对接的业务代表的。要找到合适的PO，应该按照业务产品来切分。而且目前的预算也是从项目中来，这就主导了生产方式必须围绕着项目来开展。

教训：要实现产品/特性团队，首先要找到业务产品的合理切分点（当然要足够小和独立，请参阅），然后根据康威定律，IT团队与之对接。

03

—

IT运维部门的去中心化

过去IT运维部门是独立的，他们掌管着一切基础设施，如服务器、中间件、网络以及相应的专家团队。由于重要的权限都掌握在专家团队手上，交付团队如果无法获得专家团队的支持，项目根本进展不下去。当各业务线的项目需求越来越多时，他们就成了整个集团的瓶颈。尽管IT运维部门也在努力建设私有云及服务自助化，但革命尚未成功，卡在半道上。

为了解决瓶颈问题，IT运维部门开始去中心化，人员重新分配到各业务线团队中。但是以DBA为例，多大的团队需要一个全职DBA成了一个问题。团队太小，拥有一个DBA响应力绝对没有问题，但是无法充分利用其时间。如果几个团队共享一个DBA，又会重新出现原来的瓶颈问题。如果这个DBA不在你的时区，则更头疼。

教训：响应力与资源效率，从来就是一对矛盾，如何拿捏这个分寸，是一个难点。IT运维部门的云化与服务自助化可能才是改革的重点。

你今天看到的所有问题，都是曾经的解决方案！尽信书不如无书，针对具体问题，持续改善才是王道。

欢迎留言一起讨论。

关于作者

---

• 早期敏捷践行者

• 起步于极限编程

• 熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书

点击“原文链接”可直接购书