微信小程序端的可观测性平台建设与落地
道阻且长, 行则将至，行而不辍, 未来可期
大家好，前几篇文章一直在讲SRE，讲MDD(Metrics-Driven Development)，很多工程师不太理解，这到底有什么用呢，具体的收益点又在哪呢？前面也讲了一些落地案例（见：SRE实战(01) 初识+探索SRE如何推进好大夫在线技术债务改造），刚好最近在思考MDD结合SRE，花了两周的时间打造了小程序端的可观测平台。接下来和大家分享一下整个心路历程，谈谈我的一些启发，顺便谈谈当工程师具备MDD意识后，是否能如虎添翼。
事情的背景是这样的，2022年2月10日，好大夫部分小程序用户投诉上传图片失败。接到投诉后，业务研发团队立即组织人手进行排查，随着排查过程的深入，各兄弟团队（前端架构、系统架构和运维）都给予了很大的支持，整个排查过程有10多人参加，前后排查了三天（含周六日）才最终有结论。
一团乱麻，谁人背锅侠？
大家知道上传图片失败，一直是个老大难的问题，因为失败的原因太多了。对很多数工程师而言，整个流程是一个黑盒，完全不知道该如何去分析问题。
这时候工程师大脑中会有一堆问号：
简单说一下这个问题我们是如何排查的。
怀疑链路传输问题：我们有多家网络节点运营商，尝试切换链路，甚至直接回源，问题还依然存在。期间通过抓包并和运营商技术支持一起排查未能明确问题原因，给出的反馈还是用户侧问题；
怀疑用户网络问题：联系用户切换网络尝试依然失败，加上分析Kong日志，发现部分用户重试多次都是失败，切换到好大夫的APP能上传成功，前端认为不是用户侧网络问题；
怀疑好大夫小程序有新引入的bug：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的收集。
顺势而为，落地整体链路改造
用户侧：
每次小程序启动的时候发起一个探包请求，会上报一下版本信息(平台/版本/微信版本/微信基础库版本/小程序包名/小程序版本)，当然为了安全审计不会收集用户隐私相关的信息。探包请求还额外获得了小程序启动频次的粗略统计数据。
通过hash算法生成版本信息的指纹hash_key，后续的用户请求url和http header中都携带这个hash_key。
通过hash_key关联kong日志和版本信息，从而能提炼出终端不同维度的SLI。
为了将整个链路串联起来，小程序每次请求生成trace_id，并通过header透传下去。
小程序网络不佳的时候，会先将Error等日志信息暂存到LocalStorage队列中，等有网了再次上报。所有记录日志的地方都会记上trace_id，方便后续异常定位分析。
网络节点：
新增运营商标识，方便对比分析不同运营商传输的可用性。
收集运营商的日志，存储到Clickhouse中，方便后续分析，尽可能让网络传输节点可观测。
入口网关：
按业务类型拆分route_name，如上传，订单提交等等。
route_name支持打标签，如业务部门，所属页面等，方便告警监控及识别到的风险通知到具体的业务部门。
插件支持生成trace_id或透传已生成的trace_id，打通KongLog和后端服务TraceLog。
后端服务：
增加日志埋点，分析不同图片尺寸大小的上传下载相关的指标。
定义好不同的code码，方便异常定位分析。
可观测平台：
鉴于之前研发了强大的分析器，只用添加分析，告警规则就能满足这次场景需求。
为了节约研发成本，SLI存储到了Clickhouse，可视化基于Grafana写SQL绘制。
新增地理位置分析，将请求ip转换成经纬度，方便提炼地区维度的SLI。
整个小程序日志上报的流程如下：
我们在改造的过程中也遇到了不少问题：
控制Error信息大小。单条信息过大会导致Flume收集异常，重复收集或丢失日志。
采样上报，控制频次。一般异常发生可能会产生连锁反应，瞬时产生大量日志，需要避免频繁上报导致用户带宽的消耗。
降噪处理。如腾讯周期性安全扫描可能会产生一些干扰异常，如499等，会影响用户维度SLI的准确性，需要识别这些干扰进行降噪处理。
提升分析性能，简化SQL，很多分析需要连表查询，数据量增大的时候，会存在性能问题。于是添加了大量视图，重建了不同维度的索引表。将数据按分钟维度聚合成SLI，避免了分析查询原始日志的性能开销。
接下来，一起看一下最终成果。
应运而生，建设可观测性平台
在整个改造的过程中，大家也看到了基本上都是一次投入，后续持续受益。整个流程运转起来后，后续就是提炼感兴趣的SLI，并基于Grafana展示即可。
整个可观测性平台是基于Grafana+Clickhouse+Prometheus构建的，符合低代码平台研发，只要会写SQL就行。
我们一起看一下具体的看板：
No1.小程序分析首页
首页看板用于大盘投屏使用的，包括两个部分，上部分是最近15min的瞬时数据，大于某个经验阈值会标红显示，下部分是长期趋势，比对同比和环比，各个面板都支持下钻分析。
首页一定要清爽，列出最关心的SLI，如QPS/UV、慢路由请求数、异常请求数。根据时延和ErrorCode分布，下钻到具体的分析页面。也可以通过分析长期趋势，查看小程序整体的状态，如慢路由风险是否在增加。
No2.长期趋势分析
通过首页跳转到长期趋势分析，可以查看最近1周/1月/1年的宏观趋势，这块可以结合项目上线计划，分析上线节点前后的变化，如UV是否有增加，慢路由是否有增多的趋势，还可继续下钻分析具体哪些路由慢了。
No3.Code异常分析
在首页可以观察异常code分布，下钻到具体的code分析页，这里模拟分析一下code=400量增加的场景。
整个过程其实是一个模型匹配问答的模式。
1.是否需要人工介入？假定SLO为code=400的错误率<0.5%，p = total_400_request / (total_200_request + total_400_request)，如code=200访问量是10K，如果这时候400访问量达到500则需要人工介入排查。
2.同比环比是否具有差异性？分析当日请求判断是否具有突发性，分析一周数据判断是否具有周期性。比如每晚直播访问量就会到峰值，这个点错误率增加了可能是机器负载过高了，从而给排查提供一个方向。
3.是否具有路由差异性？是大面积无异常报错还是特定的路由异常，结合一周趋势，从而给出排查方向。
4.同理分析异常特征是否具有终端平台、微信版本、微信基础库版本、小程序版本差异性？
5.整个差异性分析的过程，其实是判断差异显著程度的过程，这里可能存在认知误区，如iPhone异常数比oppo大，很可能是iPhone总体访问基数大，这个时候其实是看各自长期占比趋势的。
如果判断出来特定route_name异常具有显著差异，可能是有突出抓取，或者业务代码异常，或者业务机器负载过高等等，这时候需要下钻分析。可下钻到”NO5.路由详情分析“，”NO6.抓取分析“。
No4.慢路由风险分析
慢，会严重影响用户体验，随着业务的发展，我们对慢的容忍度也越来越低，如果不关注性能问题，整个接口会朝熵增的方向恶化，用户会越来越不满意。
一般重点关注Top10的慢路由，可以分析是长期慢，还是突发抓取的慢，结合APM链路分析，整个请求慢在哪，是依赖中间件慢还是请求路径过长抑或是存在其他慢风险。这部分依然可下钻到”NO5.路由详情分析“，”NO6.抓取分析“。
NO5.路由详情分析
这部分依然在做问答题，主要是围绕给定的route_name展开分析的。
1.code分布是否具有显著差异性，如P99时延增加了，可能是缓存命中率code=304过低了。
2.同比环比是否具有差异性？尤其是周期性存在明显波动，或突发波动的会被优先怀疑。由于是在分析具体的路由，首要怀疑是否有线上变更，如图中P99具有显著差异性，是因为当天业务有修改线上配置造成的。结合链路分析慢的问题，最终优化了链路请求解决了这个问题。
3.是否是抓取造成的？另外一个常见的异常是由于蜘蛛突发抓取造成的，为了资源最大利用率，一般不会冗余过多的机器，当蜘蛛突发抓取冷数据的时候可能会造成波动。这部分主要是分析UA，为了避免UA过长带来的分析性能损耗，采用了hash ua的方式。结合ua占比，ClientIP占比，评估是否存在抓取的可能，具体可以下钻到“NO6.抓取分析”。
4.是否存在地域差异性？如北京用户异常占比过高，可能是北京链路出现了异常。
5.异常分布运营商节点是否存在显著差异？比如腾讯回源造成缓存穿透。
6.异常分布在后端节点上是否具有显著差异性？从而判断是否存在机器问题。这部分可以继续往机器的维度下钻，分析是CPU或其他资源异常。
7.如果以上常见场景都没命中，可以分析客户端相关信息是否具有显著差异性。
NO6.抓取分析
抓取分析就比较简单了，判断UA和ClientIP访问占比，抓取一般特征是单个UA访问量突增，ClientIP比较集中，结合QPM长期趋势，判断是正常访问还是抓取。
NO7.程序异常分析概览
为了更好的反映小程序的异常，会收集异常信息进行统计分析，这里和前面类似了，就不展开分析了。
道阻且长, 思考从1到n的演化
做到这，小程序可观测性平台已经从0到1了，但这只是一个开始，后续要如何演化推进，还面临了很多困难。
如何验证？
可观测性平台是否能帮助大家进行异常定位呢？线上真实异常可以验证，但太被动了，能否主动模拟异常？如模拟抓取，或单个机器异常。这部分也是今年主要发力的地方，会通过混沌实验平台去辅助故障演练。
如何推广？
小程序面向的业务场景茫茫多，如何让工程师转变习惯去适应新的排障工具，也是一个难点。这部分除了培训分享以及持续迭代平台外，可以召集大家攻防演练，在实践中让大家快速掌握新工具，发现平台的不足一起共建。
如何横向迁移？
其实这次只是做了小程序端的可观测性，能否延伸到其他各端(触屏/PC/APP)呢？能否推广到中间件，能否推广到其他业务呢？试想一下，业务团队基于MDD达成共识后，工程师很多工作就能被量化了，比如优化了几个慢路由，降低了p99时延，先于用户发现问题，加速定位问题，是否提升了UV等等，都可被观测到。其次工程师可以主动发现一些问题，如上线后接口变慢了，到底慢在了哪里，是否存在慢SQL风险等等，就会主动去探寻风险点。
如何更快定位异常？
工程问题是需要数学建模，可观测性只是第一步，要想提效不能靠人脑经验分析，如何评估异常的显著差异及关联性，需要选择相应的算法，通过函数拟合建模分析。
如何优化用户体验？
数据分析，不同的人会有不同的思路，可观测性反映的现象由于每个人的经验不同，排查思路可能也迥异。另外异常分析定位平台无法穷举所有的异常，就像患者病因溯源一样，很多分析场景具有跳跃性。平台能做的就是尽可能多的给出工程师常用排障按钮，就像超链接一样，让大家按照自己的思路去排查。后续分析这些行为，选择最短路径，固化到程序中，从而达到高效的根因定位。
缩短MTTR还有很长的路要走，一起共勉，道阻且长, 行则将至，行而不辍, 未来可期。
今天的分享就到这吧，感谢在整个建设过程中一起努力的小伙伴们（韩兴达、梁伟、孙文华、尤锦忠、翟康奇、欧阳陆伟、张旭和张国超），也欢迎大家持续关注我们的SRE专题，一起共建高可用的服务体系。
方勇：好大夫基础架构部高级工程师，专注于 SRE，微服务、中间件的稳定性和可用性建设，整体负责好大夫服务治理云平台的设计和搭建。
好大夫在线创立于2006年，是中国领先的互联网医疗平台之一。已收录国内10496家正规医院的69.2万名医生信息。其中，23万名医生在平台上实名注册，直接向患者提供线上医疗服务。“让行医简单，看病不难” ，始终追求“成为值得信赖的医疗平台”。