互联金融的理念日益发展，传统金融IT对业务功能需求的持续快捷交付，运维资源有限的情况下，唯有不断使运维工具化与自动化，才能实现应用从研发平滑对接到生产，同时运维保障能力也已经同步就绪。作为此项工作其中最重要的一环是，研发与运维共同完成非功能需求的方案并落地。 演讲提纲： 1、传统金融IT非功能需求局限性； 2、互联金融下非功能需求的演变； 3、非功能需求平台实践方案； 4、 高效运维工作思路实践方案。 运维自动化程度取决与非功能需求的实现深度！

前言

本文根据招商银行数据中心应用管理负责人张建林，在GOPS2017·深圳站演讲整理而成，文章共分为五个小议题：

传统金融IT应用运维痛点分析

思想的碰撞

困局之下如何求变

成果初现

自动化运维之路

1、传统金融IT应用运维痛点分析
可能大家都知道, 传统金融遇到了一个瓶颈，而互联网金融给我们带来很大冲击。传统金融应用运维的发展趋势是，系统规模越来越复杂，组件越来越多，用户的流量不断上升，事件变更各指标较以往而言不是量级增长，而几乎都是呈非线性增长。

传统运维模式带来的成本消耗比较大，已经不能很好地应对非线性增长的系统规模和流量。解决的方法是要做好传统金融业务的主机下移，与做好应用全流程运维的标准化管控。那么我们需要如何应对这方面的需求呢？接下来，我们针对传统金融的痛点做分析。

通过对传统金融的痛点做分析，可以发现“非功能”是根本原因。因为要针对目前系统运维成本和流量接入，我们一定要做到应用运维全自动化才能应对目前的现状。

当前运维环境下，非功能引起的事件比较多，我们拿招行2016年的生产事件做分析，可以发现与非功能相关的事件占比将近三成。无论是从应对自动化的需求、接入的需求、传统的可用性要求、还是变革的期望，我们对于非功能的需求越来越强烈。

2、思想碰撞

面对我们当前的痛点，我们怎么做思想碰撞呢？首先，传统金融IT的模式中，开发与运维是割裂的，开发对运维基本上是“甩包袱”的形式。

其实，流程和自动化并不矛盾，但是我们如何做到开发和运维优雅的结合呢？招行采取的方式是围绕运维自动化去做。通过非功能的落地、运维系统的规范标准化，并通过规范制定自动化的工具，再结合现在的流程，形成迭代的完善，最终达成运维自动化的目的。

这可能是现在比较流行的 DevOps 的思想。DevOps 和 SRE 的理念会有些许冲突，但整体思路是一致的，都是加强开发和运维之间的配合。DevOps 可能更侧重开发层面将自动化的理念推送给运维，而SRE 的理念则侧重于运维人员角度，它的理念是运维的自我研发，我们运维怎么去开发出适合我们工具，通过工具来进行日常运维的工作。

目前，招行已经将以上两个理念都承接到现在的运维工作中，招行对运维的管理已经做了一套流程，固定了由 DevOps 理念形成的、适用于招行的一套持续交付的流水线平台。

接下来是优化现有开发模式和现有产品架构，消除流水线流动障碍。构建轻开发测试的发布流程，做到发布全生命周期的自动化。

3、困局之下如何求变

在当前流行的 SRE和 DevOps 上，我们如何融合他们之间的差异点，选择适合我们招行的解决方案，是一个关键。这两个理念不冲突的是持续迭代的交付，也是我们一定要做到的关键点：承接开发给我们的产品发布和如何运维好这些交付的产品。

3.1 以非功能管理为抓手的应用运维持续改进

我们如何能快速做到这一点呢？首要任务是做到产品发布的自动化。而支撑自动化的基础，则是一定要有一个非功能管理的运维工具，并对其持续改进。

所以我们的做法是，先要对产品规范的制定，再有架构能力的提升，接上流程管控，运维工具的自动接管，还有运营数据的分析和挖掘，并形成持续改进的循环。这就是我们以非功能管理为抓手，推动应用运维的持续改进和自动化的改进的方式。

3.2 非功能矩阵

