【DEVOPS】共识

短命女 2022-11-03 15:23 204阅读 0赞

> 截至目前，在公司集团内部尝试推进DevOps已经三月有余，度过最开始一个月的高速发展期之后，明显感觉到进度的停滞，过程中看到不少可改良的问题却始终有种"一拳打在棉花上"的感觉。

### 0. 目录 ###

*   *   *  1. 前言
         *  2. 分歧
         *   *   *  2.1 "测试环境的快速准备"
                 *  2.2 "开会"
                 *  2.3 "代码分支管理"
                 *  2.4 "制品版本管理"
                 *  2.5 间或出现的版本库的代码编译不通过
                 *  2.6 "业务忙"
                 *  2.7 "人员水平较低"
                 *  2.8 "这个新增加的流程工作量没多少"
                 *  2.9 "我们现在更急迫的痛点是在需求侧与研发测的协作"
         *  3. 一句话
         *  4. Links

### 1. 前言 ###

对于DevOps推进缓慢的问题，静心思考之下，发现很大一部分原因来自认知上的不同步：虽然大方向上已经不再有疑问（技术不是导致我们效率低的主因，管理和流程上的缺失才是导致技术无法为业务提供有力支撑的关键），但对于如何达到目标的路径选择上存在比较大的争议，最明显的表现就是对于问题严重性的认知存放相当大的差距 ——你所认为的很严重的问题，身边人甚至领导认为是在小题大做 。

以下笔者就几个目前感受比较深的几个分歧陈诉下个人观点。免责声明：本文档记录仅作深度思考之用，无其他额外意义。

### 2. 分歧 ###

包含但不限于。

##### 2.1 “测试环境的快速准备” #####

**现状**：

1.  目前我们的测试环境从零搭建所耗费的时间远远超出我们的阈值。
2.  这里所说的测试环境不仅仅指代"员工的个人开发机上的测试环境"，“专门的集成测试环境”，"UAT测试环境"等。

**分歧**：  
关于这一点的分歧在于：

1.  领导层认为现在测试环境的搭建也许是稍微耗时长了一点，但我们只要完成搭建，之后就可以一直使用了，这只能算是一次性投入。而且我们现在的重心在于不仅逼近的业务需求，而不是这种问题。
2.  笔者的个人观点：“不论以何种语气强调其重要性都不为过”。  
    a. 反：“测试环境的准备时间长” > “每次提交测试的规模必然不小” > “修复成本高(离错误远，问题之间相互影响等原因)；解决方案抄近路(因为临近上线时间紧迫，且抄近路是需要付出代价的)” > “加上原本计划内的提测内容，在下次提测时候需要一次性测试更多的功能” > “更长的环境准备时间” > …  
    b. 正：“分钟级别的环境准备时长” => “采取少量高频的测试方式(甚至可进阶为自动化测试)” => “大幅降低的错误修复成本” => “节省下大量的精力进行业务的理解和功能的优化” => “开发计划顺利进行”。  
    c. 一个环境反复使用，直接违背程序开发"正交性"的铁律，极容易发生前面测试产生的中间/结果数据对后续的测试产生影响，进而导致幽灵错误的出现，极大抬高错误修复的成本，并沉重打击团队的士气。相反快速搭建环境的能力所带来的环境独立性和正确性能够让各方人员更快捷地聚焦问题本身， 实现快速修复，继续前进。  
    d. 平时进行功能模块开发的时候，非常容易出现将所有功能开发完毕之后一起测试的情况，这种方式直接违背了程序稳定性计算公式（一个系统由三个模块组成，每个模块稳定性为70%，那么系统稳定性不是70%，而是 34.3%）。而要实现"每完成一个功能就进行一轮完整测试"，测试环境的快速重建是一个非常重要的前置条件。

**愿景**：

1.  我们希望视项目的规模情况能够在0.5 - 5分钟内搭建好应用所需的测试环境，然后就能进行相应的测试/验证工作。
2.  我们希望每个人在需要测试某项功能的时候能够自助地完成所需环境的准备。而非多米罗骨牌式地牵扯进来大量人员，导致大量的团队计划任务被挂起。
3.  这是一个需要做好大量前置工作才能实现的目标，我们应该尽快开始。

##### 2.2 “开会” #####

**现状**：

1.  每次开会的时长往往在两小时以上，一场会开一整天也不是很罕见的事情。
2.  经常发生直到会议开始，与会人员才知晓今天会议的主题和大致的流程。
3.  会议内容经常被发散，陷入细节的拉锯中，很容易出现变成某几个人的激烈讨论，而其他人一脸的神游天际。

**分歧**：

