一切以可用性为中心！大型券商业务数字化转型路上的技术运营实践

说明：本文为国信证券系统运行部蔡华老师在 GOPS 全球运维大会 2020 · 上海站分享。

蔡华，国信证券系统运行部运维专家，十余年运维经验，曾就职于腾讯科技负责微信支付和红包的运维工作，现就职于国信证券负责电商系统的运维工作。

大家好，很荣幸的参加了GOPS大会，今天我给大家分享下国信证券的技术运营体系的建设。

首先做一个简单的自我介绍，我叫蔡华，专注于运维领域10年+，来国信之前，在腾讯待了8年，主要是负责腾讯金融，微信支付的运维工作，目前在国信证券的系统运行部，负责电商系统的运维。

今天我分享的内容主要有四大块：

• 金太阳手机APP介绍。

• 券商运维的挑战。

• 技术运营体系建设工作。

• 对技术运维体系未来思考。

一、金太阳 APP 介绍

金太阳手机APP是国信证券自主研发的一款集行情，交易，理财于一体的金融投资理财软件。目前金太阳手机证券注册用户数超过1400万，日活超过120万，证券客户数超过800万，委托交易占比超过整个国信的交易总量的80%，已成为公司最重要交易渠道。

针对金太阳手机APP，一年有3000+的变更，350多个系统组件，整体系统是两地三中心部署，有阿里云，微软云，亚马逊云，上证云等多个云。

金太阳 APP 虽然只是一个小小的 APP，但是他覆盖了大部分国信的业务，包括港股交易，沪深交易，行情，自选股，产业链图谱，业务办理，开户，智能盯盘，期权，理财，机构开户等大大小小几十个业务。

金太阳 APP 虽然只是一个小小的 APP，但是他覆盖了大部分国信的业务，包括港股交易，沪深交易，行情，自选股，产业链图谱，业务办理，开户，智能盯盘，期权，理财，机构开户等大大小小几十个业务。

二、运维挑战

对于券商业务来说主要有以下的运维难点；

行情波动频繁：行情波动没有规律，突发性大，不知道啥时候川建国同志发布个消息，就有可能带动一波行情。不像微信红包都是在固定的日子才会有流量的突发，例如 520 ，214，元旦，春节这种都可以很好的预测，但是我们券商业务是没有办法预测。

业务系统复杂：各种业务系统非常多，大部分业务系统都自带监控，发布等工具，导致工具平台众多；单业务架构复杂，涉及子系统多，同一个业务链上，多种架构并存，与不同机构系统对接多。

故障分析定位困难：故障定位一直是运维最大的痛点难点，在故障定位中主要存在系统分散，数据分散，工具分散，链路长等问题导致故障分析定位难。

监管严格：整个券商业务都是涉及资金的交易，不能出现任何差错，对稳定性要求高。当出现问题的时候会引起客户的投诉和索赔。运维权限大，责任高，如果是运维原因导致的故障会有严格的问责机制。

整个行业对金融科技越来越重视。为了满足数字化转型的需要架构面临着微服务的改造压力，在微服务的改造过程中会长期保持着老系统，导致新老系统相互交织耦合，加大了运维的难度。业务开始实行快速迭代，小步快跑的开发模式，版本发布越来越频繁，对版本的交付时效也要求越来越高。大量新系统上线，每个系统开发商不一样，系统架构多样化，导致运维的难度成几何上升。

三、技术运营体系建设

在种种困难和挑战下，对于我们的技术运营体系要求越来越高，下面介绍下国信技术运营体系建设。

从分工来看开发主要负责程序的业务逻辑，架构优化，性能优化等内容。运维需要负责IaaS 层如网络，存储，服务器，虚拟化；PaaS 层的基础组件/框架，操作系统；最后要负责业务的部署和保障业务的可用性，我们不生产代码，我们是代码的搬运工。

运维最重要的是保障业务的可用性。从性能，安全，效率，变更，容灾，持续交付，故障处理，容量等各个方便来保障业务的稳定性和可用性。一切以可用性为中心进行运维。

针对可用性这个目标，我们分析了技术运营体系的痛点，总结出来以下四个主要矛盾。

3.1 配置信息不准确

