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

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

0. 标题

- - 1. 中拔出溜公司的特点
  - 2. 循序渐进
  - - 2.1 从研发团队开始
    - 2.2 先CI（持续集成）
    - 2.3 再CD（持续部署）
    - 2.4 告警/监控
    - 2.5 最后是自动化测试，
    - 2.6 不要教条
  - 3. 后记
  - 4. 相关

1. 中拔出溜公司的特点

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

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

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

2. 循序渐进

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

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

2.1 从研发团队开始

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

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

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

2.2 先CI（持续集成）

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

CI解决了打包电脑环境各异导致的诡异问题。早几年我亲眼见证研发人员本机jdk1.7打包，然后在jdk1.8的服务器上部署，花费半个团队大半天时间去调查。
同时搭配集中的制品版本库实现打包制品版本的统一管理和交流，历史追溯。这一步最简单的实现方式就是Nginx+操作系统自身的文件系统，如此可以快速让研发和测试/技术支持看到效果，争取支持。
上一步的基础上，接着出现的需求就会是"制品版本说明"的问题，因为打包和制品存储下载的统一，各方也看到了其中的好处，接下来你就可以开始借机推进需求管理的标准化，以及代码提交的标准化，并且在此基础上最终实现需求说明，提交代码，打包制品三者之间的彼此关联绑定，这个过程的全自动化将大幅降低沟通成本。

2.3 再CD（持续部署）

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

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

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

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

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

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

2.4 告警/监控

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

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

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

2.5 最后是自动化测试，

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

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

2.6 不要教条

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

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