将软件包部署到生产环境并为用户提供软件服务，这并不是快速验证环的最终环节，通过对软件服务进行持续监测，确保交付的软件可以为客户持续提供服务，并能够收集到有效的数字反馈信息，根据所获得的数据进行决策，确定接下来的行动方向，这才能真正完成持续验证的闭环。

生产检测范围

后台服务的检测

包括如下三个层次：

• 基础监控：对系统基础设施的健康度进行检测，包括网络与服务器节点的监控，检测内容包括网络连接和拥堵状态、CPU负载和内存等；
• 应用监测：对应用程序的运行健康进行监测，例如，业务进程是否存在，是否正常对外提供服务，是否有功能缺陷，是否能正常连接数据库等；
• 业务监测：对业务指标健康度的监测，例如实时的用户访问量，页面的浏览数，转化率，订单量和交易额等。

分发软件的监测

分发到用户手中的软件包，比如移动APP，PC端软件等，并非受控环境，受到客观条件的限制。通常情况下，需要在用户授权的条件下，在用户设备上收集自身软件的运行状态，以及宿主机设备的运行状态，并将收集的数据定期发送到后台服务器，由后台服务对收集上来的数据进行分析与呈现。当然，对分发软件的监测不仅仅是来源于软件本身，企业还要关注网络上的信息，比如移动软件应用市场的评分，用户发布的评价等。

数据监测体系

为了得到有效的监测数据，必须对监测数据的获取过程、处理流程进行全面管理，包括数据源、数据格式与采集周期、数据处理算法等。

收集与处理

采集、处理和应用的过程

• 采集上报：将事先定义的事件数据在当地采集并上报
• 数据整理：对数据源上报后的数据进行收集、清洗和整理
• 实时分析：对实时数据进行分析处理
• 离线分析：通过大量数据进行模型或规则提取
• 结果输出：将实时和离线分析的结果展示，供决策参考
• 问题决策：根据“结果输出”，认为或者自动给出下一步的行动判定；同时将判定记录保存下来，以便为后续决策提供依据。
• 数据存储：离线的原始数据、分析数据以及处理记录的保存
• 自动修复与运维执行体系的接口：将修复指令发送给运维执行体系，由执行体系将指令分发到对应节点。

数据的标准化

要想得到监测数据，首先需要对软件产生的事件（Event）进行规划和跟踪。持续交付价值环中的“探索”和“验证”，其最重要的信息来源之一就是真实的用户反馈。在实现业务功能之前，除了对业务方案的讨论，还需要做好两件事：

• 对业务指标的定义：该功能相关的业务指标是什么？与其他业务指标有哪些关联性？如何计算这个业务指标？
• 数据事件的定义：为了得到这个业务指标的数据，应该在产品代码的哪个位置设置埋点监听事件，输入和输出格式是什么样的，与其他事件之间的关系是什么。

为了利于统计分析，团队必须在一开始就对数据日志格式与手机标准及规则进行定义，并定期进行宣讲。标准定义可以让数据的收集与处理更加方便，减少不必要的脏数据或者数据分类错误，从而提升数据处理的时效性和准确性。

数据日志的格式本身并不复杂，通常分为基础信息和扩展信息。

• 基础信息：需要描述最基础的应用背景信息，包括4个W，即Who（哪一个用户或服务）、When（什么时间）、Where（什么地点）、What（做了什么），如应用程序基本信息、事件时间、级别、环境信息、时间代码等。
• 扩展信息：为了数据更好的扩展性，以应对不同业务的监控统计需求，通常会由各业务团队自行定义、解析和使用。

监测数据体系以及其能力衡量

很多决策依赖于大量的数据分析，因此数据的质量尤为重要，可以从正确性、全面性和及时性来衡量监测数据。除此之外，监测系统还应该具有抽样能力，可以根据实际数据量的需要，工程师可以配置每个数据采点的采样密度，并快速生效。

问题处理体系

从监测数据中发现问题的过程，通常先由及其根据各种规则进行判断，尽可能多地自动发现生产中的疑似问题，无法自动处理时，就作为一个告警发送给指定问题的接收人。

告警海洋与智能化管理

对于不断增加的告警数量，如何提高告警信息的质量非常重要，通常由两个方面来衡量：

