生产环境的质量监控实践和思考
昨天的文章《系统测试的实践与思考》中，分享了质量监控相关的思考。我是这样描述的：
质量监控是很多技术团队容易忽视的一点，即系统上线后才开始补上对应的各种主机资源监控、研发日志监控、服务监控和业务监控，但在上线后到补上监控的这段时间内，是线上故障的高发区。
更好的做法是，在系统测试阶段，就由测试同学推动相关的研发或者运维同学，对本次线上发布部分相关监控进行提前构建并且验证通过，随着需求代码一起发布。这样即使上线后出现问题，也能及时发现和修复。
有同学看完后提了这样一个疑问：线上的质量监控和运维的主机监控&服务监控，以及研发的日志监控&业务监控有什么区别？质量监控主要包含哪些方面？
这篇文章，分享一些我对于线上质量监控的实践和思考。
常见监控有哪些类型？
对于各种监控工具监控平台，相信大部分技术同学都不陌生，按照监控的作用域不同，监控大致可以分为如下几种类型：
主机监控：衡量服务器性能和可用性的各项指标，常见的指标有CPU、Memory、DiskIO、Network。
服务监控：衡量应用服务性能和可用性的各项指标，常见的指标有QPS、Art&99rt、Throughput、Error%、Load5。
业务监控：评估业务活动变化趋势是否正常的指标，常见的指标有同比、环比、点击率、支付订单量、营销推广转化率。
链路监控：链路追踪(Tracing)是一种用于监控和诊断分布式系统中服务间调用关系的技术，可以辅助技术同学快速了解掌握系统运行情况，在故障定位解决和服务治理以及审计合规方面有很大的作用。目前应用较为广泛的开源工具有Jaeger、Zipkin、Prometheus等。
日志监控：即监控和分析系统各项日志，协助技术同学及时发现和解决问题的技术，一般监控数据的采集有三种方式，分别是埋点、日志、探针。其中链路追踪常用探针的方式采集数据，业务监控大多用埋点，其他大部分监控还是通过日志采集存储加工分析的方式来实现。
日志监控实现通常包括以下几个步骤：
- 日志收集：将日志文件收集到日志服务器或分析工具中，一般通过代理、syslog协议或使用API等方式实现；
- 日志存储：将收集到的日志存储在存储介质中(Elasticsearch、Logstash、Splunk)，以便后续的分析和查询；
- 日志分析：使用日志分析工具对日志进行实时或离线分析，提取有用的信息，一般通过正则表达式或算法实现；
- 日志可视化：将分析结果以图表、仪表盘等形式展示出来，以便技术同学更直观地了解系统的运行状况(ELK)；
- 告警和通知：检测到异常问题时，自动发送告警通知给值班的技术同学，以便他们能够及时进行响应和应急处理；
如何理解线上质量监控
如文章开头所说，虽然大家都很重视线上的质量，在测试阶段也会通过各种方法和技术手段来验证和提升质量，但在系统上线之前，质量到底怎么样依然是一个薛定谔的猫状态。
我对线上质量好坏的评价，主要从这几个纬度来开展：用户使用体验良好、正确实现业务需求、系统稳定支撑业务活动运营、可以尽早发现并及时修复线上问题且不影响用户使用和业务运营。
这几点对应的是用户体验、功能正确性、系统健壮性、系统容错性，这又和分布式系统的CAP理论不谋而合。
对于系统的各种监控，常规的做法是系统上线后，找对应的运维或者负责监控的团队提需求，然后进行埋点、探针部署，最后生成各种看板图表。
这种做法不能说不对，但整体来说监控的发现和诊断问题能力是滞后的，但线上问题从出现到造成大范围影响，时间往往是以分钟为单位的(见前段时间的阿里云、滴滴)。
而质量监控该如何理解呢？我的看法是不仅要对测试阶段最终交付的质量负责，更要对线上发布后的运行质量负责。
因此除了线上发布后的主流程回归验证，还应该在测试阶段或者系统设计阶段就考虑到本次线上发布内容的相关监控。
在每次迭代的系统技术方案设计阶段将监控能力纳入范围，在测试阶段验证迭代需求对应监控的正确性和覆盖率，在线上发布后通过线上巡检的方式不断对线上系统质量进行检验。
这样做的好处是对线上系统的监控永远是最新和及时的，降低可能出现的故障造成的巨大影响。
有一点要注意的是，监控系统的构建和部署并不一定是运维或者开发的事情，测试同学也应该参与其中。
无论是前期设计阶段，还是系统测试阶段，无论是测试驱动开发运维，还是测试直接参与监控系统的构建，最终目的是保障系统的线上质量。
