小小故障排查三天，早用上可观测性哪来这么多麻烦事！

最近在思考 MDD 结合 SRE，花了两周的时间打造了小程序端的可观测平台，接下来和大家分享一下整个心历路程。谈谈我的一些启发，顺便谈谈当工程师具备 MDD 意识后，是否能如虎添翼。

事情的背景是这样的，2 月 10 日，好大夫部分小程序用户投诉上传图片失败。整个排查过程有 10 多人参加，排查了三天才有结论。我们来回顾一下当时的情况。

一、一团乱麻，谁人背锅侠？

大家知道上传图片失败问题，一直是个老大难，因为失败的原因太多了。对一般的工程师而言，整个流程可能是一个黑盒模型，缺少一个抓手去分析问题。

这时候工程师大脑中会有一堆问号。

简单说一下这个问题是如何排查的。

怀疑用户网络问题，联系用户切换网络尝试依然失败。加上分析 Kong 日志，发现部分用户重试多次都是失败，切换到好大夫的 APP 能上传成功，前端认为不是用户侧网络问题。怀疑链路传输问题，我们有多家网络节点运营商，尝试切换链路，甚至直接回源，问题还依然存在。期间通过抓包并和运营商技术一起排查未能明确问题原因，给出的反馈还是用户侧问题。怀疑小程序版本问题，2 月 9 日有个业务方向上线了小程序，修改的是 http2 相关的，大家很兴奋，时间点也能对上，觉得抓到罪魁祸首了，然后就是紧急上线，用户更新包后问题依然存在，这下打击有点大。怀疑 Kong 进程处理异常。前面几个关键点都怀疑了，大家谁都说服不了谁的问题。11 日晚上重启 Kong 进程，担心 Kong 进程启动太久，有垃圾没有回收，有点病急乱投医了，试一试总不差。重启后第二天问题依然没有得到缓解。经过几轮排查，对比最近几天 code=400 的占比趋势，2 月 10 ~ 11 日比之前多了一倍，code=400 的 route_name 基本上也都是小程序侧的上传图片接口。基本上定位是小程序端的问题，越发怀疑微信端是否异常了。联系微信社区，联系微信内部开发，2 月 13 日下午才得到反馈：“2 月 9 日下午微信升级了基础库，灰度了 1%IOS 用户，并于 2 月 11 日回滚，部分用户还有异常需要清理缓存”。

虽然这次问题是找到了，整整三天，包括运维、前端、服务端、系统架构组一共有 10 多人参入了排查。

痛定思痛，有没方式缩短异常定位时长呢？首先我们来看看用户上传会经历哪几个环节。

一次网络请求，中间其实经历了很多环节，细节这里就不展开讨论了，我们来看一下简化后的模型，用户发起请求，到网络节点，再到源站处理，再经过网络节点返回响应给用户。

从图中可以看出，上传失败存在几个关键的环节中：用户侧、网络节点、入口网关、后端服务。

可能是用户侧本地异常，如机器内存不足，小程序闪退。可能是用户网络不稳定，还有可能是用户在上传图片的过程中，中途将小程序切换到后台，重新唤起小程序续传失败。为了请求的安全和加速，在请求打到源站入口网关前，是先走运营商传输节点，传输节点也对接了多家运营商，传输不稳定或命中防火墙策略也会造成上传失败。入口网关用的是 kong，如果路由策略配置异常，或者 Kong 节点异常，或者某个 upstream 节点异常都会造成上传失败。后端图片服务，如果处理能力不足，负载高，进程夯住，或其他异常也会造成上传失败。

经过思考，如何做到普适性呢，就要面临以下几个问题。

异常能被有效地观测到吗？异常定位对经验要求很高，如何减少传承成本？异常分析有哪些提效的工具链，能平台化吗？异常千千万万，再加上排练组合，真的能通过数据分析出来吗？异常分析平台增加了学习成本，会不会增加工程师负担，会质疑研发平台的受益？

