腾讯 CDN 业务连续性的“宝典”，根治“故障”有妙招

不赖

黄小华，来自腾讯云架构平台部，负责腾讯CDN SRE体系建设，带领腾讯 CDN 运维体系先后从工具化、规范化演进到自动化时代，并且正在向智能化时代转型。同时在运维行业耕耘多年，具有丰富的业务连续性建设经验。

说明：本文根据黄小华老师在 GOPS 全球运维大会 2022 · 上海站的演讲整理而成。
腾讯CDN业务连续性挑战





腾讯CDN的业务连续性建设，挑战其实比较大。

• 第一是带宽储备，目前我们有150T带宽的储备，遍布全球的2000+的CDN节点，覆盖了国内外的主流运营商以及中小运营商。这种海量的带宽和复杂的跨国、跨运营商的网络环境，给运营带来了很大挑战。
  
• 第二是设备资源，目前为止我们已经有500W核的设备资源、85种机型、10类硬盘。以硬盘为例，为了做好现网的运营，我们做了十个等级硬盘速度的区分，来适配各个业务的挑战。硬件设施的丰富程度也让运营的复杂度陡增。
  
• 第三是海量请求，目前CDN QPS在晚高峰已经超过100M/s。100M其实就是一个亿，这一个亿的每秒请求量，包含多种业务形态，比如点播、静态、下载、直播、动态加速等，还有当前正在推出的安全加速；包含多种类型的协议，比如网络协议上支持IPv4，IPv4+IPv6双栈，应用层支持HTTP、HTTPS、H2、QUIC等协议。海量的请求，丰富的业务场景也对现网运营体系的设计带来极大挑战。
  

接下来讲讲具体的挑战：

• 第一是业务场景复杂 ，我们既要涵盖金融行业极致的可用性追求；也要涵盖高带宽要求的游戏下载，尤其是王者荣耀、和平精英这种游戏，游戏发布时，对带宽要求是非常高的；还包括极高稳定性要求的直播场景。
  
• 第二是客户敏感 ，CDN作为业务和End User终端用户相连的第一跳，有人称它为互联网的流量入口，客户的敏感度非常高，团队内部有3家客户投诉即录故障单的要求。3家客户的投诉，不管客户大小、影响面以及影响的时长，只要达到3家就会录单。
  
• 第三是故障定级严苛，我们的定级规则是SLO只要影响超过1%，时间持续十分钟，就一定会被定级，而且这种定级会纳入整个团队的OKR考核。
  
• 最后是现网复杂度高，前面提到我们有500W核资源，我们做个简单的数学推导，即使现网硬件这种基础设施能够达到99.9%的可用性，每天还是有超过5000核的硬件设备出现各类异常，这里还没有算网络波动、软件异常、攻击流量等等复杂度。
  

以故障管理为基础的业务连续性建设

介绍完CDN业务连续性的挑战，那我们是如何做好CDN业务连续性的呢？



我们的核心思路是以故障管理为基础的业务连续性建设。故障管理，是把故障做一个全生命周期的分解，分为三个阶段：故障预防，故障处理和故障根治。
首先是故障预防，它是我们下功夫最多的一个阶段，因为任何人尤其是SRE都不希望发生故障，每一次故障都是对SRE技术能力的一次大考。在大考之前，都希望它少来、迟来、甚至不要来。
其次是故障处理，故障处理细分为三个小阶段，包括故障发现、故障定位、故障恢复。最后是故障根治，在故障发生后，我们会努力从故障中学习，对故障进行全面复盘，并总结演进措施，同时做好考核、文化建设等事情。对于故障全生命周期的管理，有两个核心指标 MTBF 和 MTTR。MTBF 是故障预防、故障根治阶段的度量指标，是指平均故障间隔时间，我们希望故障少来、不来、迟来其实就是MTBF的概念。MTTR是故障处理阶段的衡量指标，在不幸发生故障时，需要尽快发现、快速定位，然后快速执行故障预案，第一时间完成故障止损。
腾讯 CDN 业务连续性体系全景图



