本文根据演讲者在 GOPS 2023·深圳站演讲整理而成，如有图文不妥，请以视频为准。更多精彩，请关注高效运维公众号。（文末领取讲师演讲PPT）

今天我的分享主要有三部分组成：

• 一是实践的背景和意义

• 二是运营实践的过程

• 三是规划和展望

  
  

在数字化转型逐步推进的过程中，伴随着云原生、微服务等技术的大规模使用，业务的开发模式逐步向敏捷开发演进，在DevOps 流程被广泛应用的前提下，应用系统的稳定性保障受到了巨大挑战，主要包括如下三个方面：

一是，如何建立应用系统快速迭代背景下的风险识别模型

为了适应当前快速发展变化的市场环境以及业务需求，以往烟囱式的应用系统架构，现在逐步被拆散成彼此间更为独立，包含自身功能特点的微服务模块。

但是在解决了业务快速上线、快速迭代的同时，也导致了部署架构的复杂度增加，业务链路加长，调用关系复杂。传统的风险“评估”方法已经很难应对日趋庞大繁杂的架构，如何应对日趋复杂的架构、检验潜在风险成为了燃眉之急，需要在不断发展的同时建立风险识别模型，以快速应对风险。

二是，如何高仿真的模拟故障以应对风险

传统的演练是人工断网、手杀进程的形式，但这个方法无法满足同时大量风险场景进行演练的需求。而且这种模拟方式往往和实际发生的生产故障相差甚远，目前证券行业对可用性要求极高，控制“爆炸半径”的演练无法在核心业务实施，所以生产环境的“无损演练”和仿真环境“有损演练”需要相互结合。

三是，如何完善现阶段的技术风险管理体系

在金融行业领域，业务风险的防控现在已经非常成熟，但是技术风险的管理尚未形成体系。以往“编写预案+组织演练”的形式需要结合现有的技术手段在管理模式上进行拓展完善。构建风险管理文化、建立配套组织架构、丰富演练组织形式、优化平台技术手段、量化评估演练效果、持续完善闭环管理，全方位的技术风险管理需要不断的通过实践进行总结优化。

为进一步消除安全生产隐患，压降生产事件，提升故障及时发现率，缩短故障处置时长。我们在三年前引入了混沌工程，搭建了自己的稳定性工程平台，同时组织开展了“保卫波特姆”，行动，波特姆就是bottom，意为守住底线，去年是保卫波特姆的第二季。相比第一季，强化了技术风险识别，采取“专项行动+突袭演练+红蓝攻防”结合的形式，尝试逐步建立了风险管理体系。

关于技术风险，我们基于证券行业的特点，结合生产运维经验，总结出威胁安全稳定运行的五大风险：

1. 单点故障风险

2. 功能缺陷风险

3. 性能容量风险

4. 数据丢失损坏风险

5. 运维误操作风险

对每个风险类别进行进一步细化，截止目前，已经有28个二级分类。针对这些风险我们建立了技术风险防范的整体框架。

• 风险发现：主要包括内/外部事件分析，加上问题管理、故障管理、变更运营分析、系统上线测试、以及系统弱点进行分析。

• 场景构建：主要是在系统架构、业务功能、业务步骤、容量管理，四个维度形成专家库。

• 自动化演练：主要是依赖平台能力，后面有详细的介绍。

• 度量改进：多维风险分析、系统健壮评估、业务拓扑检验、演练运营分析（风险防控）监控覆盖、定位及时、预案有效、自动处置。左侧文化运营，右侧制度规范，整体构成了技术风险体系框架。

  
  

稳定性实践的技术核心肯定是平台建设，稳定性平台的建设紧紧围绕高仿真模拟故障、多维度数据分析、全流程自动化展开。

故障构建能力：支持linux和windows两种操作系统，合计近两百多种故障场景的注入能力，支持灵活的编排能力，可以实现历史故障的回放能力。

量化分析能力：支持系统稳定性评估、用户行为分析（频度、覆盖度等层面）、演练运营报表多维度的分析能力。

自动化能力：支持批量创建场景、“串行”任务集演练、“并行”批量演练等自助编排、自动演练。所谓的串行就是设置好一个任务集，依次演练。并行就是多个任务同时进行，对于负责多个系统的运维工程师尤其适用。

➢ 能力视图（管理视图、用户视图、报表看板、API开放）

➢ 平台功能（演练流程、资源管理、演练管理、演练度量、演练防护、技术运营）

➢ 故障场景（1.基础资源、2.应用资源、3.业务资源、4.专项资源、5.五大风险）

➢ 资源支持（基础设施、操作系统Windows、Linux）

➢ 支撑模块（团队管理、用户管理、权限管理、配置管理、交易日历、安全审计）

目前，故障场景构造能力覆盖了基础资源、应用资源、业务资源、专项资源。在业务资源上，相信听过第一季的小伙伴，已经听说过“卡”、“吊”、“死”，在此基础上我们增加了“错”。

