【DEVOPS】现状篇

1. 前言

一直以来，深感内部工程化能力欠缺，急于将事情向前推进，总是希望能够向前走几步，再走几步。

可惜的是，数年下来，进展实在乏善可陈。这里我们不去分析原因，本篇主要是阶段性总结到目前这个阶段，我们在DEVOPS上所处的状态，取得共识。

毕竟，DEVOPS作为一种文化，认知齐了才可能进一步地发展。

2. 现状

我们以一个软件项目的全生命周期里的各个阶段为线索，逐一总结各个阶段的进度情况。

2.1 需求管理

如我们在【DEVOPS】需求跟踪管理全面落地里提到过的，截止当下，我们已经分别在行业部门和基础平台部门分别进行了成功的试点，但是距离全面铺开以及进一步规范化还存在比较大的距离。

落地特点：

1. 两类部门均对禅道标准流程进行了自主调整。
2. 行业部门内落地的管理流程特点参见【DEVOPS】基于禅道 - 重构研发协作流程，总结一句话就是改进主要是由研发推动，遵循了"产品需求-项目任务-测试BUG"这三个概念基础之上，抛弃了敏捷开发里“冲刺（Sprint）”概念，显著减少流程里对应人员能力的要求，以及流程学习和维护成本；关于制品/发布这一步暂时放弃。
3. 基础平台部门内落地的管理流程则是以质量保证部门发起，所以最终落地的管理流程特点也是非常明显。现阶段他们基本忽略了需求的流转这一过程，关注点主要是在于需求、BUG与发布版本之间的关联。也就是确定当前发布的版本是被验证过哪些BUG或需求被解决了的，并且基于这个要求，完善了用例的编写和基础用例库的建立。嗯，你说"难道他们之前？"，是的，你猜得没错。
4. 各自都基于自身的本地化流程做了相应的禅道二开报表统计和流程流转限制。这是一个好现象，但还远远不够。

存在问题：

1. 集团公司内诸多行业部门，但落地成功的现阶段只有一个。
2. 行业特点各异，所以很可能部门行业部门还需要进行对应人员进行主动实践，本地化出适合自己的流程。
3. 本地化程度低，以上很明显可以看出不管是行业还是基础平台部门，它们对于禅道的应用还只是处于最初的起步阶段，只能算是真正踏出了第一步，如果不进行持续的迭代改进，那么与过往的土八路打发并不能拉开显著的差距。

2.2 开发流程

这一部分关注点主要是自动化的程度，以及经验复制的范围。

1. CICD在行业部门的内个别小组中有试点，并且反馈也不错，但是一旦相应的跟进停止，相关的人员在退回原有开发模式时，并没有过多的抵触。这应该是过往DEVOPS推进始终停滞不前的重要原因 —— 有好处，但是不多，没有达到形成这种自下而上的变革力量。
2. 编码规范等一系列的前置检查也有尝试，但是受限于业务压力，以及历史代码的纠缠等原因，这一块的推进始终反复不断，目前处于搁置状态。
3. 技术解决方案的沉淀一直在推进，但基本属于剃头挑子一头热的状态，距离理想中的"共建"还存在着很大的距离。
4. 以上尝试，在基础平台部门起步更晚。

2.3 测试流程

做得也不怎么样。

1. 行业部门的测试以"猴子测试"为主，保证基本的业务功能就可以了，相应的人员招聘也是按照这个标准来的，而且相关人员还要身兼售后等职责，所这一块的尝试始终无法更进一步，截止目前也是缺乏显著的进展。
2. 基础平台部门因为自身业务特点，所以在用例的维护上取得了显著效果，这对于产品质量在一定程度上的保证，以及人员结构的稳定上有了明显的进步 ——新入职的人员两周内必然上手，而不是过往一个月过去了这人都不知道自己该怎么干。
3. 并且内部的基础设施（典型如何服务器）使用效率底下，没有一个基本的CMDB。每次申请服务器之后，用一段时间之后就闲置了，逐步积累直到无法分配新的服务器，于是导致每隔一段时间都需要重新统计服务器使用情况，从零再来一轮新的分配，循环往复。

2.4 部署流程

这一块因为行业特点，问题的复杂性，造成相应的推进涉及不多。

相关原因大致有：

1. 部署环境高度各异，且不可控。
2. 相关人员缺乏基本知识素养。
3. 软件自身未考虑鲁棒性问题。

2.5 维护阶段

对于这一阶段，进展大致分为两类：

1. 对于以上已经实现基本的禅道管理流程的，目前已经可以实现反向地，由研发/测试团队倒逼需求提出方去规范基础的需求/BUG处理流程。
2. 但对于其他团队，逮着认识的人往死了用，出现相关问题不知道找谁等无谓的沟通摩擦成本依然是大量存在，并且毫无改进的迹象。

3. 后记

自下而上，没有专人投入，领导不理解，短期难以见效，这样的背景之下，任何流程的推进都是“横垄地里拉车,一步一个坎儿”，我也是见证了不少半途而废的改良者。

放弃者并不能说是懦弱，而坚持下来的人也只是各有各的原因。

4. 相关

1. 传统软件行业中技术团队的发展(现状篇)
2. 【DEVOPS】需求管理