讲到具体的落地，首先讲讲非功能管理规范中的非功能的矩阵。

首先我们运维需要面对的是一个多且杂的庞大的系统体系。面对这种情况，我们对招行的系统进行了归类，针对不同的部署平台和应用场景进行分解和剖析。梳理出针对不同部署平台、应用场景适用的非功能矩阵。归类情况如下：

1. 应用场景：针对招行现有的架构，结合招行对非功能要求，对应用场景，我们做了如下的分类：

前端应用

后端应用

联机事务处理

联机分析处理

2. 部署平台：招行的产品部署平台包括390、AS400、以及开放平台，而开放平台是未来发展的主流。

3. 非功能指标：同样，我们对招行系统进行分类的同时，为了方便对非功能指标的维护、管理及更新，我们也对非功能指标以及其验收方式也进行了梳理和规范。

可用性：我们对产品的高可用和数据备份管理提出明确的要求，保证各产品上线后的稳定和持续运行。

可维护性：对于产品的可维护性，我们提出提升进程自愈管理能力、加强日志管理能力、强化进程维护和柔性功能，提升业务指标监控和探测能力。

容量规划：对每个产品，我们都会对业务容量做提前规划与度量，固化应用性能评估，明确要求数据归档策略。

技术规范：对产品要有明确后台跑批任务管理办法，规范应用部署路径和日志格式标准化的管理，明确运维文档的要求。

4. 验收方式：以前对一些非功能需求的提出，比较少，并且落地验收更少之又少，为了非功能指标的落地，我们对非功能指标的验收方式进行的分类，按照不同的指标采用不同的验收方式进行落地的验收：

测试验收

数据的交叉检验

自动化工具的验收

人工验收

3.3 非功能公共技术组件库

有了产品的非功能规范后，对于招行的产品所采用的不同的技术、不同的框架和不同的部署平台，我们应当如何实现非功能的统一管理？我们做成了非功能技术组件库，直观看起来似乎比较复杂。

先从资源层看起。目前招行所有系统是以单个系统为单位进行切割，而我们则以部室为单位进行切割。

基于资源上的应用，我们怎么把它真正落地到运维的自动化呢？通过将非功能公共组件、技术组件做成抓手，我们从资源层里面提取公共组件的数据，比如安全、日志、消息、数据访问、缓存、文件管理的公共数据。

除了公共数据之外，我们提出了标准化的非功能技术组件库，这个组件库是一个以我们非功能规范作为的技术标准，跟其他平台适配的API公共组件，供开发调用。该组件库适配各种开发语言、框架和平台，可以使开发人员更专注业务功能的实现。这样就实现了以非功能公共组件推动业务功能开发的效果。

完成了 API 的开发之后，研发中心还提出刚才讲的性能容量和应用架构改进的诉求，但是招行现有系统中存在各种各样的业务组件，这就要求我们的 API、以及我们的应用要做到对高可用、性能容量有一个自我探测的功能。

我们做完非功能组件之后，就是我们运维接管的事情了。我们的目的是为了运维的自动化，所以首先要做就是自动化平台的整合及开发，这就要求我们的平台有自动化发布、一体化监控、API 网关、数据平台、作业平台、管控平台等功能。我们的自动化平台对运维的工作进行了整合。

以往运维涉及的自动化平台太多，我们没有办法将他们之间割裂的部分逐一统一起来。现在，我们有了非功能组件，通过非功能组件，我们能把底层的资源、开发的规范和对高可用的应用诉求都在公共组件里面集中实现并通过它来协助我们的自动化平台对运维工作进行整合。

当实现之后，我们怎么知道开发所交付的产品确实能做到自愈或者满足我们的非功能要求呢？这就要求我们做到应用全流程的监控。

我们的做法是采用探针式应用全流程的监控，上面是用户的公共接口，用户通过客户端的公共接口访问我们的服务器，通过我们的探针，将用户的行为及应用的处理等信息收集起来。

在自动化平台中，我们将会对这些信息进行监控及分析，确保我们开发所交付的产品符合我们的非功能要求。而核心就是我们的统一组件库。

3.4 应用框架设计优化