深入思考，有点细思极恐，异常定位好难呀，提效异常定位更难！

二、追本溯源，能否提效异常定位？

很多工程师在分析异常的时候，往往聚焦单次问题，一上来就陷入个案分析的细节，耗神耗力，心态都会查崩。

随着网站拓扑的演进，异常定位也越来难，很多公司都在推进 SRE 体系建设，其中对可观测性呼声也越来越高。异常如何被量化，被观测。这其实是一个“工程问题”。

所谓工程问题本质上是数学，需要在一个定义良好的环境里，用定义良好的参数描写一个定义良好的问题。引起网站异常的的原因有各种各样，就像诊断患者一样。统计分析健康的人和病患各项身体基能指标的差异性，从而判断病患程度及探究病因。

结合我的一些日常排障经验，来看一下异常定位这个工程问题。

异常定位需要在一个参照系中进行，通过可视化界面去呈现 SLI 的波动性，而 SLI 的波动性往往是和引起异常的根因相关联。分析不同 SLI 波动振幅差异性大小，从而推断异常的可能性原因。

简单来说，就是给异常进行数学建模，并关联到可观测的 SLI 上。透过 SLI 的表象反查异常原因。说起来比较简单，和医生诊断一样，往往一种病理现象对应了不同的病因，而同一种病因也会有不同的表象。有急性有慢性，还有扩散传递性，一种病变可能引发一系列身体其他的病变，溯源病因可能需要多次会诊。当然经验越丰富，数据越多，模型分析也就越准确。

总结一下提效异常定位，首要任务就是需要量化异常，让异常可被观测到。其次就是友好的界面提示一步步引导大家定位问题。

接下来一起探讨一下如何建设小程序上传图片整体链路的可观测性，去尝试建模分析异常定位这个工程问题。

三、破而后立，MDD 劈开黑盒模型

具体到上传图片的场景中，SRE 体系关注各个环节及整体链路的可用性。MDD 思想就是需要我们提炼合适的 SLI，设定 SLO，达成共识，进而围绕这些 SLO 开展工作。

来一起看一下，上传图片各个环节中我们感兴趣的点。

这里总结一些经验：”两点一线，分两面，一面监控画像，一面异常定位“。

为了尽可能的观测各个环节，我们需要梳理一个脉络，如请求的开始到结束，抓住这两点，连成一线，分两面，一面关注长期趋势，一面关注异常分析。

具体提炼 SLI 可参考 Google VALET(Volume、Available、Latency、Error、Ticket)模型。

从图中我们可以看出，评估链路各个环节是否有风险或者有异常，需要一个参考系，长期的指标趋势和经验阈值都是参考的数据源。故而设置 SLO 有两种模式，第一根据经验设置固定阈值，如 QPS 峰值不得大于 10k；第二是设置相对值，如 code=404 环比增加 20%。

有了这些准备工作，提炼了以下 SLI 和 SLO，大家可以参考一下。

为了异常的可观测性，需要按不同的维度去细分 SLI，这次上传图片异常是由于微信灰度了特定的基础库，改造后需要收集终端相关信息，如设备平台，设备型号，微信版本，微信基础库版本以及小程序版本。

在为上传图片链路建模分析的时候，也一直在考虑能否将这些经验延伸到小程序整体的可观测性中呢？

于是进一步细化了分析维度，按不同的小程序包，统计了不同 code 码、路由、domain 的请求数及时延。这样就能更好地支持下钻，并能迁移到整个小程序异常分析中。接下来一起看一下如何落地改造各个环节以便 SLI 的收集。

四、顺势而为，落地整体链路改造