1.  目前比较流行的共识是"这也是没有办法的，讨论清楚了才知道这事情怎么做嘛"，"要讨论的事情变化超出了原本的预期，当然要延长会议时长了"等等。
2.  个人观点：
    
    1.  **开短会**。会议应该是属于通知性质的，而不应该成为讨论问题的方式。最典型的就是敏捷开发中的"站会"。
    2.  **多开会**。只有在实现了开短会的前提下，我们才能实现多开会的目标，尽量减少"信息不对等"导致的重复性工作或者路线偏差。
    3.  连锁反应：开会时间长 > 开会频率低 > 信息沟通不畅 > 无用功增加 > 效率低 > 少开会 > 一次开会要解决大量的信息不对等/决策问题 > 开会时间长。
    4.  参考： 极客时间专栏《10x程序员工作法 - 郑晔》 - 《22 | 轻量级沟通：你总是在开会吗？ 》

**愿景**：

1.  以"面对面沟通"取代"开会"这种重量级的沟通方式。
2.  参会人员越少越好，必要人员参加即可。

##### 2.3 “代码分支管理” #####

**现状**：

1.  如[【DEVOPS】传统业务软件企业之痛][DEVOPS]中提及的，目前的业务场景属于"产品项目化，需求产品化"的尴尬局面：打着产品的口号做项目，然后这些项目代码又需要被部署到其他地方，视需求可达上百个地方，而这些地方又各自有不同的需求。
2.  对这几百个地方都进行分支管理，相应的管理成本仅凭想象就将这种念头掐死在了摇篮里，仅对几个重点地区进行了分支。

**分歧**：

1.  大部分人认为进行分支管理，在多达数百个市县的个性化需求之下，其成本将直接压垮原本已经非常紧张的研发团队。
2.  个人观点：
    
    1.  分支管理必须做！ 笔者一直的遗憾是没有去过大公司亲身经历几百上千人协作的项目，因此虽然一直保持手不释卷，但往往在理论和现实出现矛盾时候，自己都会犯嘀咕，这一点在"是否必须要对代码进行分支管理"上表现得非常明显。但现在笔者可以无比坚定地说：“分支管理必须做，按地区进行分支划分”。
    2.  然后是所谓的"管理成本"，这也是导致笔者之前一直不敢坚持自己观点的主要原因。但其实，笔者一直被带入一个误区，所谓的"带来巨大的管理成本"，深层次原因是目前所有的分支操作完全是靠人工来完成，没有统一规范的流程；并且缺乏变更管理和代码提交管理等。多重的不规范和缺乏自动化影响之下，才造成所谓的"难以想象的管理成本" 。

**愿景**：

1.  推进代码分支化管理。
2.  以规范化的流程和大量的自动化辅助来大幅降低分支化管理成本。

##### 2.4 “制品版本管理” #####

**现状**：

1.  制品库中只存在大版本号变更的制品，例如1.0，2.0，3.0。
2.  开发过程中，测试过的版本不会被留存，经常是直接被新提交版本覆盖掉。

**分歧**：

1.  大部分人认为"如果将所有的版本都进行留存，其中花费的精力和成本太高，我们还有大量的业务需求需要完成"。
2.  个人观点：.
    
    1.  “一切皆版本控制”。制品对应的代码库都应该保留，生成的制品都应该保留。其实这一点和上面的"代码分支管理"有异曲同工之妙，底层原理正是这句话：只有"一切皆版本控制"，我们才能快速验证我们的猜想（“这功能上版本是好的，很明显本次变更导致的？”），实现最快速定位出问题的本因。
    2.  所谓的"成本高"，完全是因为现有的制品管理所倚靠的是全人工操作，耗时耗力，还经常发生低级错误。通过自动化，标准化将这些工作全部交给机器，本需求的实现将如"探囊取物"一般轻松。
    3.  我们应该思考的是如何让让机器来帮助我们完成这些操作，而不是不去作这些操作。

**愿景**：

1.  实现无人值守的自动化运维。
2.  实现自助式地部署。

##### 2.5 间或出现的版本库的代码编译不通过 #####

**现状**：  
隔三岔五必然出现连编译都无法通过的代码都回传到代码仓库，直到某个倒霉蛋不幸更新代码之后发现原本的工作节奏被完全打乱，不得不中断原来的思维进度来协调解决眼前这个天降横祸。更要命的是如果发现得晚，期间又有几个人的提交，那场面想想就觉得刺激！

**分歧**：

1.  大部分人认为"这只是小问题，虽然是有点烦，解决也花费不了多少时间。这种问题的产生主要是因为研发人员的责任心缺失。"
2.  个人观点：
    
    1.  部分原因确实是"责任心缺失"，但更重要的原因是"门禁"的缺乏，代码没有经过任何校验直接入库了，这简直是不可想象的 —— 想想没有经过任何检疫就上市的牛奶，猪肉等等，怎么后者一点都不能忍，前者却认为问题并不严重。
    2.  这问题一点都不小！这直接打断研发人员"持续开发"的状态，极大打击了研发团队的士气。

