快速验证.监测
12009概述
监测环节收集数据，并统计展现结果、及时发现生产系统问题以及业务指标的异常波动，并做出适当的反应。它也是团队做出决策的最重要数据源之一。只有当数据可信无差错时，团队才能基于它们做出合理的分析和判断。假如有数据丢失或者误差时，团队很可能做出错误的决定，与商业机会失之交臂。另外，为了能够及时发现生产环境的稳定性问题和隐患，快速收集系统运行监控数据并加以分析定位问题也是必不可少的。
为了能够在第一时间收集到所需数据，团队必须在验证一开始就讨论并确定验证所需的数据需求，尽早讨论并定义数据需求规范，制订日志记录标准，建立数据日志元数据，并与相对应的功能需求一并同时实现。否则即使相应的功能特性上线，也无法得到相应的数据而耽误决策。
监测范围
生产环境的监测范围包括3个层次，分别是基础监测、应用监测和业务监测。尽管根据每一层次的特点，监测数据的采集方式有所不同，但是其处理流程基本一致。每个监测体系都包括数据收集、上报、整理、分析、展现与决策这几个环节。
后台服务监测
后台服务监测包括3个层次，分别是基础监测、应用监测和业务监测。
- 基础监测是对系统基础设施的健康度进行监测，包括网络与服务器节点的监测，监测内容包括网络连接与拥堵状态、CPU负载和内存及外部存储空间的使用状况等。
- 应用监测是对应用程序的运行健康度进行监测，例如，应用程序进程是否存在，是否能正常提供对外服务，是否有功能缺陷，是否能正常连接数据库，是否有超时现象，是否有服务抛出的异常和告警，是否可以及时扩容以应对突增的大量请求等。
- 业务监测是对业务指标健康度的监测。例如，对电商网站来说，应当包括但不限于实时的用户访问量、具体页面的浏览数、转化率、订单量和交易额等。
分发软件的监测
由于分发软件运行的环境并非受控环境，对它们的服务监测受到客观条件的限制。通常来说，我们需要在用户授权的条件下，在用户设备上收集自身软件的运行状态，以及宿主设备的运行状态，并将收集的数据定期发送到后台服务器上，由后台服务对收集上来的数据进行分析与呈现。如果宿主设备运行于非联网状态，则软件需要缓存数据到本地，一旦联网后再上传数据。
与后台服务的监测一样，分发软件的监测也包含3个监测层级。基础监测是软件所运行的基础环境（如移动设备的机型、操作系统、内存等）的运行情况，以及与服务器的连接情况。应用监测是软件应用本身的健康状态（如内存使用、程序崩溃、无响应、与后台服务器的通信情况等）。业务监测是用户的使用数据，如所在页面、停留时间、用户操作等。
当然，对于分发软件的监测不仅仅是来自软件本身的上报，企业还要关注网络上的信息，例如移动软件应用市场评分、用户在各类新媒体中发布的关于软件本身的评价等，以便从更广泛的渠道全面收集信息，及时修正软件中的缺陷和漏洞，为用户提供最优体验。
问题处理
建立了数据监测系统，接下来就是要从这些监测数据中发现问题，并快速解决。通常发现问题的方式有两种：一是人工判别；二是机器自动发现。面对大量的监测数据，全部依靠人工处理是不现实的。因此，通常先由机器根据各种规则进行判断，尽可能多地自动发现生产中的疑似问题，无法自动处理时，就作为一个“告警”，生成一个工单，发送给指定的问题接收人。
告警海洋与智能化管理
在国内某互联网公司中，有一位运维人员每天接到告警信息在6000条以上。如果每个告警都需要看一下的话，平均每分钟要查看4条报警信息，一天 24小时待命。然而，虽然告警信息已经多如牛毛，但是，每当出现生产事故以后，事故复盘分析必有两个行动项：一是梳理当前日志监测和告警点，把相关人全部配置一遍，生怕漏掉任何一个人；二是加入更多的监测点和报警。
一方面是告警数量多，希望减少告警；另一方面是害怕出事了没有告警，只能加入更多的告警。而最终的胜利者通常都是后者。事实上，很大一部分告警信息都会被接收者直接忽略，看都不看。原因主要有两点。
- 告警信息的第一处理人不是自己。
- 告警信息是一个预备告警，并不需要马上处理。
当然，我们并不排除很多告警的正确性和真实性，但我们也需要提高告警信息在另外两个维度的质量。一是及时性，这一点的重要性无须解释；二是告警信息的可操作性。也就是说，当收到告警信息后，接警人应该可以针对这个告警做出相应的操作，否则告警信息就如同垃圾短信一样，应该将其屏蔽，因为它会令工作效率降低。而且，一旦真正的告警信息淹没在大量无须处理的“伪”告警信息之中时，很容易酿成生产事故。我们可以从4个方面来缓解“告警海洋”的问题。
- 通过关联分析，让监控点离问题发生地更近。
- 通过动态阈值设定合理的告警。
- 定期梳理告警设置，清理不必要的告警。
- 通过人工智能动态解除告警。
通过不断努力，我们可以将告警数量控制在一定的水平，但很难消除告警。对于那些常见告警，我们可能已经有了应对之法，真正需要花时间处理的是那些以前没有出现过的异常告警，因为它们很可能是“生产问题”。
问题处理是一个学习过程
“生产问题”的处理也是一个产品研发管理流程的重要环节。假如没有良好的处理流程，很可能会出现更多的管理问题。
在团队规模不大时，这个处理流程都是依靠人工执行的，主要通过电子邮件、IM工具或者“大嗓门（吼）”进行。一旦人员规模变大，系统变得复杂，这个过程就变得非常耗时。例如，由于问题定位点判断不准，经常需要在几个不同团队之间移交处理，在交接过程中，经常丢失问题上下文。为了提高效率，通常需要将该流程中人工部分尽可能通过自动化方式来解决，包括问题单的自动跟踪、相关信息的附加记录、整个处理过程的时效度量、多种及时的通知机制以及问题反馈的升级机制等。这就需要一个工单系统来支持。而且，当我们对问题进行复盘时，有了这样一个工单系统，可以为我们及时正确地提供很多过程信息。
在很多团队中，问题复盘会常常被视为“追责会”，会议气氛剑拔弩张。在一个学习型组织中，问题复盘是一个良好的学习机会，是一个最有效的学习方法。复盘时，所有相关的人一起对照结果，回顾过程，进行得失分析和规律总结。这是一个最好的相互学习的过程，对每个人都是一个提高机会。复盘总结出来的规律，对于后来者再处理类似的事情时是一个“菜谱”一样的行动指南，也是一个组织最好的知识传承，可以最大限度地帮助后来者进步。
复盘活动有一个最重要的前提，那就是：要有详细的问题处理过程记录，以及整个过程中的各方参与者（包括产生问题移交的参与方）的全面参与。对于复盘过程中有疑问的点，甚至应该进行二次场景复现，以便得到更好的预防和根源解决方案。