稳定性实战指南

最新推荐文章于 2024-07-08 20:51:10 发布

程序员麻辣烫

最新推荐文章于 2024-07-08 20:51:10 发布

阅读量615

点赞数 19

分类专栏：架构文章标签：后端

本文链接：https://blog.csdn.net/shida219/article/details/139726035

版权

架构专栏收录该内容

48 篇文章 16 订阅

订阅专栏

在任何项目开发过程中，稳定性治理是不可或缺的一环。原因何在？

当系统出现问题时，我们是否能及时发现并应对？
我们是否对系统的整体稳定性有清晰的认识？
面对出现的问题，我们应如何解决？

因此，稳定性的维护需从两个维度考虑：首先是问题的发现，其次是问题的解决。

发现问题

如何有效地发现问题？首先，我们需要对“问题”有一个明确的定义。例如，当成功率低于99.99%时，这是否构成一个问题，以至于需要触发警报？或者只有当问题足够严重，才值得深入调查和报警？不同的定义将直接影响后续的处理策略。

报警机制

实施有效的报警机制是必要的。虽然不同的公司因基础设施差异而采用不同的报警方案，但有一些通用的报警规则可供参考。

报警规则概览

系统层面

CPU使用率过高、内存占用过大
流量负载分布不均
实例进程异常退出
响应时间增长

这类报警发生的频率相对较低。

业务层面

接口成功率下降
错误日志QPS超过设定阈值
下游系统错误率上升
请求量波动
针对特定模块的特殊配置需求
特定错误量突增
程序崩溃（panic）

这些规则尽可能配置，它们对于监控系统状态非常有用。

报警治理

仅仅配置好报警规则并不足够。过多的无效报警会导致人们对报警的敏感度降低。因此，报警治理变得尤为重要。

阈值调整：检查当前的阈值设置是否合理。比如，频繁波动的请求量或成功率频繁触发99.99%的报警，可能需要重新设定阈值。对于请求量较小的接口，可以根据请求量调整报警阈值。
流量准确性：确保统计的流量准确无误，排除如压力测试、自动化测试等非生产流量。
错误类型筛选：并非所有错误都需要触发报警。例如，由风控措施或地区限制引起的错误可以不被计入错误统计中。同时，为了不漏掉真正的问题，可以设立特定错误量突增的报警规则作为补充。

报警治理是一个持续调优的过程。初期可能需要较多的关注和调整，但随着时间的推移，系统将趋于稳定，报警也将更加精准。

L0报警的视角

团队通常会对L0链路（即最关键的服务路径）进行梳理，并加强对其的监控。虽然在报警系统中标记L0链路有其优势，但是否需要为L0链路独立设置一套报警系统还需进一步考量。因为如果报警系统能够有效减少噪音，那么触发的每一个报警都值得立即关注。

报警等级与通知方式

根据报警的严重等级（如警告、紧急），采取不同的通知方式，包括推送消息、短信、电话甚至直接联系领导。关键在于不要让错误等级与通知方式混淆。例如，曾有QA团队因L0链路稳定性问题而频繁夜间电话报警，引发的问题往往不值得深夜唤醒多人处理。这种情况下，可以通过优化报警配置（如屏蔽某些错误码、缩小通知范围）来解决。可以保持当前的配置只发消息，重新配置一份规则，在极小阈值情况下触发电话。本质上，需要区分稳定性问题和真正紧急的问题所采取的通知方式。