企业级应用的高可靠运维实践与DevOps（一）

很高兴今天有机会在这里与大家交流，也要感谢普元提供的交流平台和普元CTO焦总的邀请。我今天与大家分享的主题是关于企业级应用的可靠运维实践的这个话题。

本次交流的内容主要包括我对运维工作的认识、运维与架构、运维设计和持续改进的体验四个方面，最后是开个头，谈一下可靠运维与DevOps。

···

一、运营是一项以始为终的工作

首先谈一下我的观点，可靠的运维不能仅仅只是从具体运维工作开始，或者是系统发布开始。

我们认为，运维设计需从系统的规划设计就要开始，服务于企业发展的愿景，应围绕着企业和系统的运行要求而确定运维的要求和目标，进而进行运维的设计。只有从这里出发，运维人员才会对所维护的系统有一个正确的认识，才能够进行可靠的、恰当的运维设计。

不同企业不同系统，有着不同的运行要求，必然会产生不同的运维目标。以交易所的交易系统和客户管理系统为例，前者面向全国的投资者，交易期间出现任何运行问题都是不能容忍的，而后者是面向企业内部的业务管理人员。运行目标不同，使用对象不同，在运维目标上有着完全的要求，在系统的运维设计上必然有着较大的差异。

借助DevOps的开发与运维协作的理念，企业或系统的可靠运行，不仅仅是运维和开发人员的目标，更是需要从管理，需求，再到开发、测试，进而到运维，实际上有着共同的企业愿景和系统服务要求，这样才能达成一致的运维目标，和进行有效的系统运维。

很幸运，交易所的领导在很早之前就提出了“交易不断，数据不乱”的要求，从管理层、业务部门、技术部门在这一点上达成了共识，为后续的部门协作和可靠运维提供了基础。

···

二、运维与系统架构

传统的架构设计更多集中在满足功能需求、性能需求、系统开发的可维护性方面，而在系统运维方面投入较少，在一个项目实施过程中，我们多是看到业务人员、需求人员、设计人员、开发和测试人员，但是少见运维人员的身影。

外部IT实施的项目，往往也是以验收上线则项目结束标识，而上线对系统运维而言，则只是刚刚开始。所以，对于一个系统，要保证其可靠运维，上线后稳定运行，易于运行维护和监控，异常后快速排障，运维人员在前期架构阶段，即投入进来，将运维的目标和要求，线上实际的运行场景与环境提出来，这样才能为可靠运维打好坚实基础。

系统架构阶段的一小步，会带来运维改进的一大步。

从最简单的系统状态检查，在多系统场景下，想象下，如果在系统结构阶段缺少统一日志体系的规划，对于运维人员来说则可能造成巨大的困扰，会形成众多的case when a 系统 then loga，when b 系统 then logb的情况。如果进行了统一的日志规划设计，对系统状态的检查，则就是非常容易的一件事情了。

···

三、可靠的运维设计

前面简单讨论了我对运维工作，和运维与架构的认识，接下来主要谈一下运维设计的实践。主要从流程、多视角看系统、复核和核心运维能力四个方面进行介绍。

在运维流程初建过程中，参照ITIL的最佳实践，建立了事件管理、突发事件管理、问题管理和变更管理的流程，简单说明一下。

事件：与系统运行正常情况相背离的异常现象，通过巡检、操作、监控等发现，遵循全面记录和及时处理原则。

事故：导致或可能导致服务中断或服务质量下降的事件，遵循快速报告、快速处理和完整记录。

问题，为所有未知根本原因的事件、已经识别但没有修复的系统缺陷、通过风险分析发现的不能预防的技术风险。

变更，信息系统因业务需求变化、系统升级改造、系统优化、故障修复等原因，对信息系统的状态、配置、流程、操作方法及对应的例行操作手册的改变。

ITIL定义中强调了以上四项内容需要定义相应的流程进行管理，而在实践中，我们是将事件、突发事件、问题和变更4个流程统一驱动起来，各个环节的管理可以真正驱动起来，提升运维的质量。

下图说明了闭环管理之后事件、事故、问题和变更之间的流程转换，通过这个闭环的管理过程，做到杜绝同一性质事件问题的再次发生，这也是将4项进行闭环管理的根本目的。

事件/问题的处置通过变更进行，而变更后对事件的再次回顾、变更过程的总结和对变更后相关检查/监控等确认是闭环运维管理实现的重要方式。

变更准备阶段，业务系统为例，主要包括系统版本分析（基线版本对比）、关键代码比对、符合预期后版本部署测试、关键功能验证、历史数据反演测试、变更操作手册准备（变更操作步骤、变更配置变动信息、变更后验证、测试步骤、变更回退准备）等。

变更评审，则是邀请网络、主机、系统、数据库、应用系统的专家集中对变更的准备情况进行评审；涉及到多个变更，对变更的先后顺序、变更间的相互影响等进行建议。

变更，原则上只在变更窗口进行，对于国内交易所变更窗口则周三至周日，工作日在当日所有业务结束后。

变更后，由质控岗位进行变更系统、环境的配置进行比对验证，确保变更符合预期。

变更实施后，设置观察期，确保变更后系统正常，符合预期。观察期结束后，进行变更的总结和评估，主要是变更中的问题、预期外的行为进行总结，并更新到对应的系统的常见问题。