在架构的实现上，我们大体上参考了架构优化的精髓，这里提出来的，主要是架构设计的理念。

首先考虑市场响应，将构建小、发布快、实效小做为考量依据；

其次是成本，站在成本方面考虑，一般情况下，我们都会使用较为成熟的技术，对于非核心的产品，对于不是我们最擅长的，也提供不了差异化的竞争优势的产品，则直接购买；对于我们所使用的商品化的硬件，我们的原则是在大多数情况下，便宜的就是最好的；

三是产品的非功能性，产品的非功能性我们主要关注产品的可用性、可扩展性、可维护性等质量指标。

综合这三方面的考虑出发，我们就很容易得到了我们对应用框架设计优化的基本参考原则：

N+1设计：永远不少于两个服务器（互为主备）

回滚设计：确保系统可以回滚到以前发布的任何版本

禁用设计：能够关闭任何发布的功能

监控设计：在设计阶段就必须考虑监控

多活中心：不要被一个数据中心的解决方案限制住

使用成熟的技术：只用确实好的技术

异步设计：只有在绝对必要的时候才进行同步调用

无状态系统：只有确实需要的时候，才使用状态

水平扩展：永远不要依赖更大、更快的系统

设计至少要有两个步骤的前瞻性：在扩展性问题发生前考虑好下一步的行动计划

非核心则购买：如果不是你最擅长的，也提供不了差异化的竞争优势则直接购买

使用商品化硬件：在大多数情况下，便宜的是最好的

小构建，小发布，快试错：不断迭代

故障隔离：实现故障隔离设计，通过断路保护避免故障传播和交叉影响

自动化：如果机器可以做，就不要依赖于人

3.5 性能容量动态扩容

接下来，说到性能容量扩展。我们怎么做应用性能容量扩展？这里我们以 AKF 扩展立体方理论为基础参考，划分 XYZ 轴。我们传统的是通过Y轴的扩展复制，但这并不能满足我们对性能容量的扩展需求。所以，我们根据客户的数量、应用的组件库还有客户层面不同，我们针对性做了三种不同的扩容方式。

从应用层面上来看，无论针对应用做怎样的扩展，基本上都是按照这个理念做。

X轴：应用无差别复制、克隆。例如：我们会部署N台同样的应用服务器，我们采取这种策略来应对应用服务器不断攀升的压力。

Y轴：根据功能分割。这是因为很多应用功能所消耗的资源以及交易高峰并发时间都不是统一的，有些功能消耗资源较大，有些功能资源消耗就相当少，而且这些功能都是可以独立出来的，例如用户信息维护功能和用户的交易功能。

如果仅仅是对服务器无差别复制和克隆，可能对运维瓶颈没有突破，或者说成本相当高。这就是我们根据功能对服务器进行分割方式，基本原则是针对不同的交易类型就通过不同的服务器处理，以此达到对性能提升的扩容目的。

Z轴：根据客户分割。如果只按应用功能跟服务器数量方面进行扩容的话，不同地域的客户数量和访问速度都存在很大的差异，故面对不同地域的服务器压力也会存在差异，所以我们在应用层面还必须按不同地域的接入量来做性能容量的切割，比如对南方接入、北方接入的客户进行分割。

我们对应用层面对服务器进行分割的同时，为了使服务器性能达到进一步的提升，还在数据层面进行了进一步的优化。

数据分割与应用分割差不多，但也有差异。

X轴：无差别复制和克隆。主要体现为读写分离的数据库架构对于不同业务功能分别访问不同的服务器，达到对数据库压力的分摊。

Y轴：根据功能分割。体现为根据交易数据库和日志库数据分离，提高交易响应时间。

Z轴：根据客户分割。通过做分库分表的架构，按客户某一特征进行取模或哈希来分配不同的数据库，从而降低数据库服务器的压力，从而让客户有更好的体验。

3.6 非功能流程管控

怎么做好管控？

运维在项目立项阶段就开始介入非功能管控的设计。通过和项目室对接，和开发需求对接，在项目立项开始阶段，我们已经介入一些非功能的设计和诉求的提出，以保证开发及项目室和运维是同步的，达成无缝隙对接。