第一个主要矛盾是 CMDB 信息更新不准确，运维系统规划和建设碎片化，没有以 CMDB 为基础构建。

基础资源数据依赖 Excel 表格维护，运动式人工管理。数据中心过去以基础设施资源管理为主，忽视了上层应用的管理能力。资源维护自动发现能力严重匮乏，维护成本高、效率低。运维系统规划和建设碎片，没有以 CMDB 为基础构建。

线上操作不规范，数据录入不规范，系统问题等各种原因导致 CMDB 信息不准确。CMDB 是我们技术运营体系中的基石，CMDB 的数据准确性非常重要，尤其对接自动化之后，任何的数据异常都有可能造成重大的运维事故。

为此我们启动了 CMDB 准确性的项目，从流程上规范手工录入，减少手工录入出现错误。实时的采集机器信息更新数据，以 CMDB 为源定期和 ITIL，基础监控，昆仑大数据监控，集中事件平台，持续发布平台，容量系统，云管平台等周边系统进行数据核对，多平台的交叉对比，事后策略扫描。多种维度来保证 CMDB 信息的准确性。

这个图是我们 CMDB 的架构：

资源生命周期管理主要是对服务器，IP地址，基础资源，应用资源的生命周期管理。

逻辑层主要有模型管理，基础设施对象管理，PaaS 对象管理和应用管理。

针对公有云，私有云，服务器，网络等基础资源信息，提供了自动采集和数据校验程序定时的采集更新。

下面是国信基于磐石的 DevOps 运维整体架构图。

通过云管平台实现自动化的装机，资产管理等工作。通过运维自动化平台和持续交付平台实现对资源交付，和应用交付的自动化部署能力。大数据平台通过采集应用和系统的日志并且联动 CMDB 进行管理，最后由集中事件平台和统一告警渠道进行监控告警。这些各个运维能力都抽象出统一的API接口暴露给最上层的统一运维服务门户进行管理。

整体的技术运营体系以 CMDB 为核心基础平台，打通自动化、监控、安全等各种运维平台的能力。打通资源交付和应用交付的自动化能力。以 CMDB 为基础，建设统一事件平台、运维大数据平台、混合云管平台、自动化装机平台和运行监控系统，加强数据消费场景。

3.2 标准化不到位

针对标准化主要有以下的问题，大量人工发布容易导致误操作，版本部署的效率非常低下，部署未标准化，业务环境复杂，同一个组件不同的机器配置都不一样，只有运维负责人才了解具体的部署细节，当运维负责人休假的时候，其他人员没有办法很好的顶替其工作。

对于故障来说，大部分的故障都是发布变更导致，对于我们持续发布平台来说最主要的目标是使变更可控、快速，安全，并减少变更对业务可用性的影响；可控主要体现在：流程可控：所有版本都通过ITIL流程平台进行流程管控；版本可控：版本从开发测试到生产统一制品库，避免人为操作；配置可控：通过动态配置功能，针对不同环境，不同集群生成对应的配置，让配置集中管理；回退可控：通过持续发布平台实现版本快速安全的回退。

标准化是我们持续发布平台最主要解决的问题。针对标准化的建设主要分为4个方面：

• 交付标准：目录标准化，应用配置规范，版本控制&全量交付，    文件格式和编码规范

• 部署标准：固化部署步骤，启停脚本规范，验证脚本规范，部署规范检查

• 厂商应用接入标准：程序目录标准化，数据和日志目录分离，版本控制&全量交付，启停和验证脚本

• 数据库脚本标准：版本控制，SQL语句规范，变更操作规范，备份/变更/检查规范

针对应用的交付，先由开发进行持续集成之后，系统把程序推送到测试制品库，由测试人员在开发测试环境进行部署和验证，如果验证没有问题就通过平台进行流转到生产环境，在流转过程中会进行内外网的交换，并且进行安全扫描，确定没有问题之后同步生产制品库。然后由运维人员进行发布部署，首先进行预发环境的发布和验证，然后进行生产环境的灰度发布和验证。

