运维事件驱动（基于事件驱动）

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

本文目录一览：

• 1、有效运维的 on-call 机制
• 2、程序员应知应会之自动化运维那些事儿
• 3、IT运维管理的IT运维服务管理软件

有效运维的 on-call 机制

[编者按]本文作者为陈伯龙，云告警平台 OneAlert 创始人，著《云计算与 OpenStack 》，在IT运营管理、云计算方面从业10多年。

互联网技术的发展，离不开运维支撑工作，没有零bug的程序，没有不出问题的系统，问题故障不可怕，可怕的是没能有序的处理：

如何有效处理紧急事件驱动的工作，成为（特别是运维主管）运维工作的关键。我接触了大量的各类型公司运维，从初创、中小、大型公司，总结和分享一些大多公司通用的on-call机制，帮助有序的处理紧急事件：

基本上都是围绕人、流程、工具三方面进行，参考了ITIL的管理思路，大家感兴趣也可以参考下，特别是其中的ITIL V3的运营管理。

大多公司都用了zabbix和nagios、open-falcon等监控工具，对硬件、网络、应用进行监控。可能会存在监控分散问题：

告警集中化，就是所有的生产监控发现的告警事件集中到一起，这样我们盯着一个平台就够了，同样也容易分析问题，是不是相同和类似原因。

如果监控工具单一，集中化不是最必要的，如何有序处理才是最核心的。特别运维团队是3-5人到数十／百人，就很有必要梳理下支撑流程和响应机制了。

如果管理比较细一些，还会进行业务拆分，形成一个矩阵，例如一线、二线根据不同专业，如负责网络和负责不同应用的团队。
另外还要考虑告警严重的程度级别，进行差异化处理，要求严格的同学一般会建立响应级别[1-3]或[1-5]：

那么问题来了，规划和设计挺好，如何落地呢？目前看zabbix、nagios、open-falcon等监控工具更多是聚焦如何发现问题，支撑流程属于处理问题的范畴，或者是说管理范畴，这一点目前市面上合适工具较少：

接触过一个互联网金融公司，设计了非常规范化的流程和P0-P5级别应急处理方案，涉及了网络、云平台、近50个应用研发团队。

分派升级

排班管理

再好的流程和设计，当时没有及时收到通知和处理，那么就会很郁闷了，最后一公里问题解决方式：

还支持几点：不同级别、不同时间段的设置，例如晚上严重的电话通知，白天工作时间就不用了。
这里面还存在一个问题，当告警规模大了后，特别是告警风暴的话，很容易撑爆邮箱或者是手机短信了，所以接下来就聊下告警风暴规避的问题。

这个问题比较大，基本上有些监控工具做了一部分，目前看也是一个业界难题，简单来说：

我们目前做了一些尝试分享下：

机器学习告警合并

如果告警量很大，告警后续处理和跟踪往往会依赖于外部团队（部门外或公司外）。但是监控告警粒度太细了，可能很多告警都是一个事情。如上面的告警风暴中，由于应用程序故障，引发引发了大量的异常，之后又产生连锁反应，其实就是一个事情，只需要处理一个事情就行。
一般来说一线人员会采用邮件或者电话方式，直接通知对应负责人，但是这个就很难追踪和事后分析，所以一套事件管理机制。
ITIL规范的事件Incident流程很有参考价值，感兴趣同学参考下。事件工单需要：

事件单

影响范围和紧急程度的交叉矩阵影响到优先级

On-Call机制建立后，通过告警和事件数据分析、建立起以数据指标驱动的团队文化，有机会和大家分享。

OneA lert 是 OneAPM 旗下产品，是国内第一个 SaaS 模式的云告警平台，集成国内外主流监控/支撑系统，实现一个平台上集中处理所有 IT 事件，提升 IT 可靠性。想阅读更多技术文章，请访问 OneAPM 官方技术博客 。

本文转自 OneAPM 官方博客

程序员应知应会之自动化运维那些事儿

对于一个开发人员来讲运维事件驱动，可能运维并不是自己运维事件驱动的职责所在。但是作为一名开发人员，却不能不了解自动化运维的整个流程。因为对于一个信息系统而言，开发和运维本质是一体的，尤其对于一些小公司来讲，可能运维人员本身就是开发人员抽空兼任的。

