如果有什么东西出了故障,该如何提醒大家并做出回应?工具可以帮助解决这个问题,国为它可以定义提醒人类的规则。
故障响应是建立在使用可观测性系统构建的数据之上,并借助反馈循环,来帮助我们加强对服务的监控。
故障响应通常包含如下几个动作:
关注:不论是主动发现瓶颈点或异常点,还是通过可观测性系统被动暴露瓶颈点,我们都应该进行主动关注
交流:及时将观察到风险点通知到相关方,并告知影响面以及相关的补救措施
恢复:三方达成一致后,根据补救措施进行修复相关风险点和异常点
需要注意的是,如果在前期整个可观测性系统能够做好,通常故障应当始于一个简单的告警信息或一个报障电话,因此,通常情况下,可观测系统做的足够好仅能起到追溯和排查的作用,但是无法起到及时发现的作用,此时就需要依赖于各个观测数据进行计算和评估告警,以及时将相关的告警通知到相关人,以暴露风险点。
告警只是整个故障响应的第一个环节,解决的是故障如何发现的问题,而大多数的故障响应工作都是关于定义处理策略和提供培训的,以便人们在收到警报时知道该怎么做,通常这部分更多的是过去历史经验和运维经历的总结和沉淀,包括经验的一些抽象和工具化沉淀,以保证故障响应的效率和普遍化(即不依赖人为经验)。
而对于整个告警系统来说,需要确保的是告警的有效性,否则,整个报警系统很有可能沦落为垃圾数据制造机,告警有效性意味着需要满足如下两个需求:
在整个运维过程中,我们经常会发现有大量的无关紧要的告警信息,让运维人员的注意力迷失在告警海洋当中,而通常非运维领域的领导会关注整个告警的响应程度,因此,抑制和消除无效的告警,让运维人员不被告警风暴所吞没,也是告警管理中重点建设的内容。
通常情况,在我们的各个可观测系统构建完成后,可以通过整合到监控平台中的各种监控数据,应用趋势预测、短周期检测、间歇性恢复、基线判断、重复压缩等算法和手段实现告警压缩收敛,强化告警的有效性。
同时,面向一线的运维人员,我们需要根据同一个系统或设备的多个监控指标进行综合性建模和分析,汇总成一个健康度的分值,给予一线运维人员系统的基于健康度的系统分层评价体系,真实、直观反映系统运行状态,实现问题快速定界。
比如,通过基础资源的多个指标进行综合加权计算来整体评估该资源的利用率;通过一个应用关联的全部资源的资源利用率以及应用的运维架构整体建模分析来计算一个分值来整体评估该应用的健康程度。
这个过程如果做得成熟一些,可以根据内部已有的解决方案和告警进行闭环打通,一个简单的场景就是,当磁盘满时,告警会首先触发一次标准化的磁盘巡检,并进行相关的可丢弃数据的删除,如果依然无法解决该报警,下次可直接关联到一线运维进行人工干预,之后进行标准化经验总结。