• 及时性：过期的告警没有任何作用，只能浪费宝贵的时间
• 可操作性：收到告警的人应该可以针对这个告警做出相应的操作，否则告警信息就如同垃圾短信一样，应该将其屏蔽，因为它会令工作效率降低。一旦真正的告警淹没在大量无需处理的“伪”告警信息之中时，很容易酿成生产事故。

对于告警海洋的问题，可以从四个方面来缓解，如下：

• 通过关联关系，让监控点离问题发生地更近：从调用链的源头开始告警，而不是末端服务。
• 通过动态阈值设定合理的告警：通过一定的算法动态来设定阈值，确保算法的准确性需要一定时间的观察和积累，以及大数据分析。
• 定时梳理告警设置，清理不必要的告警：包括两种场景，一是告警时间本身是不必要的，比如软件功能发生变化后；二是接收人没必要接收到这个告警。
• 通过人工智能动态接触告警：通过人工智能算法找出生产环境中不同事件之间的关联关系，更早识别问题，早发告警，甚至自动处理问题而不修复，这是AIOps领域，目前还属于探索阶段。

问题处理是一个学习的过程

良好的问题处理流程是一个重要的环节，为了提高效率，通常需要将流程中人工部分尽可能通过自动化方式来解决，包括问题单的自动跟踪、相关信息的附加记录、整个处理过程的时效度量、多种及时的通知机制以及问题反馈的升级机制等。通过一个工单系统来支持。

团队中的问题复盘环节是一个良好的学习机会，是一个最有效的学习方法；复盘过程中，相关的人一起对照结果回顾过程，进行得失分析和规律总结；复盘总结出来的规律，对于后来者再处理类似的事情是一个行动指南，是一种很好的知识传承，可以最大限度地帮助后来者进步。

生产环境测试

生产环境测试存在的原因在于：非生产环境无法永远保证发现生产环境中可能出现的所有问题，测试场景不可枚举性概率在逐渐提高，非生产的测试场景显得不充分。

测试活动的扁平化趋势

在传统的瀑布开发方法中，测试执行和决策活动通常集中在软件研发周期的中部，随着版本交付频率的不便加快，团队的测试活动开始向左右两侧移动。

测试活动的左右移动

• 测试左移：测试人员更早且更积极地参与到软件项目前期各阶段活动中，越来越多的团队中的测试人员开始拥抱“增量测试”，在软件集成测试之前，就开始针对单个已开发完成的功能集进行质量验证，提早发现质量风险。通过频繁运行各层级的自动化测试，确保软件的交付质量，缩短软件的研发周期，提高发布效率。
  测试左移
• 测试右移：通过各种技术手段，将一部分质量验收工作放在软件发布后，主要用于验证业务涉及方案的有效性，而非某个软件功能的执行正确性。多见于软件产品的展示性功能，更倾向于内容的展示，比如搜索软件、拍照软件、商品展示、新闻推荐等，这类功能出现一些问题，对软件产品会有一定的影响，但只要及时发现和修复，就不会对用户造成本质性的损失或严重影响。

生产环境中的测试

应该将生产环境的测试也纳入日常质量保障工作。

生产巡检：对生产环境中的后台服务进行定期的功能验证，以确保该后台服务依旧对外正常提供服务，并且处理的结果是正确的。这种巡检应该被自动化，并定期自动执行。

生产环境上的测试应该遵循以下原则：

• 创建自用的测试数据，确保不污染真实用户的数据
• 使用的测试数据尽可能真实
• 不要修改真实用户的数据
• 创建测试专用的用户访问凭证，登陆生产环境。

混沌工程

指通过在生产环境注入“问题”，从而发现生产环境系统性弱点，并进行系统性改进的方法或手段。其目标是为了不断提升生产环境面对任何变更的可靠性。比如Chaos测试，通过模拟整个region挂掉、调用延迟、服务降级等异常。这种主动监测使得软件工程师在架构设计时就需要考虑一些常用的失败问题。

向东还是向西

经过分析和总结，如果收集到的业务度量数据符合在价值探索环中定义的目标预期，就能够确认我们在价值探索环做出的假设是正确的，就可以回到探索环的起点，选择下一个业务挑战；一旦结果不符合预期，不要气馁，已经用最快的速度得到了结果，团队需要进行分析与预期结果不一致的根因，确认是否需要进行微调，还是再选出另一个试验方案；也有可能在验证环的运行过程中，发现了新的业务知识，从而说明探索环中精炼的所有备选方案都是错的，需要带着刚刚学到的知识重新开始价值探索环之旅。