我们做的所有非功能，最终目标都是运维自动化。所以我们除了原流程上的功能开发和 ST/UAT 测试验收外，我们还增加了对产品非功能的开发，非功能的测试和验收，以及运维自动化模块的集成。

我们提出这些非功能的诉求，无外乎是为了开发能按照我们的公共接口、公共组件进行开发，并根据我们的性能容量的框架要求，以及自动化平台的要求做好产品开发，做到开发工作和我们运维工作的无缝对接。

所以在基本诉求提出之后，运维就要和开发一起进行评估、立项，乃至最后开发。开发完之后，我们将对开发的非功能进行测试和验收，并与自动化平台进行对接。只有在测试结果满足运维对非功能的要求时，才允许它投产上线。这不仅为了让产品在上线后持续稳定地运行提供更好的保障。更为了后续实现运维自动化打好基础。

产品投产上线后，我们还将对产品进行持续的跟进以及评估，对应用质量做事件回顾，以此来发现我们设计的非功能和开发开出来的非功能对自动化运维和生产事件存在的缺陷及问题，我们后续需要针对这些缺陷和问题，对产品进行重新优化和设计。这是我们对产品从开发到上线的非功能过程的管控方法。

3.7 自动化工具平台

非功能管控我们做运维工具自动对接，自动化平台怎么具体落地？

自动化工具平台，基本上接管了整个数据中心，从开发到测试之后到我们运维阶段的全流程管理，面向业务支撑全生命周期自动化接管了。

自动化接管包含什么呢？包括上线扩容、发布、日常运维、服务请求、下线、故障处理，都需要做到统一的平台里去。我们的目的是为了保持传统运维模式的安全的同时，达成具备自我设计、自我修复能力的数据中心。我们的框架和实现理念已经落地，这就为做实现全自动化运维的数据中心打好了基础。

自动化平台的设计理念：

以全生命周期情景，梳理出具体的自动化需求。我们会根据各个业务品种做自动化的诉求，比如网银、手机银行等等。

基于API网关中的API基础服务，按照需求完成运维管理平台，支撑全生命周期自动化管理。

如果这个平台支撑它的管理之后，但是我们的工具平台的引擎、数据怎么做呢？我们会有一个API网关还有流程总线，会把它快速提升自动化应用。

根据API规范，将功能和服务封装成为标准API。在我们讲的数据源里面做真正数据源的汇总，最后支撑自动化的应用。

这是我们自动化运维平台的设计理念。

3.8 应用全流量监控

自动化运维设计之后，还有应用全流程监控。自动化发布之后我们怎么做运维呢？图中就是现在的自动化的监控，我们通过它对目前产品的非功能还有运维、应用质量做实时监控。我们会做到节点上线即刻监控，我们将通过NPM节点连接质量监控对Web端到中间件、再到应用服务器、到最后的数据库等等（包括中间的各个节点）进行全解码的监控，基本上所有业务流、业务性能容量和真正的交付都做了第一线监控和实时展示。

3.9 性能容量预测

最后是性能容量的预测，也就是运维数据的分析和挖掘。我们会把性能数据和价格数据统一收集到一个数据解析中，并且将相关的依赖关系、配置信息、每个服务器需求的数据资源预测数据等集中到大数据平台之后，通过求解器，结合容量算法、资源供给、资源价格及分配计划，形成一个算法。

这个算法是通过性能的实时参数、业务增长趋势的函数、性能容量预测等方面进行实现。我们通过该算法，能得到诸如连接、响应时间、趋势分析、CPU 内存、硬盘使用率等方面的趋势分析。现在，我们能做到所有应用节点的性能容量实时的展示，并且能做到实时的数据分析。

这样的好处是，我们不需要通过压测以及烦琐的数据收集、大数据分析，基本上通过全自动化就能自动出现性能的趋势图和后续分配计划匹配。

4、成果初现

我们逐步深化非功能的管理，我们管理的流程给大家分享一下。

我们的非功能管理平台已经搭建起来，这是由运维先提出的非功能规范。这是针对开发的所提出来的，因为传统的开发都比较关注功能的实现。而我们的要求是，开发一定要将功能和非功能同等看待。