而自动化运维，本质上是介于开发和运维之间的，是运维和开发的交集，甚至很多时候都要写不少代码。因此，任何一个开发人员，都需要有自动化运维的相关知识。

一个了解好的开发人员，即使自己不做运维相关的工作，也能够知道自己在将项目交付给运维人员的时候，哪些东西是重要的，那些是必须配置的等等。然而在实际工作中，往往开发人员会给运维人员留下一些坑，一些只有运维事件驱动他自己知道，而运维人员不知道的东西。导致运维人员自己试了很多次发现不行的时候，找到开发人员，开发人员研究了一下才会告诉他，在某某环境中必须用哪个端口之类的。这样不仅白白浪费了运维人员的时间，也增加了很多沟通的工作量。

反过来也是如此，一些现场的问题如果运维人员不能现场给出问题的定位。对于开发人员来讲是非常难以复现的。比如之前有某家企业，运维人员在客户现场发现问题。费了很大力气从客气的内网里面把日志导出来，发给开发人员，结果开发人员仔细研究了日志之后，发现是网不通的问题。开发人员显然是不可能知道为啥网不通的，搞不好是压根没连网线。

所以今天运维事件驱动我们来聊一聊，对于一个程序员来讲，需要了解的自动化运维的那些事。

一、自动化运维的概念

随着信息时代的持续发展，初期的几台服务器已经发展成为了庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求。一个运维人员手工配置几台服务器还可能。配置几百上千台服务器那就累死了，还容易出错。那么就需要对运维工作进行标准化、自动化、架构优化、过程优化等。从面降低运维服务成本。其中，自动化最开始作为代替人工操作为出发点的诉求被广泛研究和应用。

所谓自 动化运维，即在最少的人工干预下，结合运用脚本与第三方工具，保证业务系统7*24小时高效稳定运行 。这是所有业务系统运维的终极目标。

按照运维的发展成熟度来看， 运维大致可分为三个阶段 ：

（1）依靠纯手工，重复地进行软件的部署与运维；

（2）通过编写脚本，方便地进行软件的部署与运维；

（3）借助第三方工具，高效地进行软件的部署与运维；

二、自动化运维需要解决的问题

自动化运维通常来讲，需要解决以下几个问题： 自动部署配置、风险事前预警、故障事中解决、和故障事后管理 。

三、自动化运维的常用工具

自动化运维常用的工具包括以下几种：

1、Ansible

ansible是基于Python开发的自动化运维工具，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

ansible具有如下一些特性：

(1)模块化：调用特定的模块，完成特殊的任务。

(2)Paramiko(python对ssh的实现)，PyYaml，jinja2(模块语言)三个关键模块。

(3)支持自定义模块，可使用任何编程语言写模块。

(4)基于python语言实现。

(5)部署简单，基于python和SSH(默认已安装)，agentless，无需代理不依赖KPI(无需SSL)。

(6)安全，基于OpenSSH

(7)幂等性：一个任务执行一次和执行n遍效果一样，不因重复执行带来意外情况。

(8)支持playbook编排任务，YAML格式，编排任务，支持丰富的数据结构。

(9)较强大的多层解决方案role。

2、Chef

Chef是一个功能强大的自动化工具，可以部署，修复和更新以及管理服务器和应用程序到任何环境。

Chef 主要分为三个部分 Chef Server、Workstation 以及 Chef Client。用户在 Workstation 上编写 Cookbook。然后，通过 knife 命令上传到 Chef Server。最后，在 Chef Client 上面实施安装和部署工作。所以，对于 Cookbook 地编写在整个自动化部署中起到了重要的作用。

Chef Server 包含所有配置数据，并存储描述Chef-Client中每个Nodes的Recipe，Cookbook和元数据。配置详细信息通过Chef-Client提供给Nodes。所做的任何更改都必须通过Chef Server进行部署。在推送更改之前，它通过使用授权密钥来验证Nodes和Workstations是否与服务器配对，然后允许Workstations和Nodes之间进行通信。

