互联网时代的网络自动化运维

智能运维(AIops)是目前 IT 运维领域最火热的词汇，全称是 Algorithmic IT operations platforms，正规翻译是『基于算法的 IT 运维平台』，直观可见算法是智能运维的核心要素之一。

本文主要谈算法对运维的作用，涉及异常检测和归因分析两方面，围绕运维系统Kale 中 skyline、Oculus 模块、Opprentice 系统、Granger causality（格兰杰因果关系）、FastDTW 算法等细节展开。

一、异常检测

异常检测，是运维工程师们最先可能接触的地方了。毕竟监控告警是所有运维工作的基础。设定告警阈值是一项耗时耗力的工作，需要运维人员在充分了解业务的前提下才能进行，还得考虑业务是不是平稳发展状态，否则一两周改动一次，运维工程师绝对是要发疯的。

如果能将这部分工作交给算法来解决，无疑是推翻一座大山。这件事情，机器学习当然可以做到。但是不用机器学习，基于数学统计的算法，同样可以，而且效果也不差。

异常检测之Skyline异常检测模块

2013年，Etsy 开源了一个内部的运维系统，叫 Kale。其中的 skyline 部分，就是做异常检测的模块， 它提供了 9 种异常检测算法 ：

first_hour_average、

simple_stddev_from_moving_average、

stddev_from_moving_average、

mean_subtraction_cumulation、

least_squares

histogram_bins、

grubbs、

median_absolute_deviation、

Kolmogorov-Smirnov_test

简要的概括来说，这9种算法分为两类：

从正态分布入手：假设数据服从高斯分布，可以通过标准差来确定绝大多数数据点的区间；或者根据分布的直方图，落在过少直方里的数据就是异常；或者根据箱体图分析来避免造成长尾影响。

从样本校验入手：采用 Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor 等非参数校验方法。

这些都是统计学上的算法，而不是机器学习的事情。当然，Etsy 这个 Skyline 项目并不是异常检测的全部。

首先，这里只考虑了一个指标自己的状态，从纵向的时序角度做异常检测。而没有考虑业务的复杂性导致的横向异常。其次，提供了这么多种算法，到底一个指标在哪种算法下判断的更准？这又是一个很难判断的事情。

问题一： 实现上的抉择。同样的样本校验算法，可以用来对比一个指标的当前和历史情况，也可以用来对比多个指标里哪个跟别的指标不一样。

问题二： Skyline 其实自己采用了一种特别朴实和简单的办法来做补充——9 个算法每人一票，投票达到阈值就算数。至于这个阈值，一般算 6 或者 7 这样，即占到大多数即可。

异常检测之Opprentice系统

作为对比，面对相同的问题，百度 SRE 的智能运维是怎么处理的。在去年的 APMcon 上，百度工程师描述 Opprentice 系统的主要思想时，用了这么一张图：

Opprentice 系统的主体流程为：

KPI 数据经过各式 detector 计算得到每个点的诸多 feature；

通过专门的交互工具，由运维人员标记 KPI 数据的异常时间段；

采用随机森林算法做异常分类。

其中 detector 有14种异常检测算法，如下图：

我们可以看到其中很多算法在 Etsy 的 Skyline 里同样存在。不过，为避免给这么多算法调配参数，直接采用的办法是：每个参数的取值范围均等分一下——反正随机森林不要求什么特征工程。如，用 holt-winters 做为一类 detector。holt-winters 有α，β，γ 三个参数，取值范围都是 [0, 1]。那么它就采样为 (02, 04, 06, 08)，也就是 4 3 = 64 个可能。那么每个点就此得到  64  个特征值。

异常检测之

Opprentice 系统与 Skyline 很相似

Opprentice 系统整个流程跟 skyline 的思想相似之处在于先通过不同的统计学上的算法来尝试发现异常，然后通过一个多数同意的方式/算法来确定最终的判定结果。

只不过这里百度采用了一个随机森林的算法，来更靠谱一点的投票。而 Etsy 呢？在 skyline 开源几个月后，他们内部又实现了新版本，叫 Thyme。利用了小波分解、傅里叶变换、Mann-whitney 检测等等技术。

