携程运维工作流平台的演进之路.docxVIP

PAGE 1 PAGE 1 携程运维工作流平台的演进之路  随着互联网技术的快速发展，运维的事务也日益复杂，如何能更加高效的协调好人、工具与流程之间的关系，把运维人员从低效率、高强度、易犯错的人工操作彻底解放出来，让他们的能力与精力有更大程度的发挥，将是一个很大的挑战。  前言  随着互联网技术的快速发展，运维的事务也日益复杂，如何能更加高效的协调好人、工具与流程之间的关系，把运维人员从低效率、高强度、易犯错的人工操作彻底解放出来，让他们的能力与精力有更大程度的发挥，将是一个很大的挑战。  携程运维工作流平台在经过三年时间的演进，从最开始引入商业产品BMCRemedyARS做为底层单一工作流引擎，渐渐演化到抽象工作流平台的建设并扩展支持更多开源的工作流引擎，同时把原来的平台进一步分层、建立了统一标准的接口，对业务进行了服务标准化、业务流化以及流程自动化的改造。  本文将从以下几个主要方面分别阐述流程平台的建设与演进： 面临的挑战 运维工作流平台的建设  收获总结  下一代流程平台的设计  将来展望  一、面临的挑战  在讲挑战之前，我们先简洁看一下携程运维工作流平台的演进历史：  流程平台的演进主要分为以下三个阶段：  第一阶段：摸索期  从2013年下半年到2014年上半年，我们引入了BMCRemedyARS产品作为携程IT服务管理工具，但是我们发觉它的基于工作流工作的思路可以借鉴到更复杂和核心的运维流程中，所以开始尝试使用它的底层引擎构建我们自己的流程。  第二阶段：成熟期  在2014年下半年到2016年上半年，在Remedy平台上相继开发了一系列的流程，包括：服务器上线、下线，应用上线、下线、扩容、缩容、迁移等等，还包括ENP，APIgateway等一系列标准化的接口服务模块，开始慢慢形成流程平台。  第三阶段：革新升级期  在经过了一个成熟期之后，现有的流程也渐渐暴露出了一些新的问题，包括流程的可视化、价值数据的挖掘、底层流程引擎的单一，为了解决这些问题，我们从去年下半年开始，对原来的流程进行了重新设计，抽象出更加标准化的流程模型，以及标准规范的可视化和监控。  那么在没有流程平台之前，我们究竟面临着怎么样的挑战呢？  在这里我给大家举一些运维过程中常见例子，比如日常工作，当用户遇到问题时IT部门报障时，用户如何跟踪问题处理的进度，又或者当网站发生故障时，如何能够快速恢复服务，后续的问题分析是否有流程支持，运维人员的日常变更操作，是否有过风险评估以及审批授权，我们又是如何保障配置数据的牢靠、精确性，服务器如何上下线，应用生命周期有没有统一的管控，等等，正是在这样一个背景下，我们开始着手设计建设一个综合的工具平台来统一管理运维过程中涉及的这些流程。  二、工作流平台的建设  关于自动化流程平台建设，自动化的意义相信大家应当都是有共识的，在上面的挑战中我们已经提到了这些运维过程中大家可能会遇到的问题，那么我们是如何去建设这个流程平台的呢？  1、系统架构  我们先来看一下最初设计的流程平台系统架构  从下往上看主要有三层： 底层工作流引擎 前面我们已经提到了，在一开始，我们引了BMCRemedy产品主要作为内部IT服务管理流程的支持，在原有的ITSM包括事件、问题、变更以及恳求单基础上做了携程自己的一些客户化定制，同时在这个平台上设计开发了包括服务器上、下线，应用相关的上线、下线，扩容、缩容等支撑业务的相关流程。 中间接口网关层 在中间接口网关这层从左往后分别是OSG服务网关、ENP事件通知平台以及协助工具，为什么会有这样的设计呢，主要有以下几点考虑？  第一，外部工具服务过多，需要统一标准化管理  需要对流程接口服务进行标准统一的管理，全部工具供应的服务需要注册在平台；   随着互联网技术的快速发展，运维的事务也日益复杂，如何能更加高效的协调好人、工具与流程之间的关系，把运维人员从低效率、高强度、易犯错的人工操作彻底解放出来，让他们的能力与精力有更大程度的发挥，将是一个很大的挑战。  前言  随着互联网技术的快速发展，运维的事务也日益复杂，如何能更加高效的协调好人、工具与流程之间的关系，把运维人员从低效率、高强度、易犯错的人工操作彻底解放出来，让他们的能力与精力有更大程度的发挥，将是一个很大的挑战。  携程运维工作流平台在经过三年时间的演进，从最开始引入商业产品BMCR