遇到线上问题，经常陷入一个误区：一定要找到问题的根因（root cause）。但实际上对线上应用而言，最重要的是恢复可用性，所以在开发设计环境除了完成功能性需求以外，还需要加入非功能性设计的需求：

  1. 限流保护。抵挡来自突发流量冲垮整个集群。
  2. 降级保护，对调用的服务接口保持警惕，其各种因素导致不可用，可以对齐降级，从而确保核心功能可用。
  3. 削峰填谷（traffic shaping），不因突发数据来袭，造成任务消费陡增，造成调用系统的连串抖动。

这些基本的系统保护，是应对未来的各种突发不确定事件的高可用思考。

以上描述的是问题的应对机制设计，问题的发现机制，也需要结构化地考虑，体系化地建设：

  • 发现机制，是我们的眼睛，也是基础。
    • 监控主指标，需要找对业务的主要指标，常见的主指标一般是：RT（响应时间）、总量、成功量、失败量、成功率。
    • 主指标有异常，还要有细分维度（即结果还可以内部 group by aggregation）。
  • 快速恢复
    • 根据监控快速寻找问题发生的方向和位置。
    • 找对恢复的人、恢复的预案。
    • 倾向于选择成本低的恢复手段。—— 并不是所有的恢复都用大招（熔断、限流），大招一定有损且有风险
  • 最后执行恢复
    • 一般我们都会对恢复预案做演练，避免恢复预案失效。或者因执行了预案产生更大的问题。
    • 执行恢复动作要谨慎。一切线上操作都为变更，都有风险。

经验告诉我们：线上问题70%来自变更，找到变更快速回滚是第一优先级，其余30%的问题需要做好预案及防护，快速对应不同的线上突然事件。

高可用思路