Workstations 用于与Chef-server进行交互，还用于与Chef-nodes进行交互。它还用于创建Cookbook。Workstations是所有交互发生的地方，在这里创建，测试和部署Cookbook，并在Workstations中测试代码。

Chef命令行工具 是创建，测试和部署Cookbook的地方，并通过此策略将其上载到Chef Server。

Knife 用于与ChefNodes进行交互。

Test Kitchen 用于验证Chef代码

Chef-Repo 是一个通过Chef命令行工具在其中创建，测试和维护Cookbook的存储库。

Nodes 由Chef管理，每个Nodes通过在其上安装Chef-Client进行配置。 ChefNodes 是一台机器，例如物理云，云主机等。

Chef-Client 负责注册和认证Nodes，构建Nodes对象以及配置Nodes。Chef-Client在每个Nodes上本地运行以配置该Nodes。

Cookbook 是Chef 框架的重要基础功能之一。在 Chef Server 对目标机器做安装部署的时候，是通过 Runlist。而 Runlist 里面又包含了一个一个具体的 Cookbook，所以，最终对一个目标机器的部署任务就落到了 Cookbook 上。而对于 Cookbook 来说，其中包含了多个组件，运维事件驱动我们可以将 Cookbook 简单地理解成一个容器或者可以理解为一个包，里面包含了 recipes、files、templates、libraries、metadata 等信息。这些信息用于配置我们的目标机器。

3、Puppet

puppet是一种Linux、Unix平台的集中配置管理系统，所谓配置管理系统，就是管理其里面诸如文件、用户、进程、软件包等资源。它可以运行在一台服务器端，每个客户端通过SSL证书连接到服务端，得到本机器的配置列表，然后根据列表来完成配置工作，所以如果硬件性能比较高，维护管理上千上万台机器是非常轻松的，前提是客户端的配置、服务器路径、软件需要保持一致。

客户端Puppet会调用本地facter，facter探测出该主机的常用变量，例如主机名、内存大小、IP地址等。然后Puppetd把这些信息发送到Puppet服务端；

Puppet服务端检测到客户端的主机名，然后会检测manifest中对应的node配置，并对这段内容进行解析，facter发送过来的信息可以作为变量进行处理；

Puppet服务器匹配Puppet客户端相关联的代码才能进行解析，其他的代码不解析，解析分为几个过程，首先是语法检查，然后会生成一个中间的伪代码，之后再把伪代码发给Puppet客户端；

Puppet客户端接收到伪代码之后就会执行，执行完后会将执行的结果发送给Puppet服务器；

Puppet服务端再把客户端的执行结果写入日志。

4、Saltstack

SaltStack是基于python开发的一套C/S自动化运维工具。部署轻松，扩展性好，很容易管理上万台服务器，速度够快。与服务器之间的交流,以毫秒为单位。SaltStack提供了一个动态基础设施通信总线用于编排,远程执行、配置管理等等。它的底层使用ZeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理，传输采用AES加密。

在saltstack架构中服务器端叫Master，客户端叫Minion。

在Master和Minion端都是以守护进程的模式运行，一直监听配置文件里面定义的ret_port(接受minion请求)和publish_port(发布消息)的端口。当Minion运行时会自动连接到配置文件里面定义的Master地址ret_port端口进行连接认证。

saltstack除了传统的C/S架构外，其实还有一种叫做masterless的架构，其不需要单独安装一台 master 服务器，只需要在每台机器上安装 Minion端，然后采用本机只负责对本机的配置管理机制服务的模式。

saltstack提供如下一些功能：

（1）远程执行：（批量执行命令）在master上执行命令时，会在所有的minion上执行。

（2）配置管理/状态管理 ：（描述想到达到的状态，saltstack就会去执行）

（3）云管理(cloud)：用于管理云主机

（4）事件驱动：被动执行，当达到某个值会自动触发

这四种自动化运维工具的比较如下，现在主流的基本上ansible和saltstack用的多一些：

IT运维管理的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服务台变更控制功能与事件和问题管理紧密集成，企业可轻松追踪变更原因，促进对变更和发布的高效管理，节省变更和发布管理所需时间。

关于运维事件驱动和基于事件驱动的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 运维事件驱动的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于基于事件驱动、运维事件驱动的信息别忘了在本站进行查找喔。