对于技术团队而言，线上服务的稳定性是衡量工作成效的关键。
如何衡量服务的稳定性？
这里要介绍两个概念：SLI、SLO。
- SLI，全名Service Level Indicator，是服务等级指标的简称，它是衡定系统稳定性的指标。
- SLO，全名Sevice Level Objective，是服务等级目标的简称，也就是我们设定的稳定性目标。
简单一句话：SLI就是我们要监控的指标，SLO就是这个指标对应的目标。
整体流程：
- 选择SLI
- 制定SLO
- 监控各项指标
- 定期复盘（实施PDCA循环，需要注意的是：这些指标不能只是用来衡量绩效，而是要帮助技术团队不断的提升。）
那么如何选择SLI呢？
常见的指标有很多种，比如：
- 系统层面：CPU使用率、内存使用率、磁盘使用率等 应用服务器层面：端口存活状态、JVM的状态等。
- 应用运行层面：状态码、时延、QPS、TPS以及连接数等。
- PASS层面：mysql、redis、kafka、mq和分布式文件储存等组件的QPS、TPS、时延等。
这么多指标，应该如何选择呢?只要遵从两个原则就可以：
- 选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外。
- 优先选择与用户体验强相关或用户可以明显感知的指标。 比较有代表性的是Google的VALET。
如何持续监控SLI？
个人理解如何有效监控（提升可观测性）是SER的核心要点。
对于服务端来说，可以引入比较成熟的第三方APM：EliaticAPM（建议选择AWS的开源版本OpenDistro） 、Skywalking、Zipkin、阿里云ARMS。
以上几个产品本人都使用过且应用于生产环境。可以说是各有千秋，侧重点都不同，例如Skywalking更关注具体的性能指标，很适合在性能测试阶段收集各方面的指标。但在异常（Exception）领域的交互就做的没有EliasticAPM友好，对于异常概览可观测性较差，不利于开发人员的日常问题排查和观测。
对于前端来说，近几年RUM（Real User Monitoring,真实用户监控）可以说是发展迅猛，比较有代表性的是NewRelic、NPAW、国产友盟OneAPM之流。这里国产的就不多做介绍。NewRelic功能更类似传统的APM，监控各项前端用户体验指标，例如每个页面的打开时间长、系统崩溃，可以说比较中规中矩。
关于NPAW
一个专注于监控app视频播放器在使用过程中的各项指标和用户体验分析，比较适合音视频类的app。个人认为是下一代RUM监控软件的典型代表。随着移动行业的内卷，未来用户对app的体验要求会越来越高，传统的“泛指标“已经无法满足团队为如何优化app端的用户体验去做更有利的决策，这个时候就需要有更垂直细化的工具来帮助收集某个具体场景的用户体验指标，例如NPAW就会去收集例如用户在观看视频过程中的各种数据（例如”播放过程中的卡顿时长、首帧加载时长、FPS的稳定性），虽然像Youtube这样的大型app会去自己收集这些数据，但对于中小型app来说，基于成本因素，像NPAW这样的产品能够很好的帮助团队去做决策和提供音视频领域的专业见解。
爬虫小程序的核心指标管理实践
选择SLI
- 系统层面：服务的可用性，小型爬虫程序只要python进程不crash就可以了，如果crash要及时告警、修复。所以这里可以使用MTTA、MTTR、MTTF这几个指标来衡量。
- 业务层面：每小时抓取量
制定SLO
- 系统层面：
- MTTA < 1min
- MTTR < 1min
- 业务层面：每小时youtube商务Email抓取量 > 600
监控各项指标
整个监控体系可以拆解为：采集、集成、分析、展示。
以阿里云SLS+ARMS为例，下图展示了一个简单的采集、集成、分析流程
关于接入阿里云SLS+ARMS的具体步骤可以参照：# 集成日志服务告警
以下是关键部分截图
以上就是一个简单的小程序监控实践，关于业务层面的监控方法与此类似，这里就不介绍了。
