第十三章：监测与决策
生产监测范围
监测内容不同来进行划分：
资源监测
应用监测
业务监测
软件两种服务形式
运行于我们自己管理的后台服务器上，持续为用户提供远程服务
分发到用户自己手中的软件包，如移动APP、PC端软件和硬件设备中的嵌入式软件等
后台服务的监测
基础监测：对系统基础设施的健康度进行监测，包括网络与服务器节点的监测。监测内容包括网络连接与拥堵状态、CPU负载和内存及外部存储空间的使用状况等
应用监测：对应用程序的运行健康度进行监测，例如，应用程序进程是否存在，是否能正常提供对外服务，是否有功能缺陷
业务监测：对业务指标健康度的监测。例如，对电商网站来说，应当包括但不限于实时的用户访问量、具体页面的浏览数、转化率、订单量和交易额等
分发软件的监测
在用户授权的条件下，在用户设备上收集自身软件的运行状态，以及宿主设备的运行状态，并将收集的数据定期发送到后台服务器上，由后台服务对收集上来的数据进行分析与呈现
基础监测：软件所运行的基础环境（如移动设备的机型、操作系统、内存等）的运行情况，以及与服务器的连接情况
应用监测：软件应用本身的健康状态（如内存使用、程序崩溃、无响应、与后台服务器的通信情况等）
业务监测：用户的使用数据，如所在页面、停留时间、用户操作等
数据监测体系
收集与处理
采集上报：将事先定义的事件数据在当地采集并上报
数据整理：对各数据源上报后的数据进行采集、清洗和整理
实时分析：对实时数据进行分析处理
离线分析：通过大量数据进行模型或规则提取
结果输出：将实时和离线分析的结果展现，供决策参考
问题决策：根据上一步的输出，人为或自动给出下一步的行动判定；同时将判定记录保存下来，以便为后续决策提供依据
数据存储：离线的原始数据、分析数据以及处理记录的保存
自动修复与运维执行体系的接口：它需要将修复指令发送给运维执行体系，由执行体系将指令分发到对应节点，并进行相应的操作
数据的标准化
为了利于统计分析，团队必须在一开始就对数据日志格式与收集标准及规则进行定义。
数据日志的格式本身并不复杂，通常分为基础信息和扩展信息。
基础信息需要描述最基础的应用背景信息，包括4个W，即Who（哪一个用户或服务）、When（什么时间）、Where（什么地点）、What（做了什么），如应用程序基本信息、事件时间、级别、环境信息、事件代码及表示位
扩展信息是为了数据更好的扩展性，以应对不同业务的监测统计需求，通常会由各业务团队自行定义、解析和使用
事件的定义与日志标准需要持续更新。
监测数据体系及其能力衡量
从3个维度衡量数据质量
正确性：即收集到的数据与事实的一致性
全面性：即收集到的数据信息是否足以支持团队做出决策
及时性：即数据的发生到能够支持决策所需要的处理时间足够短
2种方式验证数据质量
依靠业务专家的经验来判断
多方数据对比验证。多方数据是指数据源既可以来自企业外部的数据（如行业内的一般数据、相近企业的数据表现），也可以是来自系统内不同维度的数据（如浏览数据、订单数据与财务数据等的对比）
问题处理体系
发现问题的方式
人工判别
机器自动发现
告警海洋与智能化管理
告警信息被直接忽略的原因
告警信息的第一处理人不是自己
告警信息是一个预备告警，并不需要马上处理
缓解告警海洋的措施
通过关联分析，让监控点离问题发生的更近
通过动态阈值设定合理的告警
定期梳理告警设置，清理不必要的告警
通过人工智能动态解除告警
问题处理是一个学习过程
复盘活动要有详细的问题处理过程记录，以及整个过程中的各方参与者（包括产生问题移交的参与方）的全面参与
生产环境测试
测试活动扁平化趋势
测试左移：测试人员更早且更积极地参与到软件项目前期各阶段活动中，例如更早地参与探索环活动，在开发功能之前就定义相关的测试用例，测试执行任务也在向左移动，表现为：在越来越多的软件团队中，测试角色开始拥抱“增量测试”，即在软件集成测试之前，就开始针对单个已开发完成的功能集进行质量验证，提前发现质量风险。
测试右移：指通过各种技术手段，将一部分质量验证工作放在软件发布之后
多见于软件产品中的展示型功能，即软件功能更多的倾向于内容展现，例如搜索软件、拍照软件、商品展示等
生产环境中的测试
生产巡检：对生产环境中的后台服务进行定期的功能验证，以确保该后台服务仍旧对外正常提供服务，并且处理的结果是正确的
实施方法：创建一个覆盖应用程序主要功能的日常健康检查清单，对生产环境进行例行测试和检查软件服务的质量
最典型的是接口测试
遵循原则：
创建自用的测试数据，确保不污染真实用户的数据
使用的测试数据尽可能真实
不要修改真实用户的数据
创建测试专用的用户访问凭证，登陆生产环境
混沌工程
通过在生产环境中注入“问题”，从而发现生产环境系统性弱点，并进行系统性改进的方法或手段
目标：不断提升生产环境面对任何变更的可靠性
