当你打开这篇文章的时候，也许你也在为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 平台白皮书 | 云原生资料库
- 敏捷流畅之路——敏捷成功的简要指南
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net
