中拔出溜的公司如何实施DEVOPS

虽然推进起来很艰难，但在这类公司也并非一无是处：只要让各方尤其是领导曾看到了成效，大范围铺开很容易，你也非常容易因此变得出众。

1. 中拔出溜公司的特点

按照本系列文章的风格，开篇咱们依然是针对本文讨论的主题，针对性说明下中拔出溜公司的特点：

1. 业务场景要求低，CRUD式研发，无专业运维。 这些特点在这个链接里已有详尽介绍。
2. 业务研发压力大。以上背景下公司想要盈利肯定不会做什么小而美的产品，广撒网接项目、项目周期短、业务功能点多、非功能性需求很少考虑等是其主要特点。
3. 项目管理处于蛮荒阶段，缺乏过程管理，项目负责人的认知和态度对于项目最终质量的影响巨大。
4. 项目团队里对于软件工程理解严重缺乏。普遍信奉人多力量大，大力出奇迹。

在项目管理上，中拔出溜公司既没法像小公司那样快速掉头，直接重新从零开始去适应市面上的成熟流程；也没法像大公司那样——人员认知到位，直接从上往下压，并且有足够的人力来支撑自研和内部持续推进。所以如果真正想要落地DEVOPS，过程远比想象中的要曲折 —— 问题永远不会是出在技术了。

2. 循序渐进

对于这种彻彻底底的自下而上，我们需要遵循"晓之以理，不如诱之以利"的基本指导思路，仔细衡量，持续监测所推进的每一步改良，做到灵活机动。

这里需要额外说明一句：多年以来，以我个人的观察，很多这类公司，即使是做到总监级别（我这里说的是职级），也只习惯于在一言堂的情形下做决定，完全没有经历过复杂场景下的决策博弈和方案落地。直接表现上就是思维方式很简单：我是不会允许xxx，我要求他们必须xxx。

2.1 从研发团队开始

原因很简单，研发人员属于是这个团队里最有能力，也是最有希望改变这一切的。

彼此如齿轮咬合在一起的团队协作里，我们要先将某个齿轮的转速提上来，并且持续保持并优化下去，逐步打通整个链条，最终实现全面变革。

当前这一切并不简单，要不我也不至于从18年做到现在，现在政府项目都开始软件过程管理的投标了，我这依然是成绩寥寥；所谓"起大早赶晚集"，现在都已经不是晚不晚的问题，是这集都要散了。

2.2 先CI（持续集成）

对于毫无基础的团队，推荐从CI开始。这一步改动非常小，而且对于研发人员的观感体验上也是有利无害，所以非常容易争取到相关支持，为进一步的改良打下良好基础：

1. CI解决了打包电脑环境各异导致的诡异问题。早几年我亲眼见证研发人员本机jdk1.7打包，然后在jdk1.8的服务器上部署，花费半个团队大半天时间去调查。
2. 同时搭配集中的制品版本库实现打包制品版本的统一管理和交流，历史追溯。这一步最简单的实现方式就是Nginx+操作系统自身的文件系统，如此可以快速让研发和测试/技术支持看到效果，争取支持。
3. 上一步的基础上，接着出现的需求就会是"制品版本说明"的问题，因为打包和制品存储下载的统一，各方也看到了其中的好处，接下来你就可以开始借机推进需求管理的标准化，以及代码提交的标准化，并且在此基础上最终实现需求说明，提交代码，打包制品三者之间的彼此关联绑定，这个过程的全自动化将大幅降低沟通成本。
4. 另外"Nginx+文件系统"这一简陋的集中制品库还有很多额外的惊喜。 典型如例如Nginx的静态文件服务器特点，搭建简单的信息共享黄页——将组织内部需要共享的信息统一放在上面，杜绝信息的反复摩擦沟通。这一点按现在时髦的说法算是IDP（内部开发者平台）的一部分。（虽然市面上有着诸多开源项目来做到类似的事情，但对于当前阶段的我们来说，足够简单且尽量减少所需引入的额外工具以最大化降低运维成本才是核心诉求）

2.3 再CD（持续部署）

在上一步见效，有部分主动性较高的组员愿意参与进来，实现自运转之后，马上要进入落地环节的就是CD了。

在前一阶段CI让相关成员感受到CI的好处之后，接下来你只需要稍微演示下CD，其进展会比过往快不少。不过有一些需要注意的：

