“你在团队里是做什么的?”
“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 个迭代(每个迭代两个星期),我梳理了一下每个迭代的工作内容,整理出主要成就如下:
遇到的问题
当然在交付价值的同时,有很多痛点是非常折磨人的:
分析
问题背后的原因及可能的改进方案
团队解散后经过一段时间的沉淀,我针对以上痛点与过往的成员一一交谈,了解了他们的想法,总结分析出了以下原因,以及可能的解决方案。
原因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 高级咨询师顾宇
我们是否还需要 DevOps 团队
结合我自身的经历,“DevOps 团队”应该是一次有价值的试错,让我看到了这种方式的一些弊端,应用开发团队自身如果不具备产品思维,要由一个独立的团队去影响它们是很难的,这种实践下的 DevOps 团队就像是披着 DevOps 外衣的 Ops 团队,不能产生理想的价值。
相比之下如果有一种自上而下的方式让开发团队基于已有业务基础之上去优化交付流程,并对每一个提交的最终价值负责,将产品思维真正植入到开发团队,从而达到全局优化的效果,这种做法才更符合真正的 DevOps 精神。
更多精彩洞见,请关注微信公众号:思特沃克