当你打开这篇文章的时候,也许你也在为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落地难,到底难在哪里?也许你还没找到套路的更多相关文章

  1. DevOps落地实践点滴和踩坑记录-(1)

    记录初衷 本人一直在从事企业内DevOps落地实践的工作,走了不少弯路,也努力在想办法解决面临的问题,期间也经历过不少人和事情,最近突然有想法把经历过的,不管好的不好的都记录下来,分享给和我一样的一线 ...

  2. DevOps 转型到底难不难(转自成哥的世界)

    原文:https://mp.weixin.qq.com/s/QwZf6ZsKGNT6YyereSmpQg DevOps 自 2009 年诞生以来,至今整整过去了十年,从最初的摸索,逐步变成一种主流的软 ...

  3. 互联网研发效能之去哪儿网(Qunar)核心领域DevOps落地实践

    本文从业务目标角度出发,确定了开源+自建模式搭建 Qunar 研发工具链整体生态:通过 APPCODE 打通工具链,流程规范化自动化:多种手段+发布门禁助力质量提升:建立应用画像确定运维最小单元,可发 ...

  4. 基于微服务的DevOps落地指南 交付效率提升40%

    基于微服务的DevOps落地指南 交付效率提升40% 2015-2016年,珍爱线下门店已新增覆盖城市9个,与此同时,CRM系统大小故障却发生了数十起... ... 珍爱网是以“网络征选+人工红娘”模 ...

  5. DevOps落地实践点滴和踩坑记录-(2) -聊聊平台建设

    很久没有写文章记录了,上一篇文章像流水账一样,把所见所闻一个个记录下来.这次专门聊聊DevOps平台的建设吧,有些新的体会和思考,希望给正在做这个事情的同学们一些启发吧. DevOps落地实践点滴和踩 ...

  6. TFS在项目中DevOps落地进程(下)

    紧接上篇 TFS在项目中Devops落地进程(上) 再接着说TFS相关之前先插入一个番外篇,虽然跟TFS关系不大但跟DevOps关系很大,觉得有必要在此乱入一下. 番外篇--监控之Applicatio ...

  7. DEVOPS落地实践分享

    DEVOPS落地实践分享 转载本文需注明出处:微信公众号EAWorld,违者必究. 引言: DevOps的理念已经说了很多年,其带来的价值逐渐被接受,很多企业也逐渐引入了DevOps.目前普元DevO ...

  8. php artisan 命令报错,什么命令都是这个错误,cmd下运行也不行,又没看到语法错误

    Laravel 5.1 以上的版本的框架需求PHP的版本是5.5以上的版本.如果你的PHP版本等级太低,将会出现上述的问题. 估计你要升级你的PHP版本了.

  9. 在由N个元素构成的集合S中,找出最小元素C,满足C=A-B,其中A,B是都集合S中的元素,没找到则返回-1

    package bianchengti; /* * 在由N个元素构成的集合S中,找出最小元素C,满足C=A-B, * 其中A,B是都集合S中的元素,没找到则返回-1 */ public class f ...

  10. 不会吧,你连Java 多线程线程安全都还没搞明白,难怪你面试总不过

    什么是线程安全? 当一个线程在同一时刻共享同一个全局变量或静态变量时,可能会受到其他线程的干扰,导致数据有问题,这种现象就叫线程安全问题. 为什么有线程安全问题? 当多个线程同时共享,同一个全局变量或 ...

随机推荐

  1. Nginx http 文件服务器 中文名称文件乱码以及不能访问下载问题 (解决全过程)

    书接上文: 在Windows 环境下使用 Nginx 搭建 HTTP文件服务器 实现文件下载 全步骤(详细) _ 发现的中文乱码问题,终于自己解决了! ^_^ Nginx http 文件服务器 中文名 ...

  2. 痞子衡嵌入式:盘点国内RISC-V内核MCU厂商(2018年发布产品)

    大家好,我是痞子衡,是正经搞技术的痞子.今天痞子衡给大家介绍的是国内RISC-V内核MCU厂商(2018). 虽然RISC-V风潮已经吹了好几年,但2019年才是其真正进入主流市场的元年,最近国内大量 ...

  3. 干货 | BitSail Connector 开发详解系列一:Source

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 BitSail 是字节跳动自研的数据集成产品,支持多种异构数据源间的数据同步,并提供离线.实时.全量.增量场景下全 ...

  4. flutter issue---->Scaffold.of(context)

    当我们想showSnackBar的时候,需要通过Scaffold.of(context)得到Scaffold.但是如果这个context用错的话,flutter就会抛出错误.下面我们通过代码仔细看一下 ...

  5. DOM选择器之元素节点选择器

    <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8&quo ...

  6. CPU内部的奥秘:代码是如何被执行的?

    我们是袋鼠云数栈 UED 团队,致力于打造优秀的一站式数据中台产品.我们始终保持工匠精神,探索前端道路,为社区积累并传播经验价值. 本文作者:景明 我们以一段 C 代码为例,来看一下代码被编译成二进制 ...

  7. Thread 线程中的 Synchronized block and lock

    Thread Definition of Synchronized Synchronized block in java are marked with the synchronized keywor ...

  8. 二进制安装Kubernetes(k8s) v1.26.0 IPv4/IPv6双栈

    二进制安装Kubernetes(k8s) v1.26.0 IPv4/IPv6双栈 https://github.com/cby-chen/Kubernetes 开源不易,帮忙点个star,谢谢了 介绍 ...

  9. 联邦学习FATE框架安装搭建

    联邦学习 FATE (Federated AI Technology Enabler) 是微众银行AI部门发起的开源项目,为联邦学习生态系统提供了可靠的安全计算框架.FATE项目使用多方安全计算 (M ...

  10. [Linux]Vmwaer创建CENTOS7虚拟机

    1 前期准备 CENTOS系统镜像 本实验版本: CENTOS 7.9 安装 VMware Workstation 本实验版本: VMware Workstation Pro 15.0 2 VMwar ...