首先我们会通过应用非功能管理平台对产品提出非功能的规范和需求。接下来，我们的开发将对其进行开发，通过非功能测试及验收，完成最终的版本确认。最后，把已具备非功能要求的产品与自动化的工具平台对接，落地自动化工具之后，最后自动化平台将自动对产品进行上线投产，再完成上线验收。

开发是否完全按照我们的诉求做研发呢？最后是否真正落地运维的自动化呢？这就要依赖于投产之后的验收，以及后续不断的迭代循环。

基于 Profile 的应用标准化管理。在这里我们可以通过应用系统视角，描述应用系统里面的产品编号、名称、人员、管理员、组件还有程序等之间的关联关系，详细记载应用各项非功能属性信息。在把应用非功能属性标准化之后，开发发布过来的应用，数据都是完整的，我们做后续的管理和台帐或变更，都能很容易达成自动化管控。

有了标准化数据之后，图片上的功能都可以做到自动化实现，并且做到自动化的应用画像，可以清晰地知道应用流到底怎么走。

我们还会对一级环境和二级环境环境进行自动化的验证，也就是大家常说的试运行和灰度环境，我们从灰度环境到生产环境，会不断做两个版本之间的验证，并且我们的验收是通过自动化的方式进行验收的。

所有产品在投产之后，还要做节点的监控，确认刚才所说落地的东西已经真的已经达到了我们的要求，这就要求我们在变更之后的对产品进行全自动化监控。我们会有一个算法，即对比运算模块（核心是基线、阀值），这是一个自我学习的验证模块，也是验证的核心。

我们核心模块怎么完善？我们会对原节点的数据和外部节点的数据、原始节点数据反复对比，最后到运算模块之后，从对比里面可以发现一些流量中不存在或者节点属性关系缺失的，我们可以对缺失信息去协调数据的进项，完善应用模块，并且在已知节点的对比，发现节点访问关系变更，包括新增、消失、访问关系变更，我们都会做自动更新，我们通过这个实时监测运维所监管的所有应用的健康状况，还有非功能的运维状况，还有所有自动化发布或者自动化运维工具的现状。

5、自动化运维之路

刚才讲到所有的非功能实现的理念，无论是框架、架构、性能容量还有监控还有发布、自动化，我们最终都是为了自动化运维。

自动化运维即是最终的目标。以前的传统模式下，需要做应用需求、资源准备、环境构建、公共组建、日志追溯、应用开发、代码部署、监控告警等工作。我们在做非功能时，把这些全部集中在一个模块，即都在非功能公共组件里面实现，应用需求提出之后，我们就把它集成到这个平台里。

将公共组件和自动化平台对接后，就实现所有资源准备、环境准备等等方面的全自动化，所以现在基于招行所推崇的 SRE 的开发模式，就是我们运维和开发一起完善功能和非功能的需求整理。

需求完善之后，就根据我们公共模块的要求规范做开发。开发之后，后续所有传统的模式下的工作，我们都可以一键式交给自动化发布平台，自动化运维就实现了。自动化运维代替了以前分布式的所有工作，包括资源准备、环境构建、组件的升级、日常的监控、日志的管理等。这是招行的自动化理念。

6、总结

我们有了自动化理念，并实现了所有自动化理念后。我们的工作重点，就从传统的金融IT模式转变为以非功能模块作为核心、作为抓手的自动化运维模式。

从功能需求开始，与开发共同参与产品非功能设计，并且在非功能公共模块里支持和推动开发立项，并不断完善自动化工具的集成，完成运维对自动化所有的诉求。

我们将所有自动化运维的诉求都提出来，统一监管 API，并且将接口提供给开发。开发完毕之后，我们对产品非功能进行验收和投产后评估等工作就可以和自动化平台进行无缝对接。当把所有整套流程运作完成之后，我们就真正能实现运维工具的自动化集成，做到真正的运维的自动化。

这是我们今天讲的主要议题，即传统金融IT怎么应对现代日益增长的运维瓶颈，怎么解决诉求和应用的扩展。通过非功能的推动，达到自动化真正的落地，做到传统金融非功能工作的重心转变。