证券公司运维（中国基金公司排名一览表）
证券公司运维（中国基金公司排名一览表）
红方的设计思路主要是制定完善的压测方案，最终实现流程自动化、工具平台化、制度常态化。
我们先看一下传统的压测方案是怎么做的，是以交易中间件为界限，分别对渠道接入系统和交易系统做性能测试，达到的结果作为我们应用部署上线的参考。
实践证明效果并不是很好，为什么？对证券交易系统来说，测试数据对结果的影响非常大的，持仓较少的散户与持仓多的机构客户在查询效率上差别非常大。不同登陆方式：资金登陆、股票登陆的调用路径也不一样。测试环境的机器大多采用的是低配的、单机部署。而监管机构对我们的要求是两地三中心的部署，跨中心、跨网络的测试环境无法完全模拟的。因此，在实验环境拿到的数据的参考价值并不大。这是交易系统每天的用户访问量曲线。这个曲线每天的形态非常类似，在开市期间会有2个小高峰，分别是早上开市后5分钟和下午闭市前5分钟，连续竞价开市9:30-9:45期间，往往是当天的*峰。右图是天猫双十一的用户访问流量曲线。两者非常相似。假如将阿里应对天猫双十一的核武器——全链路压测引入到券商核心业务系统来，效果会怎样？参考阿里应对天猫双十一的*实践，我们设计了基于流量回放的全链路压测方案，整个系统分为4大部分：
第一部分是全链路压测数据构造部分，基于大数据平台分析用户的分布情况，共同构成压测流量。
第二部分是压测集群，采用是两地三中心的部署架构，可以支持动态的横向扩展。
第三部分是应用系统，流量会从最外层的接入层进来，经过渠道接入部分、应用部分、交易中间件，最终到达集中交易后台，覆盖了前中后台的各个系统。
第四部分是监控系统，是基于现有的Prometheus和大数据平台，实现全方位立体化的监控。
在实施全链路之前，首先要保证流量能够顺利向下传递。我们在硬件层和应用层都有安全拦截策略。硬件层的拦截比较好处理，主要是用添加白名单的策略。应用层则需要做针对性的改造，在每个流量向下传递的过程都做了配置化改造。接下来我们依托运维自动化平台把流程串联起来，实现了环境准备、环境恢复、硬件检查的全自动化。我们的数据应该怎么构造，怎么才能更好的模拟生产环境的用户分布模型，怎么模拟高峰期用户的访问操作呢？有多少用户是在每天高峰期下单，进行交易登陆，有多少用户在查询行情呢？我们的方案是直接选用生产的数据来进行测试。
我们利用现有的运维大数据平台抽取数据，分析用户访问高峰的模型，利用生产运行真实用户数据分析，然后进行脱敏、订正之后导入构造压测数据池。
如何构造压力呢？在工具选型方面我们从五个纬度进行分析。首先是并发能力强，其次是要支持多协议，因为我们不仅有标准的HTTPS和HTTP协议，还有私有的TCP协议。同时必须有很强的扩展性，支持二次开发。为了在团队内进行顺利的推广，我们希望它有比较友好的界面，门槛低、上手简单、易推广。当然它能够开源免费，用比较低的成本获取，那是*的。根据监管要求，核心交易系统必须采用两地三中心的部署架构，因此我们的压测集群部署了对等的两地三中心，借助于容器化技术，可支持节点动态扩展。工具、数据、方案都准备就绪后，可以撸起袖子开工了。问题又来了，全链路压测的*实践对象是生产运行环境。如何保证压测期间的中间数据不会被用户看到？压测产生的脏数据如何与生产的数据隔离？互联网的方案是对压测流量做标识、改造中间件识别压测流量，利用影子库隔离脏数据。
券商系统涉及自研、外购，前后链路非常长，改造的难度非常大，而且必然会引入风险。稳字当头，注定了这个方案不可行。幸好，证券行业与互联网不同，它并不是7*24小时提供服务的。休市之后应用系统的流量就会大幅下降。我们在非交易时间利用网络隔离和数据库备份恢复策略来保障实施的安全性。
全链路压测方案在国信落地实施后，经过不断的演进，我们对工具进行了工程化，实现了容量测试全流程的自动化，环境准备可以按需弹性扩容，压测数据可以一键生成，压测流量可以动态调节，自动的进行结果分析和报表输出。做到全程0人工干预。自动化下一层是工具平台化，为了让我们的工具能够推广到更多的团队，实行了平台化处理。平台分为四大部分，最下面是应用系统，最上层是权限管控、数据报表展示，同时我们还与外部系统实现了对接和联动。
生产环境并不能每天都测试，所以我们按照生产环境等比例建设了预发环境，在预发环境里，我们会每天自动分析当天访问模型、抽取*的用户数据，对待发布的金太阳应用版本，进行全自动的容量压测，从而建立容量的变化基线，并进行容量预警。
蓝方的设计思路蓝军的防守策略主要从我们熟悉的故障预防、发现、定位、修复这4步开展。
故障预防方面，我们建设了全生命周期的容量管理。首先通过常态化压测容量基线更新，每天对容量做巡检，超过安全基准线进行告警。然后定期汇总容量告警，反馈给开发做持续的优化改进。在故障发现方面，我们建设了全面覆盖的监控体系，可以简单抽象成四层。在采集层我们采集了基础的资源监控指标，调用监控信息和日志信息统一发送到处理层，进行数据的落地。通过运维大数据平台和安全大数据平台进行聚合分析，发送告警到事件平台，使对应的人进行处理。最后对事件进行复盘回顾。
故障定位方面，我们实现从系统、组件、再到用户级别的,从立体到平面再到单点的层层递进式定位。首先对系统健康检查识别到请求量、错误率、时延的异常，接着下钻组件层，看到系统下各个组件各台机器的请求量、时延的异常，进而追溯到每个用户每笔交易的明细。
尽管我们做了充分的准备，但是依然可能会面临各种突发情况。假如用户的流量远高于我们的预估，出现了部分服务故障或者机器故障，我们应该怎么处理？扩容、降本是我们的手段。在业务限流方面，我们通过自研框架管理中心方面进行解决。在业务降级方面我们通过自研平台实现快速业务降级。
四、国信的建设成果下面我们看一下效果。全链路压测在每半年的生产演练和每月的灾备演练中使用。覆盖了10多个应用体系，上百个应用组件和上千个应用主机。通过系统调优，主数据中心每秒处理能力提升3倍。福田、金桥两大新数据中心性能分别提升了4.1倍和5倍，平稳度过了2020年的行情高峰。
这一路走来，我们对系统容量认知经过了四个阶段。第一是愚昧山峰，不知道自己不知道，容量不够，机器来凑。第二是绝望之谷，知道自己不知道，毫无头绪、惴惴不安。第三阶段是开悟之坡，思路清晰，了然于心，我们知道系统的瓶颈会在哪里。第四个阶段是平稳高原，我们在实战中沉淀宝贵的经验，对未来更胸有成竹：如何快速进行故障定位，怎样及时评估应用的变更对系统容量影响，容量优化的方向和思路。近期好文：阿里巴巴技术专家：大型团队如何从0到1自建SRE体系数据库之监控系统建设，看看运维团队是如何实现的“高效运维”*诚邀广大技术人员投稿，投稿邮箱：jiachen@greatops.net，或添加联系人微信：greatops1118.
