大熊最近在 ThoughtWorks 给大家讲数字平台战略(Digital Platform Strategy)，非常高兴向大家地宣布，我们已经有了战略框架，鼓励项目上的同事多讲讲故事，那我就来讲一个。借此对过去5个月在项目上的磕磕绊绊做个整理。

背景介绍

客户是一家澳洲大型金融保险企业，在保险领域处于本地绝对领先地位，其IT部门总人数在千人以上，维护应用两百余个。在经历了几年的收购和合并之后，在业务上指定了将收购来的多个品牌进行整合的大方针，于是IT部门也开始面临着系统整合，业务线整合，网站合并的问题，同时客户正在将他们的服务逐渐从自建数据中心向 AWS 公有云服务上迁移。

团队概览

在数字化转型的漫漫长路中，该企业已经在内部搭建起了一套持续交付系统，以Jenkins为中心，有制品库，依赖管理，代码管理，任务管理系统，敏捷实践成熟。

我所在的团队是在整个组织向 DevOps 转型中的一个比较关键的团队，肩负着 CI/CD 优化、持续交付改进、运维能力输出的重任。类似的团队应该在很多 DevOps 转型的组织里都有，负责维护 CI/CD 基础设施，搭建应用开发脚手架，维护基础设施变更，做各种自动化的工作（姑且就将这类团队称之为 Platform 团队）。比较特殊的是我在的这个团队实行轮岗制，由产品团队的成员（通常是开发）定期轮换到 Platform 团队，带着在产品团队遇到但是没能解决的问题，在这个团队寻求最佳实践和解决方案，一段时间后（通常是三个月），开发从 Platform 团队回到开发团队，同时将 DevOps 技能和最佳实践待到产品开发团队。整个 Platform 团队大小基本维持在3-5人，有一个 IM（Iteration Manager 迭代经理），其余全是 Dev (Developer 开发)。

取得的成就

回顾过去的五个月，Platform 团队一共经历了10个迭代（每个迭代两个星期），我梳理了一下每个迭代的工作内容，整理出主要成就如下：

• 围绕 CI/CD 做了很多优化，比如简化 Jenkins slave 创建流程，给自动化脚本（基础设施代码）贡献了许多新功能。
• 新技术试点，比如尝试用将静态文件部署到 AWS S3 中代替 Apache 服务。
• 为应用设置监控，更新了基础设施脚本用于开启监控，并协助应用团队将配置脚本应用到各个环境。
• 团队之间的沟通，了解开发团队痛点，帮助开发团队找到能够解决问题的团队（权限，责任划分，知识传递），技能培训等。
• 响应变化，解决技术难题（虽然我认为更多的还是一个沟通+权限的问题，但是其他所有团队都认为是技术难题那我也就这样认为吧），以及修复一些类似于硬盘空间已满，网络延迟，权限的的问题。

遇到的问题

当然在交付价值的同时有很多痛点是非常痛的：

