这项任务虽然不触及任何的 KPI 之类的，也没有什么技术含量，还都是一些“沟通”的任务，但是却带给我很大的成就感。我置信它也会在未来节省我很多时间。比如说我们评价系统的 SLI 和 SLO，由于 false alarm 太多，招致要花很多任务确定 down time 有多少，如今直接经过监控就可以确定了。

这项任务带给我的一些感想：

从源头处置成绩最彻底;

不关键怕沟通;

错误的发作都有缘由，排查下去，零就是零，一就是一(从这个 Case 看，也确实一切的错误都可以被处置的);

每个公司都有脏活，累活(毕业去的第一家公司维护爬虫，也有很多脏活、累活)，这些都需求有人去做。

需求补充一下，我并不是完全否认做缺点定位的思绪。毕竟之前在蚂蚁，有四五个组在做相反的东西，我们(和其他做一样东西的组)尝试过十分多的思绪，也有很多人由于这些提升了(你说去联络了有数个团队，排查了很多成绩，这有什么 impact 呢?你说本人做了一个“智能定位”系统，提升就稳了吧。)。印象比较深入的是有个项目制定了上千个(他们称为)决策树，复杂来说就是：假设发作这个，就去反省这个。颇有成效，很多配置不当的告警就被这种规则给过滤掉了(虽然我觉得直接改报警要好一些)。我十分佩服他们的毅力。

说了这么多湿货，再说点干货。我们其实还有一个成绩没有处置。假设读者有思绪，欢迎评论。

在 Service Mesh 中，一切的效劳都是经过 Agent 来调用的。比如 App1 要调用 App2，它会把央求发到本地的 Agent 中，由 Agent 去调用 App2 所在机器的 Agent。

这里，超时的成绩就难处置。比如我们设置了 1s 超时。假设说 server 端的 Application 超时了，那么 Server 段的 Agent 可以报告一个运用超时错误，不算做我们 Oitsi 系统错误。但是关于客户端的 Agent 呢?它无法知道究竟是 Server 的运用超时了，还是 Server 的 Agent 超时了。所以关于 Server 超时的状况下，客户端的 Agent 总会报出一个外部超时错误。

这种错误，我们以后还是无法区分能否是由运用惹起的。

(责任编辑：admin)