另外，社区在 Skyline 上同样做了后续更新，Earthgecko 利用 Tsfresh 模块来提取时序数据的特征值，以此做多时序之间的异常检测。我们可以看到，后续发展的两种 Skyline，依然都没有使用机器学习，而是进一步深度挖掘和调整时序相关的统计学算法。

开源社区除了 Etsy，还有诸多巨头也开源过各式其他的时序异常检测算法库，大多是在 2015 年开始的。列举如下：

Yahoo! 在去年开源的 egads 库。(Java)

Twitter 在去年开源的 anomalydetection 库。(R)

Netflix 在 2015 年开源的 Surus 库。(Pig，基于PCA)

其中 Twitter 这个库还被 port 到 Python 社区，有兴趣的读者也可以试试。

二、归因分析

归因分析是运维工作的下一大块内容，就是收到报警以后的排障。对于简单故障，应对方案一般也很简单，采用 service restart engineering~ 但是在大规模 IT 环境下，通常一个故障会触发或导致大面积的告警发生。如果能从大面积的告警中，找到最紧迫最要紧的那个，肯定能大大的缩短故障恢复时间(MTTR)。

这个故障定位的需求，通常被归类为根因分析（RCA，Root Cause Analysis）。当然，RCA 可不止故障定位一个用途，性能优化的过程通常也是 RCA 的一种。

归因分析之 Oculus 模块

和异常检测一样，做 RCA 同样是可以统计学和机器学习方法并行的~我们还是从统计学的角度开始。依然是 Etsy 的 kale 系统，其中除了做异常检测的 skyline 以外，还有另外一部分，叫 Oculus。而且在 Etsy 重构 kale 20 的时候，Oculus 被认为是10 最成功的部分，完整保留下来了。

Oculus 的思路，用一句话描述，就是：如果一个监控指标的时间趋势图走势，跟另一个监控指标的趋势图长得比较像，那它们很可能是被同一个根因影响的。那么，如果整体 IT 环境内的时间同步是可靠的，且监控指标的颗粒度比较细的情况下，我们就可能近似的推断：跟一个告警比较像的最早的那个监控指标，应该就是需要重点关注的根因了。

Oculus 截图如下：

这部分使用的 计算方式有两种：

欧式距离，就是不同时序数据，在相同时刻做对比。假如0分0秒，a和b相差1000，0分5秒，也相差1000，依次类推。

FastDTW，则加了一层偏移量，0分0秒的a和0分5秒的b相差1000，0分5秒的a和0分10秒的b也相差1000，依次类推。当然，算法在这个简单假设背后，是有很多降低计算复杂度的具体实现的，这里就不谈了。

唯一可惜的是 Etsy 当初实现 Oculus 是基于 ES 的 020 版本，后来该版本一直没有更新。现在停留在这么老版本的 ES 用户应该很少了。除了 Oculus，还有很多其他产品，采用不同的统计学原理，达到类似的效果。

归因分析之 Granger causality

Granger causality（格兰杰因果关系）是一种算法，简单来说它通过比较“已知上一时刻所有信息，这一时刻 X 的概率分布情况”和“已知上一时刻除 Y 以外的所有信息，这一时刻 X 的概率分布情况”，来判断 Y 对 X 是否存在因果关系。

可能有了解过一点机器学习信息的读者会很诧异了：不是说机器只能反应相关性，不能反应因果性的么？需要说明一下，这里的因果，是统计学意义上的因果，不是我们通常哲学意义上的因果。

统计学上的因果定义是：『在宇宙中所有其他事件的发生情况固定不变的条件下，如果一个事件 A 的发生与不发生对于另一个事件 B 的发生的概率有影响，并且这两个事件在时间上有先后顺序（A 前 B 后），那么我们便可以说 A 是 B 的原因。』

归因分析之皮尔逊系数

另一个常用的算法是皮尔逊系数。下图是某 ITOM 软件的实现：

我们可以看到，其主要元素和采用 FastDTW 算法的 Oculus 类似：correlation 表示相关性的评分、lead/lag 表示不同时序数据在时间轴上的偏移量。

皮尔逊系数在 R 语言里可以特别简单的做到。比如我们拿到同时间段的访问量和服务器 CPU 使用率：

然后运行如下命令：

acc_count<-scale(acc$acc_count,center=T,scale=T)

cpu<-scale(acc$cpuload5,center=T,scale=T)

