腾讯CDN业务连续性建设之智能运维探索

接下来讲讲具体的挑战：

第一个是业务场景复杂 ，我们既要涵盖金融行业极致的可用性追求；也要涵盖高带宽要求的游戏下载，尤其是王者荣耀、和平精英这种游戏，游戏发布时，对带宽要求是非常高的；还包括极高稳定性要求的直播场景。

第二个是客户敏感 ，CDN作为业务和End User终端用户相连的第一跳，有人称它为互联网的流量入口，客户的敏感度非常高，团队内部有3家客户投诉即录故障单的要求。3家客户的投诉，不管客户大小、影响面以及影响的时长，只要达到3家就会录单。

第三个是故障定级严苛，我们的定级规则是SLO只要影响超过1%，时间持续十分钟，就一定会被定级，而且这种定级会纳入整个团队的OKR考核。

最后是现网复杂度高，前面提到我们有500W核资源，我们做个简单的数学推导，即使现网硬件这种基础设施能够达到99.9%的可用性，每天还是有超过5000核的硬件设备出现各类异常，这里还没有算网络波动、软件异常、攻击流量等等复杂度。

我们的核心思路是以故障管理为基础的业务连续性建设。

故障管理，是把故障做一个全生命周期的分解，分为三个阶段：故障预防，故障处理和故障根治。

首先是故障预防，它是我们下功夫最多的一个阶段，因为任何人尤其是SRE都不希望发生故障，每一次故障都是对SRE技术能力的一次大考。在大考之前，都希望它少来、迟来、甚至不要来。

其次是故障处理，故障处理细分为三个小阶段，包括故障发现、故障定位、故障恢复。

最后是故障根治，在故障发生后，我们会努力从故障中学习，对故障进行全面复盘，并总结演进措施，同时做好考核、文化建设等事情。

对于故障全生命周期的管理，有两个核心指标MTBF和MTTR。MTBF是故障预防、故障根治阶段的度量指标，是指平均故障间隔时间，我们希望故障少来、不来、迟来其实就是MTBF的概念。MTTR是故障处理阶段的衡量指标，在不幸发生故障时，需要尽快发现、快速定位，然后快速执行故障预案，第一时间完成故障止损。

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

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

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

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

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

在故障预防阶段，监控体系里，有一些比较细微的异常、隐患级的异常发现是比较困难，用传统的阈值波动告警，可能很难去触及这种轻微、细小的隐患；另外我们的服务团队接收到客户咨询之后，很难从不同的咨询单里，甄别出现网共性问题；还有CDN体量很大，业务场景很复杂，对于容量的预测和规划靠人工调整，精细化、及时性都有很大的瓶颈。

在故障发现阶段，告警信息的孤岛化，故障发生时的信息狂轰乱炸现象让人捉襟见肘。

在故障定位阶段，存在模块多、涉及团队多，导致根因定位时间长等问题。

在故障恢复阶段，传统混沌工程构建的异常场景比较有限。

在故障根治阶段，异常场景的管控比较优先，希望引入更多手段尽可能多地管控异常场景。

以下会介绍一些腾讯CDN在AIOps里面的一些探索与实践的具体案例。

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

后面我们引入AI智能识别的流转体系，当客户提交了咨询单之后，马上对他提交的内容做语义理解，提取出关键字并且智能分析有没有现网的共性，如果有就立即升级，触达全链路的一线、二线、SRE团队，全团队介入进行异常恢复，降低MTTR。

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

SSD硬盘是有寿命概念的，当擦写次数达到上限后，就无法继续写入数据了。传统SRE的视角，会在寿命到期之后，接到告警，之后进行现网隔离，然后去买一块新硬盘，替换掉旧硬盘，最后再将设备加回现网，整个流程冗长且繁琐。

在智能自动化时代，我们会提前预测寿命到期时间，并监测擦写速率；同时做好现网业务IO写入量画像，区分出高写入和低写入业务；有了这两个数据之后，我们再将硬盘进行动态调整，对于写入量非常快的硬盘，一段时间后要将它换到写入量低的业务里面，延长它的使用寿命；另一方面因为已经有了预测数据，在硬盘将要到期之前，就将它隔离出现网，防止影响现网的业务连续性。做完这个事情之后，SSD硬盘寿命平均延长了近8个月，基本追平了整机的淘汰时间，省下来一大笔新采购SSD硬盘的费用。

CDN要处理遍布全球的网络，复杂度非常高。原来我们的体系里是一刀切的划线式质量管控，一刀切的方式难于应付省份级甚至城市级的网络情况。比如说网络质量优秀的沿海地区，丢包率延时都非常优秀，而网络质量相对弱一些西北地区，就经常有网络抖动现象的发生。如果划线过紧，可以保障最优秀的网络体验，但是会导致西北区域经常触及这条线引发误告；反过来如果划线过松，沿海地区的用户体验又会收到冲击，业务质量劣化了都有可能发现不了，出现管控盲区。这两种情况都会引发现网告警，然后需要SRE人工介入判定。

后来我们做了一个演进，首先绘制了全网运营商的质量地图，然后基于历史数据制定当地网络质量标准，这样每个区域都可以依据各自的质量标准来进行调度，做到了千人千面；同时质量地图也会持续运营，当地网络质量变化时，也会相应地更新质量标准。

LDNS分块调度是有一个背景的，在DNS协议里有一个512字节的报文长度限制，这个限制导致没有办法塞足够多的IP到DNS的解析结果里面去，这个进一步导致了现网平台会有容量上限。为了应对这个问题，SRE只能在一个平台即将达到上限时，新建一个平台承载，这样一而再再而三地新建平台，导致现网运营复杂度持续提升。这个问题也经常导致局部区域高负载，SRE不得不在接到告警之后，将某些业务做平台切换处理。

LDNS分块调度的思路，首先会把Top域名筛选出来，并将这些域名所有LDNS对应的需求带宽结合历史数据计算出来；然后将资源纳入统一的池子，并结合Top域名LDNS分块需求匹配现网资源，如果多个域名合在一起超过LDNS分块需求，就在资源池之上使用虚拟平台进行隔离；最后如果业务有突增，就自动将域名进行跨虚拟平台的调度均衡。LDNS分块调度改造之后，SRE再也不用低效地去做多平台物理拆分了，运营复杂度大幅度降低；现网局部高负载问题也大幅度降低。