集团公司内部推进DevOps的几点感悟。
0. 目录
1. 前言
不得不说，这看着很美好，听着也很美好的DevOps，宣传时各方也都给与高度评价，纷纷表示其要解决的问题正是他们平时工作中所深恶痛绝的。但在实际推进过程中，却是横拢地拉车——一步一个坎，各种非技术问题的接踵而至，让你陷入不断地自我怀疑 —— 这么费心费力地，我他喵到底图个啥？
作为一种流程管理思想，DevOps的落地必须结合所在公司的实际情况来对症下药，必须先深刻理解团队当前的状态，然后才能因地制宜地，将DevOps中的各类思想和操作一点点引入进去。
除非有高层领导的铁腕支持，否则在现有团队中推进DevOps，你最好是抓住DevOps的神，而不要在形上过于纠结。
本文尝试总结截至目前为止，笔者在集团公司内部推进DevOps所秉承的一些准则。相较于笔者之前的【DEVOPS】最佳实践和指导思想，本篇博文更多的是个人总结，用词上更加口语化，更多强调实践感受。
2. 背景
正式开始经验分享前，先介绍下公司背景。
公司属于非常传统的电子政务公司，由业务驱动一路发展起来，期间没有进行过专门的流程管理改进，相关的办事流程属于走一步看一步建设起来的。也由于公司的业务特点，对于技术人员要求并不高，因此员工的职业素养方面也不能报太大希望。
领导对员工没有过强的约束力，即使犯错也不敢轻易责罚员工。——就给这点工资，在哪干不干，你再BB爷不伺候了。因此自上而下的决策除非直接和工资相关，否则执行程度完全看天。但是如果政策过多与工资挂钩，又会进一步激化员工关系。
因此在这样的企业，领导对于改良的态度基本就是“不见兔子不撒鹰，不见鬼子不挂弦”，只有看到改良带来的实际好处之后，领导才出现宣布将改良作为一项企业制度推进下去。前期更多的是对于改良的默许和私下支持。
记住上面这一点，它是下面这些最佳实践的基石。
3. 整体指导思路
指导思想这种东西，字数越少越好，太多了一来自己可能忘记，二来也是不便于宣讲和推广。
- 先减负，再加正。
- 完成比完美重要，且重要得多。
上面这两条，专门解释下：
- “先减负，再加正”。你要通过观察团队的当下工作协作流程， 采取DevOps思想评估当下他们流程里的痛点，找出那些改进ROI最高的点——只需要少量甚至不需要改变他们的现有工作流程，甚至能够直接去掉他们原本的某些工作流程节点，推进这些措施降低他们当下的工作压力，进而赢得他们的信任，然后再将DevOps流程里那些对当下流程影响较大，需要作出改变较多的措施按照实际情况编排后的顺序逐一推到台前。
不要一上来就试图在团队原本已经紧张的工作压力上，再加上几条新措施，这只会遭受激烈的反抗，这与你推进的措施是不是对的关系不大，每个人对待工作意义的认知是不同的，你要承认这一点 —— 这里的承认是从心底去理解并遵从，而不是口头上承认之后，转身就大声责备这帮人朽木不可雕，明明这些新制度推进下去之后能大大减轻团队的压力，团队之前的很多问题就会消失不见，而他们只会摆出各种借口拒绝执行。
尤其是起步初期领导不会进行公开地支持，你更得抓住这一准则，先采取改良减轻团队成员的工作压力，然后用新的DevOps填补上这些节省下来的工作时间，然后重复以上操作，进入正向循环。 - “完成比完美重要”。DevOps推进过程中经常出现的另外一个问题是，当你推动某项改良起步时候，之前原本对此兴趣不大的团队成本看着你规划出来的流程，指点道"唉，你这个节点不应该这样，可以那样那样做效率更高"，“你这个节点执行太慢了，可以那样那样来加快执行速度”，“你这个不能解决xxx，我想要的yyy能不能一并解决了，要不你就得给我把所有问题在这一个流程里全部解决掉，要不就继续之前的路数不要折腾了”等等。
这个时候千万不要过多地陷入和对方的细节拉锯中，我们之后有的是时间进行改良，现在的重点是让流程执行起来，将整个团队赶到流程上来，之后改良的需求会自己主动跳到面前，而且那个时候的改良，更具体，也更实际。
4. 最佳实践清单
让我们正式开始吧。
4.1 标准完善
大型软件开发和运维过程中，团队协作属于必选项， 而在团队协作中，沟通的重要性又是属于怎么强调都不过分，为了降低沟通成本，我们需要进行一系列的约定来降低不必要的摩擦成本。这一系列的约定最终也就是所谓的"标准"了。
按照很多DevOps先行者的经验，都会首先强调标准的重要性，强烈建议"标准先行"。
这里我并不是要搞什么特立独行，我也非常认同标准的重要性，但标准的推进势必带来现有团队工作习惯的改变，而这一定会造成现有团队成员的反抗（没有人是自愿走出舒适区的），正如上面的背景介绍里所说，在没有高层领导的公开支持在先，甚至如果领导自己本身就是含糊的，加上新制度推荐初期，对于整体协作效率上一定是会出现短暂降低的。这种背景下，换位思考下，你作为领导接到的现团队成员反馈，客户反馈之后， 你会如何看待当下新标准的推进？
因此，本小节标题我用的是“标准完善”，DevOps推进不必过于在乎形式，把握住DevOps思想，在解决团队问题的过程中，采取利诱的方式逐步形成新的标准，采取润物细无声的方式将标准落实下去。
- 对待标准的形成和推广，都应该采取小范围试点，逐步推广，以点带面。
- 在实际推进过程中，要不断宣讲标准的关键点，不要将希望寄托在成员的主动了解上，相反你要假设他们都完全不感兴趣，并且即使说了马上就会忘记，你需要不断强化人员认知，寻找一切机会给接触到的每一个人灌输标准。当你说到不想再说的时候，改变才会开始。
4.2 先把操作全部赶到流程上来
这一小节其实就是上面"完成比完美重要"的具体展现。
DevOps推进过程中，一定会对现有团队成员每个人的操作习惯造成影响，他们势必会提出各种要求，要求你作出适应，这个时候的你就要把握这个原则，只要对方提出的要求不是完全开倒车，那么就不要拘泥于什么与业界DevOps最佳实践不符，和对方进行沟通，双方各让一步来将该员工所代表的节点拉入到改进后的流程中。
只要能把人先拉到新的流程上，之后在改良阶段，你有的时间和机会调整。
- 虽然上面我的有些言论似乎将绝大部分的团队成员放在被批判的对立面，但其实并非如此，因为他们的选择才是正常的，是普遍存在的现象，是事实，是必须被承认的事实。所以你必须接受可直观感受到的改良发生是一个非常缓慢的过程。
- 在认清人性好逸恶劳，宁愿体力上付出十分也不愿意脑力上付出一分的弱点之外，你还需要相信人们对优秀的天然追求 —— “我本可以忍受黑暗，如果我不曾见过光明” ，如果你的改良让他们感受到事情在发生有利的变化，那他们会自己转变态度，让你的DevOps进程不断加速。
4.3 多写文档
在DevOps改良的推进过程中，牵扯到大量的新知识的普及，除了会议宣讲，一对一沟通之外，这里要再专门强调下文档的重要。
经典笑话"最厌恶的是接手的代码没有文档 VS 最不喜欢的就是写文档"常看常新。除非经过刻意的认识训练，否则按照人性好恶形成的工作习惯，文档这东西一定是能省则省。
作为推进者的你，需要尽快扭转这样的认知：
- 文档化知识能够有效降低你的重复性劳作。新知识和新制度的普及需要被每一个人知晓，繁杂的业务压力之下，领导不会允许脱产式学习，文档可以让你原本一对一地复读机式地介绍变为指向性文档链接的分发。让你有机会将宝贵的注意力分派在疑难问题解决上。
- 文档实现了最大范围的知识共享。别跟我说什么发到群里了，不要让信息在小范围里(比如群里)自嗨，你跟我这玩特务接头呢，生怕第三个人知道了。
- 再补充一个自私的观点：哪怕是为了你自己，你也最好多写点文档，现在劳心劳力的时候很少有人会主动上来帮忙，但到时候事情做成分功劳的时候，你信不信个顶个都是斯巴达战士，记录好你的每一步决策作出的过程，以及最终的决定，让文档的编写时间和数量来作为你努力付出的铁证，你应得的就应该分给你，老实人不该被人拿枪指着。
- 关于哪些应该记录成文档，本来我是很想像古尔丹劝地狱咆哮那样说句everything的，但这里我决定尽量具体些： 想象你未来某个时间点开始，你需要作为前辈，为新人讲解流程细节；作为核心骨干在某些技术论坛上介绍流程的形成过程等等，那么为了担当好这些角色，眼下的你需要准备哪些东西？ 想好了的话，那现在就开始记录吧。
- 最后要专门强调一下：文档必须是在线的，实时分享，实时更新。文档就应该你这边更新了，我这边马上就能看到，然后我们继续讨论下一个需要优化的细节。不要再跟我说什么文档内容初级怕人笑话，文档还没有写好不宜公开。没人对你的文档感兴趣，专门跑去挑你的毛病；也不要聊天工具里你扔过来我扔过去地传递文档，一个更新整个团队鸡飞狗跳，每个人都在质疑手上的文档是不是最新的。
4.4 断开直接联系
很多时候，人们总是喜欢直接面对面沟通，认为这样效率高，文字来文字去半天扯不清楚的交流还不如直接面对面几句话就解决了。这一点在上面背景里介绍的协作流程里非常常见。
世间没有完美的事情，上面高效沟通方式的副作用缺乏留痕，以及大量信息的个性化（例如对于同一个概念，员工甲称呼为A，而员工乙称呼为B，那在沟通的时候，各方除了熟悉A，B的意义外，还得看看所面对沟通的对象是谁，才能最终确认名词的含义；另外比较典型的就是一些他人也需要使用的产出物，各团队按照自己内部的规则存放，其他人只有在直接找到团队内部熟悉这件事的人才能获得想要的东西）。
针对上面这样的场景和问题，我们就需要不断宣讲和推广“断开直接联系”的理念：
- 不要搞"一句话需求"。哪怕真的只有一句话，你也给我把它按照约定的结构写到禅道里面去，然后我们再一点点掰扯这个需求到底应该是什么样子，这个掰扯的过程也要记录在禅道里。
- 关于产出物的存放，统一存放规则。哪怕你团队内部有自己的规则，你也给我放在一个公开的位置，然后广而告知存放规则，之后你负责存，别人只负责取，基于这个存放规则去操作，不要每次都是一问一答地乐此不疲。
- 产出物的说明性信息，你给我直接和产出物绑定在一起。不要产出物放这，说明信息放那，甚至直接口头喊两声就自认为任务完成了。
我们要极力避免面对面式沟通，"QQ"式地单对单沟通，留痕，留痕，还是TNND留痕。
QQ那种不叫留痕，能够广而告之，任何利益方可以方便地查询到的，才叫留痕。
4.5 可观测性
我们借用下运维监控领域目前非常火热的概念名词"可观测性"作为小节标题。
监控领域的可观测性，是在原本监控快速定位问题的基础上再次提升要求，能够快速确定系统为什么不能工作。
我们在DevOps推进过程中也需要时刻秉承这样的思想：
- 信息找得到，与信息非常容易获取， 这两者之间的差别比想象中的要大得多。我不是在和你玩猜谜游戏，把相关的信息公示出来，明确告知对方应该在哪里可以找到，并保持信息更新。
- 在DevOps推进开始，第一个流程开始试点之后， 你就要考虑针对性地进行报表开发和展示了。打补丁方式形成的流程中，上级对于问题进度的了解基本都是通过下级的汇报完成的，这就会造成因为缺乏独立信息来源，导致上级被下级牵着鼻子走，进而失去对于问题真实情况的掌握。 DevOps推进时就需要避免这种情况，在将团队成员的操作迁移到新建流程的过程中，还是流程开始试点，或者是之后的平稳运行之后，我们都应该基于度量的思维 , 数据思维，针对性地进行统计报表的设计和实施，通过对于数据的统计展示揭示团队当前健康状况的真实呈现，一来展示我们改良的效果，二来也是借助收集来的数据来为下一步优化提供方向。
- 核心思想还是要将问题及时暴露出来。有问题不能藏，养病如养虎，虎大要伤人；小问题藏来藏去到压不住的时候，代价更大。而且很多时候问题的相关方甚多，可能你觉得很棘手的问题，在兄弟部门看来稍微变通下就完成了。
- 将团队当前的进度情况直接呈现在所有人面前，并且可以让其他感兴趣的人都可以轻易获取。这是可观测性的追求，也是DevOps改良的追求。
- 本小节相关的一些实例，参见我之前写过一些相关的文章 ——【DEVOPS】基于禅道 - 重构研发协作流程。
4.6 顺势而为
关于这一小节，只看标题有点让人丈二和尚摸不着头脑。
正如前面所说，DevOps推进的起步阶段，领导不会给出明面上的直接支持。你之所以想要推动DevOps改良，肯定是因为看到了团队里导致效率底下的各种问题，你希望有所改进。领导也不是傻子，在日常的管理工作中他肯定也能看到这些问题，之所以默许你的改革，原因也是在于此。
针对看到的问题，领导也是有着自己的解决方案思考的，他也会自己判断接下来应该干什么可以解决眼前的问题，而往往这些解决方案确实是你的改良计划里的一个关键点，只是不适合当下团队基础条件下，也就是领导的想法太超前了，团队当前的状况不支持立即实行这个解决方案。这个时候，除非万不得已，否则建议你先按照领导的思路去执行操作，让他自己见证方案实施后的效果，不要拧着领导来，他想要啥效果你就先实现，哪怕看着现阶段为时过早。
我在公司推进DevOps的初期，领导们被产品质量始终无法有效提升所头疼，而在了解同行业其他公司的方案后，认定自动化测试是解决这类问题的关键。但现实是当时的我们，连测试用例都还没有规范化地管理起来，自动化测试如无源之水，成功的可能性为零。
当时我们最终决定先抛开现实，就按照领导的想法去做，让领导自己去看最终的效果。如果一开始就拧着领导的认知去行事，那么在初期这种双方信任尚浅的情况下，很容易造成各种各样的误会，导致事情夭折。
除了在向上争取信任的同时，也尽量避免拧着一线人员来：
- 多个改良行动中，优先选择变动小，见效快的。
- 某项改良，如果实现的方向不止一个，优先选阻力小的，即使它会带来某些隐患。只要可控，那就不要太在意。
盯紧你的目标，结果导向，其他的都只是方法。不要舍本逐末。
4.7 把问题逼到角落里
不论日常工作，还是生活中，人们其实都是在解决各种各样的问题，而价值也正是在解决问题的过程中产生的。
类似的观点推广到DevOps改良中也是如此， 我们正是通过解决一个又一个的问题来推进DevOps改良进度的。
而在DevOps改良中发现的问题通常有"牵扯利益方多"的特点，这导致问题解决起来举步维艰——每个人都做到了自己该做的，每个人都没责任，但问题就是没解决。
所以我们需要强化一下相应的思维认知，我们需要"将问题逼到角落里"：
- 尽量往前走。首先是从我们自身出发，拆解问题之后将能够做的尽量都做了，我们关注的是解决问题，而不是职责范围。然后开始逐步推动其它人员的跟进。
- 盯着问题 / 保持对问题的跟踪。上面的"牵扯利益方多"的特点，非常容易造成的一个现象就是每次说起来就全是抱怨，抱怨各种各样的问题，但一旦吐槽/分锅会议结束，这事就算是过去了，之前怎么干的接下来继续怎么干，等待吐槽/分锅会的再次召开。我们需要采用各种各样的方法盯紧问题，提示各方问题的存在以及进度。比如将问题清单化，并保持更新，避免每次都搞成复盘 —— 先讨论有什么问题，然后发现一个都解决不了，于是不了了之；下次继续同样的操作。先记录下来，拆解问题，解决掉几个；下次的时候直接拉出清单，逼着在场的人拆解问题，再解决几个，循环往复。（Zentao的主要用途之一）
4.8 向开源社区学习
最后，在面对一些抉择时候，如果你无法作出决定，那么就看看开源社区是如何处理类似问题的吧，看看如何用爱发电的前提下，依然可以创造出奇迹。
去看看那些稳定运行多年，依然保持着活跃氛围，旺盛生命力的社区，比如Spring，Apache Camel等等，看看他们是怎么协作的？甚至可以亲身参与感受下。
5. 补充
以下内容过于细碎，因此单独归拢为小节。
- 在整个DevOps改良推进过程中，解决每个问题都至少存在两种方案，首先当然是要求相关人员提高责任意识，能够对结果负责；其二则是思考如何从流程上来解决和杜绝问题出现。对于这两种方案，无脑选第二种，只有当第二种做得非常深入，继续下去ROI过低的时候，才开始考虑着手第一种方法的推进。人是最难改变的，或者干脆直接认定人是不可能改变的，这有助于在推进DevOps的过程中，不会那么容易放弃。
6. 思考
关于DevOps改良的推进，你需要付出很多，远远超出你所获取的工资，在这种背景下，为了获得心态上的平衡，思考下几个问题：
- 如果让你重来一遍，你还是在见招拆招？ 是否有些东西是可以快速复制的？
- 关于DevOps，你自己的认知是否已经体系化？这直接决定你是否有机会进行知识的二次销售。