这是业务连续性体系的全景图，包含了腾讯CDN业务连续性体系建设的核心指导思想。
在故障预防阶段，我们的思路是防御式稳定性建设。防御式稳定性建设就是所有的容灾体系的设计，一定要有个假设，即假设所有的隐患是一定会发生，即使现在不发生，将来某个时间点也一定会爆发。
在这个假设的基础上，每一个风险点都要想好如何设计防御措施。为此我们在监控体系上引入了隐患的预警机制、进行了监控的全面性治理；在架构设计上，我们引入了业务分级、最坏假设、容灾架构、容灾预案的设计；校验机制上引入了混沌演习。
在故障处理阶段，我们的思路是临危能不乱，功夫在平时。

• 故障处理 · 故障发现
  

在故障发现子阶段，监控体系我们追求快速，IaaS层做到10s，PaaS层力争做到1min；同时我们也在做监控的准确性建设，防止SRE日常告警量过多，进入麻木状态，贻误故障处理的战机；另外我们也非常重视业务反馈，与前端团队紧密联动，一旦前端反馈有共性问题，立即升级为故障进行处理。在这个阶段除了故障发现时长，还有故障主动发现率的指标需要持续度量。

• 故障处理 · 故障定位
  

在故障定位子阶段，我们通过灵鸽体系，提前预设各类异常处理人列表，故障时实现一键拉人、入会、入群；同时在平时持续建设灵析体系，实现告警联动，实时分析异常原因，部分场景给出原因，部分场景给出建议方案，部分场景实现自愈。需要注意的是，故障定位能力一定不能只依赖 SRE 的临场发挥，需要在故障发生之前，就预测好可能出现什么问题，将这些问题的排查方法沉淀到灵析体系里。

• 故障处理 · 故障恢复
  

在故障恢复子阶段，因为现网的故障大概率是无法依靠一个人解决，需要有人做业务知会、有人定位问题，有人执行故障恢复预案，有人double check恢复方案会不会引发二次故障，这就需要为故障设立经验丰富的故障指挥官，由他把控整体的故障恢复脉络，做好团队分工，防止处理现场的慌乱。

在故障根治阶段，也有明确的指导思路——文化先行、分级有度、量化精准。

对于业务连续性的投入，需要持续的警钟长鸣，不能因为MTBF比较长，就放松对现网故障发生的警惕，这就需要团队做好文化先行工作，包括安全运营100天，混沌专项等思路。当我们的产品进入到稳定运营状态，MTBF可能会比较长，一年下来故障数量应该能控制在一两个甚至完全没有，这时候就需要我们把视角往下放，重点关注工单、问题单，通过分级有度的思路，将现网隐患区分出轻重缓急，虽然工单、问题单不需要紧急应对，但同样需要将每一个隐患都跟进到底，防止它们演化成故障。还有很重要的一点是量化精准， 故障的定级标准一定要非常清晰，故障的个数、主动发现率、故障的时长等等指标，不光精确度量，还要持续跟踪，需要每个季度、每半年、每一年review变化趋势。
自动化时代业务连续性建设瓶颈

有了业务连续性建设的整体思路之后，当前自动化时代，是否有哪些瓶颈是难以突破的呢？



在故障预防阶段，监控体系里，有一些比较细微的异常、隐患级的异常发现是比较困难，用传统的阈值波动告警，可能很难去触及这种轻微、细小的隐患；另外我们的服务团队接收到客户咨询之后，很难从不同的咨询单里，甄别出现网共性问题；还有CDN体量很大，业务场景很复杂，对于容量的预测和规划靠人工调整，精细化、及时性都有很大的瓶颈。在故障发现阶段，告警信息的孤岛化，故障发生时的信息狂轰乱炸现象让人捉襟见肘。在故障定位阶段，存在模块多、涉及团队多，导致根因定位时间长等问题。在故障恢复阶段，传统混沌工程构建的异常场景比较有限。在故障根治阶段，异常场景的管控比较优先，希望引入更多手段尽可能多地管控异常场景。
业务连续性建设视角下的AIOps

AIOps 应用场景很广泛，SRE 三大核心领域质量、效率、成本，都各自有对应的 AIOps应用场景。在腾讯 CDN 业务连续性建设视角下，Observability（可观测性）、Analysis（智能分析）、Automation（自动化）的有机结合，构成了业务连续性建设的 AIOps体系。

• Observability（可观测性）
  

腾讯 CDN 基于日志体系、指标监控体系以及全链路追踪体系，建设了完备的可观测平台。

• Analysis（智能分析）
  

基于腾讯 CDN 丰富的网络、业务、性能等基础数据，结合专家经验，智能分析现网异常。