制品库管理是整个持续发布平台的核心，制品库主要功能是管理程序，配置和部署脚本。根据不同环境，测试，预发，生产等进行版本管理。我们使用统一制品库，解决制品分散存储，管理困难的问题；版本统一管理；配置统一管理：通过分离配置项和配置值，解决同一集群不同机器配置不同的问题；

交付流水线主要分为5个阶段，第一阶段构建入库：统一通过 Jenkins 构建，第二个是合规检查：包括版本号检查，配置变更检查，组件规范检查。测试环境发布，测试结果入库，最后通过安渡杀毒、校验转生产。整个流水线过程中制品只有一个生产源，制品消费过程中不能修改制品。

平台对应用部署提供标准化发布流程，例如：运维人员从平台选择主机，主机信息都是联动 CMDB。然后设置分批的策略，选择对应的程序版本和配置版本，确认清单，平台做发布前的检查，最后通过自动化平台进行，应用的下发，启停，检测等工作；

整个持续交付平台打通程序版本端对端的交付部署。从标准化建设，需求调研， 最后到平台功能落地与实施。完成了金太阳APP，金太阳PC版，期权系统，集中交易，集中运营等系统的接入，大大提高了运维的发布效率与安全。保证了业务的稳定与可用。

3.3 故障定位困难

第三个主要矛盾是券商业务的监控系统多，业务链路长，故障定位难。

故障处理的目标是降低客观因素对线上系统的影响，对已知故障尽量避免，自动或者快速切换实现，对未知故障，实现快速定位，一键切换；原则：先恢复业务，后分析问题。

整个故障处理可以分为5个阶段，第一个是故障预防，在这个阶段把一些可能故障情况尽可能掌握，针对性的优化和保障，把系统隐患提前暴露，并且扼杀在摇篮里。主要包括：灾备预案，容量管理，监控覆盖，持续交付，系统压测；

第二个是故障发现，故障是不可避免的，当时出现故障的时候我们需要尽快的知道故障出现了，故障影响如何，这个阶段主要包括监控告警，常规巡检，客户反馈等方式。

第三个是故障定位，当出现故障的时候需要快速的定位出来故障的原因，主要手段包括日志分析，监控分析，模调系统，根因分析；

第四个故障恢复，故障出现之后如何快速恢复业务是对运维的最大考验，这里主要包含版本回退，服务限流，降级，熔断，容灾切换等。最后一步是故障改进，故障恢复之后需要故障复盘，改进验收，并且持续运营，避免下次再出现类似的故障。

针对故障定位困难的问题，主要是要解决监控的问题。

监控系统多：券商业务很多系统都是采购的，各个厂商都带有自己的监控系统，再加上开源的监控工具就更加多，

体系化监控少：监控系统多，导致各个监控都独立，监控维度不足，业务缺少整体的体系化监控。

各个监控系统都有监控配置，很难全面的查看系统运行监控的，导致监控管理难。

监控告警缺失导致每次出现故障的时候定位困难，难以定位到根本原因，导致故障定位慢。

针对以上的监控问题，我们从以下 6 个方面来建设。

• 整合资源：整合各个厂商提供的监控系统，进行统一可视化。

• 日志管理：收集系统日志和业务日志，结合cmdb快速查询日志，统一日志转指标

• 指标与告警管理：多维度业务指标监控，包含请求，耗时，成功率等指标，包含系统，组件，主机等多种维度。根据业务指标，业务日志配置告警，支持动态波动，阈值，智能预测多种算法；

• 场景监控：提供快速业务场景定制能力，支持业务体系化配置监控视图；

• 容量管理：结合业务QPS，机器资源，网络带宽，业务压测数据多种维度数据进行容量的管理与预测；

• 调用链：结合微服务调用链进行故障快速定位。

下面可以看下昆仑运维大数据平台架构：最底层是我们的数据源层，包括我们网络，服务器系统日志，业务日志，CMDB，云管平台。

上面是我们逻辑层，主要有：

数据集成，数据存储，数据计算，数据服务，在这基础之上提供丰富的运维应用：包括业务全景监控，业务监控大屏，日志检索，调用链分析，告警管理，容量管理，资源监控。

所有的告警和事件都对接集中事件平台，进行告警的收敛，告警回顾，知识的沉淀，事件管理等。

