故障自愈作为运维领域的热门话题之一，各个公司都会投入大量的人力来开发不同的组件，如何正确、有序的调用不同组件以及避免相同功能组件的开发，是一件亟待解决的问题。StackStrom是一个基于事件流并自动执行的系统框架，基于此，可以让外部系统产生的事件，有序的、可编排的集合到一起，作为一个完整的事件流去执行，从而解决一些高频次的运维难题。

1 背景介绍

目标

基于报警事件，进行收敛和自愈处理。

收敛：合并报警，减少报警数量。
自愈：根据预先设定好的规则库进行根因分析，命中后对报警进行自处理。

愿景

打造企业级云服务的医疗中心、自愈中心。

整体架构图：

2 StackStorm介绍

StackStorm是一个基于事件流的自动执行开源项目。它可以基于现有的流程、平台工作流、API、和其他一切可执行的应用环境。让这些外部系统产生的事件，有序的、可编排的集合到一起，作为一个完整的事件流去执行，从而解决一些高频次的场景。

这些执行流程中的每个动作称为一个action(原子)，不同项目中的action可以共享。

官方描述支持的场景：

故障排查：捕获Nagoios、zabbix等监控系统报警，然后组合排查action。
自动执行：比如自动解决OpenStack compute node的硬件故障，自动编排和发送邮件等。
CI/CD：结合jenkins、aws等，进行持续部署、持续集成。

官方提供的StackStorm架构图：

StackStorm组件介绍

Sensors: 监听和接收外部系统的事件，当一个从外部系统过来的事件出现并被接受, trigger被触发执行；
Trigger: 是外部事件的具体表现，简单理解为就是事件触发器，衔接sensor和rule；
Rule: 映射着所有trigger到action的规则(或者到workflow的对应关系)，记录着criteria匹配的规则，映射trigger实例到action的input，简单理解就是规则匹配配置记录；
Action: 是st2的具体执行动作和步骤，可以使用脚本、调用API或者其他任何自定义的action。如ssh、API call、OpenStack、Docker、salt、puppe、jenkins等的调用；
Workflow: 多个action的集合，这些action被有序的、按照预先定义好的规则先后执行；
Pack: st2的内容单元集合，简单理解为一个项目就是一个pack；

官方开放的pack"应用商店"截图：

StackStorm流程说明

sensor通过pull\push 方式接受外部系统的(事件流)数据，通过trigger触发器将数据注射到st2体内，并通过rule模块接收，同时rule模块记录着基于事件的匹配规则，当数据进来的时候根据匹配规则进行匹配，如果命中的话执行action的集合workflow，并按照workflow预先定义好的流程去执行。

pack的结构

workflow的结构

Sensor：yaml配置文件+Py脚本文件组成

yaml配置文件示例：

py脚本文件示例：

Rule示例：

Workflow示例图：

关于StackStorm的更多示例这里不做详细解释，有兴趣的可以参考官方文档。

3 应用实例

workflow结构

workflow流程

st2 web平台记录的结果示例

4 总结

目前我们基于这套流程已经完成了团队内70~80%的通用运维场景，大部分日常报警都已经满足了可自愈的状态，此服务大大节省了运维人员的精力、提高了工作效率，并最大限度的降低了服务故障的时间。

通常每个Server端的服务都有自己的问题排查流程和技巧，结合这些流程、丰富运维场景（troubleshooting流程、止损动作），并最终结合到我们的StackStorm自愈平台上，一个无需人肉干预、可自愈的云服务打造完成。

未来：结合业务拓扑图、调用链关系去完善和丰富平台，同时基于监控、日志数据等结合AI算法做到故障预警、预知，可以先于故障提前发现问题。最大限度的减少业务中断带来的损失。

本文转载自公众号360云计算（ID：hulktalk）。

原文链接：

https://mp.weixin.qq.com/s/mbO4vxImvgE1qNqGFcx0QA

创作场景

基于 StackStorm 的 ChatOPS 方案 - 监控报警的自愈