• Automation（自动化）
  

对于现网已知场景，沉淀专家经验库，智能决策后快速执行落地；对于隐患场景，基于智能算法，推导出隐患后，通过先摘除后排查的方式防范现网隐患。以下会介绍一些腾讯 CDN 在 AIOps 里面的一些探索与实践的具体案例。
智能告警体系





基于腾讯智研监控宝强大的智能告警体系，我们可以很轻松地引入智能告警，帮助我们识别传统告警方法难以发现的现网隐患。

• 局部模式突变
  

如图所示，每天晚上21:30左右会有一个很大的突增毛刺，这个毛刺大概率是业务的一个正常动作，不是现网问题。如果使用传统划线式的阈值告警，将很难避开这个毛刺，只能把阈值一位地调高，或者将时间分成多个区间，分段调整阈值，但是如果这个毛刺不是固定时间出现，时间分区方法也难以覆盖。而智研监控宝的智能告警完美地解决了该问题，它可以非常轻松地识别这个毛刺，并发现23:00开始的明显异常突增。

• 抖动强度突变
  

上图所示的抖动强度偏离日常值，也可以非常轻松地发现。

• 均值平缓偏移
  

上图所示的均值虽然没有剧烈抖动，但是也有平缓的偏移，也能够发现。
咨询单共性问题

CDN 作为一个大型的 PaaS 平台，承载了非常多内外部各种类型的客户。服务团队会收到客户各种各样的咨询单，由于客户的背景不同，对于同样的问题会有不同的认知，描述这个问题的语言也是不一样的；服务团队也有不少人，每人会收到不同的咨询单，大部分情况下工作也比较忙，也没办法去看别人的咨询单。在这种情况下，如果现网真的有异常，其实很难靠人工手段进行共性甄别，这就导致异常问题流转周期很长。后面我们引入AI智能识别的流转体系，当客户提交了咨询单之后，马上对他提交的内容做语义理解，提取出关键字并且智能分析有没有现网的共性，如果有就立即升级，触达全链路的一线、二线、SRE团队，全团队介入进行异常恢复，降低MTTR。



智能容量规划

接下来介绍下CDN的智能容量规划体系。CDN的容量规划需要兼顾成本、效率、体验、业务特性，同时需要满足直播突发、电商抢购、大规模攻击等瞬时带宽飙升场景，很多时候一点小的需求就要牵一发而动全身，挑战非常大。



我们的容量规划算法1.0，是以成本为核心，进行全局最优求解的一套算法，交付效率大约为2h。1.0的算法需要以成本为核心，兼顾效率、体验、业务特性等多个目标，求解是无法做到实时的，这也导致1.0算法难以应对直播突发、电商抢购、大规模攻击等瞬时带宽飙升场景，需要通过预留一定的 buffer 来解决。



后来我们就想，当业务容量有变化的时候，实时计算可能需要两个小时，如果我们提前算好呢？从算好的结果里面直接拿变化的数据，那就可以做到准实时了。因此我们引入了自我训练的体系。当容量进入一个稳态之后，我们会虚构一些容量变化，以专家经验分层、历史经验积累、系统自我进化三种方式来逐步模拟可能的容量变化情况，将计算结果存起来，真的有容量需求的时候，直接拿取结果即可。当然这里存在一个问题，系统再怎么计算也无法穷尽现网的变化情况，我们还引入了一个偏大匹配的视角，比如现网变化需要500G，但是我们只算出了600G的变化，那就做个轻微的容量让步，直接使用600G的结果，应对完现网交付速度之后，再二次微调，达到最佳效果。自训练体系引入之后，我们基本做到了准实时的容量规划，能够轻松应对瞬时的带宽飙升场景。
根因分析





根因分析在业务连续性建设的视角里是非常重要的一环，不管是故障预防阶段，还是故障定位阶段，根因分析的速度和准确性，都会成为MTTR控制的关键。在腾讯CDN根因分析体系里，最核心的是数据底座。数据底座会收集好网络数据、单机性能、业务指标、全链路日志、事件数据、调度数据、健康度数据、客户端数据等等，并且将这些数据以业务视角全链条关联起来。专家经验的持续沉淀也非常重要，不管是点播/直播/静态/动态 这些多领域的经验，还是网络/硬件/软件/OS等多维度经验，亦或缓存/调度/成本/资源等CDN体系经验，都需要持续沉淀、持续运营、持续迭代。最关键的智能诊断分成几个阶段来帮助SRE降低故障MTTR，首先会依赖全链路数据，快速完成初因定位，之后SRE立即介入，执行容灾预案，快速完成现网止损；然后结合数据底座收集到的全量信息，快速定位出具体异常模块；最后结合专家经验，完成根因定位，彻底扫除现网隐患。
故障根治，智能自动化持续迭代