**愿景**：

1.  建立多重门禁系统，尽量将问题杜绝在其发生的位置。

##### 2.6 “业务忙” #####

**现状**：  
我们的业务需求太多了，只是满足需求功能就已经需要加班了。

**分歧**：

1.  大部分人认为"我们已经被业务需求逼得连喘息的时间都没有了，哪来的时间去陪你搞这规范，那规范的；本来一步就能走完的路，你非得给我多加两步"。
2.  个人观点：
    
    1.  必须承认业务负担重的现状。
    2.  这里存在的问题是"我们到底如何看待我们面临的问题？我们认为解决这些问题的重要性到底有多高，我们是否认同每个迭代周期中必须抽出一部分时间来进行工作流程的优化？"
    3.  对工作的优化，比完成工作本身更重要。如果你认为没时间去做优化，那就是认为其优先级不够，直白点说就是还不够疼。
    4.  这里面展现出来的另外一点就是 “短期利益” 与 “长期利益” 的博弈。一个比较典型的例子是项目负责人要求"如果项目真的很紧急情况下，我们应该直接抛开YApi这样的沟通平台，直接实现基于代码的面对面沟通——前端根据原型直接在代码中写入样例数据等，然后后端拿着前端的代码进行接口编写"。这种所谓的"抄近路"方式当下看确实会节省时间，但长远看，你最终只能拿到一个终版的成品界面和相应的最终代码，缺乏历史回溯能力；你的系统没有自动化测试的可能性(除非补上这些测试用例，但"later is never")，接任者不敢修改你的代码，代码腐朽速度难以遏制。

**愿景**：

1.  统一认识，每个迭代抽出一定比例的时间来优化工作的流程。

##### 2.7 “人员水平较低” #####

**现状**：  
因为人员更迭速度较快，缺乏完善的培训流程，以及待遇偏低等原因导致整个软件开发流程中低级错误频发，沟通障碍等。

**分歧**：

1.  大部分人认为"以上现象出现的主要原因是因为我们的人员缺乏责任心，不能胜任所处的职务，也不愿意学习相应的技能等"。
2.  个人观点：
    
    1.  人员能力缺失，且自驱力较差这是客观存在的事实。毕竟"永远不要低估人们为了不动脑子，而愿意在体力上付出多大努力"。
    2.  相较于"将希望寄托在通过增加培训次数来进行人员技能和责任心培养"，笔者更愿意相信在一个不断自我迭代和优化，不给人犯错机会的流程更具有实现的可能性。

**愿景**：

1.  大幅降低对于人员能力的需求，将希望寄托在流程的自动化，规范性和强制约束性上，让流程推着人走，而非倒置。

##### 2.8 “这个新增加的流程工作量没多少” #####

**现状**：  
为了扭转现有研发效能低下，以及大量的人力被浪费在一些毫无价值的事情上的现状，我们一直在试图通过规范化流程来降低沟通/错误修复成本，杜绝低级错误等等。而这些规范化的流程往往是通过新增流程节点或改变现有沟通习惯来实现的。

**分歧**：

1.  大部分人认为"这个新增加的流程工作量没多少，研发人员只需要在XX时候稍微多出那么一点精力就可以了，废不了多少功夫"。
2.  个人观点：
    
    1.  单个流程节点来看确实工作量不大，但是一来这些新增的流程节点很多都有被自动化的可能性，二来则是蚁多咬死象，压死骆驼的最后一根稻草看着也不重。
    2.  任何制度的制定从来都不是问题，拍脑袋都能在半小时内整出来一个，PDCA环李最重要的是那个C，而在沉重的业务压力下，最难的就是这个C。
    3.  以接口管理服务YApi的导出文档为例，如果只是作公司内部沟通，那YApi是完全能够满足要求，但往往我们会有与他家公司系统做对接的需求，这个时候我们就需要将api导出来交付的需求，一般这个时候我们需要进行格式的自定义。
    4.  对于上面这个需求，如果我们能够提供"自动导出满足自定义格式需求的文档"，相关研发人员是不是就会主动把接口往YApi平台上面写， 并且会严格按照我们的要求来，而不是需要我们不断通过抽查，强调等等方式来造成双方时间和效率上的损耗，还经常得不到满意的效果。

**愿景**：  
“晓之以理，不如诱之以利”，以断舍离的原则——“给你增加一项规范流程的时候，一定会给你减轻已有的另外一项工作的压力”，通过这种诱导性的，渐进式的改革最终塑造出规范的流程。

##### 2.9 “我们现在更急迫的痛点是在需求侧与研发测的协作” #####