1、用户侧每次小程序启动的时候发起一个探包请求，会上报一下版本信息(平台/版本/微信版本/微信基础库版本/小程序包名/小程序版本)，当然为了安全审计不会收集用户隐私相关的信息。探包请求还额外获得了小程序启动频次的粗略统计数据。通过 hash 算法生成版本信息的指纹 hash_key，后续的用户请求 url 和 http header 中都携带这个 hash_key。通过 hash_key 关联 kong 日志和版本信息，从而能提炼出终端不同维度的 SLI。为了将整个链路串联起来，小程序每次请求生成 trace_id，并通过 header 透传下去。小程序网络不佳的时候，会先将 Error 等日志信息暂存到 LocalStorage 队列中，等有网了再次上报。所有记录日志的地方都会记上 trace_id，方便后续异常定位分析。2、网络节点新增运营商标识，方便对比分析不同运营商传输的可用性。收集运营商的日志，存储到 Clickhouse 中，方便后续分析，尽可能让网络传输节点可观测。3、入口网关按业务类型拆分 route_name，如上传，订单提交等等。route_name 支持打标签，如业务部门，所属页面等，方便告警监控及识别到的风险通知到具体的业务部门。插件支持生成 trace_id 或透传已生成的 trace_id，打通 KongLog 和后端服务 TraceLog。4、后端服务增加日志埋点，分析不同图片尺寸大小的上传下载相关的指标。定义好不同的 code 码，方便异常定位分析。5、可观测平台鉴于之前研发了强大的分析器，只用添加分析，告警规则就能满足这次场景需求。为了节约研发成本，SLI 存储到了 Clickhouse，可视化基于 Grafana 写 SQL 绘制。新增地理位置分析，将请求 ip 转换成经纬度，方便提炼地区维度的 SLI。

整个小程序日志上报的流程如下：

在改造的过程中也遇到了不少问题。

控制 Error 信息大小。单条信息过大会导致 Flume 收集异常，重复收集获丢失日志。采样上报，控制频次。一般异常发生可能会产生连锁反应，瞬时产生大量日志，需要避免频繁上报导致用户带宽的消耗。降噪处理。如腾讯周期性安全扫描可能会产生一些干扰异常，如 499 等，会影响用户维度 SLI 的准确性，需要识别这些干扰进行降噪处理。提升分析性能，简化 SQL，很多分析需要连表查询，数据量增大的时候，会存在性能问题。于是添加了大量视图，重建了不同维度的索引表。将数据按分钟维度聚合成 SLI，避免了分析查询原始日志的性能开销。

接下来，一起看一下最终成果。

五、应运而生，建设可观测性平台

在整个改造的过程中，大家也看到了基本上都是一次投入，后续持续受益。整个流程运转起来后，后续就是提炼感兴趣的 SLI，并基于 Grafana 展示即可。

整个可观测性平台是基于 Grafana Clickhouse Prometheus 构建的，符合低代码平台研发，只要会写 SQL 就行。

我们一起看一下具体的看板。

1、小程序分析首页

首页看板用于大盘投屏使用的，包括两个部分，上部分是最近 15min 的瞬时数据，大于某个经验阈值会标红显示，下部分是长期趋势，比对同比和环比，各个面板都支持下钻分析。

首页一定要清爽，列出最关心的 SLI，如 QPS/UV、慢路由请求数、异常请求数。根据时延和 ErrorCode 分布，下钻到具体的分析页面。也可以通过分析长期趋势，查看小程序整体的状态，如慢路由风险是否在增加。

2、长期趋势分析

通过首页跳转到长期趋势分析，可以查看最近 1 周/1 月/1 年的宏观趋势，这块可以结合项目上线计划，分析上线节点前后的变化，如 UV 是否有增加，慢路由是否有增多的趋势，还可继续下钻分析具体哪些路由慢了。

3、Code 异常分析

在首页可以观察异常 code 分布，下钻到具体的 code 分析页，这里模拟分析一下 code=400 量增加的场景。

整个过程其实是一个模型匹配问答的模式。

是否需要人工介入？假定 SLO 为 code=400 的错误率