什么是sap运维、IT运维及方式

IT服务管理软件，帮助企业建立以服务台和事件为驱动、统一的IT服务管理平台，实现规范的服务流程（如问题、变更、配置等流程），从根本上提高了IT服务运维效率，用最低的成本交付高质量的IT服务。

LANDESK Service Desk IT服务管理软件的应用价值

LANDESK Service Desk：LANDESK Service Desk流程驱动IT服务管理软件解决方案。让企业更好的控制服务交付。

功能优势

LANDESK Service Desk是一款流程驱动的IT服务管理（ITSM）软件解决方案，可以部署为预置式、云式或混合式。提供了使用者期望从市场领先解决方案中所能获得的全部核心ITSM功能，包括经ITIL®验证的事件、请求、自助服务、控制、知识管理以及多级报告。

LANDESK Service Desk提供功能丰富的端到端服务管理平台，支持核心服务管理任务，同时可实现企业IT组织从基本解决方案管理到成熟服务组合管理、能力和可用性优化以及持续服务改进的高级业务目标。LANDESK Service Deskc能与使用者的系统和网络管理环境无缝集成，包括所有用于系统生命周期管理和端点安全性的LANDESK®解决方案。

该解决方案功能开箱即用，又易于配置，无需编码就可以满足特定的需求。企业使用其能够快速从反应状态转换到一种更可控、更主动并且面向服务的状态。可提高企业服务台员工和用户的工作效率，同时可缩短系统的恢复时间，能降低停机费用和服务相关的行业风险。

易于使用 轻松拥有

LANDESK Service Desk使IT部门能够与其技术基础架构以及用户社区进行有效地交互。其流程自动化和策略执行功能简化了最佳实践应用过程。通过深度集成，提供带有基本业务环境的可 *** 作智能，可支持快速准确的决策制定及持续的服务改进。

无代码配置

特殊设计，无代码、拖放配置就能进行修改，设计界面简单直观，数据修改和创建、布局和工作流程更简单。

规范且可控

工作流程清晰明确，使用时更高效，用户体验更佳

服务部署

服务交付控制不当，可能对企业服务台成本和生产效率造成严重影响。使用LANDESK Service Desk可在服务管理的整个生命周期中进行掌控。通过从部署到终止的整个过程中应用标准的验证和授权流程，有效的确保交付那些能提供价值并与企业战略目标一致的服务。

稳定可靠 适用广

LANDESK Service Desk设计用于跨多个时区和语言环境开展运营的分布式组织。不受IT环境的范围或性质限制。

基于流程的方法

定义并记录使用者的IT支持流程，包括是哪一流程，做什么，何时做，确保每个人都以相同的方式朝着相同的目标努力。

LANDESK Service Desk通过功能强大的流程引擎赋予使用者执行能力，可构建、自动化及修改任意复杂度的服务管理流程。LANDESK服务台附带丰富的预定义流程库，及简化新流程设计的模板。

服务台流程引擎是促进与推动服务交付和质量保证各个方面的强劲动力核心。在每个阶段，根据用户的角色和职责，企业可以看到不同的视图和提示。

使用服务台解决事件、更改系统配置、满足服务请求或部署新的员工，都能确保遵循IT支持流程而不出现偏差。要完成任务就无法避开任何流程，使用LANDESK Service Desk企业可以很简单的满足法规或安全方面的合规性要求。此外，通过针对每位用户对流程和窗口进行本地化，解决方案还支持跨国境的运营。

嵌入ITIL最佳实践支持

LANDESK Service Desk使ITIL最佳实践融入企业IT组织工作流程，构成ITIL V3的全部15个流程已经通过Pink Elephant的软件认证，可轻松展示出企业的良好IT治理状态。

服务级别合规性

利用服务台，可以轻松监控事件、请求、问题、变量或服务流程如何按照SLA执行。在任意任务中，服务台会根据输入的数据为分析人员自动预先选择相应的响应级别，因此系统会采取相应的升级 *** 作。若快要违反SLA，服务台将提升优先级、重新分配活动或通知服务台。保障用户的利益。

将服务管理扩展到核心IT之外

在核心服务管理之外，还有其他服务（如：项目管理和组合管理）。使用者可通过创建核心项目生命周期流程，使用其来管理单个项目或项目组合的全部内容——从里程碑阶段和任务工作流程直至风险、时间和成本管理。

管理变更

IT基础架构变更负责人可通过LANDESK Service Desk管理整个变更流程，并降低由于变更失败、不完全或误导而造成的生产中断风险。

LANDESK服务台变更控制功能与事件和问题管理紧密集成，企业可轻松追踪变更原因，促进对变更和发布的高效管理，节省变更和发布管理所需时间。

智能运维(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 就是采用了皮尔逊系数的计算，接口文档见：

>

sap是一款企业资源规划软件，它覆盖企业的业务系统。SAP运维包括SAP软件的升级、业务数据的备份、报表开发、软件错误处理、业务错误处理、业务流程的持续改进等，它是与企业业务密切相关的。

IT是信息技术，它的概念比较广，包括了SAP系统，也包括了支持SAP系统的网络架构，甚至包括包含此网络架构的更广泛网络架构，以及在其中运行的其它系统，如电子办公平台，网页服务器、邮件服务器、数据库审计设备等等。

按运维人员的来源，分为三种运维方式：

1、内部人员：人员隶属企业本身，可兼职也可专职（成本问题）

2、外部人员-实施方：由SAP软件的实施方提供后续的运维服务，这样任务的连续性较好。

3、外部人员-第三方：既不是企业方，也不是实施方，而是委托（由企业方或实施方）第三家企业来负责。连续性差，视具体情况吧。

以上就是关于IT运维管理的IT运维服务管理软件全部的内容，包括:IT运维管理的IT运维服务管理软件、IT运维平台算法背后的两大“神助攻”、什么是sap运维、IT运维及方式等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！