当你打开这篇文章的时候,也许你也在为DevOps的落地而苦恼,也许你的组织正在尝试DevOps转型,作为一线的实践者,说说我对这个“落地难”的看法,欢迎交流不同看法~
DevOps是实践摸索出来的,别人的终究是别人的
如下图所示,你可能在不同企业研发效能的分享都看到过,各种关于DevOps的书上有会提到DevOps的CALMS 框架(该首字母缩写词由《DevOps 手册》的合著者 Jez Humble 提出,且分别代表文化 (Culture)、自动化 (Automation)、精益 (Lean)、衡量 (Measurement) 和分享 (Sharing)),告诉你通过何种手段,何种步骤来推进DevOps落地实施。
你听了,感觉说的都很有道理,可是好像没有解决自己遇到的问题🤔
- 不同的组织文化不同,领导有的懂技术,有的完全是外行
- 不同的业务不同,互联网的玩法对传统企业是不适用的,特别是发布节奏
- 技术债务不同,新的项目可以轻松上路,老的项目只能“负重前行”
- 研发团队对转型的态度不同,有的团队很封闭,有的团队很开放
- 是否有“专家”角色帮助梳理整个流程
- 有的买的商用平台工具,有的自研平台
- 组织规模不同,几十人,几百人到上千人的转型肯定不是一回事
所有这些因素决定了,可以参考,但是没法照抄。因为DevOps转型不仅仅是个技术问题,而是一次“组织”的变革之旅。
你可能会遇到的转型阻碍
提到组织,首先就是人,面对转型他们大概都是这样的想法和态度。
- 对于领导,他们会经常问你,效果怎么样?你需要面对灵魂拷问,如何向不懂“DevOps”的领导解释做这个实践的意义。对于领导,他们更关注业务的增长,成本的降低,对于什么最佳实践,他们是不懂的
- 对于团队,他们会告诉你我知道有好处,我怎么开始需要投入多少?你能给我提供什么?我很忙,没看到你们做这个事情的意义!你们提供给我的,不是我最急迫的!
- 对于转型团队内部,需要告诉他们怎么配合,可能你和他们不是一个部门,也许你们的目标并不完全一致
以下来自《中国DevOps现状调查报告(2022)》
**组织缺少具备 DevOps 经验的专家、组织不清楚 DevOps 的路线图成为限制组织级 DevOps 转型的 最大障碍。 **
调查显示,28.65% 的企业组织缺少具备 DevOps 经验的专家,导致推进缓慢甚至无从下手;25.47% 的组织不清楚 DevOps 的路线图以及如何进行转型,同比增长 5%;25.40% 的企业受限于组织行业的 限制。另有 21.10% 的企业项目团队工作繁重,没有时间进行 DevOps 改进。
别人的转型之路?
普遍的转型方式如下图所示,无非就是
- 自上而下,领导强势要求
- 自下而上,个别团队试点,经验推广
- 引进咨询机构,或者成立转型小组
可是现实是
- 大老板或CTO只是提了要求,指派了某位“领导”来负责这个事情,定期听听汇报,遇到不懂的领导死活讲不清楚
- 自下而上,如果组织规模较小(几十人规模)还有可能,最多也只能推广到自己的小部门
- 引入咨询机构,不是每个组织都有咨询费,另外转型是个漫长的过程,最终落地还是组织内部自己落地
到了这里,只能感叹“理想很美好,现实很骨感”。
面对现实,如何破局?
寻找“反抗军”,找到你的目标用户
在《独角兽项目》这本书中,主角来到一个“陌生的杂乱无序,连一周都没有产出成功构建的组织”,通过在和“各个角色”接触过程中,发现了“反抗军”,他们和主角一样希望解决当前的困境。建议去看看,你可能有种似曾相识的感觉。
如何找到目标用户
一般来说转型初期,你可能会遇到以下这四种角色
- 拥护者:这就是你要找的“反抗军”,但是初期他们不会自己站出来,需要你“快速”甄别出来
- 徘徊者:认可带来的收益,但是对投入比较担心,你需要展示真实的“案例”和收益给他看
- 旁观者:对转型不是很关注,也不反对,属于人云亦云型,跟随者
- 反对者:你的改进可能对他影响很大,触及他的利益,或者他曾经受过“折腾”,对转型丧失信心产生抵触心理
对于前面两类角色,是你主要争取合作的对象,特别是拥护者,要能切实解决他们的问题,赢得信任。对于后面两类角色,转型初期,他们绝不是你的“目标用户”,他们往往在整个组织里的地位比较重要,业务压力也是最大的,你必须保持足够耐心。
每个团队的leader的风格和经历也很重要,如果曾经在高效的组织工作过,他们带领的团队也可能是你合作的目标,但是他们的要求会很高,这个也可能是个小小的“阻碍”。
识别改进点,解决关键问题
寻找目标用户的过程,其实也是识别他们痛点的过程,你需要帮助他们找到问题,刚开始他们是不清楚到底哪里病了,只是知道痛而已。通常有以下几种方式引导识别问题
价值流分析
DevOps的理论基础就是“精益思想”,所以通过精益价值流分析是比较普遍的做法,但是这种更适合“工作坊”,另外需要团队理解什么是“精益”,什么是价值流,这种评估方式适合有一定经验的专家教练引导。
能力评价体系
这种通过行业标准的方式,对照参考,寻找差距,制定改进计划,更多适用于企业评级,比较正式。
团队访谈
上面两种方式都是比较高大上,偏正式的套路,需要一定的组织能力和引导能力,如果你已经参与上述活动,恭喜你,已经有专家在指导你们做改进了。
这里提供一个更“省钱”,更容易执行的方式,出去跑“客户”,和研发团队“促膝长谈”,引导他们说出自己的问题(注意,引导交谈方式,别被研发团队带偏了,你要引导他们到你的思路上)
- 你们现在的痛点是什么?
- 我这里有这样一个能力或方案,你们看行不行?这样可以帮助你们xxxxx
- 你的问题可能另外一个方式更合适,也能帮助你解决
找出共性问题,建立改进清单
引导说出共性问题
通过前期的团队访谈或者工作坊,你需要梳理出来“普遍”的共性问题(PS: 砍掉那些稀奇古怪的个性化需求),并且告诉团队问题解决后能带来的收益,绘制一个宏伟的蓝图,画个大饼~
在人力有限情况下,尽可能把大家拉到一个“同性问题”上,最好还是性价比高的问题(PS: 投资少,见效果,快速取得客户信任),对于“底子”差的组织,更是如此。
评估团队,制定不同策略
不同的团队情况不同,底子也不同,痛点不同,建立团队的档案。如果有可能,制定明确的标准和要求,也许会事半功倍
注意:团队可能比较关心获得这些收益需要哪些投入,这个可能你需要提前准备好应对的方案和各种辅导材料准备,避免用户流失。
共同制定改进清单,跟踪评价
你需要和团队的代表(这里最好是固定的研发效能爱好者,也许他会让改进事半功倍)共同制定改进清单,刚开始定一个“小目标”,周期别太长了,不要超过一个月。
目标感-进展感-协作感
记住这三个关键词,如果没有清晰的目标,双方感觉不到进展,沟通完后没有任何协作,或者单方的努力,都可能导致改进失败。作为教练,你需要保持这个警惕,与团队要有互动,时刻保持“关心”。
小时候,你改掉一个坏毛病,不还要老师父母在屁股后面整天说,同理,你要时刻向团队灌输最佳实践,保持和他们的互动。
平台工程团队及时响应用户需求
一般在你的背后,应该有个平台工程团队建设与之配套的效能提升有关的基础设施(代码仓库,制品库,流水线,代码扫描,自动化测试等)。
他们需要针对目标用户的需求和问题,做出快速反应。除了自助服务开发,教育和协作也成为挑战。平台工程师发现,他们花越来越多的时间培训应用程序开发人员,让他们了解最佳实践和如何最好地使用平台。应用程序开发人员还发现他们依赖于其他应用程序开发人员团队,并期望平台工程团队为他们提供与不同团队高效协作的工具。
保持曝光率,不断洗脑
组织改进的过程是个长期而艰难的过程,不要指望某个工具,某次培训宣讲,就能达到预期效果。为了让你的用户知道“你们”和你们的“平台”,需要提高曝光率,你要当作一个“产品”在运营,你要和你的用户建立联系,收集他们的需求,听取他们的心声,但是如果他们连你的工具有什么功能都不知道,能够带给他们的收益都不清楚,你的“产品功能”再牛逼,也是没有任何价值的。
- 定期通过组织内部渠道(论坛,邮件,公众号)等打广告
- 定期组织关于平台功能和DevOps实践的培训分享
- 建立用户行为分析体系,你需要知道推出的哪个功能用户喜欢,活跃度高
- 定期发布优秀实践案例
团结一切可以团结的力量
DevOps贯穿整个研发过程,所以会涉及到不同的部门,特别是“部门墙”很严重的组织。有人会说,DevOps不就是要推翻“部门墙”的吗?那个是理想状态,现实不会和书上说的那样。
一般来说,你可能需要打交道的会涉及项目管理部门,企业IT部门,技术中台部门,安全部门等组织级公共部门,这是另外一波你要合作的对象。
特别是,项目管理部门(PMO),组织的流程规范都是通过他们发出的,但是往往他们并不具备相应的能力,你们需要合作。当然,怎么合作也是有讲究的,往往他们并不懂技术,更多你要做解释,寻求理解支持。
定期汇报,展示成果
做了这么多,你需要去汇报了,要去面对领导的“灵魂拷问”,效果怎么样?这也是比较头痛的问题,难在哪里呢?
- 特别是传统企业,甚至可能都不是IT企业,领导不懂技术,更别提DevOps了
- 你讲最佳实践,讲技术方案,讲敏捷如何好,DevOps如何好,都没用,效果呢?
这里其实就是值得讨论的一个问题,什么是效果?
很明显,你需要告诉他效能提高多少?那什么是效能?如何定义效能?是否能提供数据?什么数据?领导是否认可这些数据,构建频率/时长/前置时间等等,是否他们明白背后的意识呢?
留个思考题,欢迎讨论~
转型过程避坑指南
开始要想清楚
- 组织解决什么问题,也许一开始是会想不清楚,那么聘请外部专家是个合适的选择
- 引入什么工具,什么是合适的工具,能花钱买的千万别自己开发,能开发的也不要一股脑都是商用,工具是助力的,不是添堵的
- 转型组织的构成有那些人,是否合适,要能各展所长
- 要做长远规划,一年目标,三年目标,五年目标
切记“大跃进”
不要急于匆忙上马,不要以为买个工具或平台,就可以全面使用接入了,这个要衡量下是否真的能解决问题。往往这是“自上而下”往下推,由领导发号施令产生的,他们急于看到效果,往往不了解什么是DevOps.
这样做的后果是,团队不再信任改进,抱怨声一大堆,最后可能就失败了。
多走进团队,多引导
研发团队是你的用户,你需要走进他们,了解真实情况,不要以为外面商业的平台就一定能解决他们的问题,特别是大型组织,他们的需求千奇百怪,往往你需要适应他们,再去改进。而不是上来就说,你们怎么不好,不是最佳实践,商业平台必须这么玩,这个真的要看团队的底子好不好。
组织转型的过程,其实是改变别人十几年工作习惯的问题,是需要引导,培训,指导,提升认知的,让他们知道什么是好的,什么是不好的。
不要过度迷信成熟度模型
虽然我上面也提到了成熟度模型,但是这个仅仅是个参考。鞋子合不合适还是要看穿鞋的人,“成熟度”只是给你定义了标准的鞋子应该如何生产。对穿惯了布鞋的人来说,他需要的只是轻便合脚,对于穿惯了运动鞋的人来说,他需要的是能够弹跳好。同理,团队/组织的基础目标不同,不能一概而论,也许他只只适合爬个小山丘,没必要要求他能爬珠穆朗玛峰,不现实,他要的也许是“减肥”,而不是成为“专业运动员”。
过度迷信成熟度,往往容易走偏,给转型带来不利因素。
总结:落地套路关键词
总结下,DevOps落地是以“技术工具”为实现手段,“各种最佳实践”为赋能指引,“组织级流程规范”为牵引,通过各部门角色的合作,对现有“混乱”状态进行改造的过程。
人们总说拥抱变化,但是当变化到来时,他们却拒绝变化,因为已经习惯,即使低效无趣,也不想改变。所以,做了DevOps的实践者,你需要找到合适的套路去影响他们。
- 赢得用户信任,建立良好的合作关系,甚至是个人关系
- 投资回报率优先,不要试图强加一些不切实际的最佳实践和要求给团队,他们需要“投入少,见效快”。改进是有成本的,寻找收益最大化的方案
- 利益分析,互相吹捧,互相成就
- 提供真实的,一定数量的成功案例
- 保持耐心,循序渐进,接受不完美
参考
- 成熟度模型已死,请你别靠近DevOps
- 成熟度模型罪与罚 - Thoughtworks洞见
- 敏捷流畅度:找到适合需求的敏捷方式_文化 & 方法_Diana Larsen_InfoQ精选文章
- CNCF 平台白皮书 | 云原生资料库
- 敏捷流畅之路——敏捷成功的简要指南
我的博客即将同步至腾讯云开发者社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=2oacl07nc9ic0