图片来自极客时间
问题5：关于报警优化的方法？
- 报警合并：把一些一样性质的指标合并掉，或者只保留一个。
- 报警升级：可以逐级报警。
二、容量篇
问题1：容量的目的是什么？
容量的目标就是资源、稳定性、业务发展三者之间取得平衡，利用有限的支撑尽可能多的流量。
问题2：如何衡量容量是否充足，有哪些指标来衡量？
首先是容量如何定义，如果是入口则按照QPS来进行。如果是内部服务，则按照CPU来进行（绝大部分都是CPU，除了少量的）。
这个是为什么呢？如果在后端服务因为受制于机型、容器配额等等，不可能每一个都压测出一个比较准确的极限值，而且压测成本很高，所以只需要关注CPU就行。
问题3：容量的数据从哪里来？
容量数据从哪里来呢？压测、日常监控、经验等，都需要有一个平台来记录。
问题4：如果发现容量不足了应该如何处理呢？
常见的方式有快速扩缩容、限流、降级、错峰、缓存等。
问题5：针对xxcase你有什么解决方案？
故障1：2021年12月由于西安疫情的加重，在2021年12月20日，西安市“一码通”因访问量过大导致系统崩溃。无法扫码导致许多西安市民难以进行核酸检测。
故障原因：流量突然变大，负载过重，短时间由于各种条件限制无法及时扩容和分流导致。这个跟当年火车站抢票一样。
针对西安健康码的案例，我们应该做什么：
- 首先是限流，一定要确保自己的服务不挂；
- 第二是快速扩容，如果服务在云上，利用云上的资源快速扩容自己的服务；
- 第三是降级，看看有哪些接口没用的，赶紧降级调，把用户最关心的红码、黄、绿 这一个信息保留就行，其他图片加载都可以去掉；
- 第四是缓存，如果是15分钟查过的就缓存一下，不要让用户无限重试。
问题6：容量保障的方法论是什么？
（这个问题一般是百度T5，阿里P6以上会问到的问题。）
三、变更篇
问题1：变更的目标是什么？
变更的目标：在效率和稳定性上取得一个均衡。
目前60%以上的故障都来自变更，这个想想为什么，因为变化才更容易导致问题，不能因为没有故障，就不变更。
问题2: 如何减少变更的影响？
