运维工程师告警分析（运维工程师常见故障）

本篇文章给大家谈谈运维工程师告警分析，以及运维工程师常见故障对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享运维工程师告警分析的知识，其中也会对运维工程师常见故障进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、系统运维工程师工作职责具体内容
• 2、运维工程师，工作内容有哪些？
• 3、IT运维平台算法背后的两大“神助攻”

系统运维工程师工作职责具体内容

系统运维工程师需要具备良好沟通能力，具备较强的责任心及工作执行力，对人热情，有良好的团队合作精神;以下是我精心收集整理的系统运维工程师工作职责，下面我就和大家分享，来欣赏一下吧。

系统运维工程师工作职责1

1. 负责项目版本管理和发布管理，实现环境版本迭代的顺利交付。

2. 参与制定配置管理规范，流程和策略，针对具体项目制定具体的配置管理计划。

3. 持续集成和持续交付管理模式的建设与优化，及相关平台的技术调研。

4. 配置管理平台维护，确保配置相关工具平台、site、beta及生产环境的稳定性。

5. 负责生产环境的巡检与问题排查，紧急问题的处理。

6. 项目日常支持，流程工具的培训指导，协助解决项目配置管理相关问题

系统运维工程师工作职责2

1、负责公司的软件系统的日常维护和培训;

2、负责与软件服务厂商的日常沟通协作;

3、负责公司BI系统数据报表的开发和培训;

4、完成上级交办的 其它 事项;

5、完成与IT相关的综合性支持工作。

系统运维工程师工作职责3

1.根据维护及工作要求，对设备、设施及系统进行现场/远程检查;

2.能对设备、设施及系统的问题进行简单故常排除。

3.负责记录巡检及故障 报告 。

系统运维工程师工作职责4

1、 负责系统运行团队的日常运维工作;

2、 做好相关系统运行情况的值班记录和数据汇总工作;

3、 负责团队运维系统的安装、调试、维护、监控和故障处理等日常工作，对团队运维系统提供技术支撑，保证系统稳定运行;

4、 负责日常运维问题记录、反馈和跟踪。

5、 撰写相关的运行维护手册和后续完善修订，定期编写系统运行维护报告。

6、 完成领导安排的其他事项。

系统运维工程师工作职责5

1、整体设计，参与项目架构设计，运维方案撰写，推动落地实施。

2、实施部署，合理计划，把控项目实施部署节奏，保障工作质量。

3、系统优化，主导必要系统优化工作，解决系统性能瓶颈。

4、日常运维，分析运维指标，优化执行过程，提供工作效率。

5、问题处理，剖析问题根源，深刻理解原理，给出明确的解决思路。

6、运维管理，主导新技术调研并分享，考虑系统稳定性、执行高效性，管理一个项目运维交付。

系统运维工程师工作职责6

1、负责Linux\Windows物理服务器日常维护及公司内部网络软硬件维护;

2、负责服务器的系统安装和网络服务配置;

3、参与APP开发，全生命周期运维管理，包括制定系统架构规范、技术规范、系统安装部署等;

4、负责环境搭建、安全防护、系统部署上线、变更处理、参数优化、漏洞修复等、故障排除;

5、负责系统的日常运维管理，并分析系统运行数据，对性能、容量提出优化建议并实施，包括架构优化、系统扩容等;

6、负责阿里云服务器管理、维护、集群搭建、分布式管理及现网变更，事件、告警、奔溃处理，并分析改进;

7、协助编写日常运维操作手册,建立应用运维的制度，知识管理体系、流程与文档等。

系统运维工程师工作职责7

1. 负责城市视频监控系统前端系统的巡检、调试工作;

2. 负责城市视频监控系统前端系统故障的判断与排除;

3. 负责一般性网络、监控等技术问题的咨询工作;

系统运维工程师工作职责具体内容相关 文章 ：

★ 系统运维工程师岗位的主要职责描述

★ 系统运维工程师的职责内容

★ 系统运维工程师的工作职责

★ 系统运维工程师的主要职责描述

★ 系统运维工程师岗位的基本职责

★ 系统运维工程师的岗位职责范本

★ 运维工程师的岗位职责描述

★ 系统运维工程师的具体内容

★ 运维工程师的具体职责概述

运维工程师，工作内容有哪些？

一： 运维工程师要保证线上系统地稳定，这是运维人员的核心价值 ，围绕这个展开，是一个非常大的话题，后面细化

二：基础建设：安全，质量，效率，成本 是运维人员可以展开运维工作的四大方面。围绕着这四个方面，我们需要制定规范，流程，建设对应的系统保证效率，标准化提升效率等等
质量： 立体化监控系统；测速，备份容灾等等
效率： 提升运维效率的系统建设，标准化机器初始化，软件安装标准化，监控标准化等等，提升效率，批量部署脚本等等
安全：互联网安全，系统支持，cgi扫描等等
成本：预算制定等等，合理优化部署，平衡成本与体验

三：基础建设升华：一切以用户价值为依归
1：异地部署 ，异地容灾
2：柔性可用 ，柔性可损
3：全网调度 ，实现成本与 用户体验的平衡
4：优化用户体验：提升速度
四：从一个项目上看运维人员的工作分解
1：项目初期介入，提对应运维需求，需要运维工程师预计运营时可能需要的数据，可以从两个方向考虑：A监控；B评估系统好坏的运维指标，如接口调用数据，用户访问速度等等，提出对应需求，开发在设计时实现，方便上线后运维采集这些数据做系统评估。 这个阶段要了解系统架构，评估运维上是否合理。是否方便部署，运维风险有哪些，从哪些层面可以避免，做好容灾，cache数据丢数，db down掉等的评估以及应对方案设计，全网调度方案等。
2：项目开发阶段，这个阶段运维也要参与其中，了解对应运维需求开发的完成情况
3：项目测试发布： 运维负责运营环境的搭建，发布上线，并监控线上系统稳定
4：项目发布后：保证对应监控，备份，容灾等对应工作完成
5：项目运营阶段：及时对告警进行处理，对系统发展趋势做好评估，扩容等，预估可能的运营风向，并做好对应的应对措施
6：相关演习
7：做好系统优化，提升用户体验

五：从运维人员面对的周边角色做 运维人员的工作分解
1：上游战略依从：理解公司发展方向，调整运营战略
2；开发
3：测试
4：QA
5：老板等

IT运维平台算法背后的两大“神助攻”

智能运维(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]。那么它就采样为 (0.2, 0.4, 0.6, 0.8)，也就是 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 2.0 的时候，Oculus 被认为是1.0 最成功的部分，完整保留下来了。

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 的 0.20 版本，后来该版本一直没有更新。现在停留在这么老版本的 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)

cor.test(acc_count,cpu)

可以看到如下结果输出：

对应的可视化图形如下：

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

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

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html

唯一需要注意的就是，要求计算相关性的两个字段必须同时存在于一个 event 里。所以没法直接从现成的 ES 数据中请求不同的 date_histogram，然后计算，需要自己手动整理一遍，转储回 ES 再计算。

饶琛琳，目前就职日志易，有十年运维工作经验。在微博担任系统架构师期间，负责带领11人的SRE团队。著有《网站运维技术与实践》、《ELKstack权威指南》，合译有《Puppet 3 Cookbook》、《Learning Puppet 4》。在众多技术大会上分享过自动化运维与数据分析相关主题。 关于运维工程师告警分析和运维工程师常见故障的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 运维工程师告警分析的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于运维工程师常见故障、运维工程师告警分析的信息别忘了在本站进行查找喔。