cortest(acc_count,cpu)

可以看到如下结果输出：

对应的可视化图形如下：

这就说明网站数据访问量和 CPU 存在弱相关，同时从散点图上看两者为非线性关系。因此访问量上升不一定会真正影响 CPU 消耗。

其实 R 语言不太适合嵌入到现有的运维系统中。那这时候使用 Elasticsearch 的工程师就有福了。ES 在大家常用的 metric aggregation、bucket aggregation、pipeline aggregation 之外，还提供了一种 matrix aggregation，目前唯一支持的 matrix_stats 就是采用了皮尔逊系数的计算，接口文档见：

>

互联网时代的网络自动化运维

互联网上有两大主要元素"内容和眼球"，"内容"是互联网公司(或称ICP)提供的网络服务，如网页、游戏、即时通信等，"眼球"则是借指海量的互联网用户。互联网公司的内容往往分布在多个或大或小的IDC中，越来越多的"眼球"在盯着ICP所提供的内容，互联网公司进行内容存储的基础设施也呈现出了爆发式的增长。为了保障对内容的访问体验，互联网公司需要在不同的运营商、不同的省份/城市批量部署业务服务器用以对外提供服务，并为业务模块间的通信建立IDC内部网络、城域网和广域网，同时通过自建CDN或CDN专业服务公司对服务盲点进行覆盖。因此随着业务的增长，运维部门也显得愈发重要。他们经过这些年的积累，逐步形成了高效的运维体系。本文将结合国内互联网公司的经验，重点针对IT基础设施的新一代自动化运维体系展开讨论。

一、运维的三个阶段

● 第一个阶段：人人皆运维

在早期，一个公司的IT基础设施尚未达到一定的规模(通常在几台到几十台机器的规模)，不一定有专门的运维人员或部门，运维的工作分担在各类岗位中。研发人员拥有服务器权限，自己维护和管理线上代码及业务。

● 第二个阶段：纵向自动化

随着业务量的增长，IT基础设施发展到了另外一个量级(通常在上百台至几千台机器的规模)，开始有专门的运维人员，从事日常的安装维护工作，扮演"救火队员"，收告警，有运维规范，但运维主要还是为研发提供后置服务。

这个阶段已经开始逐步向流程化处理进行过渡，运维部门开始输出常见问题处理的清单，有了自己业务范围适用的自动化脚本，开始利用开源软件的拼装完成大部分的工作。

具体表现为：各产品线有自己编写的脚本，利用如SVN+puppet或chef来完成服务器的上线和配置管理等工作。

● 第三阶段：一切皆自动

在互联网化的大潮中，越来越多的黑马团队应运而生，都曾有过短时间内用户访问量翻N倍的经历。在流量爆发的过程中，ICP的互联网基础服务设施是否能够很好的跟进，直接决定了业务内容能否满足海量用户的并发访问。

与此同时，运维系统需要足够地完善、高效、流程化。谷歌、腾讯、百度和阿里等规模的公司内一般都有统一的运维团队，有一套或多套自动化运维系统可供参照，运维部门与开发部门会是相互平行的视角。并且也开始更加关注IT基础设施在架构层面的优化以及超大规模集群下的自动化管理和切换(如图1所示)。

图1大型互联网公司IT基础设施情况概览

二、BAT(百度、阿里、腾讯)运维系统的分析

国内的互联网公司百度、阿里、腾讯(以下简称：BAT)所提供的主要业务内容不同，IT架构不同，运维系统在发展过程中有不同的关注点。

1腾讯运维：基于ITIL的运维服务管理

预计到2015年腾讯在全国将拥有60万台服务器。随着2012年自动化部署实践的成功，目前正在进行自动化验收的工作。在网络设备方面，后续将实现从需求端开始的全自动化工作：设备清单自动生成->采购清单自动下发->端口连接关系、拓扑关系自动生成->配置自动下发->自动验收。整个运维流程也已由初期的传统IT管理演进到基于ITIL的服务管理流程(如图2所示)。

图2腾讯基于ITIL的运维服务管理

2阿里运维系统：基于CMDB的基础设施管理+逻辑分层建模

