【DEVOPS】传统业务软件企业之痛

0. 清单

• • • 1. 公司背景
    • 2. 不同视角
    • • • 2.1 产品侧
        • 2.2 开发
        • 2.3 测试
        • 2.4 运维
    • 3. 最后
    • 4. 参考

1. 公司背景

1. 传统业务软件企业。
2. 强势的甲方，卑微的乙方。
3. 产品项目化，需求产品化。
   a. 最终生产的软件需要进行多地区实地部署，且各个地区针对软件又有自己特定的需求。
   b. 因为进度原因最终造就打着”做产品”的口 开始，但在落地过程中针对每个地方的需求进行跟进式开发。
   c. 因为缺乏需求分析导致没有一个需求类别认定的流程，又因为监控的缺失导致无法提供充分的日志数据进行决策分析，最终只能依靠产品经理个人当时的理解进行需求归类。
   d. 因为代码分支管理的缺失造成制品包没有回退修复机制，研发之路上只能进行没有回头箭式的夺命狂奔。

2. 不同视角

2.1 产品侧

1. 同时负责多个产品，精力被过度分散。
2. 产品采取”分区域”的方式进行销售，并有着比较长期的个性化需求更新和BUG维护的要求。
3. 专业性缺失。大部分产品经理并未接受到专业的培训，绝大部分属于从事相关业务多年从而成为了”产品经理”，细数之前的履历，有”测试转产品”，“开发转产品”，“售后转产品”，“项目经理转产品”。
4. 产品经理之间缺乏沟通，互为黑盒，很少进行信息的共享。直接结果就是除非存在联结点，否则相同的功能会在不同的产品间进行重新实现。

2.2 开发

1. 专业性缺少。公司业务背景决定了大部分研发人员并没有接受过专业的计算机基础训练，且缺乏这方面的意识。（不少开发人员甚至连堆栈都不会看，复制错误提示信息到百度中是其最显著的排错能力。）
2. 公司业务特性决定了一个研发人员需要同时承担多个项目/产品的开发维护工作，人员更迭相当快，紧急的项目救火时有发生，导致出现低级问题出现概率较高，职责无法溯源，等问题。
3. 相关技术管理的缺失。缺乏变更控制，缺乏版本管理，研发流程中只存在前进的方向，没有回退机制；研发部门的各个小组之间技术栈的不统一导致人员调动摩擦成本高，破窗效应严重。内部技术栈培训短缺或者效果不明显。
4. 技术历史债较重。新技术和规范的引入瞻前顾后，导致最终或圈地自萌，或不了了之。
5. 持续开发能力缺失。开发环境千差万别，工具版本各有千秋，无法实现快速验证，甚至或有意(如因为懒于自测，直接将问题抛给测试，甚至生产环境)或无意(例如本来应该采用单元测试的验证，却选择必须将前后端同时搭建起来之后从浏览器端开始)地人为延长验证时间间隔。

2.3 测试

1. 专职测试人员数量稀少，且仅集中在性能测试或安全测试。
2. 持续测试能力缺失。环境的准备到系统的部署全程基本为人工完成，低级错误频发，测试缺乏可复现性。
3. 验收测试，冒烟测试以”猴子测试”的形式完成，严谨性缺失的同时无法对全流程进行复盘和审计。
4. 与研发之间缺乏有效的沟通反馈机制，双方互为黑盒。
5. 管理缺失。缺乏基本的量化指标。

2.4 运维

1. 地方项目经理兼职运维人员，除了运维之外，还要身兼收集局方需求的职责，但往往只是个传话筒，缺乏”需求分析能力”。
2. 待遇低，专业能力缺失。导致的直接结果就是 “将WAR包丢进Tomcat目录下，然后启动起来”都可能存在问题。更不谈避免端口冲突，收集问题及相关场景都存在问题等等。

3. 最后

任重道远，但正面问题是开始改变的第一步。我们需要就问题先达成一致，否则只能在各奔东西式的努力中耗尽所有人的心力和热情，爱因斯坦曾说过”当问题清晰之后，解决方案自然就出现了”。

引用一段从微信推文看到的文字，相信很多人都会感同身受：

我在某金融软件公司工作，随着客户数的增多，成本与效率/质量的矛盾日益凸显。

~
设想下，从一波人维护一套代码，渐渐变成一波人维护几套代码，这样一来，Bug增多，效率下降，抱怨也随之变多，再加上甲方挖人，最后人员离职，团队土崩瓦解，Game Over……
~
在这种情况下，一般公司会采取三种应对措施：

1. 一对一服务 – 项目制：多个团队，多套代码，多套标准，服务多家客户，但这样一来成本又难以承受，时间一长，肯定资不抵债。
2. 一对多服务 – 标准化：一个团队，一套代码，一套标准，服务多家客户，但客户不买账，客户说我的需求都是个性化的，你别拿某某标准来引导我，叫你咋做，你就咋做，不愿意您走，我找别人家做。
3. 一对多服务 – 产品化：一个团队，一套代码，多套标准，服务多家客户，通过技术与配置化的手段，利用SOA思想，打造自己的产品化平台，但对技术投入要求较高，尤其是核心人才的依赖较大，中小型企业一般都很难留住这些人，只要他们一走，公司基本完蛋。

最后总结一下部分最佳实践：

1. 离问题越近，修复成本越低。所以快速部署是需要一个能让各方收益的需求，而不仅仅”这是运维/售后的问题”。
2. 我们信任的是测试结果，不是所谓的口头承诺。而这同样需要快速部署的支持。

4. 参考

1. 《凤凰项目 : 一个IT运维的传奇故事》
2. 《看板方法 : 科技企业渐进变革成功之道》
3. 《持续交付2.0》
4. 《持续交付 : 发布可靠软件的系统方法》
5. 《持续集成 : 软件质量改进和风险降低之道》

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8583 人正在系统学习中