SRE实践之SLI/SLO设定

在监控建设中，稍微有点规模的公司，几乎都有告警不准、告警泛滥的问题，这几乎成为了运维人长期苦恼的问题。

那么追寻问题根源，一般是由以下原因造成  

1. 复杂的服务环境 
2. 没有做好SLI及SLO标定 

第一种场景在一些有历史并且有一定规模的公司中非常常见，往往这种场景的解决需要一些自动化思路。比如在过往真实经历中，因各种原因，同一个服务的多个服务器规格不一，又因每个服务器的数据量存在变数，在对相关硬盘容量进行监控的时候，不管是按照百分比还是其它方式，结果总是要么数据迁移不及时导致数据丢失，要么陷入频繁的无效告警。其实追溯硬盘监控的目的，其实是解决数据保存问题。所以最终解决方案是，写一个通用的判断剩余容量并执行数据迁移的自动化脚本，放到每一个服务器上设置自动任务，然后监控系统不再对硬盘进行监控，而是转而对脚本是否执行以及执行是否错误进行监控，基本解决了报警泛滥及报警不准的问题。

第二种场景往往是在监控体系建设中，许多运维人常常犯的一种思维问题，就是告警不力的情况，总是认为是监控指标不够多，一味的准求大而全。其实殊不知指标过多非但不能解决问题，甚至还可能将问题更加复杂化，监控指标的选用一定要坚持“减法”原则。比如在过往真实经历中，某个核心服务经常出现问题，用户侧表现是不能下载，但具体映照在服务上，如服务故障、网关故障、资源不足等等问题都会导致用户不能下载。在监控实践中，反映一个问题所需要的指标，往往是不超过三个，我们在针对用户不能下载的表现监控上，经过广泛讨论，分别对相关核心接口进行站点监控，主要监控延迟及5xx错误，对核心中间件消息队列进行监控，主要监控分钟内有多少排队，对服务进行健康监控，是否正常状态。一旦出现相关告警，即意味着用户侧出现问题，需要立即介入解决。而针对资源不足可能导致的问题，则针对性的增加弹性伸缩方案，在做好容量规划的基础上，不再对资源进行监控告警，转而只是监控弹性伸缩的状态及是否正确运行。另外基于“减法”原则，对Kubernetes的Node监控也进行了相应取消，只对Pod的资源及Kubernetes的状态事件进行监控。

做好监控，不仅仅是需要技术，更需要优秀的思维方式，以下是总结的如何做好监控的步骤

• 确定系统稳定性指标

        这些指标应该包括对用户有影响的关键性能指标（KPI），例如响应时间、吞吐量、错误率等。此外，我们还需要考虑业务需求和用户期望，以便更好地衡量系统的可用性和可靠性。

• 设定目标值

         这些目标值应该基于先前确定的系统稳定性指标，并考虑到业务的优先级和用户需求的紧急程度。我们可以通过与业务部门和用户进行沟通来确定目标值。同时，我们也需要考虑实现这些目标所需的资源和技术限制。

• 监测和评估系统表现

        这可以通过收集各种性能指标来实现，例如日志记录、监控工具等。我们还需要定期对这些指标进行分析和评估，以了解系统的表现是否符合预期，并及时采取必要的措施来解决问题。

• 持续改进

        不断地调整和优化系统性能，以提高其稳定性和可靠性。这可以通过引入新的技术和最佳实践来实现，例如自动化部署、容器化、负载均衡等。同时，我们也需要考虑如何最大限度地减少故障和停机时间，以满足用户的期望和需求。