故障根治，除了常规故障复盘之后落地改进措施，还需要通过智能自动化持续迭代，将发现的所有隐患问题彻底地根治。这里举三个腾讯CDN体系内智能自动化的例子，供大家参考。

• SSD硬盘寿命到期
  

SSD硬盘是有寿命概念的，当擦写次数达到上限后，就无法继续写入数据了。传统SRE的视角，会在寿命到期之后，接到告警，之后进行现网隔离，然后去买一块新硬盘，替换掉旧硬盘，最后再将设备加回现网，整个流程冗长且繁琐。在智能自动化时代，我们会提前预测寿命到期时间，并监测擦写速率；同时做好现网业务IO写入量画像，区分出高写入和低写入业务；有了这两个数据之后，我们再将硬盘进行动态调整，对于写入量非常快的硬盘，一段时间后要将它换到写入量低的业务里面，延长它的使用寿命；另一方面因为已经有了预测数据，在硬盘将要到期之前，就将它隔离出现网，防止影响现网的业务连续性。做完这个事情之后，SSD硬盘寿命平均延长了近8个月，基本追平了整机的淘汰时间，省下来一大笔新采购SSD硬盘的费用。

• 链路质量
  

CDN要处理遍布全球的网络，复杂度非常高。原来我们的体系里是一刀切的划线式质量管控，一刀切的方式难于应付省份级甚至城市级的网络情况。比如说网络质量优秀的沿海地区，丢包率延时都非常优秀，而网络质量相对弱一些西北地区，就经常有网络抖动现象的发生。如果划线过紧，可以保障最优秀的网络体验，但是会导致西北区域经常触及这条线引发误告；反过来如果划线过松，沿海地区的用户体验又会收到冲击，业务质量劣化了都有可能发现不了，出现管控盲区。这两种情况都会引发现网告警，然后需要SRE人工介入判定。后来我们做了一个演进，首先绘制了全网运营商的质量地图，然后基于历史数据制定当地网络质量标准，这样每个区域都可以依据各自的质量标准来进行调度，做到了千人千面；同时质量地图也会持续运营，当地网络质量变化时，也会相应地更新质量标准。

• LDNS 分块调度
  

LDNS分块调度是有一个背景的，在DNS协议里有一个512字节的报文长度限制，这个限制导致没有办法塞足够多的IP到DNS的解析结果里面去，这个进一步导致了现网平台会有容量上限。为了应对这个问题，SRE只能在一个平台即将达到上限时，新建一个平台承载，这样一而再再而三地新建平台，导致现网运营复杂度持续提升。这个问题也经常导致局部区域高负载，SRE不得不在接到告警之后，将某些业务做平台切换处理。LDNS分块调度的思路，首先会把Top域名筛选出来，并将这些域名所有LDNS对应的需求带宽结合历史数据计算出来；然后将资源纳入统一的池子，并结合Top域名LDNS分块需求匹配现网资源，如果多个域名合在一起超过LDNS分块需求，就在资源池之上使用虚拟平台进行隔离；最后如果业务有突增，就自动将域名进行跨虚拟平台的调度均衡。LDNS分块调度改造之后，SRE 再也不用低效地去做多平台物理拆分了，运营复杂度大幅度降低；现网局部高负载问题也大幅度降低。
总结：智能运维助力腾讯 CDN 业务连续性提升体系





上图总结了智能运维在腾讯 CDN 业务连续性里面的实践体系，希望能给大家提供参考。结语：我们对于 AIOps 的探索才刚刚开始，未来还会继续，期待智能化运维体系能为业务连续性的提升带来更大的价值。最后，我想将这句话送给大家：未来已来，拥抱智能化，开启 AIOps 新时代！
End
点击此处即可免费领取 DevOps 资料~
❤️卫星宫主号- GHDevOps【 DevOps光环国际 】