CMDB(Configuration Management Database) 配置管理数据库(以下简称：CMDB)，将IT基础架构的所有组件存储为配置项，维护每个配置项的详细数据，维护各配置项之间的关系数据以及事件、变更历史等管理数据。通过将这些数据整合到中央存储库，CMDB可以为企业了解和管理数据类型之间的因果关系提供保障。同时，CMDB与所有服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。可实现IT服务支持、IT运维以及IT资产管理内部及三者之间的流程整合与自动化。在实际的项目中，CMDB常常被认为是构建其它ITIL流程的基础而优先考虑，ITIL项目的成败与是否成功建立CMDB有非常大的关系。

3百度自动化运维：部署+监控+业务系统+关联关系

百度主要面临的运维挑战包括：突发的流量变化、复杂环境的关联影响、快速迭代的开发模式以及运维效率、运维质量、成本之间的平衡等等。百度的运维团队认为，当服务器规模达到上万台时，运维视角需要转为以服务为粒度。万台并不等于"百台100";机器的运行状态，也不再代表业务的工作状态;运维部门为研发提供前置服务，服务与服务之间关系也随着集群的扩大逐渐复杂起来。

图3百度自动化运维技术框架

百度的自动化运维技术框架，划分为部署、监控、业务系统、关联关系四大部分，整个框架更多突出了业务与IT基础设施的融合，注重"关联关系"的联动。所谓关联关系，主要是指任务与任务之间的时序依赖关系、任务与任务之间的数据依赖关系、任务与资源之间的引用依赖关系，分别对应到任务调度、数据传输、资源定位的服务流程中，形成了多条服务链。

关联关系的运维与业务较强相关，需要有一套系统能够理清楚关系的全貌，从而在复杂的服务链上，定位运行所在的环节，并在发生故障时预估影响范围，及时定位并通知相应的部门。在这样的一套系统中，自动化监控系统非常重要。百度的技术监控框架，主要通过数据采集、服务探测、第三方进行信息收集，进行监控评估后交给数据处理和报警联动模块处理，通过API接口进行功能扩充(如图4所示)。

图4百度自动化技术监控框架

其实无论是BAT等互联网企业还是其他行业的企业，在IT建设中都会遵循IT基础架构库(ITIL)或ISO20000服务管理的最佳实践，采用自动化IT管理解决方案以实现重要的业务目标，如减少服务中断、降低运营成本、提高IT效率等等。随着ISO20000、ITIL v30的发布和推广，两者已经成为事实上的某种标准。在当今企业IT管理领域，对两个标准有着很迫切的需求。特别是ISO20000的认证要求，已经成为企业越来越普遍的需求 。ITIL v30包含了对IT运维从战略、设计到转换、运营、改进的服务全生命周期的管理，相关方案往往覆盖了多个领域和多个产品，规划实施和工具的选择会比较纠结。如果选择开源的工具，从CMDB开始就会遇到很多的开发工作，对于很多注重成本收益比的企业，可以参考，但由于无法保证性能与效果并不一定适用。因此，成熟的商业方案会是更好的选择。

最新的iMC V7版本，围绕资源、用户、业务三个维度进行创新，发布了SOM服务运维管理(基于ISO20000、ITIL标准)等组件，增加了对服务器的管理，能很好的满足更多互联网化的场景需求。

通常认为，一个高效、好用的配置管理数据库一般需要满足6条重要标准，即联合、灵活的信息模型定义、标准合规、支持内置策略、自动发现和严格的访问控制。企业IT基础架构的元素类型、管理数据的类型往往有较多种，如网络设备、服务器、虚拟机等，因此对于多种信息的存储需要有合适的联合的方法。虽然 iMC智能管理平台在网络设备、服务器设备等方面已经能够较好的的满足，但是随着服务器虚拟化技术的发展，虚拟机正越来越多的成为IT基础架构的一大元素。因此，针对这一需求华三通信基于CAS CVM虚拟化管理系统，对服务器CPU、内存、磁盘I/O、网络I/O等更细节的重要资源以及虚拟机资源进行全面的管理。与BAT不同，华三通信的网管软件面向全行业，目前虽然没有对域名管理等特殊资源的'管理，但是能够通过API接口等方式与特有系统进行联动，进而满足定制化运维的需求，尤其是在互联网化的场景中，针对不同的业务需求，可以实现很多定制化的对接需求，例如，iMC+WSM组件与国内某大互联网公司自有Portal系统进行了对接，打通了iMC工具与用户自有运维平台，很好的实现了架构融和。另外，与阿里的逻辑分层建模相似，H3C "iMC+CAS"软件体系在上层也做了很多的逻辑抽象、分层，形成了诸多的模块，也即是大家看到的各种组件。

