最近想着把MDD和SRE结合起来，花了两周的时间在小程序端搭建了一个可观察的平台。接下来，跟大家分享一下全程。说说我的一些感悟吧，顺便说说一个有MDD意识的工程师能不能如虎添翼。事情的背景是这样的。2月10日，部分好豆腐小程序用户投诉上传图片失败。整个调查过程有10多人参与，历时三天得出结论。让我们回顾一下当时的情况。1.乱七八糟谁负责？大家都知道上传图片失败的问题一直是个大问题，因为失败的原因太多了。对于一般工程师来说，整个过程可能是一个黑盒模型，缺乏分析问题的句柄。这时候，工程师的脑子里就会出现一堆问号。简要说明这个问题是如何解决的。怀疑是用户网络有问题，尝试联系用户切换网络仍然失败。除了分析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节点异常，或者上游节点异常，都会导致上传失败。对于后端图片服务，如果处理能力不足、负载高、进程卡顿等异常也会导致上传失败。在思考如何实现普适性之后，我们必须面对以下问题。能否有效观察到异常？异常位置需要大量经验，如何降低传承成本？异常分析的提效工具链有哪些，能否平台化？有几万个异常，再加上排练组合，真的能通过数据分析找出来吗？异常分析平台增加了学习成本，会不会增加工程师的负担，会不会质疑研发平台的收益？仔细想想，我有点后怕，定位异常非常难，定位异常提升效率更难！2、追根溯源，能否提高异常定位的效率？很多工程师在分析异常的时候，往往只关注单一的问题，一上来就卡在案例分析的细节上，耗费精力和心态，心态就会崩溃。随着网站拓扑结构的演进，定位异常的难度越来越大。很多公司都在推进SRE系统的建设，对可观察性的呼声越来越高。如何量化和观察异常。这其实是一个“工程问题”。所谓工程问题本质上是数学，需要在定义明确的环境中用定义明确的参数描述一个定义明确的问题。网站异常的原因是多种多样的，就像诊断病人一样。统计分析健康人与患者各项身体机能指标的差异，从而判断疾病的严重程度，探寻病因。结合我日常的一些排查经验，我们来看看异常定位的工程问题。异常定位需要在一个参照系中进行，通过可视化界面呈现SLI的波动性，而SLI的波动性往往与异常的根本原因有关。分析不同SLI波动的幅度差异，推断异常的可能原因。简单地说，就是对异常进行数学建模，并将它们与可观察到的SLI相关联。通过SLI的外观检查异常原因。说起来比较简单，就像医生的诊断一样，往往一种病理现象对应不同的病因，同一种病因会有不同的表现。有急性传播、慢性传播和弥散传播。一个病变可能引起身体其他一系列病变，追查病因可能需要多次会诊。当然，经验越丰富，数据越多，模型分析就会越准确。综上所述，异常定位提效的首要任务是对异常进行量化，使异常能够被观察到。二是友好的界面提示，一步步引导您定位问题。下面我们来探讨如何在小程序中构建上传图片整体链路的可观测性，尝试对异常定位工程问题进行建模分析。3.突破再站起来。MDD拆分了黑盒模型。具体来说，在上传图片的场景中，SRE系统关注的是每个环节和整体环节的可用性。MDD的思想是我们需要提炼出合适的SLI，设定SLO，达成共识，然后围绕这些SLO进行工作。我们来看看每个上传图片的环节中我们感兴趣的点。这里总结一些经验：“两点一线，分两侧，一侧监控人像，另一侧定位异常”。为了尽可能多地观察每一个环节，我们需要梳理一个上下文，比如请求的开始到结束，抓住这两个点，连成一条线，分成两边，一边侧重于长期趋势，另一侧侧重于异常分析。SLI的具体细化可以参考GoogleVALET（Volume,Available,Latency,Error,Ticket）模型。从图中我们可以看出，需要一个参考系统来评估链路的各个环节是否存在风险或异常。长期指标趋势和经验阈值是参考数据来源。因此，设置SLO有两种方式。第一种是根据经验设定一个固定的阈值，比如QPS峰值不要超过10k；二是设置一个相对值，比如code=404，环比增加20%。通过这些准备工作，我们提取了以下SLI和SLO供您参考。对于异常可观测性，SLI需要根据不同的维度进行细分。这次上传的图片不正常是因为微信灰化了一个特定的基础库。改造后需要收集终端相关信息，如设备平台、设备型号、微信版本等。、微信库版本和小程序版本。在对上传图片的链接进行建模分析的时候，我一直在考虑这些体验是否可以扩展到小程序的整体可观察性上？因此进一步细化分析维度，根据不同的小程序包统计不同代码、路由、域的请求数和延迟数。这样可以更好的支持drill-down，可以迁移到整个小程序的异常分析。接下来，让我们看看如何转换每个链接以收集SLI。四、顺势而为，实现整体链路改造1、每次小程序启动，用户端发起一次包检测请求，上报版本信息（平台/版本/微信版本/微信基础库版本/小程序包名)/小程序版)，当然不会收集涉及用户隐私的信息进行安全审计。包检测请求也得到了小程序启动频率的粗略统计数据。通过hash算法生成版本信息的指纹hash_key，hash_key携带在后续用户请求的url和http头中。konglog和版本信息通过hash_key关联，可以提取终端不同维度的SLI。为了串联整个链路，小程序为每个请求生成一个trace_id，通过header透传。当小程序网络不好的时候，会把Error等日志信息暂存到LocalStorage队列中，等网络好了再上报。所有的logging地方都会记录trace_id，方便后续异常定位分析。2、网络节点新增运营商标识，方便不同运营商传输可用性的对比分析。收集运营商日志并存储在Clickhouse中供后续分析，使网络传输节点尽可能可观察。3.Ingress网关根据业务类型拆分route_name，如上传、提交订单等。route_name支持标签化，如业务部门、页面等，方便告警监控，将识别出的风险通知具体业务部门。插件支持生成trace_id或者透传生成的trace_id连接KongLog和后端服务TraceLog。4、后台服务增加日志埋点，分析不同图片大小上传下载相关指标。定义不同的代码，方便异常定位分析。5.Observable平台鉴于之前开发的强大的analyzer，只需要增加分析和告警规则就可以满足这个场景的需求。为了节省研发成本，SLI存储在Clickhouse，可视化基于Grafana编写SQL绘制。新增地理位置解析，将请求ip转换为经纬度，方便提取区域维度的SLI。整个小程序的日志上报过程如下：改造过程中，遇到了很多问题。控制错误信息的大小。如果单条信息量过大，Flume采集会出现异常，反复采集会导致日志丢失。采样和报告，频率控制。一般来说，异常的发生可能会引起连锁反应，瞬间产生大量的日志。需要避免频繁上报和消耗用户带宽。降噪处理。比如腾讯的周期性安全扫描可能会产生一些干扰异常，比如499等，影响用户维度SLI的准确性。需要识别这些干扰并进行降噪处理。提高分析性能并简化SQL。许多分析需要表连接查询。当数据量增加时，就会出现性能问题。于是增加了大量的视图，重建了不同维度的索引表。将数据按分钟维度聚合到SLI，避免分析查询原始日志的性能开销。接下来，让我们来看看最终的结果。5.应运而生，搭建可观测平台。在整个转型过程中，大家也看到了，基本上是一次性投入，后续会持续受益。整个流程运行起来之后，后续就是提炼感兴趣的SLI，并基于Grafana进行展示。整个可观察平台基于Grafana+Clickhouse+Prometheus搭建，符合低代码平台的发展，只要会写SQL即可。我们来看看具体的看板。1.小程序分析首页看板用于行情预测，包括两部分，上半部分是最近15分钟的瞬时数据，超过一定经验阈值会以红色显示，下半部分为长期趋势，与去年同期及环比相比，各面板均支持向下钻取分析。首页一定要清晰明了，列出最关心的SLI，比如QPS/UV、慢速路由请求数、异常请求数等。根据延迟和ErrorCode分布，下钻到具体的分析页面。你也可以通过分析长期趋势来查看小程序的整体状态，比如路由慢的风险是否在增加。2、长期趋势分析跳转到首页长期趋势分析，可以查看最近一周/一个月/一年的宏观趋势。这个部分可以结合项目上线计划，分析上线节点前后的变化，比如UV有没有增加，如果慢路由有增加的趋势，可以继续下钻分析哪些路由很慢。3、代码异常分析在首页可以观察到异常代码的分布情况，下钻到具体的代码分析页面，模拟分析代码数量=400增加的场景。整个过程其实就是一个模型匹配的问答模式。是否需要人为干预？假设SLO是code=400错误率<0.5%，p=total_400_request/(total_200_request+total_400_request)，比如code=200，访问次数为10K，如果400访问次数达到500这个时候就需要人工干预了。年年有区别吗？分析一天的请求判断是不是突发性的，分析一周的数据判断是不是周期性的。比如每晚的直播访问量都会达到顶峰。如果此时错误率增加，可能是机器负载过高，从而为故障排除提供方向。有路由区分吗？无论是大规模非异常报错，还是特定路由异常，结合周趋势，给出排查方向。同理分析异常特征是否存在终端平台、微信版本、微信基础库版本、小程序版本差异？整个差异分析过程其实就是一个判断差异显着性的过程。这里可能存在认知上的误区。比如iPhone的异常数量就比OPPO多，这很可能是因为iPhone的整体访问量大。这个时候其实就是看各自占比的长期趋势。的。如果判断具体route_name异常有明显差异，可能是爬行比较突出，或者是业务代码异常，或者是业务机负载过高等。这时候，需要向下钻取分析。可以深入到《NO5.路由详情分析》和《NO6.爬虫分析》。4、慢路由风险分析速度慢，影响用户体验。随着业务的发展，如果不注意性能问题，整个界面会朝着熵增的方向恶化，可能会越来越慢。一般关注前10条慢路由，可以分析是长期慢还是突发爬取慢，结合APM链路分析，整个请求慢在哪里，是依赖中间件还是请求路径太慢长，否则还有其他缓慢的风险。这部分还是可以细化到“NO5.路由细节分析”和“NO6.抓取分析”。5.路由细节分析这部分还是做问答题，主要是针对给定的route_name的分析。代码分布是否明显不同，比如P99延迟增加，可能是缓存命中率code=304太低。年年有区别吗？尤其是有明显周期性波动或突然波动的，会首先被怀疑。由于我们分析的是具体的路由，所以我们首先怀疑是否有线上变化。图中P99的显着差异是由于当天业务修改了线上配置。结合慢速链接问题分析，最终对链接请求进行了优化，解决了这个问题。是爬行引起的吗？另一种常见的异常是由蜘蛛突然爬行引起的。为了最大限度地利用资源，一般不会有多余的机器。当蜘蛛突然抓取冷数据时，可能会引起波动。这部分主要是分析UA。为了避免UA过长带来的分析性能损失，采用了hashua的方式。结合ua和ClientIP的占比，评估是否有爬取的可能。详情可以深入《NO6.爬虫分析》。有地域差异吗？如果北京用户异常比例过高，可能是北京的链路异常。算子节点异常分布是否有显着差异？比如腾讯回源导致缓存穿透。后端节点之间的异常分布是否有显着差异？从而判断机器是否有问题。这部分可以继续下钻到机器的维度，分析是CPU还是其他资源异常。如果以上常见场景均未命中，则可以分析客户端相关信息是否存在显着差异。6、抓取分析抓取分析比较简单。从UA和ClientIP的访问比例来看，爬虫的普遍特征是单个UA的访问量突然增加，ClientIP集中。结合QPM的长期趋势，判断是正常访问还是爬虫。7.程序异常分析概述为了更好的反映小程序的异常情况，会收集异常信息进行统计分析。这个和上一个类似，就不展开分析了。六、路漫漫其修远兮，想着从1到n的进化实现这个，小程序可观测平台已经从0到1了，但这只是开始，如何进化还有很多困难并在未来取得进步。1.如何验证？可观测平台能否帮助定位异常？线上真实异常可以验证，但过于被动??。他们能主动模拟异常吗？比如模拟爬虫，或者单机异常。这部分也是今年的重点工作，将利用混沌实验平台辅助故障演练。2、如何推广？小程序的业务场景非常多，如何让工程师改变习惯去适应新的排查工具也是一个难点。除了培训分享和平台的不断迭代，这部分可以召集大家进行攻防演练。在实践中，大家可以快速掌握新的工具，发现平台的不足，共同搭建。3、如何横向迁移？其实这次我们只做了小程序端的observability，可不可以扩展到其他端（触屏/PC/APP）？能不能扩展到中间件，能不能扩展到其他业务？试想一下，业务团队基于MDD达成共识后，工程师的很多工作都可以量化，比如优化几条慢路由，降低p99延迟，先于用户发现问题，加快问题定位，是否改善紫外线等，可以观察到。其次，工程师可以主动发现一些问题，比如上线后界面变慢，慢在哪里，是否有慢SQL的风险等等，会主动挖掘风险点。4、如何更快定位异常？工程问题需要数学建模，可观测性只是第一步。为了提高效率，不能用人脑经验分析。如何评价异常的显着性差异和相关性，需要选择相应的算法，通过函数拟合进行建模分析。.5、如何优化用户体验？对于数据分析，不同的人会有不同的想法，可观察性所反映的现象可能因每个人的经历不同而不同，排错的思路也可能大相径庭。另外，异常分析定位平台无法穷举所有异常。就像追查一个病人的病因一样，很多分析场景都是跳动的。平台能做的就是给工程师尽可能多的故障排查按钮，就像超链接一样，让大家按照自己的想法进行排查。后续对这些行为进行分析，选择最短路径，固化到程序中，从而实现AI智能根因定位。缩短MTTR还有很长的路要走。让我们互相鼓励。路漫漫其修远兮，但很快就会到来。坚持下去，未来可期。
