SACC2017:百度AIOps实践——单机房故障自愈

AIOps是Gartner在2016年提出的概念，其预测到2020年AIOps的采用率将会达到50%。传统运维不仅耗费人力和时间，而且很难定位故障的根因，所以以运维大数据为基础，利用人工智能和机器学习算法对运维数据进行分析的AIOps受到了广泛的欢迎，国内IT大厂也有做一些尝试。

▲百度监控平台技术负责人 哈晶晶

2017年10月19日-21日，由IT 168主办的第九届系统架构师大会在北京新云南皇冠假日酒店盛大开幕，“智能化运维&DevOps”技术专场中来自百度监控平台技术负责人哈晶晶，为我们分享了百度在AIOps的实践——单机房故障自愈。

单机房故障不可避免，自愈必不可少

业内关于单机房故障的新闻屡见不鲜，单单2017年就发生了几起比较大的单机房故障，例如，2017年1月某业务天津机房故障，服务数小时无法提供服务，6月北京某处机房掉电，多家互联网公司受影响……

单机房故障是不可避免的，所以一旦出现就必须立刻止损，否则不仅会造成PV、流水损失，商业赔付，影响用户体验，而且还会给竞品以机会，造成研发成果浪费、用户信任度下降等严重后果。

单机房故障的诱因众多，百度在复盘了核心业务之后发现大多数的单机房故障都可以归因于这四个方面。一是基础设施故障，物理机房故障、流量转发平台故障;二是程序缺陷，程序隐藏bug、程序性能退化;三是变更故障，程序/配置/数据变更、运维误操作;四是依赖的服务和平台故障，例如认证服务、支付服务等第三方服务，存储、计算、缓存服务等第三方平台。

容灾很重要，百度是如何建设单机房容灾的?

国际知名IT企业都有自己的单机房容灾能力建设指导思想，如Google和LinkedIn服务N+2冗余是标配。据哈晶晶介绍，百度单机房容灾能力建设主要有三个方面的指导思想：将服务拆分为若干不同的逻辑单元，每个逻辑单元处于不同的物理机房，均能提供产品线完整服务;服务容量支持N+1冗余;任意一个逻辑单元发生故障时，可将流量切换至其他逻辑单元，保证向用户正常提供服务。

目前单机房容灾建设存在的问题主要有服务存在单点，单点服务在某一机房发生故障，导致服务整体故障;服务跨机房混联，两个机房的故障无法通过切流量止损，导致服务整体故障;服务不满足N+1冗余，机房1故障，机房2和3不足以承担机房1的流量，单机房故障引发多机房故障。

哈晶晶表示百度在单机房容灾能力建设方面有很重要的一个环节，那就是盲测验收。

百度单机房故障自愈解决方案

百度单机房故障止损能力标准有5个level，level 0到level2都是人工感知决策，分别为手动执行止损命令、手动执行止损脚本和预案平台执行止损预案。Level 3和level 4是自动感知决策，也就是我们说的单机房故障自愈。

据悉，2016年以前百度大多数业务都处于level 2的阶段，2016年业务开始了部分场景下L3能力的探索。目前百度实施基于AIOps故障自愈的解决思路为：

书同文：运维知识库，一致运维“语言”;

车同轨：运维开发框架，一致运维“方法”;

行同伦：运维策略库，一致运维“模式”;

▲单机房故障自愈解决方案

百度单机房故障自愈风险控制策略包含两个层面：接入层决策风险控制和服务层决策风险控制。接入层决策风险控制包括避免跨运营商、跨地域流量调度;目标VIP的健康程度;外网入口带宽资源协调。服务层决策风险控制包括故障和过载机房流量尽可能切到健康机房，各机房水位尽可能平衡;流量调度参考实时容量反馈，动态规划调度策略。