系统稳定性方法论 - 提感知、快响应、做复盘

之前在<系统稳定性方法论>中提到了稳定性建设的四大抓手，在<降发生>之后，今天来说一说其余的三点 提感知、快响应、做复盘

提感知

何为"提感知"

提感知指的是：对于已经出现问题，能够及时且精准的进行告警，提升对异常的感知能力

如何"提感知"

对异常的感知主要分为：被动接收 与 主动发现 ，抓手是 监控 & 告警

监控

首先要明确一点，监控是分层级的，常见的可以分为5层：

1. 服务器监控：物理机监控、虚拟机监控、容器监控，分别监控cpu、内存、io、存储、网络…
2. 中间件监控：数据库、缓存、MQ… 例如监控连接数、RT、积压…
3. 服务监控：服务的存活、服务集群实例、每个实例的请求数、QPS、TPS、RT、线程数、error数…
4. 业务监控：针对服务提供的各种业务指标进行监控，比如司机出车率、完单率、拒单率、乘客发单率…
5. 体验监控：终端用户的体验指标

分层带来了不同的关注点，基础设施的同学只需要关注基础服务层的监控；RD同学需要监控中间件、服务与业务层；对于业务与运营同学来说更关注于业务指标与用户体验

告警

没有人喜欢收到报警，相比于那些滞后的、毫无意义、重复、完全无法理解的报警，我们更期望的是，在对成本、优先级、降打扰、时效性综合考量下的，精准的通知到目标人群

定期巡检

只依赖被动接收告警是不够的，还需要定时定期的主动巡检；可以设立值班制度，按照SOP 或 checklist 查看大盘、监控与指标，能够做到主动发现事前异常

快响应

不论是主动发现的异常，还是被动通知到的，首先要做的就是，快速响应！并且第一件要做的就是，快速止损，而非 尝试去定位与解决问题

遇到问题总是先想着梳理来龙去脉，这是很多RD同学的通病，这确实很重要，但眼前更重要的是快速止损，犹豫就会败北，几秒钟的耽搁可能换回的是业务的巨额损失

而快响应的前提是需要提前埋点，比如限流开关、切流开关、熔断开关，甚至一键回滚，都需要在上线之前做好兜底预案！

做复盘

系统异常不可避免，没有系统能做到5个9，遇到问题也不可怕，可怕的是在同一个地方跌倒两次！

而一次好的复盘，不仅可以帮助我们梳理出异常产生的直接原因，更能帮助我们发现系统中深层次的问题，进而优化我们的底层逻辑、架构、流程… 使系统持续演进

一次标准的复盘至少包含5个方面：

1. 背景信息：至少需要介绍这是哪块业务的哪个服务，异常描述、异常处理时长、异常处理结果…
2. 故障复盘：严格按照真实的时间轴描述各个时间节点
3. 故障影响：异常所造成的影响
4. 故障分析：造成故障的直接原因分析
5. 故障反思：造成故障的深层次分析，反思与总结！