软件系统的监测与决策

生产监测范围

后台服务的监测

• 基础监测
  • 是对系统基础设施的健康度进行监测，包括网络与服务器节点的监测，监测内容包括网络连接与拥堵状态、CPU负载和内存及外部存储空间的使用状况等
• 应用监测
  • 是对应用程序的运行健康度进行监测
  • 例如：应用程序进程是否存在，是否能正常提供对外服务，是否有功能缺陷，是否能正常连接数据库，是否有超时现象，是否有服务抛出的异常和警告，是否可以及时扩容以应对突增的大量请求等
• 业务监测
  • 是对业务指标健康度的监测
  • 例如：实时的用户访问量、具体页面的浏览数、转化率、订单量和交易额

分发软件的监测

• 由于分发软件运行的环境并非受控环境，对它们的服务监测受到客观条件的限制
• 通常我们需要在用户授权条件下，在用户设备上收集相关运行数据，并定期将数据发送到后台服务器上
• 该监测也包含3个监测层级。分别是软件所运行的基础环境监测（基础监测。如移动设备类型、操作系统、内存等）；软件应用本身的监控状态监测（应用监测。如内存使用、程序崩溃、无响应、与后台服务器的通信情况等）；业务监测是用户的使用数据，如所在页面、停留时间、用户操作等

数据监测体系

收集与处理

监测数据与处理过程

1. 采集上报。将事先定义的事件数据在当地采集并上报
2. 数据整理。对各数据源上报的数据进行收集、清洗和整理
3. 实时分析。对实时数据进行分析处理
4. 离线分析。通过大量数据进行模型或规则提取
5. 结果输出。将实时和离线分析的结果展现
6. 问题决策。将上一步的输出，人为或自动给出下一步的行动判定，同时将判定记录保存下来，以便后续决策提供依据
7. 数据存储。离线的原始数据、分析数据以及处理记录的保存
8. 自动修复与运维执行体系的接口。它需要将修复指令发送给运维执行体系，由执行体系将指令分发到对应节点，并进行相应的操作

数据的标准化

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

• 衡量维度
  • 正确性。即收集到的数据与事实的一致性
  • 全面性。即收集到的数据信息是否足以支持团队做出决策
  • 及时性。即数据的发生到能够支持决策所需要的处理时间足够短
• 验证数据质量的两种方式
  • 依靠业务专家的经验来判断。可以邀请业务专家在初期建立基本数据体系
  • 多方数据对比验证。多发数据是指数据源既可以来自企业外部的数据，也可以是来自系统内部不同维度的数据。通过互相印证，发现质量问题，并逐步改善

问题处理体系

常见发现问题的两种方式

• 人工判别
• 机器自动发现。由机器根据各种规则进行判断

告警海洋与智能化管理

• 告警信息被忽略的原因主要有两点
  • 告警信息的第一处理人不是自己
  • 告警信息是一个预备告警，并不需要马上处理
• 如何缓解“告警海洋”的问题
  • 通过关联分析，让监控点离问题发生地更近
  • 通过动态阈值设定合理的告警
  • 定期梳理告警设置，清理不必要的告警
  • 通过人工智能动态解除告警
• 问题处理的常见流程
  1. 报告问题
  2. 初步定位
  3. 确定并通知处理人员
  4. 分析问题
  5. 问题解决
  6. 根因分析
  7. 根源解决

生产环境测试

测试活动扁平化趋势

• 在传统的瀑布软件开发方法中，测试执行和决策活动通常集中在软件研发周期的中部
• 随着现代软件交付频率的不断加快，测试活动开始向左右两侧移动
• “测试左移”是指测试人员更早且更积极的参与到软件项目前期各阶段活动中，也叫“测试前移”。即在软件集成测试之前，就开始针对单个已开发完成的功能集进行质量验证，提前发现质量风险
• “测试右移”是指通过各种技术手段，将一部分质量验证工作放在软件发布以后。目前测试右移的现象多见于软件产品的展示性功能，即软件功能更多地倾向于内容展现，例如搜索软件、商品展示、新闻推荐等

生产环境中的测试

• 生产环境中的质量保障工作原则
  • 创建自用的测试数据，确保不污染真实用户的数据
  • 使用测试数据尽可能真实
  • 不要修改真实用户的数据
  • 创建测试专用的用户访问凭证，登录生产环境
• “生产巡检”
  • 即对生产环境中的后台服务进行定期的功能验证，以确保该后台服务仍旧对外正常提供服务，并且处理的结果是正确的
  • 通常的做法是：创建一个覆盖应用程序主要功能的日常健康检查清单，对生产环境进行例行测试和检查软件服务的质量。由软件团队自行安排的质量验证工作，并且定期执行。通过将一些自动化接口测试的用例放在生产环境中，周期性执行，以代替手工检查
• “混沌工程”