ht025
作者ht0252021-03-16 16:03
其它, ht

混沌工程在券商的探索与实践

字数 5438阅读 6708评论 0赞 0

摘要: 混沌工程在 IT 行业属于一门新兴的技术学科,大多数 IT 公司对它的理解还没有上升到一个领域概念,在金融行业的探索实践更少。某券商在 IT 系统的研发运维、质量管理、应急管理等方面积累了多年的经验,在此基础上,我们开发了一款遵循混沌工程实验原理的产品 - 故障演练平台( HT Chaos King Kong )。

故障演练平台提供丰富的故障场景实现,能够帮助分布式系统提升容错性和可恢复性,并且通过平台能力,标准化混沌实验流程。该平台提供真实、安全、易用的演练能力,驱动监控发现和快速恢复能力升级,验证重大事件响应机制有效性,数据化度量系统、工具、流程和人的关系。

通过平台可以模拟微服务接口超时、接口异常等故障,也可以通过该工具梳理渠道端强弱依赖关系,推动核心业务与非核心业务解耦,防止非核心业务影响核心业务造成重大生产事故。

01 混沌工程

** 1.1 混沌工程介绍

什么是混沌工程?混沌工程最早由 Netflix 及相关团队提出,是指通过受控的实验去观察分布式系统运行的过程。混沌工程是一门在分布式系统上进行实验的学科 , 目的是解决分布式环境下诸多不确定因素导致的环境不可用,建立对系统抵御生产环境中失控条件的能力以及信心。 What does not kill me, makes me stronger.

1.2 实施混沌工程的好处

实施混沌工程的好处主要体现在以下几个方面:

  1. 验证系统健壮性:架构容灾、分布式弹性。
  2. 验证系统依赖:业务依赖梳理、强弱依赖分析。
  3. 验证业务连续性:监控有效性、故障响应能力、稳定性保护措施。
  4. 验证故障修复:故障回归测试、修正经验值。

1.3 混沌工程实施步骤

实施混沌工程主要有以下 8 个步骤:

  1. 制定混沌实验计划:实验工具、演练环境、实验靶点和范围、实验匹配条件和规则。
  2. 定义系统稳态指标:衡量系统状态。
  3. 系统容错行为假设:评估系统表现。
  4. 执行混沌实验:注入真实的故障。
  5. 检查系统稳态指标:通过监控观察系统表现和稳态指标差异。
  6. 记录 & 恢复混沌实验:恢复实验,修复问题,后续持续验证。
  7. 修复发现的问题。
  8. 自动化持续进行验证。

    02XX 故障演练平台( HT Chaos King Kong )

** 2.1 概述

XX 故障演练平台是一款遵循混沌工程实验原理的产品,提供丰富故障场景实现,能够帮助分布式系统提升容错性和可恢复性,并且通过平台能力,标准化混沌实验流程。该项目将提供真实、安全、易用的演练能力,驱动监控发现、快速恢复能力升级,验证重大事件响应机制有效性,具备面向业务、描述终态、开放扩展的稳定性度量中台,数据化度量系统、工具、流程、人的关系。

2.2 流程 XX 故障演练平台建立了一套标准的演练流程,包含准备阶段、执行阶段、验证阶段和恢复阶段。通过四阶段的流程,覆盖用户从计划到还原的完整演练过程,并通过可视化的方式清晰的呈现给用户。

2.3 使用场景

目前故障演练平台可适用于以下典型场景:

l 衡量微服务的容错能力

通过模拟调用延迟、服务不可用、机器资源满载等,查看发生故障的节点或实例是否被自动隔离、下线,流量调度是否正确,预案是否有效,同时观察系统整体的 QPS 或 RT ( Recover Time )是否受影响。在此基础

上可以缓慢增加故障节点范围,验证上游服务限流降级、熔断等是否有效。最终故障节点增加到请求服务超时,估算系统容错红线,衡量系统容错能力。

l 测试 PaaS 层是否健壮

通过模拟上层资源负载,验证调度系统的有效性;模拟依赖的分布式存储不可用,验证系统的容错能力;模拟调度节点不可用,测试调度任务是否自动迁移到可用节点;模拟主备节点故障,测试主备切换是否正常。

l 验证监控告警的时效性

通过对系统注入故障,验证监控指标是否准确,监控维度是否完善,告警阈值是否合理,告警是否快速,告警接收人是否正确,通知渠道是否可用等,提升监控告警的准确和时效性。

l 定位与解决问题的应急能力

通过故障突袭,随机对系统注入故障,考察相关人员对问题的应急能力,以及问题上报、处理流程是否合理,达到以战养战,锻炼人定位与解决问题的能力。