调研过国外的CME交易所，其变更过程更为严格，正式上线前，进行一到二次预上线，确保变更质量。

上图是对于系统变更的一个分类。

预授权类，也称标准变更，过程和操作可标准化的类型。在运维过程中，通过工具、手册等方式，将一些常规变更标准化，一方面优化此类变更的过程，提升效率和质量，另外一方面可以让核心运维人员从简单的变更中脱离出来。

常规变更，一般解决事件处置和版本上线等。其中不同级别，取决变更主体的保障级别和具体变更影响。根据变更级别不同，准备周期不同，评审级别不同。

常规变更，一般分为变更准备阶段、变更评审、变更、变更后测试、配置比对。关键应用系统变更，涉及到会员等，组织全市场测试。

为控制变更质量，二级以上系统包括核心业务功能变更，在变更准备阶段，必须进行代码评审确认和生产数据的反演比对测试，其中交易系统变更则更需要使用更长周期的历史数据进行反演比对；上线变更后组织市场会员的测试验证。

业务系统：关注当前和未来的业务实现，提供业务功能的灵活性；

我们认为可靠的运维设计，需要从多个视角设计所运营的业务，我们提出一套业务五套系统的理念。常规的业务系统解决业务实现的问题，而在业务需求和设计阶段，就需要业务稽核和数据稽核的角度设计稽核系统，保证上线运营后，从运维的视角校验和稽核数据的正确性。

稽核系统：关注当前业务，通过对当前业务分析，检查验证业务数据和勾稽关系的正确性；我们认为应该从业务系统的需求和设计阶段开始，就应该从业务稽核和数据稽核的角度设计稽核系统，以保证上线运营后，从运维的视角校验和稽核数据的正确性。

监控系统：对系统的运行状况、关键操作、日志报警等进行实时检查和报警；

冒烟系统：针对交易所业务的特点，基于次日的参数数据，进行次日业务的预运行，防范可能错误；这是我们特有的运维设计，不同于常见的测试系统，而是基于真实的生产参数数据和参与人数据等，对下一日的各种可能的交易场景验证，防范交易风险。

仿真系统是预研证的环境，系统正式上线前通过仿真环境的预先运行，对变更内容进行检查校验，规避可能发生的系统性缺陷。

可靠的运维设计，不能仅仅依赖系统，或是仅仅依赖运维人员。在我们的整个运维体系设计过程中，非常强调复核的概念，从一般日常操作的双人操作检查，到两重的监控系统，再到运维与质控人员的检查，处处体现着复核的理念。

为防范稽核或监控系统的错误，我们的稽核与监控系统对于关键检查点分别检查和监控，如巡检过程会对系统状态进行检查，而监控系统在正式业务开展前一段时间对系统状态再次验证，防范检查疏漏；

为什么提到多套监控体系那？为防范监控系统的缺陷，我们采用早期部署的简单监控和后期建设的统一监控平台互为验证。

运维人员的核心能力是需要在系统异常时能够在允许的最短时间内恢复系统的服务能力。而对于应急处置能力的提升我们有上图的过程，来推动运维人员的能力提升，掌握关键系统，重点是系统架构、关键模型、数据流、和代码，预设了应急场景、准备对应的手册和工具，并通过桌面推演和背靠背等方式进行演练，提升人员的核心能力。

基于快速应急处置的需要，保障人员需要具备核心系统和核心业务功能的代码评审确认能力。

···

四、持续改进是源动力

在整个运维体系的设计过程中，我们建立以下四项持续改进的管理流程：

1、事件、事故、问题、变更建立基本的持续改进闭环；

2、风险分析、应急演练、总结改进为风险防范的持续改进闭环；

3、培训、学习、演练、讲评为主的人员成长持续改进闭环；

4、以需求、设计、开发、运维打造一体化系统持续改进闭环。

以下是我们持续改进的一些成果：

1、日常运维手册：从最初的3页到现在的40多页的，将各个系统的操作进行规范化管理；

2、系统监控项目，从最初的hostmonitor的简单监控到使用专业的监控软件，实现了软硬件的一体化监控；

3、开发的运维需求和规范，则是从无到有，已有接近100项需求和运维规范要求。

···

五、未来的改进

最后谈一下关于运维在未来的一些改进方向：

1、记得几年之前，我们一直在强调运维前移，其实和今天DEVOPS强调的开发与运维协作的理念不谋而合。标准化、工具化和自动化，是优化和改进我们发布、上线、稽核和监控的必由之路。

2、“独乐乐不如众乐乐”，对于企业而言，存在着上游或下游，尤其是对于交易所而言，做好自身IT系统的开发维护对系统只是起步和基础。我们提出了大运维的理念，将可靠的运维推行到自己的业务部门和推广到行业的会员单位，只有当带动各个环节提升做好相关的维护工作，整体的运维能力才能得到更有效的提升。

今天的分享就到这里，下一阶段我将总结可靠运维与DEVOPS，希望有机会与大家再次交流，再次感谢大家的参与。

关于作者

于培言

现就职于中国金融期货交易所信息技术部，负责交易所系统规划和建设工作，主持参与了交易所的新一代业务系统、业务系统运维设计和大数据库建设等工作。东北大学硕士，曾就职于东方电子、复旦金仕达等企业，对系统运维、业务架构、数据规划和治理等领域有着丰富经验。