携程旅行网是国内领先的在线旅游服务公司，也是国内规模较大的互联网公司之一。随着近年来业务的迅猛增长，支撑网站的技术和系统的复杂性和规模也随之呈跳跃性的攀升。要迎接网站规模和复杂性提升带来的各种挑战，运维部门首当其冲。运用新技术，新思维来应对各种出现的新问题是运维技术人员天天都要面对的工作。本文中将介绍我们如何应对新场景下的排障工作。
问题描述
当运维自动化程度提高后，对于自动化服务的请求数量不断增长，业务规则和流程的复杂性日益加大。用户对自动化服务越来越依赖，因此对服务标准的要求也在提高，尤其表现在对服务可靠性的高要求。而另一方面，开发周期短，外部依赖多，不可控因素多等原因又使得工具和系统的缺陷在所难免。因此，在出现故障后能够快速定位问题，快速解决问题，把对用户的影响降到最低，就成了一个直接关系到产品成败的非功能性需求。
以携程运维工作流平台（携程运维工作流平台是一个运行携程核心运维流程，如服务器，网络，应用等上线/下线/变更等工作流的系统平台）为例，一台服务器的上线流程从提交请求到服务器交付需要控制在半小时之内，而流程由近十个环节，和近十个工具或系统交互，任何一个环节出现微小故障或者不稳定都可能造成流程中断。因此，需要我们能尽早发现每个环节的问题，修复问题。
传统策略和它的问题
传统方式下，我们使用黑盒策略，只监控流程的外在表现。监控流程中的每个步骤，给流程的每个步骤设置SLA，一旦SLA超时，就发邮件提醒相关人员及流程组。告警邮件发出后，运维人员需要接收到告警，登录系统，分析告警，定位诊断，修复故障。
上述策略存在明显的问题：
1) 时间延误：运维人员不能及时响应告警，造成响应及处理时间不可控
2) 人力成本：人工调查故障需要消耗大量的人力成本，而且经验积累过程缓慢（因为同一个处理人员处理同一个问题的间隔时间可能比较长，不能快速利用上次的排障经验）
3) 有价值的历史数据没有保存，无法统计告警现状及解决方案。如果有保存和分类的历史数据，我们可以了解系统的主要故障区域有哪些，以便进行针对性的改良设计。
4) 引入人为错误：人工处理过程还有可能引入人为错误
解决思路
为了全面掌握当前系统中故障的分布情况，我们先进行了第一步工作：建立一个排障系统对故障进行自动记录和分类。我们在流程平台中的关键环节进行埋点，将最能反映故障和异常的特征参数随着故障警告一起输送出来，在系统中根据这些特征参数对故障和人工分析的结果进行分类。
经过一段时间的人工处理，统计出如下报表：
从报表中，我们可以看到几个结果：
有很大一部分是无需干预的。
告警数量虽然很多，但是类别却不多，大量告警可以被诊断为同一问题，使用同样的修复方式。
绝大部分的故障可以通过告警中带有的特征参数进行自动分类或者利用简单的逻辑进行自动分类 – 自动诊断问题是可行的。
根据告警落地后的分析报告，很清楚地可以看到自动诊断流程是可行的，并且可以节省大量人力成本，并且大幅缩短排障时间和消除人为错误。
故障自动诊断方案
既然所有的问题的答案最终都指向自动诊断，那么我们来看下自动诊断需要包含哪些功能才能解决我们的问题。
故障自动诊断流程需要做到如下几点：
告警发出时立即响应
识别误报或可自行修复的告警
自动处理误报及无需干预的告警
对于复杂情况的告警进行预先诊断并返回结果
有了以上目标，接下来我们需要选择合适的工具实现自动诊断流程。
StackStorm介绍
StackStorm （以下简称ST2）是时下非常流行的一个自动化引擎，擅长处理自动化流程，支持各种服务及工具的自动化与集成。可以轻松的实现故障诊断和自动修复。因此利用ST2来实现故障自动诊断和修复应该是非常不错的选择。
那么，ST2到底是什么，能做什么，为什么可以应用到故障智能诊断中。下面做简单介绍。
ST2是什么
官方定义：
StackStorm is a platform for integration and automationacross services and tools. It ties together your existing infrastructure andapplication environment so you can more easily automate that environment. Ithas a particular focus on taking actions in response to events.
简单来说：StackStorm是一个事件驱动的自动化引擎。
ST2优势
携程之前使用最多的工作流平台是BMC的产品Remedy。Remedy同样是一个使用范围广泛的自动化工作流引擎。和Remedy这种比较庞大的工作流平台相比，ST2有以下优势：
• 开源，StackStorm Exchange提供了各种各样的Pack，只要进行简单的Pack安装后就可以使用。
• 对DevOPS友好，ST2的Action支持任何形式的编程语言，如：Python，Java等，用简单的标记语言定义流程，如：yaml，简单易上手。
• 活跃的用户群，很多大公司（如：Netflix，AMAZON ）都在使用StackStorm
• 平台，可以给我们提供非常有价值的参考。
• 更擅长自动化，故障诊断，自动修复等场景
• 相比Remedy复杂的集群部署配置，ST2的集群配置要简单得多
ST2运行机制
ST2运行机制 (官方)
ST2运行机制（简单理解）
Sensor接收或者监听外部Events，触发Triggers，映射到Rules，在Rules中判断是否满足Criteria，满足则运行具体的Workflow
实施过程
对ST2有了初步了解以后，我们来看下ST2如何应用到故障自动诊断流程中。
ST2故障自动诊断流程实现
通过Sensor监听吐到告警系统中的告警，通过不同的Rule将告警分发到不同的Workflow进行处理
告警系统中包含多个系统（如：ITSM，CMS，…）的告警，ST2的Sensor会定期拉取告警系统中的告警信息，进行初步处理后，分发到Rules，每个Rule会根据配置的Criteria，判断是否符合触发该Rule的条件，如果符合则执行Rule对应的Workflow，否则结束。
ST2故障自动诊断流程优势
ST2故障自动诊断流程解决了以往排障遇到的问题，告警得到及时响应，同时自动化流程解放了人力，大部分误报的请求被自动处理掉，对于无法自动处理的告警，也可以进行初步的分析，将分析结果以邮件等形式反馈给运维人员，节省人工检查的时间。自动化流程也避免了人为错误的引入。
除此之外，利用ST2实现自动诊断流程也有它自身的优势：
1) ST2通过统一的Sensor将告警预处理并分发到Rules，不同系统的Rule根据条件触发自动诊断流程。不同系统的告警诊断互不干扰，Rules之间，Workflows之间相对独立，可以很好的支持横向扩展。
2) Pack共享，减少重复代码
3) 自动诊断流程可以灵活的定义流程中的Action，方便系统告警的扩展
4) 告警处理过程被系统记录，有利于后期查找分析
ST2故障自动诊断流程实例
ITSM告警自动诊断Workflow
ITSM告警自动诊断Workflow实例
成果和小结
正确的思路+正确的工具=预期的结果。有了ST2自动诊断流程之后，我们将告警的发出，记录，诊断，报表各环节全部打通，形成闭环，成为一套完整的告警自动诊断解决方案。
通过ST2自动诊断流程，经过告警自动诊断，告警结果回写到告警系统中，得出的报表前后对比数据如下：
ST2自动诊断前
ST2自动诊断后
经过对ST2实现故障自动诊断功能的初步尝试，ST2初露锋芒，给我们带来的收益也显而易见。
有了这第一阶段的实践和成果，我们有更多的信心和经验来展望下一步：
• 将更多告警自动诊断接入ST2
• 紧接自动诊断，将故障自动修复流程也加入ST2
• 针对经常发生的故障做进一步的根因分析
原文来自:携程技术保障中心