• 权限，作为一个和各个开发团队沟通的团队，不但没有比开发团队更多的权限，甚至连开发团队的一些权限都没有，比如不能向开发团队的代码库 Push 代码(修改基础设施代码需要这个权限)，比如 Linux 底层问题没法直接修复，因为只有应用级别的权限，再比如 Jenkins 没有服务器权限，出了问题也不能修，因为这些应用是由别的团队专门管理。
• 沟通，为了解决一个 bug，有时候要花上两周的时间发邮件，找关键人物，组织会议，跟不同的人解释五遍以上的上下文（技术细节的上下文是很繁琐的），最后解决问题的人还很有可能不是自己团队的（没有权限）。因为大家平时都很忙，而且建卡工作的方式让一部分人对团队请求帮助的问题不是很热心，这种情况在沟通的时候如果表现得情商不够高对方就会要你发邮件给他们团队然后等 IM 建卡，规划到迭代里再说了，我遇到过一次这样的情况，最后还是通过社工手段拿下了这个关键人物，过程不可谓不曲折。
• 需求，Platform 团队并不交付业务价值，因此没有 BA(Business analyst 业务分析师，通常扮演梳理需求的角色)，建卡的事基本都由 IM 和 Dev 来做，虽然感觉上是合理的，但实施起来却遇到很多问题，究其根本就是因为对需求的定义和划分不够明确，往往导致最后挪卡的时候大家都说不准这张卡算不算完成了，只能用拍脑袋的方式来决定。
• 质量，同上，团队缺少QA(Quality Assurance，质量工程师，测试人员)，Dev 们都是自己做卡自己测，有时候会结对测试，但也会因为对需求理解不充分，或者说拆卡拆得有问题，导致一些卡完成得质量不够，直接影响受依赖的卡。举个例子，部署监控需要自动化脚本的两个模块支持，两个模块被分为两张卡，在做第一张卡的时候遇到了诸多问题，好不容易把代码 Push 到别人的版本库里了，在做第二张卡的时候却发现第一张卡代码里多写了一对引号，导致整个逻辑实现失败，这个时候再回过头来改之前的代码，又要重新解决之前遇到的各种问题（沟通、权限，PS：这个时候做第一张卡的人还下了项目），周期和浪费的工时是可想而知的。
• 轮岗，这是 IM 一直很头疼的一件事，Platform 团队大量的时间花在给新来的团队成员输入上下文，同时又有成员离开团队要交接工作，尤其在沟通重要的工作中，成员的离开意味着需要新的人重新和干系人建立联系，再者，一些成员因为项目上的痛点，不是很有心思工作在团队的事务上，而是更关心自己过段时间会被分配到那个团队，如此种种都对团队的价值交付造成了很大的困扰。举一个例子，有一个端到端测试工具一直由 Platform 团队维护，从我加入 Platform 团队开始，这个测试工具就打算新增一个集成远程浏览器引擎的功能，这是一个非常有价值的功能，因为开发团队长期苦于浏览器版本支持过少，端到端测试不稳定；但是在实现过程中一直存在一个网络问题，这张卡先后被关闭，开启，标记完成，又重新开启，经历了大概五六个人的手，困扰我们的网络问题直到 Platform 团队解散，都没能解决。
• 汇报，虽说 ThoughtWorks 是扁平化管理，但是面对一个金字塔结构的客户难免也会需要固定有资深的人和客户的高层对接，这种安排是合理且必要的；在交付团队中，开发如果发现资源不足，需要和 TL(Tech Lead 或是 Team Lead，可以理解为项目组长)或者 PM(Production Manager 产品经理)沟通，但是在 Platform 团队，没有合适的汇报对象，一方面在 ThoughtWorks 内部没有工作关系紧密的架构师或者 TL，另一方面客户的汇报线变动频繁，也就是客户的领导也在变，在团队成员缺少资源需要更高管理层的决策支持时沟通难度增加。比如在申请权限时需要客户领导审批，客户的领导却一直在会议中，要么就找不到人（海外项目远程办公，只能通过及时通讯软件呼叫客户），让在团队中别的客户成员帮忙跟进，客户也是无奈地摊摊手，一次又一次在站会中重复着“他很忙，我找不到他”，诸如此类。同样，没有合适的汇报人意味着团队缺少了更高的视角来实时回顾自己做的事情是否是正确的，方向有没有走偏，或者是不是又在造别人造过的轮子。我在团队解散后跟“前” IM 聊天，他还坚持认为我们团队被解散是因为没有一个强有力的领导在背后支持，这也从侧面反映了我们没有找到合适的汇报人，告诉他，我们在做什么，听他说，我们下一步可以做什么。

分析

问题背后的原因及可能的改进方案

团队解散后经过一段时间的沉淀，也和过往的成员逐一了解了他们的想法，总结分析出了以下原因，以及可能的解决方案能使做得更好。

原因1：团队方向不清晰

不同于交付业务价值的产品团队，Platform 团队不对某一个具体的产品负责，也不直接产出业务价值，所以这个团队应该是属于架构师的一个机动团队，因此客户的架构师的离开，就为 Platform 团队解散埋下了伏笔。（这一点我也是后来才意识到的）
可能的改进方案：在团队利益相关者(Stakeholder)缺失的时候，应立即与我方架构师沟通，在明确团队方向的同时还能发挥 ThoughtWorks 影响力。

原因2：团队角色缺失

在架构师不能全权参与团队工作的情况下（甚至 Platform 团队还一度没有 IM ），一帮 Dev 就很容易对团队整体整体的感知，每个 Dev 只关心自己手里的工作，迭代开始初期容易考虑不到全局影响不能准确建卡，迭代进行时因为没有合适的汇报人因而跨团队交流困难，迭代结束时没有优质的回顾。
在 Micromanagement culture（微观管理文化）中有一个 Alignment(校准)和 Autonomy(自治)两个互斥的指标，我们使用这两个指标作为向量构成四个象限，如下图所示，高校准低自治的团队由领导决定做什么以及怎么做，团队只需要执行，这样会形成“领导说什么就是什么”的局面；而高校准且高自治的团队是由领导指出要解决的问题以及原因，然后由团队成员相互合作共同找到问题的解决方案；低校准低自治的团队则缺乏活力，只能循规蹈矩；而高自治低校准的团队成员可以坐任何他们想做的事情，领导则很无助因为没有人关心真正需要的解决的问题。在敏捷团队中，如果只剩下了 Dev，情形则很有可能变成图中左下象限（也有些许右下）的情况，要想达到右上象限的期望状态，需要提高自治，更多的是校准。
可能的改进方案：在意识到这个问题的时候，团队需要一个关键人物出面充当领导者的角色，扮演这个角色的人必须关注在团队交付价值，目标和方向，并且有强大的沟通能力让团队成目标一致；和利益相关者加强沟通，保证团队方向不会跑偏。

