图片来自极客时间

问题5：关于报警优化的方法？

• 报警合并：把一些一样性质的指标合并掉，或者只保留一个。
• 报警升级：可以逐级报警。

二、容量篇

问题1：容量的目的是什么？

容量的目标就是资源、稳定性、业务发展三者之间取得平衡，利用有限的支撑尽可能多的流量。

问题2：如何衡量容量是否充足，有哪些指标来衡量？

首先是容量如何定义，如果是入口则按照QPS来进行。如果是内部服务，则按照CPU来进行（绝大部分都是CPU，除了少量的）。

这个是为什么呢？如果在后端服务因为受制于机型、容器配额等等，不可能每一个都压测出一个比较准确的极限值，而且压测成本很高，所以只需要关注CPU就行。

问题3：容量的数据从哪里来？

容量数据从哪里来呢？压测、日常监控、经验等，都需要有一个平台来记录。

问题4：如果发现容量不足了应该如何处理呢？

常见的方式有快速扩缩容、限流、降级、错峰、缓存等。

问题5：针对xxcase你有什么解决方案？

故障1：2021年12月由于西安疫情的加重，在2021年12月20日，西安市“一码通”因访问量过大导致系统崩溃。无法扫码导致许多西安市民难以进行核酸检测。

故障原因：流量突然变大，负载过重，短时间由于各种条件限制无法及时扩容和分流导致。这个跟当年火车站抢票一样。

针对西安健康码的案例，我们应该做什么：

• 首先是限流，一定要确保自己的服务不挂；
• 第二是快速扩容，如果服务在云上，利用云上的资源快速扩容自己的服务；
• 第三是降级，看看有哪些接口没用的，赶紧降级调，把用户最关心的红码、黄、绿 这一个信息保留就行，其他图片加载都可以去掉；
• 第四是缓存，如果是15分钟查过的就缓存一下，不要让用户无限重试。

问题6：容量保障的方法论是什么？

（这个问题一般是百度T5，阿里P6以上会问到的问题。）

三、变更篇

问题1：变更的目标是什么？

变更的目标：在效率和稳定性上取得一个均衡。

目前60%以上的故障都来自变更，这个想想为什么，因为变化才更容易导致问题，不能因为没有故障，就不变更。

问题2: 如何减少变更的影响？