随着大数据、人工智能和云计算技术的日益成熟和快速发展，传统的运维技术和解决方案已不能满足需求，智能运维已成为运维的热点领域。同时，为了满足大流量、高质量的用户体验和广泛的互联网应用场景，大型分布式系统的部署也成为高效运行和维护的必然选择。如何提高运维能力和效率是保证业务高可用性的最大挑战。
6 月 23 日，由百度开发者中心、百度云智学院主办，极客邦科技承办 79 百度技术沙龙邀请了百度智能云主任架构师王栋、百度智能云架构师哈晶晶、百度智能云高级运维架构师杨涛、百度智能云架构师张淼、百度智能云架构师余杰、百度智能云高级工程师廖洪流六位讲师。分享百度在 AIOps、DevOps 实战经验，百度统一前端接入（Baidu Front End, BFE）、数据库以及 Redis 以三个具体系统为例，介绍了百度如何在系统架构设计和变更、监控、故障处理和性能管理中保证系统的高可用性。
1 高可用性系统的架构和运维实践
百度智能云主任架构师王栋发表了开演讲。
1 高可用性系统的架构和运维实践
百度智能云主任架构师王东发表了开幕演讲。他首先介绍了百度运维发展的历史，主要分为三个阶段：一是基本运维阶段。提供机器管理、服务管理和权限管理，确保在线基本服务运行，监控在线基本数据管理。二、开放运维时代。以开放 API 将第一阶段业务层面的运维交给各业务部门。然而，面对垂直场景重复制造轮子的问题，难以收集运维知识和数据。三、智能运维阶段。构建统一的运维知识库、一致的运维工具开发框架和算法复用平台。
下图为百度智能运维整体框架图。底部是基本的操作和维护平台，提供最基本的操作和维护能力。在此平台的基础上，构建操作和维护开发框架、操作和维护知识库和操作和维护策略库，在不同的场景和不同的业务中提取所有场景的算法，提供服务。
要解决的智能操作和场景问题
王栋区分了运维问题的复杂性，如下图所示。纵轴表示问题的难度，横轴表示问题的频率。这样，运维问题可以分为四个象限，对每个象限采取不同的对策。左上角低频复杂的问题，可以希望智能辅助决策，提高人们的能力；右上角高频复杂的问题，希望实现智能决策、智能执行和迁移，人们只需要做一些基本的辅助工作；左下角低频简单的场景，这是一个更容易解决的问题，只是标准化和流程；右下角高频但简单的问题可以通过自动化和自助解决。
2 百度 AIOps 实践
百度运维经历了脚本 & 在工具、基本运维平台、开放运维平台阶段 2014 年开始探索智能运维，围绕可用性、成本、效率的运维目标，在众多运维场景中落地。百度架构师、智能监控业务技术负责人、智能故障自愈方向技术负责人哈晶晶以百度故障处理场景为例，介绍了百度故障预防的智能 checker 自动拦截异常变化、故障发现异常检测算法、单机房故障自动止损实践。
百度 AIOps 技术架构
百度智能运维将 Gartner 中提到 AIOps 大数据和机器学习的概念应用于四个操作和维护场景，发展成一系列智能模型和策略，融入操作和维护系统，帮助提高操作和维护本身的效率，解决传统操作和维护方法无法解决的挑战。
首先，为了解决不同业务线对运维对象的定义、操作界面和运维模式的差异化，百度提出了指导智能运维的三个原则：
同文:一致运维的语言；如运维应用、服务、机房和集群的定义
车辆同轨：一致运维的方法；如扩缩执行、流量切换执行；
行同伦：一致运维的模式
根据以上 AIOps 中书同文、车同轨、行同伦的指导思想，百度基本运维和智能运维平台也集中在三个方向：数据、工程和战略。如下图所示。
数据方向：运维数据仓库 & 运维知识库
工程方向:运维大数据平台 & 运维工程研发框架
战略方向:运维战略算法平台和运维大脑(运维战略库)
该平台最终支持故障管理、变更管理、服务咨询和容量管理场景的解决方案，并应用于百度内部、公有云和私有云客户。
运维知识库
基于操作和维护的知识库 CMDB、数据仓库、知识图谱技术，对各类型运维数据，进行统一的 ETL 处理，形成完整的运维数据存储，并提供查询和使用服务。
运维知识库
基于操作和维护的知识库 CMDB、数据仓库、知识图谱技术，统一各类运维数据 ETL 处理，形成完整的操作和维护数据存储，并提供查询和使用服务。知识库系统的功能应该是第一个和第二个，整个架构的可用性要求很高，以便运行和维护。
运维数据分为元数据、状态数据和事件数据三类：
CMDB（MetaDB）：存储运维元数据和配置数据，信息和关系包括不限于产品、人员、应用、服务、机器、实例、数据中心、网络等
TSDB（基于 HBase）：存储运维时序指标数据，可用性指标、资源利用率指标和性能指标不限于硬件和软件
EventDB（基于 Elasticsearch）：存储运维事件数据，包括不限于异常报警、故障处理、变更等
运维工程研发框架
智能操作的每一个操作和维护都可以分解为感知、决策和执行样一个标准流程，称为智能操作和维护机器人。如下图所示。如下图所示。运维工程研发框架为用户提供感知、决策和执行过程中常用的组件，以便快速构建智能运维机器人。例如这三种组件可以组织成简单的报警回调机器人和自动编排机器人。报警回调机器人可用于故障自愈，自动编排机器人可用于分级变更。
先来看 Sensor，Sensor 它是运维机器人的眼睛和耳朵，就像人有两只眼睛和两只耳朵一样。操作机器人也可以挂多个 Sensor 来获取不同事件源的消息，比如监控的指标数据或者是报警事件，变更事件这些，甚至可以是一个定时器。这些消息可以推拉两种方式 Sensor 获取到。在触发后续处理之前，后续处理之前进行一定的聚合。
再来看 Decision-Maker，DM 它是运维机器人的大脑，所以为了确保唯一的决策，机器人只能有一个 DM，DM 也是用户实现扩展的主要部分。除了常见的逻辑判断规则外，我们还将在未来加入决策树等模型，使运维机器人能够独立控制决策路径。
最后看 Executor，执行器是操作和维护机器人的手脚，因此执行器可以平行执行多个不同的任务。执行器将长操作和维护过程抽象成两种模式：状态机和工作流。这样框架就可以记住当前的执行状态，如果运维机器人发生了故障迁移，还可以按照已经执行的状态让长流程断点续起。
运维大脑
运维大脑有数据和工程。运维大脑包括异常检测和故障诊断，这两部分的共同基础是恒定阈值的基本异常检测算法。使用各种概率模型来估计数据的概率分布，并产生报警阈值。随着时间的推移，算法可以利用最新的数据修正概率模型，自动生成新的报警阈值。
由于许多数据具有上下波动的特性，恒定阈值法无法很好地描述数据的特性，百度开发了基于环比和同比的异常检测方法。假设输入的时序数据普遍平滑，通过平滑算法预测数据的基准值。然后将数据的观测值降低到基准值，恒定阈值算法可以在残差上检测异常。环比方法主要用于检测突增突降类型的异常，但有些数据在出现异常时上升或下降相对温和，这是环比算法无法胜任的。
在故障诊断方面，百度基于异常检测算法开发了指标自动排查算法和多维分析算法。指标自动调查算法可以自动扫描所有监测指标，筛选出故障前后发生剧烈变化的异常指标。然后算法将这些异常指标排列为异常 pattern，并将异常 pattern 对与故障原因最相关的异常进行排序 pattern 向运维工程师呈现。
多维分析集中在多个方面 tag 业务数据。它首先异常检测算法标记异常业务数据，然后用信息理论找到覆盖大多数异常的方法 tag 组合。这些 tag 组合通常可以直接指出故障的原因。如果把每个 tag 它被视为高维空间的一个维度，异常数据相当于分布在超立方体中的点。寻找覆盖最多点的子立方体，所以称为多维度分析。
故障管理 AIOps 实践
故障的完整生命周期包括隐患阶段、故障发生、故障发现、故障止损、故障恢复、故障分析、故障改进和故障规范阶段，可用于每个阶段 AIOps 提高故障管理质量的相关方法。如下图所示。
故障预防实践
互联网企业的产品迭代速度非常快，但如果有变化，就会有风险。2017年 年度服务故障有 54% 它来自发布，release 是当之无愧的服务稳定性第一杀手。基于这一问题，百度提出了不同的预防措施：
百度首先部署了从测试流量到真实流量的部署 sandbox，在这种情况下是无损失的
从一个 IDC 到更多 IDC，百度选择流量最少的 IDC，在异常情况下损失较少，或者可以快速切流止损
从少数例子到更多例子：百度首先部署了机房 1%，再部署 99%
有了合理的 stage，可以基于发布平台进行自动检查。在每个 stage 结束后，会自动检查是否有报警，如果有，会停止变更。在每个 stage 结束后，会自动检查是否有报警，如果有，会停止变更。
变更通常检查可用性指标、系统相关指标和业务逻辑指标。但人工检查会遇到以下问题:指标覆盖率不会很高，阈值设置困难导致漏报 & 误报。使用智能 Checker 的程序自动检查方法可以解决这些问题。
发现故障的实践
业务种类繁多，业务指标种类繁多，如请求数、拒绝数、响应时间、流水、订单等。不同业务不同数据的曲线，波动模式也不一样，在监控阈值配置时通常会遇到以下的问题：1. 不同的监控项需要不同的算法；2. 忙时 & 闲暇，工作日 & 不同的休息日阈值设置；3. 后期，随着业务的发展，门槛配置需要不断完善；4. 配置成本极高。
在此背景下，我们对数据进行分类，为不同场景提供不同的异常检测算法，解决人工配置困难和监控漏报 & 误报问题。
数据周期波动，典型场景：广告收入、搜索流量等。算法：同比基准值检测：
关注突变数据，典型场景：交易订单、流水等。算法：环比基准值检测
典型场景：pvlost。算法：基于概率的恒定阈值检测。
故障自愈实践
人工故障处理通常面临响应时间不够快、决策不够准确、误操作的情况。故障自愈是通过自动化、智能化的故障处理节省人力投入，提高故障处理的可靠性，减少故障时间，护送业务的可用性。
单机房故障是业务的常见故障，百度的核心业务线均实现了 2 到 5 故障在几分钟内自愈。如下图所示，整个框架充分利用了上述运维策略库、运维开发框架和运维 知识库构建单机房故障自愈程序。整个自愈程序也是感知、决策、执行判断的。自愈程序分两个，一个是机房外网入口故障，通过外网监控发现问题，通过 DNS 流量调度来解决；另一个是在百度内网机房故障和业务单集群故障，通过业务
世纪高通:世纪高通亮相ITS Asia 2019
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时候联系我们修改或删除，多谢。
标签：
评论