面向故障处理的可观测性体系建设学习总结

行云流水
2023-07-17 / 0 评论 / 449 阅读 / 正在检测是否收录...

前言

本文是作者关于可观测性的理解和实践。主要内容有
  • 可观测性在整个商业体系中的位置和价值
  • 如何快速发现故障,使用哪类指标告警
  • SRE 在谈论故障定位的时候,谈的是什么
  • 如何找到故障直接原因,找到止损依据
  • 如何让可观测性系统呈现观点,辅助洞察,定位故障

可观测性的价值

一个事情,价值太小就不值得投入。

可观测性在整个过程中的职能在哪个环节发挥价值。

客户/用户需要好的产品体验,好的产品体验包括可靠性体验,要想有好的可靠性体验,就得减少故障,所谓的降发生、降影响,而这,又依赖了可观测性的能力。所以:可观测性最终是服务于产品体验、服务于商业成功的。核心目标是快速发现、定位故障。

如何快速发现故障

先定义什么是故障?产品体验受损。
  • 电商产品:用户无法下单、无法支付、无法查看商品、无法查看历史订单
  • 存储系统:用户无法读、无法写、或者读写延迟过高
  • 流媒体产品:无法开启播放、无法拉流、无法浏览视频信息
定义产品体验受损
  • 电商产品:订单量、支付量、商品/订单访问成功率/延迟
  • 存储系统:读/写成功率、读/写延迟
  • 流媒体产品:播放量和成功率、拉流延迟、视频浏览成功率/延迟等

SLO指标正常的时候,业务指标未必正常。一定要重视业务指标体系的构建和监控。

SRE谈故障定位

数据->特征->观点->洞察

故障原因五花八门

 故障可能是电源模块坏了、机房空调坏了、机柜压住网线了、供电不稳、某个盘故障了、中间件配置错了、被黑客攻击了、分布式中间件脑裂了、写日志hang住了、程序配置错了、程序连接第三方的地址错配成线下地址了、DNS配错了、证书过期了、代码Bug了、疏漏了某个罕见用户流程

如何找到故障的直接原因

首先,依赖的基础设施(基础网络、硬件、Runtime环境)不能出问题,依赖的第三方其他服务不能出问题

具体要如何做

可观测性体系还需要利用平台能力、通过数据运营整理,呈现数据特征、帮用户建立初步观点,最终形成洞察,定位故障直接原因。

可观测性体系要告诉我故障模块

技术角度来看,一般模块都是有层级关系的,首先是系统,然后是子系统,然后是模块。所以,初始页面应该展示系统的健康状况,如果某个系统有问题,应该可以点击进去查看详情(这个过程称为下钻),下钻到子系统,再下钻到模块,最终找到故障模块。

故障模块的各项依赖是否健康

模块依赖的数据库、中间件、基础网络、机器硬件、第三方服务等等,都会影响模块的健康状况。所以,当模块异常的时候,我们需要知道各项依赖是否健康,如果依赖也异常,那么模块异常的直接原因基本可以断定是异常的依赖项导致的。

故障是否是变更导致的

线上故障,大概 70% 都是变更导致的,所以运维行业中流传一句话叫:“变更是万恶之源”。

提供工具分析数据特征

提供工具帮我们分析数据特征,别让用户陷入海量散乱的可观测性 raw data 中。这需要多维分析引导能力、数据串联打通能力。

原文

面向故障处理的可观测性体系建设

评论 (0)

取消
只有登录/注册用户才可评论