阶段性总结。
0. 目录
1. 前言
自上次的【DEVOPS】DevOps推进过程中的一些最佳实践之后，在过去的半年实践中，对DevOps在传统软件公司中的落地有了一些新的或着更为深刻的理解和感悟。因此有必要作一个阶段性总结，一来避免可能的遗忘所带来的惋惜，二来也是为有限的大脑内存释放压力，以便迎接之后更为复杂的难题。
背景方面因为之前文章已经介绍过了，因此以下就捞干的，直接进入正题。
2. 最佳实践清单
2.1 必要的弯路
其实不仅仅是DevOps，只要是一个涉及人数较多的方案或制度需要落地，尤其是在采取自下而上的方式推进时，你会逐渐认清现实：哪怕明知道前面是岔路，你也得亲身走一遍，这是你试图极力避免，但最终发现逃不掉的命运。
自下而上的推进方式一般属于被迫的，毕竟但凡能够获得领导鼎力支持，直接降维打击，强迫对方按照你设计的方案执行，不管是从实际推进速度，还是从心理上(“我就喜欢你这种看不惯又不得不听我的感觉”)，都是让制度推进者非常满意 。没有谁闲得蛋疼给自己增加挑战难度，因为这件事本身的难度就已经足够了。
虽然现代社会高度分工化，但归结到每个岗位上，其实还是有着相当大的左右摇摆空间的。否则就不会有所谓的职业责任心，职业道德等等这些要求了；也不会有什么日久弥新的"精益生产"模式。正如《置身事内》作者所描述的，如果得不到执行者的认可和支持，那么制度或方案的落地非常容易半途而废，无疾而终。
自上而下的方案推进方式之下，你可以借助行政权力强迫执行者度过最开始的不适期，等到改进产生好的效果时，执行层自然会慢慢转变态度。
但在自下而上的推进方式下，你需要在一开始就把争取执行层，以及高层的支持放在首位，所谓天时地利人和，这里面的人和永远是被放在最高位置的。
既然是要争取支持，统一认识，那么自然我们需要实事求是地，尝试着理解他们的思维习惯，以及在一定程度上顺着他们的思考方式执行，明知道这么下去会撞上。但所谓"事教人，一遍就会"，这个时候你需要权衡方案的执行后果，如果认为在可控范围内，那就按照对方的思路走，快速把他带到墙面前，在他撞上之后重新陈诉一遍你的构想。
举一个稍微具体些的例子，过去多年在推进DevOps过程中，我遇到了要求跳过需求评估，人员相关能力培养等前置条件，直接开始进行甘特图计算和展示，以此作为研发进度安排的；也见过在没有完整测试用例集和相关成熟流程支持下，要求直接开始进行自动化测试的等。
我也曾经一再试图说服对方你这根本就是无源之水，缘木求鱼，基础都没有你搁着盖古巴比伦空中花园呢。奈何效果甚微，甚至你的劝导起到了一种负向强化的效果 —— 对方更为坚定地认为他的想法是对的。
在你没有做出来之前，他们会强烈认为就是这个东西没有做出来导致的问题。但你做出来，他们亲身体验过几次之后，他们就噤声了。
上面阐述了"必要的弯路"是为了争取信任和支持，但有几点需要强调下：
- 这里弯路只是针对当下的场景。但并不是说已经做过的这些没有意义，做这些事情一来让对方看到你有这个实力，二来未来你还是会用到它们，它们只是出现得早了些（对于当下的环境），比如上面实际例子里的甘特图和自动化测试，这些被前辈们一再验证过的最佳实践。
- 上面说的"权衡方案的执行后果"，其中的一个指标就是方案的反馈周期不能太长。比如接口参数是用map还是自定义bean的问题，这你就不能和一线研发人员去掰扯了，对于那些两三个月重新开始一个新项目的研发人员，他们无法理解为什么？这个时候你需要的是跟那些拥有历史项目重构经验的研发人员或者项目负责人去沟通。
2.2 灵活机动，适可而止
自下而上的推进方式说明了你没有更多的行政权力，无法强迫对方做啥。而标准化意味着对方工作习惯的改变，这其中的阻力不言自明。
所以在实际推进过程中，你需要要多点开花，并时刻注意各方面的进度，如果发现阻力变大或者推进困难，那就先搁置。通过不断试探来把每个点上的ROI最大的那条线试出来。既要让相关方看到效果，又不要制造出过多的抵触力量。
不用担心因为搁置导致半途而废，星星之火已经种下，DevOps所谋的全局等得起。而且人员的培养需要时间，思维的转变也需要时间，我们也要有耐心。
2.3 抓大放小
刚接触管理的同学很容易陷入"事必躬亲"的窘境 —— 底下人抱怨没有自由，没有进步空间，自己累得半死，还不如回去当个核心骨干轻松。
DevOps的推进也要避免这种情况，规定好整体流程的每个节点，以及相应的职责，并在实践中不断调整细化。
但是与此同时，一定要秉承"放小"的原则，给予整个流程中每个节点适度的摇摆空间，这样一来是对错综复杂的现实场景的适应，也是实际执行者一定的自由度，让他们也参与到流程的优化中。
2.4 频繁测试
正如《代码大全》之父Steve McConnell的最近发言 —— “只要测试足够频繁，软件跑起来基本不会遇到太多麻烦”。
频繁测试属于典型的"以终为始"，下游倒逼上游。
- 你想要做到频繁测试，那你需要做到全流程的自动化。包括自动打包，自动集成，自动部署等等。
- 你想要做到频繁测试，你就需要有一个完善的测试集，一套完善的自动化测试流程。
- 你想要做到频繁测试，你的整套自动化流程应该拥有足够的灵活性和弹性，以应对各类突发情况和特殊的业务需求。这对于整体流程的设计者提出了非常高的要求，也暗示了整套流程需要进行持续性地优化。
频繁测试之下，问题曲线会比较平缓，应对起来也会比较从容，否则就跟火山爆发，时不时突然蹦一下，会贼刺激。
2.5 需要写文档的标准
在之前的最佳实践中，我们介绍了要为什么要多写文档。这里补充说明下"什么情况发生时，就代表需要考虑写一篇文档了"：
- 凡是需要你教授给别人，都需要在文档里。
- 内容的受众越广，落地为文档的需求越强烈，ROI越高。
- 某个问题是花费了一些时间才解决的。即使这部分时间都是用来搜索到的解决方案也算。
文档是用来沟通和修改的，不是裱起来瞻仰的。尤其现在这研发任务量不大的时候，主管们更得有意识地让研发多写些总结性文档；以及针对内部前沿技术研究的，首次出现的问题，更得留下文档痕迹。
文档的重要目的之一是为了从团队的视角去看待问题，避免各自为战，陷入老鼠跑圈的循环中。毕竟面对同一个坑里来回踩，健身呢这是。
3. 题外话
3.1 人类的本质果然是个复读机
以上便是过去这半年收集到素材，在经过整理之后所幸存下来的。原本以为都是些新视角，新发现。心中甚至有点小窃喜，但在实际成文过程中，对比之前的文章还是发现有着不少重复的，甚至上面汇报出来的观点里也是有着已经陈诉过的对应观点。
唉，人类的本质果然是个复读机。不过这也应和了笔者之前所总结的 —— 元思维其实就那么几个，之后基本就是在此基础上的加深和换角度论述了。
所以，阶段性总结确实是非常有必要的。
3.2 减少沟通成本的含义
我们总说DevOps是为了让机器代替人工的重复性操作，降低沟通成本。这里我们尝试从人的角色角度，总结下"减少沟通成本的含义：
- 老带新。这是主要目的之一，因为对于老人来说，他熟悉公司内部的技术栈，熟悉公司的工作流程，但新人对此却是完全不清楚的。如果这些流程和细节都在脑子里，那一个团队和公司的稳定性是存在非常大隐患的。知识的传承只能依赖几千年来旧社会那样师傅带徒弟的方式，以极低地效率进行。
- 老人之间的交流。不是说两个人已经都知道了所有这些规则之后，交流顺畅。这个不是我们关注的重点。
- 新人之间的交流。这也是主要目的之一。自动化的流程可以大幅降低人员心智，避免人工操作的不可琢磨性，让新人快速上手，减少沟通时的噪音。