谈DevOps-持续交付02(11.29)

注：图片来源 ThoughtWorks

今天谈持续交付过程域剩余的三个部分内容，即环境管理，数据管理和度量分析。可以看到环境和数据管理是持续集成和交付的重要输入，而度量分析是持续集成执行后的重要输出分析，这些内容都具备后，整个持续交付过程才能够形成端到端闭环，并通过度量分析形成持续改进的机制。

5.环境管理

环境做为DevOps持续交付过程中最终承载，包括环境的生命周期管理，一致性管理，环境的版本管理，环境管理是用最小的代价来达到和确保一致性的终极目标，主要包括环境类型，环境构建，环境依赖和配置管理几个部分的内容。

对于大型项目来说，我们可以看到会包括了 DEV开发环境，SIT集成测试环境，UAT用户验收测试环境和PRD生产环境四套环境，更复杂的往往还有预生产发布环境，生产克隆环境等。

对于DEV开发测试环境的作用主要是方便开发测试阶段的多个微服务模块之间的接口联调，这些到了SIT集成测试阶段做显然是不合适的，如果不具备开发测试环境就需要开发人员机器连接到SIT环境的接口服务进行联调，这种情况显然也不太合适。同时对于DEV开发测试环境也方便我们去运行自动化测试脚本进行自动化测试。

对于SIT集成测试和UAT测试，实际重点都会偏黑盒测试了，至少应该确保有一套黑盒测试环境。

在三级里面就已经强调需要有独立的开发测试环境，同时环境的准备能够达到小时级完成 ，同时有以应用为中心，有服务级依赖的配置管理能力，比如依赖的关联服务，数据库服务，缓存服务等。 在四级强调建立全面的测试和灰度环境，环境的构建可以通过容器化快速交付，而且达到分钟级。

环境是独立的配置管理对象，环境依托于具体的虚拟化资源或容器资源，同时不同环境有不同的差异化配置文件，配置文件依赖于不同的环境对象。

一个大的应用往往会分为多个微服务模块，每个微服务模块完全独立管理，因此都可以做到 独立的定义环境和环境配置变量信息 。大应用和多个微服务模块间本身也是一种松耦合的关系。

一个是环境的准备和建立可以做到快速，比如我们持续集成已经正常运行，我们可以快速的准备一套演示环境给客户使用，同时也要做到环境和资源松耦合，环境可以做到快速的销毁以回收资源。

6.数据管理

系统开发过程中为了满足不同环境的测试需求，以及保证生产数据的安全，需要人为准备数据庞大的测试数据，需要保证数据的有效性以适应不同的应用程序版本。另外应用程序在运行过程中会产生大量数据，这些数据和应用本身的生命周期不同，做为应用最有价值的内容需要妥善保存，并随应用程序的升级和回滚进行迁移。

测试数据管理

测试数据应该满足多种测试类型的需求（手工测试，自动化测试），覆盖正常状态，错误状态和边界状态，测试数据应该同时满足测试效率和数据量的要求，测试数据的输入需要受控，并运行在受控环境中，保证输出的有效性。 为了模拟生产环境情况，往往需要采用仿生产数据，使用时候需要注意安全和脱敏。

数据来源： 最基本是自己手工输入，其次是生产环境导出再导入测试环境，处理过程中需要清洗和脱敏。再四级开始强调了需要有能力能够通过代码或api接口调用来自动生产满足需要的测试数据。

数据覆盖： 在二级只强调了测试数据覆盖主要场景，包括正常，异常错误和边界场景。而到了三级，强调需要建立体系化测试数据，进行数据依赖管理，覆盖全部测试分层策略要求的测试类型。

数据独立性： 在二级强调了测试数据有明确的备份恢复机制，同时实现测试数据复用和保证测试一致性。在三级开始强调测试用例的执行不依赖其它测试用例执行所产生的数据。减少测试数据间的依赖关系。

数据变更管理

数据变更管理是指应用程序升级和回滚过程中的数据库结构和数据的变更，良好的变更策略应保证应用版本和数据库版本兼容匹配，以应对应用的快速扩容缩容等线上场景。通过应用变更和数据变更的解耦，减少系统变更的相互依赖，实现灵活的升级部署，主要包括了变更过程，兼容回滚和数据监控。

注意整个变更里面实际强调了以下几个关键点

1. 应用部署和数据变更部署解耦，相互独立，数据变更又包括了结构变更和数据本身变更

2. 数据变更应该具备向下兼容性和具体的回滚方法

对于数据变更向下兼容需要分开讨论，首先是 对于数据库结构的变更，原则上需要完全做到向下兼容 ，即数据库结构在变化后不进行回滚，向下兼容，比如拓展了字段或长度等。其次是数据本身的更新或初始化，如果是新增增量初始化数据往往并不需要回滚，但是如果是对已有数据进行update操作，往往就需要配合应用程序的回滚一同进行回滚操作。

那么我们在部署失败的时候的回滚就需要重点去考虑，前者是镜像回滚，后者是需要运行事先准备好的回滚脚本进行数据内容的回滚才行。

对于整个数据管理过程域，实际设计的不太合理，按道理测试数据管理应该纳入到测试管理这个过程域，而对于数据变更管理本身应该纳入到大的变更管理过程域更加合理。

7. 度量和反馈

DevOps基于精益思想发展而来，其中持续改进是精益思想的核心理念之一。 DevOps主张在持续交付的每一个环节建立有效的度量和反馈机制，其中通过设立清晰可量化的度量指标，有助于衡量改进效果和实际产出，并不断迭代后续改进方向。 另外设立及时有效的反馈机制，可以加快信息传递速率，有助于在初期发现问题，解决问题，并及时修正目标，减少后续返工带来的成本浪费。度量和反馈可以保证整个团队内部信息获取的及时性和一致性，避免信息不同步导致的问题，明确业务价值交付目标和状态，推进端到端价值的快速有效流动。

度量指标

度量指标的拣选和设定是度量和反馈的前提和基础，科学合理的设定度量指标有助于改进目标的达成。在拣选度量指标时需要关注两个方面，即度量指标的合理性和度量指标的有效性，合理性方面依托于对当前业务价值流的分析，从过程指标和结果指标两个维度来识别DevOps实施结果，以及整个软件交付过程的改进方向； 有效性方面一般遵循SMART原则，即指标必须是具体的、可衡量的、可达到的、同其他目标相关的和有明确的截止时间 ，通过这五大原则可以保证目标的科学有效。

度量驱动改进

度量驱动改进关注软件交付过程中各种度量数据的收集，统计，分析和反馈，通过可视化的度量数据客观反映整个研发过程的状态，以全局视角来分析系统约束点，并在团队内部分享，帮助设定客观有效的改进目标。实际里面有两个关键内容。

一个是度量信息的分类分解和可视化呈现，比如强调通过可视化看板来实时展示度量数据，报告可以多维度实时展示，同时还支持自动生成数据趋势图和趋势分析。其次就是度量发现的问题要有问题跟踪和反馈机制，形成问题闭环和持续改进。

进一步阅读材料

度量驱动devops转型:  https://www.sohu.com/a/124936190_468741

https://cloud.tencent.com/developer/article/1151042

https://wenku.baidu.com/view/b5fcfe5132d4b14e852458fb770bf78a65293aa6.html