2.4 实施方式

首先,基于部门的技术架构以及运维方式的认知,在具体实施过程中需要满足以下条件:

l 方案的实施必须契合整体架构的长期演进方向,满足低成本、高收益、可复用三个要求。在技术方案的选择上,通过开源和自研相结合的方式,在降低成本的同时最大限度贴合自身的架构特点。

l 从当前的运维方式,处于虚拟机 / 物理机部署方式向容器化过渡过程中,需要支持虚拟机、物理机、 docker 、 k8s 三种攻击模式。

l 从安全角度,线上故障注入为高危动作,需要有严格的权限控制流程。在实施前期,允许团队在线下及预发环境中验证故障注入方案的合理性。

其次,为了更真实模拟线上故障,我们对历史故障数据进行了大量分析,将相关故障场景抽象为五大类:基础设施类( CPU 、网络、磁盘)、中间件( JVM dubbo )、存储类(连接池满、慢查询)、应用层(杀进程、 OOM )、业务特性。抽象的故障场景即为需要实现的故障注入能力。

再次,综合实施条件和实施能力目标,对开源方案进行筛选。目前,开源方案可以分为三类:一类,从 chaosMonkey 衍生、以容器化部署应用作为攻击目标,采用 go 语言作为技术栈,如 pumba 、 kube-monkey 、 chaosblade ;另一类,基于 python 强大运维优势的开源方案,可以较快的实现运维层面的攻击,如 chaostoolkit ;最后一类为侵入代码层进行攻击,如 byte-monkey ,在字节码层面给 jvm 应用注入相应故障。

经过比对,阿里巴巴开源的 chaosblade 功能强大,除了基础的 CPU 、 disk 、 I/O 、 network 外,还支持 docker 、 dubbo 、 jvm 、 C++ 的攻击,同时支持攻击后对故障的恢复,并支持虚拟机 / 物理机和 docker/k8s 部署方式下的故障注入。

开源方案极大的方便了工程的实施,但并不能解决全部的问题,如: chaosblade 不支持 windows 操作系统,但是部署在 windows 操作系统上的应用也不在少数。因此,我们调研了在 windows 操作系统上进行故障注入和恢复的可行性。在架构层面上,兼容 linux 和 windows 体系;在业务层面上,目前统一了基础资源类故障注入和恢复的操作,后续对其他类的故障场景也将实现统一化和标准化。

最后,为了提升故障注入、故障恢复、故障监测的易用性,同时实现权限管控、指令下发、历史记录、场景编排等必需功能,我们设计并实现 XX 故障演练平台 -HT Chaos King KongXX 混沌金刚 HT-CKK )。

故障演练平台借助于 saltstack 实现故障注入和恢复的指令下发,以应用系统和设备(虚拟机 / 物理机)为维度实现权限管控,并将最小攻击目标限定在单个 IP 或进程上。故障演练平台架构图如下所示:

通过和系统 H ( CMDB )、自动化服务平台、监控系统、日志系统的关联,故障演练平台可以实时查看演练时的异常指标和应用日志详情,从演练准备(评估爆炸半径),故障注入,故障恢复,到报警验证和最后的演练报告,形成了一套基本的故障演练实施的标准。

** 03 实践

3.1 实现故障注入

解压 chaosblade 压缩包,目录结构如下:

├── bin

│ ├── chaos_burncpu

│ ├── chaos_burnio

│ ├── chaos_changedns

│ ├── chaos_delaynetwork

│ ├── chaos_dropnetwork

│ ├── chaos_filldisk

│ ├── chaos_killprocess

│ ├── chaos_lossnetwork

│ ├── jvm.spec.yaml

│ └── tools.jar

├── blade

└── lib

└── sandbox

下面以模拟系统 C 微服务延时 10 秒故

障为例:

1 、通过平台,执行如下命令初始化:

./blade prepare jvm --process search

2 、微服务延时 10 秒故障命令:

./blade create dubbo delay --time 10000 --provider service com.htsc.prdtcenter.search.bussiness.IPrdtZlService

3 、故障执行情况:

4 、系统 C 微服务延时 10 秒后,涨乐端系统 G 服务线程池占满,开始影响其他服务,此时系统 G 采取限流措施;线程池变化情况如下:

3.2 混沌测试场景及计划

系统 B 、系统 C 、系统 D 分别按既定计划在生产开张相关演练,并将相关演练推广到系统 E 。演练达到了以下目的:

( 1 )验证了各个业务系统在指定故障场景下的稳定性和可恢复性。

( 2 )验证了监控告警是否第一时间发现了问题。

