稳定性：可用性治理的三个关键要点

从事故预防的角度聊一聊可用性治理的关键动作

团队稳定性军规

• 业务发展会带动系统演进
• 围绕系统的风险隐患，建立 "防火墙"

变更会引起 90% 以上的故障

以年为单位统计了事故，得出了 90% 的数字

• 互联网公司的研发模式基本都是"小步快走、高速迭代"
• 系统复杂度的提高，增加了变更时所带来的不确定性 "发布三板斧"：
  • 可监控
  • 可回滚
  • 可灰度
• 发布需要监控
  • 完善的监控告警比人工反馈响应更快
  • 没有监控的变更就像盲人摸象
  • 有效的监控需要回答三个问题：（1）是否有问题发生？（2）哪里发生了问题？（3）发生了什么问题？
  • 结合业务配置有效的监控
• 有效灰度必须有耐心：
  • "灰度就是在生产环境进行小范围测试"，这句话是错误的，它本真是为了对抗"未知的不确定性"。需要更加谨慎地进行灰度，确保即使问题真的在生产环境出现，造成的影响也是可控的。
  • "在灰度的落地与推进过程中，要注意有效性"。一个系统部署在 2 个机房，每个机房 4 个集群，灰度顺序应该是单机房单集群中部分节点、单机房单集群中全部节点、单机房中全部集群，然后另外一个机房重复这个步骤。
  • 时间：每个灰度阶段至少有 5~10 min 的观察，在监控、日志和各方反馈没有异常后再扩大灰度范围，确保一些运行时异常或量变积累质变的问题可以暴露出来。
  • 流量：有时一些业务场景需要满足特定的触发条件。
  • 结合实际的情况与风险程度来确定灰度的程度
• 回滚是变更的"后悔药"
  • "何时回滚"以及"如何确保回滚"
  • "已经产生了线上影响，并且可能有资损，怎么能过两天再修复？"，"发现问题第一时间就能解决的事儿，为什么不回滚？"
  • 研发对事故的敬畏之心不足时，回滚也会失灵。
  • 如何确保变更是可以回滚的呢？可回滚的本质是系统的兼容设计与实现，比如：常见的"只增不改"
• 坚守 Design For Failure 的架构理念
  • "Design for failure and nothing will fail" 最早是 AWS 的一条最佳实践，即面向失败进行系统设计。
  • 考虑系统所有可能发生故障或不可用的情形，并假设这些可能都会发生，倒逼自己设计足够健壮的系统。
    • 非关键路径都要可以降级
    • 核心系统一定要熔断、限流、超时这些保护手段
    • 架构上要避免单点
  • 技术团队如何推行并落地这种理想？
    • 正向：如何形成 Design For Failure 的系统设计习惯？
    • 反向：如何确定系统真的可以 Failover?
  • 通过演练验证预案设计：技术 Leader 要化被动为主动，有意识地推进故障演练，不论是以注入还是回放的方式制造可控的故障，以此验证应急处理的机制流程和预先设计的灾备方案是否有效。演练是一个逐步的过程，先从测试环境检验，然后在生产环境进行有预案的演练，最后进行真正的随机故障演练。
  • 系统稳定性结果好快很大程度上取决于技术 Leader 的重视程度
    • 要把稳定性当做一个机制和团队的文化去建设
    • 不断加深大家对稳定性的认识以及和每个人切身利益的关联程度
    • 进一步形成团队的氛围与文化
  • 新人 Landing 从稳定性学习开始
    1. 1~2 周的适应期
    2. 学习并通过发布变更 SOP 考试，取得对应系统的发布权限
    3. 学习这个部门最近半年发生的真实事故，并总结一篇总结邮件给部门内所有人（利用心理学中的"承诺一致性原则"）
  • 每人不低于 35% 的稳定性 KPI：技术 Leader 的稳定性 KPI 占比在 35% 到 40%，一线研发的同学可能是 50% 以上。（避免出现口号响亮，但是落地无声的情况）
  • 通过稳定性 KPI 的设计：将稳定性的结果与所有人的切身利益实实在在得绑定到一起。
  • 好的坏的都要在阳光之下晒一晒
    • 每个月做一次红黑榜单
    • 以不同的维度公示部分内各团队的稳定性结果
    • 维度统计可以是：事故数、冒烟数、1-5-10 达成率、本月严重事故……
  • 奖惩不是目的而是手段：要选择合适的手段提高团队成员的稳定性意识，并且最终取得好的结果。

总结：

• 对于技术 Leader 而言，不能用重大事故让团队成员慢慢理解系统稳定性的重要性
• 可用性的预防与治理需要投入大量的时间和精力