根本原因

Platform 团队成立初期被定义为一个立意高远（DevOps 转型）的组织，但是在项目实施过程中变得越来越边缘化，其中有“人”的原因，有组织架构的原因，当然还有一些客观原因。但我突然意识到这背后有一个原因一直被我忽视了，那就是————我们在实践 DevOps 反模式。

国内近年来一直在对 DevOps 如何落地争论不休，DevOps 提倡的是打破开发和运维的部门墙，将开发和运维（的能力）放在一个团队。然而国内大部分项目的现状是，开发不具备运维技能和意识，也不愿意做“背锅侠”（要求开发做运维一定程度上牺牲了开发的利益，比如亚马逊的开发会隔周会被要求24小时 On-call），因此一些公司选择了在项目中先成立一个 “DevOps 团队” 作为过渡，再慢慢将 CI/CD 的理念和技能扩散到其他团队，但是这种方式稍不注意就会变成“换了个名字的 Ops ”，因为工作内容相似，写脚本，做高可用，这些是传统运维也会做的事情，这种形式非常不利于团队思维的转变，“对最终交付物负责”才是 DevOps 的精要，而不是职责划分（只对流程负责）。这样的要求无异是给项目成员增加了工作量和责任，对他们提出了更高的要求。然而很多职员不愿意无回报地多背负一些责任，比如说开发，谁不愿意每天写点代码一提交就早早回家，DevOps 要求他们得看着新功能上线，确保无误之后才能离开；所以 DevOps 的推行在产品团队中是有阻力的，因此，DevOps 应该是场自上而下的运动。

反思

做一个项目要有一个项目的收获，不然工作十年你只拥有了十年的工作经历，而不是十年的工作经验。

———— 朱平

• 尽早找到关系人，并和他建立联系。
  这一点是我觉得最需要反省的，在项目进行到7、8个迭代的时候才意识到要和我方架构师和技术专家建立联系，在此之前走了很多弯路，也错失了很多机会。
• 让事情发生比如何发生更重要。
  应该说在这5个月的工作中，我最喜欢的部分是最后两个迭代我们开始真正搜集来自应用团队的需求，开始在两地组织各个团队的 TL 开会搜集痛点和解决方案。这件事其实我早就意识到会是非常有价值的，但始终没有去做，总是顾虑不知道怎么去开始，去推动，担心自己表述不清，或者不能给 TL 真正解决问题会很不好意思。但是最后这件事终于发生了，才意识到真的是非常有价值，而且早该这么做了。
  关于这点在我还在 ThoughtWorks 试用期的时候我的 Buddy(由公司安排负责伴随新员工过度试用期的人) 给了我一个非常好的建议，就是决定要讲一个分享之前先把日程表（邀请邮件）发出来，这种看似是“Deadline driven(截止日期驱动)”的方式，背后暗含了“这件事情必须发生”的道理，这和 MVP(Minumum viable product，产品原型) 的原理也是一样的，先上线，再搜集反馈，迭代改进；就算它是一个错误的行为，这也是一次有价值的试错。
  类似的事情还有很多，比如敢于和客户沟通，敢于在团队承担很多责任，都可以借鉴。

下一步

结合我自身的经历，“DevOps 团队”的实践并不是一个很好地工作体验，应用开发团队自身如果不具备产品思维，要由一个独立的团队去影响它们是很难的，这样的实践下的 DevOps 团队就像是披着 DevOps 外衣的 Ops 团队，不能产生理想的价值。
相比之下我更愿意去到一个真正的产品团队做一名开发，交付真正的业务价值。这样不单会让开发更有成就感，而且作为一个有 DevOps 精神的开发，在真正熟悉业务需求之后做出的整体优化，才会更有价值，这种做法也更复合真正的 DevOps 精神。

DevOps 的未来

自2017年以来，有一个趋势已经越来越明显，那就是 DevOps 已经越来越多的被一些平台厂商（这里的平台指的是应用代码所需的脚手架及基础设施）掌握了话语权，以 AWS 和 Pivotal 为例，这两家公司一家是做公有云，一家做 PaaS(Platform as a Service，平台即服务)，他们一边卖自己的产品，一边卖着咨询，一边运营着自己的社区，四处宣讲最佳实践，在行业内形成一个以生态圈为中心的闭环，不断向外扩张自己的影响力。同时因为自建平台常常是工具的拼凑很难形成一整套好的解决方案，且维护成本也高，越来越多的公司被吸引去尝试使用他们的产品，接受他们的理念。我也相信，这些平台厂商在良好的现金流和足够多的用户支撑下，能够把平台做得越来越好。到那时候，我们不用提及 DevOps，每个项目都是 DevOps 的。

本文已授权转载至 ThoughTworks 洞见: DevOps团队之殇