( 3 )验证应急预案的有效性和完备性,能否第一时间处理解决问题。

( 4 )验证不同场景下对渠道端的影响和故障演练平台本身的可靠性。

3.3 混沌测试现象

混沌测试模拟相关系统服务端接口超时或者报错,对不同的消费者影响也不一样,本次测试我们重点关注与客户直接相关的渠道端的反应。

1 、渠道系统 F 视角观察

( 1 )系统 A 接口服务超时或接口报错场景会导致我的首页“网络连接不通畅”;如果命中缓存数据,则正常显示;否则,显示“ 0” 或 “--” 。

( 2 )系统 B 接口服务超时或接口报错场景会影响涨乐端我的下面的个人信息、风险评估和理财首页 - 高端理财的信息加载及更新,部分页面也会提示“网络连接不通畅”。

( 3 )系统 D 微服务接口报错或超时,主要影响涨乐前端我的、理财两个一级页面,以及手机号登陆功能;其中会员信息接口超时,用户基本信息以及短信认证登陆接口报错或超时会直接影响注册用户登陆;账户 V 值接口报错或超时只会对交易账户的二级页面账户综合分有影响,对账户首页无影响。部分页面也会提示“网络连接不通畅”。

系统 C 微服务接口报错或超时,主要影响理财首页、产品详情展示、产品搜索等涨乐端与理财相关的一级及二级页面;部分页面也会提示“网络连接不通畅”,甚至有个别页面会把后台报错路径直接返回给客户。

** 3.4 存在的问题

1 、日志平台采集及告警问系统 C 的 Service 微服务是老接口(为渠道系统 F 提供服务),未把日志发送到日志平台 octopus ,同时微服务治理平台未配置相关告警导致接口测试时未告警。

( 2 )系统 A 在 OCTOPUS 日志系统是配置告警信息指向性不明确,需人工定位,耗时较长。

( 3 系统 D 在微服务治理平台配置告警有延迟,不能及时发现问题。

2 、测试工具问题

( 1 )混沌测试工具模拟微服务服务器 cpu 使用率 100% 场景时,对接口服务无影响,与预期情况不符。

3 、渠道系统 F 前端问题

( 1 )系统 C 指数微服务超时,涨乐理财首页 - 指数掘基会把接口路径反馈给客户。

( 2 )系统 G 缓存产品数据问题,系统 G 的缓存有多个小集群,小集群之间数据独立,在缓存有效期内,后端服务异常时,存在部分客户访问正常,部分客户访问失败。

( 3 )微服务服务端存在新老接口共存提供服务的情况,不仅造成基础资源浪费,还会增加维护成本;该情况存在的主要原因是渠道端未完成接口迁移所致。

04 展望

随着研发迭代模式的变化,以及大家对混沌工程的接受和认识程度的提高,故障演练会向以下几个方向演进:演练常态化、故障标类化、演练智能化。故障演练平台未来的几个发力目标:

l 演练场景编排,以业务维度进行故障演练。

l 完成故障演练闭环,从准备、执行、验证、恢复到分析报告形成有效闭环。

l 建立高可用专家库,结构化提高应用容错能力。

l 规模化覆盖核心业务,用常态化的演练驱动业务系统稳定性提升。

l 以产品化、平台化思路开放演练能力。

总结

应用系统的稳定性、容错性和可恢复性需要多方面的保证,对应用系统实施混沌工程是建立对系统抵御生产环境中失控条件的能力以及信心的一个重要手段。本文简单介绍了混沌工程,基于混沌工程实施的原则,自研的故障演练平台,并在一些业务系统上实施了故障演练,达到了预期的效果,后续将不断完善故障演练平台,为提升业务系统的稳定性做更好的服务。

作者简介:

核桃,现就职于某证券公司。在银行从事IT工作六年,从事多种类型的操作系统、数据库、中间件、服务器、虚拟机等的技术保障工作,获得CATE、OCP等证书;在券商从事IT工作三年多,曾牵头负责零售CRM相关系统的维护工作,获得公司年度、季度创新大赛奖励十多项、国家专利多项。
晓勋,东南大学硕士,超过 6 年不同行业的软件研发、设计和架构经验,熟悉分布式、大数据、高可用架构设计,目前从事混沌工程的相关研究和实施。
连洋, 超过 10 年不同行业数字化转型和 IT 服务管理经验,横跨制造业、互联网、传统 IT 、金融证券行业,熟悉 IT 运维管理和技术运营一体化,具有多年 PMO 管理和运维管理经验,目前从事混沌工程的相关研究。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关资料

X社区推广