我在 Shopee 维护一个 Service Mesh 系统，大部分的 RPC 调用要经过这个系统，这个系统每分钟要处置上千万的央求。我们在本文中就把它叫做 Oitsi 系统吧，方便描画一些。干的事情其实和 Istio 是差不多的。

Oitsi 将对 RPC 调用设置了很多错误码，相似于 HTTP 协议的 404, 502 等等。Application 报出来的错误码在一个区间，Oitsi 外部产生的错误在另一个区间，比如 0-1000，相似于 System Internal Error，监控这些错误码可以让我们知道这个系统的运转状况。

这个系统自从接手之后就有一个成绩，就是它每时每刻都在报出来很多外部错误，比如发作外部超时，路由信息找不到，等等，每分钟有上万个错误。但是，系统的运转是完全正常的。

Oitsi 系统在正常状况下的错误

从这个脱敏之后的监控可以看到，常常有一些错误一下子动辄上万，除了图中几 K 的那些错误，在 1K 以下有更多密集的错误，只不过它们都被其他巨量的错误给拉平了，在这张图不清楚。

这就给我们形成了很多成绩：究竟是 Oitsi 真出了成绩，还是属于“正常的错误”?很难判别，每次发作这种状况都费时费力。大部分状况都是排查一番，然后发现是用户“滥用”形成的成绩，不需求关心。而它又掩盖了很多真实的成绩，比如一个新的版本发布之后偶然会有一些外部的错误，是不应该发作的，却被真实的成绩掩盖住了。基于这样的监控数据我们也无法设置告警，由于这些噪音太多了，即使有告警，也和没有一样。

这让我想起之前在蚂蚁的任务，我们有相似的成绩。我有一年多的时间都在一个叫做“缺点定位”的项目上。在蚂蚁我们也有很多告警(99%的)都是有效的，给 On Call 的同事带来很多噪音和打扰。在蚂蚁的思绪是：开发一个“智能系统”(AI Ops)，当告警发作的时分，自动地判别这个告警是不是噪音，是不是真正的成绩，成绩出在了哪里。拿到 Oitsi 的例子上说，当如今一个错误的数量突增，那么这个智能缺点定位系统就去反省 Oitsi 的一些目的能否正常，招致告警的效劳详细是什么，它之前是不是不断有相似的监控曲线形式，假设有，阐明它不断在发作，是正常的，我们可以不管。

这样做了一年，效果还是不怎样样。我倒是发现，很多告警的规则本身就有成绩，比如一个央求量每分钟只要两位数的效劳，指导的要求是 “1分钟发现缺点，5分钟定位缺点”，不要说自动定位，就算是人去判别都不靠谱。为了达成这个目的，监控团队设置了很多十分敏锐的告警，交给定位团队说：“我们担任发现成绩，你们担任定位成绩。假设出成绩了，1分钟之内有告警触发，那么我们的任务就达标了。但是至于没有成绩我们也触发了很多噪音告警，就是你们的任务了。” 它们的 KPI 确实是完成了，只需有缺点必定有告警。但理想是，在很多状况下，告警收回来，大家翻开监控，盯着监控：“在等等看，看下一分钟，有央求出去了，效劳没成绩!”

所以这一年任务里，我有一个想法，就是在源头处置成绩比运用初级的魔法系统去处置成绩要复杂、彻底很多。我们真的需求这么多人来开发一个“魔法系统”来帮我们诊断这种成绩吗?

比如监控配置的不对，那就优化监控。监控为什么配置的不对?监控系统太难用，UI 让人捉摸不透，配置了告警无法调试，监控只能保存7天的数据，不能基于历史的监控数据配置告警。很多人为了“规则”，对效劳配上了告警然后就走了，至于前面告警触发了，也不去照应。

回到 Oitsi 的成绩上，我找了几个效劳，发现这些 Oitsi 外部错误上并不能完全说是“正常的错误”，毕竟它是错误，没有错误解是正常的。只能说它没有招致线上成绩而已。它们是可以被修复的。于是一个月前，我决议从源头去处置这些成绩。把一切不应该报告出来的错误都消灭掉。

乍一看这么多错误数，用那么多团队在用，看起来是难以管理的，性价比十分低的任务。但是毕竟也没有人催我要快点完成，我可以一点一点去做。做一点错误就少一些(只需我处置成绩的速度比新的成绩出现的速度快)。

于是我按照下面的流程末尾处置：

在 Jira(我们外部的工单系统)树立一个专题 tag，叫做 oitsi-abuse，前面的工单可以关联这个 tag，这样，可以在处置的时分方便参考之前的 Case;

创立一个监控，专门针对错误做一个面板，点击面板右侧的 Legend 可以直接跳到效劳的监控面板，在效劳的监控面板上显示下游，并且关联 CMDB 的 PIC(Person in charge);

这样，我从错误数最高的效劳末尾，查看监控，看下游效劳，以及机器上的日志，看相关的错误码是什么时分末尾的，究竟是什么惹起的，确定了是效劳的成绩就创立工单给这个效劳的担任人，然后跟他联络，阐明这个有什么成绩，会对我们的监控、告警形成什么影响，需求修复;

等他确认成绩，然后要求提供一个 ETA(估量修复的时间)，把 ETA 写到工单中，到了时间去反省确认;

假设是 Oitsi 本身的成绩，去找 Oitsi 开发同事排查成绩;

等一切的成绩都处置了的话，对错误设置告警，一有错误就去联络开发。普通状况下，都是他们做的配置变更或许发布惹起了成绩。这样关于业务其实是愈加安康的，我们发现成绩的才能更强了。

就这样，其实这样坐上去就发现只要那么几类成绩，排查的速度越来越快。中间还发现一个库，它会去对 Oitsi 效劳做心跳反省，这个反省设置不当会有一些错误。很多援用了这个库的运用都有一只在报错误的成绩。但是我们细叱本身其实曾经做了探活可以保证心跳之类的成绩了，沟通之后这个库的心跳反省行为可以下线。于是库发布了新的版本，我找一切的援用者去晋级版本，很多错误一下子就消逝了，十分有成就感。

这项任务的进度比我想象中的要快，一个多月，联络了 20 多个团队。虽然说也遇到了一些很扯的事情，明明是效劳 A 的成绩，就直接让我去找下游，让我们排查半天，最后又说回来找效劳 A 担任人，拉了个群，摆出往日志，才供认是本人的成绩，末尾排查。但是大部分团队都十分配合，阐明成绩之后马上去排查，发现成绩下一个版本就修复了。如此默契的协作让我感到诧异又幸福!如今，系统错误维持在 200 以下了，并且现有的错误都曾经找到了根因，还有3个效劳待修复。最晚的会在 2 个周之后发布修复。可以预见到在不远的未来，这个系统将会成为一个 0 错误的系统!

明天细叱报出的错误，还是有一些效劳在不断报错，不过曾经大大增加了。

(责任编辑：admin)