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