腾讯：3亿人次实战演习验证异地容灾架构与快速调度能力(2)

某个电闪雷鸣、风雨交加的夜晚,运维小哥正舒服的窝在床上看着电影,突然手机一波告警袭来,N个服务延时集体飙高,经排查是运营商网络出口异常,运营商也暂时未能反馈修复时间,经评估后快速根本的解决方法就是将故障城市的xxx万用户调度到B城市,运维小哥正准备使出洪荒之力乾坤大挪移的将用户移走,但杯具的是调度系统掉链子了,调度任务计算与下发异常,极速吼上相关同学排查调度系统问题,同时开启后台柔性撑过故障期.

故事场景2：

活动开始,用户量逐步攀升,并且有地域聚集现象,A城市的整体负载已经偏高了,需要迁移XXX万用户调度到B城市,以便减少A的整体负载,在调度过程中发现B因某条业务链路的短板,所能承载的增量用户要小于前期建设评估的整体用户量,增量压过去,会把B压垮.

上面两个场景,直接折射出问题是什么?

只有通过实际场景检验的能力,才是我们运维手里真正可用的武器,而不是在军械库里放着,只是在盘点的时候“具备”的能力.

1. 为什么要现网演习?

容灾能力与容量架构把控是海量运维必修内功,能力的锻炼就是要通过不断的实战演习得来,要让我们所“具备”的能力变为关键时刻的武器.

如上图所示,通过一个完整的闭环流程,来不断的精耕细作以便提升我们的能力,通过实战将问题暴露出来,避免紧急事件时的被动.

2. 如何规划演习?

QQ是一个体量非常之大的业务(DAU:8.3亿),业务功能树复杂,一个叶子节点的异常就有可能导致大范围用户的有损体验与投诉.假设演习期间某个环节有问题,将有可能导致一个大范围的事故.

我们在思考如何安全落地演习的时候,也主要基于以上纬度的考虑.话说不打无准备的仗,事前评估越完善,相应的就能提升我们整体演习的成功率,下图就是我们最终落地的一个可执行的详细演习流程图.

如上图所示 演习也是一个节点较多的闭环流程,生命周期主要分为以下三部分

• 演习前期规划与准备；
• 演习实施,过程监控；
• 演习结束,整体质量评估与问题跟踪；

3. 演习的目标

要通过演习生产出我们所需的数据与检验我们的业务质量,双平台是服务于海量用户,全网业务链路复杂,我们期望能从下面三个维度检验我们的能力.

验证业务质量与容量：

• 通过实战演习验证三地条带化容量建设是否符合预期?
• 每增加千万用户时整体与关键业务链路负载是否可控?
• 短时间内因千万用户集中登录与关联行为所产生的压力后台是否能抗的住?
• 柔性控制是否符合预期?

量化调度能力：

• 异地调度时每分钟能迁移走多少用户?
• 异地调度1000W用户需要多少时间?
• 清空一个城市的用户需要多少时间?
• 调度速率是否均衡稳定?

运营平台：

• 现有的平台能力(实时容量、地区容量、调度平台、业务质量监控)是否能较好的支撑到演习与实际场景调度；
• 发现平台能力的短板,以容量指标来及时度量调度的效果；

4. 演习效果

我们坚持月度/季度的实际演习调度,并在业务峰值实施调度演习.整个演习期间用户“零感知”,业务质量无损,无一例用户投诉.如此量级的演习在双平台的历史上也属于首次.演习也是灰度逐步递进的节奏,下面图例展示了,我们对一个城市持续三次的调度演习,用户量级也是逐步增多 2000W?4000W?清空一个城市.

如上图所示 演习也是一个节点较多的闭环流程,用户量级也是逐步增多 2000W?4000W?清空一个城市.

• 调度质量
  • 调度效率是否符合预期：例如计划10分钟迁移多少用户量；
  • 调度速率是否可控：调度的用户量细化到分钟粒度应该是基本均等,不能忽快忽慢；
  • 调度量级是否符合预期：整体迁移用户量级稳定可控；
• 业务质量
  • 调度期间是否有用户共性投诉反馈；
  • 后台服务质量是否可控；
  • 监控系统是否有批量告警；
  • 业务负载增长是否符合预期；

6. 演习流程的闭环跟踪

演习的目的就是在于发现问题而不是秀肌肉,暴露的问题越多越好,每个问题都要完全闭环,帮助业务架构和运维能力持续优化与完善.

总结

（编辑：ASP站长网）