三、网络自动化运维体系

"哪怕是一个只有基础技术能力的陌生人，也能做专业的IT运维;哪怕是一个只有初中学历的运维人员，也能够带队完成中小型机房节点的建设，并负责数百至上千台服务器的维护管理工作"--这是一些公司对自己IT运行维护水平的一个整体评价。看似有些夸大的嫌疑，但实际上依托于强大的IT运维系统，国内已经有不少互联网公司能够达到或者接近这一标准。

这些企业都经历了运维发展过程中的各个阶段，运维部门曾经也是被动的、孤立的、分散的"救火队"式的团队，在后来的发展过程中，IT系统架构逐渐走向标准化、模型化，运维部门建立了完整的设备、系统资源管理数据库和知识库，包括所有硬件的配置情况、所有软件的参数配置，购买日期、维修记录，运维风险看板等等，通过网管软件，进行系统远程自动化监控。运维过程中系统会收集所有的问题、事件、变更、服务级别等信息并录入管理系统，不断完善进而形成一套趋向自动化的运作支撑机制。按照云计算的体系架构，在这样一套系统中，主要的IT资源包括计算、存储、网络资源，近些年随着网络设备厂商的推动，网络设备管理方面的自动化技术也得到十足的发展。

总结来看，一个企业在进行互联网化的建设初期，就需要考虑到随着用户访问量的增加，资源如何进行扩展。具体可以细化为规划、建设、管理、监控、运维五个方面。

1规划模型化

为了确保后续业务能够平滑扩容，网管系统能够顺利跟进，互联网企业一般在早期整体系统架构设计时便充分考虑到标准化、模型化，新增业务资源就好比点快餐，随需随取。

标准化：一是采用标准协议和技术搭建，扩展性好，使用的产品较统一，便于管理;二是采用数据中心级设备，保证可靠性、灵活性，充分考虑业务系统对低时延的要求。

模型化：基于业务需求设计网络架构模型，验证后形成基线，可批量复制，统一管理，也适宜通过自动化提高部署效率、网管效率。

图5常见互联网IDC架构

2建设自动化

互联网IT基础设施具备批量复制能力之后，可以通过自动化技术，提高上线效率。在新节点建设过程中，3～5人的小型团队即可完成机房上线工作。例如某互联网公司某次针对海外紧急业务需求，一共派遣了2名工程师到现场进行设备安装部署和基本配置，而后通过互联网链路，设备从总部管理系统中自动获取配置和设备版本，下载业务系统，完成设备安装到机房上线不超过1周时间。

要达到自动化运维的目标，建设过程中需要重点考虑批量复制和自动化上线两个方面(如图6所示)。

批量复制：根据业务需要，梳理技术关注点，设计网络模型，进行充分测试和试点，输出软、硬件配置模板，进而可进行批量部署。

自动化上线：充分利用TR069、Autoconfig等技术，采用零配置功能批量自动化上线设备，效率能够得到成倍提升。

图6批量配置与自动化上线

○ Autoconfig与TR069的主要有三个区别：

○ Autoconfig适用于零配置部署，后续一般需要专门的网管系统;TR069是一套完整的管理方案，不仅在初始零配置时有用，后续还可以一直对设备进行监控和配置管理、软件升级等。

○ Autoconfig使用DHCP与TFTP--简单，TR069零配置使用DHCP与>

IT智能运维必须以大数据为基础，所以企业必须具有采集IT全层级数据的能力，并能实现数据融合，结合机器学习、智能算法，对IT运维实现洞察，获得预见性。

现在推IT智能运维的服务商国内有几家，我比较认可博睿数据提出的数据为本的理念，没有数据就是无水之源，所以企业别被概念忽悠，先踏实做数据采集和融合，智能运维是水到渠成的事

以上就是关于IT技术支持人员是如何进行远程运维的全部的内容，包括:IT技术支持人员是如何进行远程运维的、如何提升IT运维管理效率、[四级体系打造整体IT运维] 华为IT运维体系介绍等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！