“卡”客户服务请求都能够得到响应，但响应时间比较长。“吊”指在监控上看进程、端口都是存活的，但是客户的服务请求长时间得不到响应。“死”指系统业务进程已不存在，客户的服务请求很快得响应，但是是错误的。“错”是增加了业务系统以及接口上面的一个返回报错的能力建设。

生产事件回放就是刚才说的多系统联动的一个具体事例，某系统发生生产事件，会在运行质量管理平台录入事件，随后生成一个技术风险。技术风险的闭环，需要在稳定性工程平台进行演练，验证改进方式是否效后，风险才能闭环。

下面主要说下风险发现途径，内/外部事件分析，最近两年历史事件的分析，尤其是涉及关机系统场景类型，需要组织演练。外部事件主要是分析外部交易所、投保的一些案例进行分析，是否与内部相关系统存在同样的风险隐患，然后针对性的进行演练。

系统弱点分析，为了增强演练的实战贴合，我们有红蓝对抗演练，业务专家、测试专家、运维专家会横向组成一个蓝军虚拟组织，蓝军会根据系统的业务特点、数据流、架构等特点分析各系统的弱点，从而形成演练场景。

有风险发现的途径，也积累了大量的需要演练的场景，那么接下来就需要专门的组织进行跟进，去年我们成立稳定性工作小组，主要包括决策组、执行组、保障组。

✓ 决策组：负责整体统筹。

✓ 保障组：产品开发组/技术支持组/平台功能开发和技术支持

✓ 执行组：具体执行对接信息和各级组织接口人

针对风险的分析，制定了2022年保卫波特姆第二季目标，主要是四个业务线和七个演练专项。

七个专项：

1.核心系统单点故障演练：主要验证各个系统告警覆盖以及应急处置。

2. 内外部事件模拟演练

3. 交易行情接入/报盘演练

4. 全链路性能容量演练：主要是指我们的app的全链路生产环境的容量演练。

5. 数据备份恢复演练：主要是根据《证券期货经营机构信息系统备份能力标准》评估系统备份恢复的RPO、RTO时间，这个在演练过程中也确实发现个别系统的RTO时间不符合要求的，后续我们对历史数据做了归档，然后备份，再次演练，最终符合要求。

6. 清算勾稽演练：这部分演练主要是经纪业务晚间清算，之前搭建起了勾稽平台，积累了很多的清算勾稽稽核逻辑，为确保这些逻辑不会随着系统升级产生变化，进行的演练。

7. 基础设施联合演练：这部分主要是网络层面的故障对业务系统的影响，前面的故障演练都是业务系统的管理员进行故障注入，联合演练是网络团队进项故障注入，各相关系统进行联合处置演练。

目前稳定性工程已经覆盖了开发、测试、生产的全部环境。这里面要提下，就是按照混沌工程的理论，稳定性演练是要在生产环境进行的，但是我们在实际演练过程中发现，随着演练的次数和频度不断加大，很多场景对于业务是有影响的。券商和互联网企业的区别在于，证券行业很难建立一个灰度区，可以用来做这种测试。于是我们搭建一套和生产环境一模一样的仿真环境，包括监控、日志分析、可视化大屏等等，通过将生产流量回放的形式评估业务影响，目前红蓝对抗主要是在仿真环境进行。

去年的演练涉及较多系统和人员，先后进行了10余次的线上线下培训，同时建立了200多个技术支持群，保证有问题第一时间处理。

演练形式包括三种：

一是专项演练，也是常态化的演练，就是前面介绍的7个专项。

二是突袭演练，在系统管理员不知情的情况下进行突袭，为了验证前面专项演练的覆盖，发现和处置能力，同时也检验应急报备、全面协同能力。

三是红蓝对抗，形成内部虚拟蓝军组织，在仿真环境进行。

随着平台能力提升，季度演练也达到了数千次，峰值是6000次。演练效率较之前也提升近26倍。演练过程中发了数百条风险，截止目前，问题闭环率已经达到了99%。我们通过演练验证了配置监控的有效性，监控主动发现率较之前提升了16%，事件发生后，十分钟内处置完成率提升了23%。

保卫波特姆第二季在范围上也有了大幅的提升，这次演练涉及SRE200多名，涉及系统300多个，总计部署单元3600多个，涉及主机8000多台，累计演练次数13000+次，同比上一季增长了近200%

后续的计划主要包括如下方面：

一是，持续深挖风险，我们正在根据业务系统的服务目录，包括对客服务和系统间服务，深挖风险场景。完善场景库，构建（英文）能力矩阵，实现演练场景的智能推荐。

二是，提升自动化能力，虽然在演练提升效率上做了平台改进，，但是从演练准备、场景构建、演练执行、演练恢复、结果验证、风险统一纳管还需要做进一步提升，争取早日做到无人值守。

三是，多维度的数据分析，包括系统层面、人员层面、执行层面，做好全面数字运营，通过数据分析揭示问题，促进内部提升。