1. 对于本文论及的公司类别，有一部分概率其部署服务器并非我们通常认知里的linux环境，而是Windows-Server（好吧，我所在的就是。至于原因嘛，其实很简单，运维要求低，可以以更低的成本招聘到人），这种情况下的CD就不要轻易变更 —— 想着我先切到Linux下，然后再实施CD。那样很大概率会失败 —— 都能够选择Windows-Server作为部署服务器了，说明研发以及相关的测试/售后团队对Linux的熟悉程度等于没有，在这种情况下贸然变更，将带来一系列的问题，这将阻止原有的工作流程，对于软件工程管理基本概念都缺失的团队，从上到下都会逼着你退回来。
2. 想明白了上一条，接下来你要做的就是在现有工作流程上小心翼翼地迈出第一步。这里以笔者的经验是将CD过程拆解为三个步骤：推送到目标服务器，解压，最后是自动化部署。
   2.1 之所以要做拆分，一来是为了实现小步快跑，通过小幅优化来减小所引入的风险，避免失败打击各方对我们的信心。以我个人的经验，对于部署包较大的团队，这一步改进就已经能够争取到售后/测试团队的支持。
   2.2 虽然拆分为了三个步骤，但其实将制品推送到目标服务器和解压这两者是可以合并实行的。
   2.3 最后一步的"自动化部署"可以在前两者稳定一到两个月之后再推进，不要过于心急。

针对使用到的工具，如果你的部署环境大部分还真是Windows-Server的，那我这里推荐一下Ansible。

这一步的成功除了可以进一步收获到各方的信任和支持外，还有很多可能意料之外的好处：

1. 首先是人工操作的低级错误将被杜绝。
2. 部署目录结构的标准化。相较于过往每次报告问题时起手三板斧的拉据问题”系统部署在哪里？“、"部署的是什么版本"等，CD有助于让各方形成共识，消除这部分无价值的琐事操作，尽快进入问题修复环节。
3. 这一步可以将我们心心念念的服务器的控制权收回来，如此的好处多多：比如部署环境的一致性、可控制性、变更一致性和及时性、资源管理和分配等等。
4. 搭配之后将要推动的监控/告警，我们将最终实现各方对于服务器的无感知化 —— 他们不需要关心系统被部署在哪里，不再被这类琐事耽误哪怕一秒钟，只需关心好业务需求是否实现即可。

2.4 告警/监控

在上面这两步推进之后，你会发现还有一个相当关键的问题 —— 相关人员还是有登录部署服务器的需求，这除了会带来配置飘逸等某些莫名其妙的问题外，也在导致你始终无法对服务器进行自由掌控——典型如上面所说的Windows-Server作为部署服务器时，相关问题解决很难找到解决方案，不像Linux那样一搜一大把。

关于监控这一块，这里给出我的个人理解：把监控细分两大块：a）自身内部环境下的监控，b）生产环境下的监控：

1. 关于后者，可以参考本人前两天发表的中拔出溜的公司如何落地监控体系。注意，中拔出溜公司的监控以够用就行，针对本地化部署的软件，数量多，规模小；此背景下监控上一堆高大上的，那最终只会造成越俎代庖 —— 好处一点没看到，一堆研发被逼成半拉运维。
2. 自身内部的监控可以稍微激进一些。整一个集中部署的监控服务端（例如Skywalking，CAT，Zabbix，Prometheus，Grafana等），然后在各个小组中试点。注：自身内部可以作为监控的培训基地，技术试验场而存在。
3. 关于监控的推荐，我依然是延续之前的思路：Loki + TraceId基本可以解决95%的问题。重点是不断优化这个方案，让公司内部的产品全部接进来。

2.5 最后是自动化测试，

对于中拔出溜公司内的大部分团队而言，不大会走到这一步，所以这里我就不再阐述一些细节问题。

以我个人的见证，这个流程进行实际的常态化使用，今年已经是第三个年头了，从一开始的"测试用例都没有"情况下被领导逼着强行启动自动化测试，到后来通过跟着领导思路走让他看到这样确实不大行，然后反过来从基础测试用例迭代开始，一步步走过来可谓步步惊心 —— 各方的不配合，领导认知含糊等等，每一步都能让你的放弃看着是那么理直气壮。

2.6 不要教条

以上只是我在实践中最终走通，然后通过反向总结出来的基本流程。

这里我想要强调一下的是：不要教条主义，你应该依据实际情况进行对应的调整，以上步骤也不是严格的先后顺序。以我自身为例，CI，CD，监控这三块其实在整个流程中都有持续并行推进，根据所参与的团队不同推荐并实际参与不同方案的落地。主打的就是"哪怕往前推半步也行，你们觉得好，下次愿意听进去我半句话就算没白忙活"。

3. 后记

给别人做信息化的软件公司，自己内部信息化却一言难尽。一个为了让机器代替人工操作的职业，自己的工作流程里却有着大量的人工操作痕迹。每每想到这些真是五味杂陈。

但是不管怎么样，既然选择了就不要轻易放弃。

最后用我数年前看过的《DevOps实践指南》里的结束语"行动起来"来作为本篇的结束。

4. 相关

1. 中拔出溜的公司如何落地监控体系
2. 【DEVOPS】现状篇
3. 【DEVOPS】技术团队角色分工
4. 【DEVOPS】制品版本打包发布的规范化
5. DevOps系列实践
6. 高级研发的基本素养
7. 传统软件行业中技术团队的发展(现状篇)
8. 传统软件行业中技术团队的发展(团队破局篇)
9. 传统软件行业中技术团队的发展(个人破局篇)
10. 敏捷中国十八年目睹之怪现状