**现状**：  
现有开发流程中，需求侧，研发侧，测试侧，运维侧之间的协作都存在着或多或少的问题。例如需求侧对于需求定义的频繁变动和更改导致研发测的疲于奔命；研发侧将测试的压力完全押宝在测试侧所带来的拉锯式沟通——"研发-部署-测试未通过-修复-再部署-测试再次未通过-再次修复"的无尽循环；运维侧的全人工操作导致环境准备时间长，低级问题频发等。

**分歧**：

1.  大部分人认为在整个研发流程中，我们最大的痛点来自于需求侧和研发测之间没有一个规范的交互流程，导致错误直到最后的验证阶段才被发现，导致修复成本猛增；而且需求的频繁变动缺乏相关的记录，最终进行复盘时候很难说清楚到底是哪一环出了问题，最终就只能是"谁嗓门大谁有理了"。
2.  个人观点：
    
    1.  笔者从一开始就认同"需求作为一切开发工作的起点，是贯穿整个研发工作的重要抓手"，“如果从根上就错了，那就不可能得到好的结果”，“错误发现的时间越晚，修复成本越低”。所以笔者是极度认可"需求/产品侧是最需要被精心管理和规划的端"，其自身的规范化，以及其与其它端的交互是需要投入120%精力去管理和优化的。
    2.  但是，从全局的角度来看，最需要改良的是需求侧，改进阻力最大的也是这一侧，其中最主要的原因是对于需求侧的改良虽然对于全流程的其它岗位而言是好事，但对于需求侧本身的人员来说，他们自身的工作量势必会增加，并且旧有的工作习惯也会经历阵痛式的改变，这势必带来个人脱离舒适区的不适以及工作效率的短期降低，所以这一步改良无疑会在前期招致需求侧的抵制，而软件研发的特殊性也使得一定会有各种完全站得住脚的理由来支撑这些抵制，所以这一步改良势必需要领导层的全力支持，而对于天朝大部分的传统软件公司，产品和研发的地位通常是前者比较强势，毕竟前者更贴近于业务，领导层也不大可能将自己的大部分精力耗费在协助解决改良过程中的矛盾上，可能经历了几次冲突反馈以及业务侧施压之后，领导也开始对制度的推进产生疑问。
    3.  鉴于以上原因，笔者一直以来的观点都是"相较于需求侧到研发侧，我们更希望从研发侧开始，先实现从研发，测试，运维三侧（以下简称"三侧"）的全流程标准化和自动化，待后三侧被打造为铁板一块之后，再集中精力反向推动需求侧的改革"。以上的观点基于以下思考：
        
        1.  相较于需求侧改良所造成的"短期内只增加了工作负担和造成脱离舒适区的阵痛，而改良的优势需要较长时间才能显现"的现象，DevOps针对三侧的改良是属于即时反馈型的，是可以被各方所能够立即感受到的，是可以有效降低他们工作量和心智负担的，是更容易被各方所接受和认可的。例如使用机器来完成环境准备实现减少环境准备时间，杜绝低级错误；使用"门禁系统"杜绝低级错误引入的可能性；使用即时通知系统实现各部门之间的信息对齐等。
        2.  三侧的改良最终会极大减少"浪费"(沟通，错误修复等)，提高工作效率，进而提升需求响应的"可预测性"，确保承诺的实现。届时能够反向倒逼需求侧进行相应的改变，这将极大提高需求侧改良的成功率。
        3.  另外，需求侧改良和三侧改良并不冲突，完全是可以并行的，我们只是推荐**在初期将关注点和主要精力集中在研发，测试，运维这三侧**。

**愿景**：  
不论采用哪种方式，我们最终都是希望能够演化出一套符合公司实际，自动化，标准化，规范化，且能够自我进化的全新研发流程，提升研发效率，为业务提供有力支撑。

### 3. 一句话 ###

对于DevOps，如果只有一个评价指标达成共识，我们的建议是：  
“每个岗位的每个人，想要执行某项任务时候，需要他人的支援越少，团队整体效率越高。这个任务不论是否需要跨部门，都是同样的标准。”

“我们要做到当一个人需要某项资源的时候，他可以凭借自己对于公司制度的了解自行找到这些资源，这中间需要打扰的人越少，效率越高”。

过去我们在做"老员工关怀"调查的时候，经常能够听到的一项诉求是"希望能够尽量将工作和生活分开，在休息时间能够少被打扰"。但之所以老员工被打扰，就是那些事情只存在老员工的脑子里，或者其他人不知道这些资料在哪。

### 4. Links ###

1.  极客时间专栏《10x程序员工作法 - 郑晔》

[DEVOPS]: https://blog.csdn.net/lqzkcx3/article/details/113939917