整体架构就是以各个监控系统，业务日志，系统日志为数据源，通过大数据平台进行整合分析，统一的可视化，统一的事件管理。

下面可以看下昆仑运维大数据平台在国信运维生态系统中的位置。

对接各个监控系统，整合监控；采集应用日志和基础架构系统日志进行日志管理，输出数据去安全分析平台。基础信息对接CMDB。对接自动化平台。告警和事件对接集中事件平台。

下面昆仑大数据平台的一些例子：基于业务视角的系统全景视图。以业务为维度配置监控曲线。

针对场景监控我们配置了基于细分业务场景监控曲线，例如，风险分析类，故障排查类，性能优化类，趋势分析类，基于细分业务场景监控，实现效率提升和知识积累沉淀。

从系统层的业务拓扑，组件层的指标趋势，服务拓扑，主机层的监控告警，日志检索，再到基于调用链的快速故障定位。从看图，看数据，定位故障域，最后解决问题。

3.4 系统容量未知

第四个主要矛盾：运维对系统容量缺少一个准确的评估，当行情爆发的时候或者机房故障的时候心里没有底气，不确定系统容量是否满足。针对这个问题，我们觉得系统全链路的压测是很有必要的。

全链路压测总体目标是以金太阳手机系统为切入点，评估金太阳系统及其后端大集中交易系统的最大容量，以满足监管要求。把目标进行分解下。第一个评估金太阳手机系统的最大容量，为系统日常运行提供参考标准。第二个找出系统瓶颈，为扩容提供参考方向；第三个暴露系统在高并发场景下的缺陷，保障系统的稳定性运行；

在传统的测试方案中，压测是在配置较低的测试环境中进行和生产环境有差异，模拟用户行为数据 ，模拟用户访问模型，和真实用户数据有差异；测试程序包，测试应用配置和线上程序有差异，压测的场景单一只是针对单机单链路容量的测试；最后得出来的结果只能估算生产系统的容量，不能准确的评估生产容量。

为了能够准确的评估生产容量，我们采用生产环境或者等比例搭建的环境，使用真实的用户行为数据，真实的用户访问模型。使用生产一致的程序包和配置包，压测系统全链路。

基于日志回放的全链路容量测试方案；首先我们需要对压测数据进行构造，获取线上峰值时段的日志数据，然后做日志采集并且输送到大数据平台。根据日志数据做分析，计算出对应的数据模型。对日志数据进行筛选组装输入到基础数据池。压测程序根据数据模型和基础数据池获取数据，进行日志回放压测。压测程序对压测流量进行控制，通过压测引擎集群开始把请求发送到系统。

整体压测从互联网防火墙，硬件负载均衡，WAF，接入服务，API网关，微服务集群，中间件，集中交易，数据库，redis 缓存，全链路进行了压力测试。在压测过程中，我们可以在实时的在监控系统查看系统运行状态，包含基础资源监控，业务监控等。

整个压测过程我们实现了全流程的自动化。从模型分析，数据提取，测试脚本生成。再到流量动态调节，调用链分析，最后到结果入库。

性能测试全流程自动化，释放了我们压测时候的人力，目前我们预发环境按照生产环境1比4进行部署。预发环境每日进行压测，可以让我们及时知道业务版本对性能的影响，对于生产环境的压测我们基本每月进行一次线上压测，及时的对线上进行容量的准确评估。

四、未来思考

最后要分享的是对于未来的一些思考。对于未来主要是从以下四个方面去提升，继续提高运维的标准化，打造高效安全的自动化运维平台，全业务持续交付，建设全自动的流水线，去 Console 运维，提高运维的安全。建设容器化平台，提高我们系统部署速度和弹性伸缩的能力。

建设运维中台，开放运维中台场景化能力，运维可以基于运维中台对业务进行运维场景化丰富；最后一个是对日志和指标智能分析告警，结合调用链和应用拓扑进行智能故障定位，提高我们运维故障定位的能力。

以上是我今天的分享，谢谢大家。欢迎大家线下一起交流。

GOPS 全球运维大会 2021 · 深圳站，5月21日-22日

震撼来袭！中行、建行及证券名企金融数字化转型议题

就等你来！