你在团队里是做什么的？”
“DevOps。”
“DevOps是什么呢？”
“DevOps是一种文化、一种实践，目标是加快软件迭代速度，让团队更快交付价值。”
“能不能具体点，你们日常工作的主要内容是什么？”
“修Pipeline…”
作为一名开发，在刚涉足DevOps领域的时候，最难的就是和传统运维撇清关系；等到DevOps不再被当成是运维，又容易被当成是专职修Pipeline的人。
DevOps在一遍遍被人们提及、一次次在项目中被实践时，也在不断地被重新定义，DevOps是什么？这个问题可能到现在也比较难说清楚，但是项目中的“DevOps”做了些什么，却是清晰可见的。
本文就结合笔者的切身经历，谈一谈关于DevOps交付的价值以及在企业转型过程中遇到的一些问题。
背景介绍
客户是一家澳洲大型金融保险企业，其IT部门总人数在千人以上，维护应用两百余个。在经历了几年的收购和合并之后，在业务上指定了“将收购来的多个品牌进行整合”的大方针，于是IT部门也开始面临系统整合、业务线整合、网站合并的问题，同时客户正在将他们的服务逐渐从自建数据中心向AWS公有云服务上迁移。
团队概览
在数字化转型的漫漫长路中，该企业已经在内部搭建起了一套持续交付系统，以Jenkins为中心，有制品库、依赖管理、代码管理、任务管理系统，敏捷实践成熟。
我所在的团队是在整个组织向DevOps转型中的一个比较关键的团队，肩负着CI/CD优化、持续交付改进、运维能力输出的重任。类似的团队应该在很多DevOps转型的组织里都有，负责维护CI/CD基础设施、搭建应用开发脚手架、维护基础设施变更、做各种自动化的工作（姑且就将这类团队称之为Platform团队）。
比较特殊的是我在的这个团队实行轮岗制，由产品团队的成员（通常是开发人员）定期轮换到Platform团队，带着在产品团队遇到但是没能解决的问题，在这个团队中寻求最佳实践和解决方案，一段时间后（通常是三个月），开发人员从Platform团队回到开发团队，同时将DevOps技能和最佳实践带到产品开发团队。
整个Platform团队基本维持在3-5人的规模，有一个IM（Iteration Manager迭代经理），其余全是开发人员。
取得的成就
回顾过去的五个月，Platform团队一共经历了10个迭代（每个迭代两个星期），我梳理了一下每个迭代的工作内容，整理出主要成就如下：
围绕CI/CD做了很多优化，比如简化Jenkins slave创建流程、给自动化脚本（基础设施代码）贡献了许多新功能。
新技术试点，比如尝试将静态文件部署到AWS S3中代替Apache服务。
为应用设置监控，更新了基础设施脚本用于开启监控，并协助应用团队将配置脚本应用到各个环境。
团队之间的沟通，了解开发团队痛点，帮助开发团队找到能够解决问题的团队（权限、责任划分、知识传递），技能培训等。
响应变化，解决技术难题（虽然我认为这更像是一个沟通+权限的问题，但是其他所有团队都认为是技术难题，那我也就这样认为吧），以及修复一些类似于硬盘空间已满、网络延迟、权限的问题。
遇到的问题
当然在交付价值的同时，有很多痛点是非常折磨人的：
权限分配：作为一个跨开发团队工作的团队，不但没有拥有比开发团队更多的权限，甚至连开发团队的一些权限都没有，比如不能向开发团队的代码库提交代码(修改基础设施代码需要这个权限)，比如缺少Linux权限导致服务器底层问题没法直接修复，再比如
Jenkins 的问题追踪到了服务层需要维护Jenkins的团队支持，因为涉及到CI／CD的应用是由别的团队在管理。
沟通效率：为了解决一个bug，有时候要花上两周的时间发邮件，找关键人物，组织会议，跟不同的人解释五遍以上的上下文（技术细节的上下文是很繁琐的），最后解决问题的人还很有可能不是自己团队的（没有权限）。因为大家平时都很忙，而且建卡工作的方式让一部分人对团队请求帮助的问题不是很热心，这种情况在沟通的时候如果表现得情商不够高，对方就会要你发邮件给他们团队然后等
IM 建卡，规划到迭代里再说了，我遇到过一次这样的情况，最后还是通过社工手段拿下了这个关键人物，过程不可谓不曲折。
明确需求：Platform团队并不交付业务价值，因此没有BA(Business analyst业务分析师，通常扮演梳理需求的角色)，建卡的事基本都由IM和Dev来做，虽然感觉上是合理的，但实施起来却遇到很多问题，究其根本就是对需求的定义和划分不够明确，导致最后挪卡的时候大家都说不准这张卡算不算完成了，只能用拍脑袋的方式来决定。
质量分析：同上，团队缺少QA(Quality Assurance，质量工程师，测试人员)，Dev们都是自己做卡自己测，有时候会结对测试，但也会因为对需求理解不充分，或者说拆卡拆得有问题，导致一些卡完成得质量不够，直接影响受依赖的卡。举个例子，部署监控需要自动化脚本的两个模块支持，两个模块被分为两张卡，在做第一张卡的时候遇到了诸多问题，好不容易把代码提交到别人的版本库里了，在做第二张卡的时候却发现第一张卡代码里多写了一对引号，导致整个逻辑实现失败，这个时候再回过头来改之前的代码，又要重新解决之前遇到的各种问题（沟通、权限，PS：这个时候做第一张卡的人还下了项目），周期和浪费的工时是可想而知的。
人员轮岗：这是 IM 一直很头疼的一件事，Platform团队大量的时间花在给新来的团队成员输入上下文、同时又有成员离开团队要交接工作、尤其在沟通重要的工作中，成员的离开意味着需要新的人重新和干系人建立联系，再者，一些成员因为项目上的痛点，不是很有心思工作在团队的事务上，而是更关心自己过段时间会被分配到那个团队，如此种种都对团队的价值交付造成了很大的困扰。举一个例子，有一个端到端测试工具一直由Platform团队维护，从我加入Platform团队开始，这个测试工具就打算新增一个集成远程浏览器引擎的功能，这是一个非常有价值的功能，因为开发团队长期苦于浏览器版本支持过少，端到端测试不稳定；但是在实现过程中一直存在一个网络问题，这张卡先后被关闭、开启、标记完成、又重新开启，经历了大概五六个人的手，困扰我们的网络问题直到Platform团队解散，都没能解决。
关键角色管理：做了什么很重要，有时候让别人知道你做了什么比做了什么更重要。这一点在 Platform
团队体现的得尤为明显；在交付团队中，开发如果发现资源不足，需要和TL(Tech Lead 或是Team
Lead，可以理解为项目组长)或者PM(Production Manager 产品经理)沟通，如果缺少合适的汇报对象，一方面在团队需要外部支持或更多资源（比如权限）的时候得不到及时的支持，另一方面意味着团队缺少了更高的视角来实时回顾自己做的事情是否是正确的，方向有没有走偏，或者是不是又在造别人造过的轮子。我在团队解散后的回顾会议中，IM还坚持认为我们团队被解散是因为没有一个强有力的领导在背后支持，这也从侧面反映了我们没有找到合适的汇报人，告诉他，我们在做什么，听他说，我们下一步可以做什么。
分析
问题背后的原因及可能的改进方案
团队解散后经过一段时间的沉淀，我针对以上痛点与过往的成员一一交谈，了解了他们的想法，总结分析出了以下原因，以及可能的解决方案。
原因1：团队方向不清晰
不同于交付业务价值的产品团队，Platform团队不对某一个具体的产品负责，也不直接产出业务价值，加上Platform团队对交付的价值缺乏有效的指标度量，造成了团队方向不清晰的状况。
可能的改进方案：Platform 团队应该是属于架构师的一个机动团队，在团队方向不清晰的时候应该立即与利益相关者(Stakeholder)沟通，即与架构师取得联系，取得高视角的资源，最好能建立交付价值指标，比如Platform团队的目标是加快持续交付，提高交付质量，那就可视化开发团队发布周期、质量报告，让每个团队成员看到Platform团队交付价值的体现，从而明确团队方向。
原因2：团队角色缺失
在架构师不能全权参与团队工作的情况下（甚至Platform团队还可能没有IM），一帮Dev就很容易失去对团队整体的感知，每个Dev只关心自己手里的工作，迭代开始初期容易考虑不到全局影响、不能准确建卡，迭代进行时因为没有合适的汇报人因而跨团队交流困难，迭代结束时没有优质的回顾。
在Micromanagement Culture（微观管理文化）中有一个Alignment(校准)和Autonomy(自治)两个互斥的指标，我们使用这两个指标作为向量构成四个象限，如下图所示：
图片来源：Spotify Engineering
Culture
高校准、低自治的团队由领导决定做什么以及怎么做，团队只需要执行，这样会形成“领导说什么就是什么”的局面；
而高校准且高自治的团队是由领导指出要解决的问题以及原因，然后由团队成员相互合作共同找到问题的解决方案；
低校准、低自治的团队则缺乏活力，只能循规蹈矩；
而高自治、低校准的团队成员可以做任何他们想做的事情，领导则很无助因为没有人关心真正需要解决的问题。
在敏捷团队中，如果团队成员只剩下Dev，情形则很有可能变成图中左下象限（也有些许右下）的情况，要想达到右上象限的期望状态，需要提高自治，更多的是校准。
可能的改进方案：在意识到这个问题的时候，团队需要一个关键人物出面充当领导者的角色，扮演这个角色的人必须关注团队交付价值、目标和方向，并且有强大的沟通能力让团队成员目标一致；和利益相关者加强沟通，保证团队方向不会跑偏。
根本原因
Platform团队成立初期被定义为一个立意高远（DevOps转型）的组织，但是在项目实施过程中变得越来越边缘化，其中有“人”的原因，有组织架构的原因，当然还有一些客观原因。但我突然意识到这背后有一个原因一直忽视了，那就是——我们在实践DevOps反模式。
国内近年来一直在对DevOps如何落地争论不休，DevOps提倡的是打破开发和运维的部门墙，将开发和运维（的能力）放在一个团队。然而国内大部分项目的现状是，开发不具备运维技能和意识，也不愿意做“背锅侠”（要求开发做运维一定程度上牺牲了开发的利益，比如亚马逊的开发每隔一周会被要求24小时On-call）。
因此一些公司选择了在项目中先成立一个 “DevOps团队” 作为过渡，再慢慢将CI/CD的理念和技能扩散到其他团队，但是这种方式稍不注意就会变成“换了个名字的Ops
”，因为工作内容相似，写脚本、做高可用，这些是传统运维也会做的事情，这种形式非常不利于团队思维的转变，“团队整体对最终交付物负责”才是DevOps的精要，而不是把团队按职责划分（只对流程负责）。
这样的要求无异是给项目成员增加了工作量和责任，对他们提出了更高的要求。然而很多职员不愿意无回报地多背负一些责任，比如说开发，谁不愿意每天写点代码一提交就早早回家，DevOps要求他们得看着新功能上线，确保无误之后才能离开；所以DevOps的推行在产品团队中是有阻力的，因此DevOps的成功不光需要团队内部努力，也需要得到高层支持并扫除障碍。
反思
在一个不确定性多发的时代，快速的从成败经验中学习比找寻正确的路径更加重要。——ThoughtWorks高级咨询师顾宇
尽早找到关键角色，并且管理好利益相关人。这一点在一个扁平化组织里往往是最容易被忽视的，在意识到要和
Stackholders(利益相关者)建立联系之前，Platform 团队走了很多弯路，也错失了很多机会。
让事情发生比如何发生更重要。应该说在这5个月的工作中，我认为最有价值的是最后两个迭代开始真正搜集来自应用团队的需求，开始在两地组织各个团队的
TL 开会搜集痛点和解决方案。作为 Platform 团队的一员，这件事其实我早就意识到会是非常有价值的，但始终没有去做，总是顾虑不知道怎么去开始、去推动，担心TL
们提出的问题不能得到真正解决。但是最后这件事终于发生了，才意识到真的是非常有价值，而且早该这么做了。关于这点在我还在
ThoughtWorks 试用期的时候我的 Buddy(由公司安排负责伴随新员工渡过试用期的人) 给了我一个非常好的建议，就是决定在讲一个分享之前先把日程表（邀请邮件）发出来，这种看似是“Deadline
driven(截止日期驱动)”的方式，背后暗含了“这件事情必须发生”的道理，这和 MVP(Minumum
viable product，产品原型) 的原理也是一样的，先上线，再搜集反馈，迭代改进；就算它是一个错误的行为，这也是一次有价值的试错。
我们是否还需要DevOps团队
结合我自身的经历，“DevOps 团队”应该是一次有价值的试错，让我看到了这种方式的一些弊端，应用开发团队自身如果不具备产品思维，要由一个独立的团队去影响它们是很难的，这种实践下的
DevOps 团队就像是披着 DevOps 外衣的 Ops 团队，不能产生理想的价值。
相比之下如果有一种自上而下的方式让开发团队基于已有业务基础之上去优化交付流程，并对每一个提交的最终价值负责，将产品思维真正植入到开发团队，从而达到全局优化的效果，这种做法才更符合真正的
DevOps 精神。 |
