这是真的“技术驱动”的公司吗？

news2024/11/15 18:49:05

“ 软件交付团队的DevOps能力，恰恰是技术能力的最好体现。”

—

“我们是技术驱动的公司”

跟我们合作的软件供应商，每次发生软件变更或升级就一地鸡毛，而且经过屡次沟通，都没有什么本质改善。

当我们跟他们的高层投诉时，他们的高层也承认问题，但给出的理由是“我们是一家技术驱动的公司，我们聚焦在为用户提供更新、更丰富的功能，但是忽略了这些变更对现有客户的影响。”

坦白说，我完全不能接受软件变更出现各种问题是因为“技术驱动”，相反，变更问题恰恰反映了他们的技术能力不足，进而严重影响了他们的DevOps能力。

从他们的屡次软件变更或升级所引起的问题，我们总结了他们存在以下问题：

沟通——新功能开发和缺陷修复过程中没有跟客户进行沟通，实际效果要发布后客户才能验证；提供的发布说明语焉不详，缺乏对客户影响的具体说明；也不能提供详尽的软件变更执行手册，缺乏具体的执行失败预案。
质量——质量不可靠，缺乏详尽的测试报告说明做了什么测试；大部分测试只是执行过程，没有验证结果（比如仅涵盖页面是否可以打开）；没有针对客户环境的测试环境；完全不知道变更对现有的客户的实际影响。
发布——范围大，过程繁杂；研发有提供执行过程给驻场工程师，但如果驻场工程师遇到问题，缺乏预案及时处理；缺乏统一的验收流程；发布执行时间动辄数小时，无法回滚。
组织——组织内部按照职能分工，责任割裂；驻场工程师受到最大的客户压力，但无法推动各产品的研发部门进行跟进和改善；客户无法直接接触到产品研发部门；缺乏既能对接客户又能拉动整个内部组织的角色。

可以看到，他们存在的问题，像极了我们十年前做DevOps转型前的模样。

而他们在软件变更上所出现的种种问题，就是DevOps能力不足的问题，也是技术能力不足的问题。

—

DevOps能力也是技术能力的体现

我们从整个软件交付的端到端过程来详细分析一下怎样算好的DevOps能力：

需求方面：通过需求管理工具记录需求细节，并与代码管理工具、发布管理工具整合，形成全流程跟踪；在理解需求时，对验收条件达成一致，并通过BDD（Behavior Driven Development，行为驱动开发）的方式把验收测试自动化；
设计方面：高内聚、低耦合，选择合适的架构确保重用性、敏捷性、扩展性之间的平衡。
编程方面：TDD测试驱动编程自动化单元测试；通过Pull Request等方式强制代码审核；所有代码在持续集成流水线中完成标准的静态代码质量检查、安全漏洞检查、测试执行、打包等；通过容器简化开发、测试、部署、迁移过程。
测试方面：除了通过TDD、BDD实现自动化持续测试外，可以快速创建测试环境，快速模拟生产环境的数据和场景；有标准的非功能性需求自动化测试套件。
发布方面：软件包版本化管理，有统一的软件包仓库；发布登记、审批、管控检查、部署、验收一律自动化，发布出现问题具备一键回滚能力。

以上目标的实现，无不需要过硬的技术能力。核心是自动化一切重复的、可标准化的过程，但落地自动化的细节，充满了技术上的挑战，这里需要引入各种开源工具、整合已有的系统和工具、适配现有的流程，涉及到很多技术和工具。

在我们公司，DevOps做得最好的团队，就是技术能力最强的团队，他们可以实现每天n次发布的能力，也自研了很多工具实现这个能力。

—

提高DevOps能力的建议

这里给大家一些提升DevOps能力的建议。有一些是技术相关的，有一些是技术以外的。研发效能的提升，当然不会只是技术驱动。

价值优先——在收到需求时，要深入理解这个需求的价值，价值最好是可以量化的，比如每个月能节约多少人力和成本。因为实现DevOps持续交付的前提是大而复杂的需求被拆分成多个最小且可独立交付的需求。拆分需求，需要理解需求的价值，从而理解需求背后的需求，理解用户最急切需要解决的核心痛点是什么，从而设计出MVP（最小可用产品）。不能明确价值的需求，可以不做。
需求拆小，速度优先——先做需求的MVP，快速解决核心痛点。这不仅关乎实现价值的速度，也是为了保持开发人员的激情。前前后后折腾几个月憋大招容易让人泄气，也容易偏离方向，几个星期甚至几天一个交付的持续交付让人激情澎湃。
以终为始——以验收条件达成一致作为确认需求的其中一步，先充分理解什么是完成，再动手去做。通过BDD行为驱动测试框架把验收条件变成自动化验收测试，成为将来回归测试的一部分。
流水线包含更多——CI/CD流水线除了编译、执行自动化测试、打包、部署外，还应该包含静态代码检查、安全漏洞检查、合规管控检查等，把软件发布所需要所有标准化过程都涵盖在内，取代所有人工操作。
TDD、BDD成为习惯——TDD测试驱动编程成为每个程序员的编程习惯，BDD行为驱动开发成为每个团队对每个需求的开发习惯。
容器化——简化部署过程，确保环境一致性，提高软件可迁移性。
合适的架构满足服务等级和弹性要求——根据业务影响等级制定合适的RTO、RPO指标以及业务流量波动特征设计相应的架构和基础设施配置。架构设计也是赋能敏捷交付的必要条件，架构层面的解耦也是实现系统最终敏捷性的要件。
Clean Code，代码是唯一可信的——类、方法和变量的命名能直接体现其作用，代码即文档。
自动化一切，包括非功能性需求——发布登记、审批、管控检查、部署、验收一律自动化。
发布拆小，频繁发布——每次发布的范围最小化，最好每次发布只包含一个需求的上线。通过自动化，消除频繁发布所需要的额外开销。
提高系统可观测性——对系统进行自动的健康检查和异常监控，比用户更早发现问题；日志集中到统一日志查看平台，减少需要登录到生产服务器的情况。
上云，增加选择——云的弹性伸缩能力，为系统架构设计带来更多选择；丰富多样的PaaS和SaaS产品也为团队带来更强的能力。
平台工程——开发人员只需要关注业务需求的开发，代码一旦提交，各种测试、检查、部署和运行都可以交给平台。当然，平台给予开发人员便捷性的同时，也有明确的适用范围，会对开发人员提出很具体的要求，只有满足的系统才能在平台上部署和运行。