写点什么

AWS 云上混沌工程实践之对照实验设计篇

  • 2019-09-30
  • 本文字数:3229 字

    阅读完需:约 11 分钟

AWS云上混沌工程实践之对照实验设计篇

上一周,笔者有幸受邀参与了QCon 2019北京大会的混沌工程专场,和与会者分享了AWS云上混沌工程实践中对照实验的设计方法。特此在本专栏回顾这一场的分享内容,以飨读者。现场有感而发画了下面这个混沌工程的小漫画:


“如果你不提早发现和解决问题(引入混沌工程实验),最后问题会来(周末/半夜)解决你”。



图 1 混沌工程带来的变化


我们在启动篇从混沌工程的发展历程出发,分析了社区对混沌工程的理解并不是一蹴而就而是循序渐进,以此得到了第一个重要结论:


结论 1 :“并不是只有研发实力突出的大型互联网公司才能实践混沌工程”。


可行性评估篇明确了混沌工程的过去、当前和未来目标(实现韧性系统,如图 2 所示),为了帮助不同类型的公司来进行实践混沌工程,我们提出了混沌工程的可行性评估模型。



图 2 混沌工程的过去和未来


因此,我们得到了第二个重要的结论:


结论 2 :“也许很多公司目前仍处在第三象限(实验技术成熟度低、公司接纳指数低),但只要根据可行性评估模型中的逐项要求和未来发展的路线图,迭代推进和持续改进,我们都可以从混沌工程实践中获得收益。”


接下来的问题便是,混沌工程实验要怎么做,具体的设计方法是什么?

混沌工程实验:一个持续性迭代的闭环体系


图 3 混沌工程实验的实践流程


如图 3 所示,完整的混沌工程实验是一个持续性迭代的闭环体系,从初步的实验需求和实验对象出发,通过实验可行性评估,确定实验范围,设计合适的观测指标、实验场景和环境,选择合适的实验工具和平台框架;建立实验计划,和实验对象的干系人充分沟通,进而联合执行实验过程,并搜集预先设计好的实验指标;待实验完成后,清理和恢复实验环境,对实验结果进行分析,追踪根源并解决问题,并将以上实验场景自动化,并入流水线,定期执行;之后,便可开始增加新的实验范围,持续迭代和有序改进。


下面我们会深入讨论有关混沌工程实验的准备事项:


  • 实验可行性评估

  • 观测指标设计与对照

  • 实验场景和环境的设计

  • 实验工具和平台框架选型(限于篇幅,未完待续)

实验可行性评估

可行性评估篇提供了这样一个混沌工程实验的可行性评估模型,从多个维度对实验技术的成熟度做了定性分析。此处的实验可行性评估,依照这个可行性评估模型,会针对具体的实验需求和实验对象进行细致评估。常见的一个形式是对照“可行性评估问题表”,对实验对象的干系人进行访谈。可行性评估问题表的内容会包含以下几个方面:


  • 架构抵御故障的能力:通过对实验对象的架构高可用性的分析和评估,找出潜在的系统单点风险,确定合理的实验范围。

  • 实验指标设计:评估目前实验对象判定业务正常运行所需的业务指标、应用健康状况指标和其他系统指标。

  • 实验环境选择:选择实验对象可以应用的实验环境:开发、测试、预生产、生产。

  • 实验工具使用:评估目前实验对象对实验工具的熟悉程度。

  • 故障注入场景及爆炸半径:讨论和选择可行的故障注入场景,并评估每个场景的爆炸半径。

  • 实验自动化能力:衡量目前实验对象的平台自动化实施能力。

  • 环境恢复能力:根据选定的故障注入场景,评估实验对象对环境的清理和恢复能力。

  • 实验结果整理:根据实验需求,讨论确定实验结果和解读分析报告的内容项。

观测指标设计与对照

观测指标设计


观测指标的设计是整个混沌工程实验成功与否的关键之一。最新的调研报告“Chaos Engineering Observability: Bringing Chaos Experiments into System Observability”指出在进行混沌工程实验过程中,系统可观测性已成为一种“强制性功能”,良好的系统可观测性会给混沌工程实验带来一个强有力的数据支撑,为后续的实验结果解读、问题追踪和最终解决提供了坚实的基础。


以下是常见混沌工程实验的观测指标类型:


  • 业务性指标:价值最大,探测难度最大

  • 应用健康指标:反映应用的健康状况

  • 其他系统指标:较易获取,反映基础设施和系统的运行状况


以 Netflix 为例,早在 2008 年 Netflix 起步流媒体,手动追踪数百个指标,全靠人工来检测问题。 这种方法适用于数十台服务器和数千台设备,但不适用于未来的数千台服务器和数百万台设备。最终 Netflix 找到了一个可以反映业务状况、用户参与度的指标:每秒流视频启动次数 SPS (stream-starts-per-second)。



SPS 指标示例比较(红色=当前周,黑色=前一周)


SPS 模式通常是比较规则的,受到假日和事件等外部影响会有所变化。上图描绘的就是 SPS 随时间变化的波动情况,可以看出,它有一个稳定的模式,每天 SPS 峰值发生在晚上,谷值发生在清晨。这是因为人们习惯于在晚餐时间看电视节目。假期时,白天的观看次数增加,因为有更多的空闲时间在 Netflix 上观看节目。

观测指标对照

如果我们将过去一周的波动图放在当前的波动图之上,就像上图中当前的图线是红色,上一周的图线是黑色,以求找出其中的差异。由此,我们可用“受 SPS 影响”或“不影响 SPS”来衡量业务的状况。此外,由于 SPS 随时间的变化可以预期,所以我们可用一周前的 SPS 波动图作为稳定状态的模型,并通过使用预期 SPS 级别与实际 SPS 级别来衡量业务的可用性。Netflix SPS 指标的这种特性,也提醒我们应以观测指标的稳定状态进行对照。


不过可行性评估中,我们发现有很多的用户还是无法定义一个合适的业务指标,如无法准确定义一个稳定状态,那么我们也可以退而求其次,使用多个指标进行联合分析来对照。具体的联合分析方法包括:静态阈值、指数平滑、双指数平滑、贝叶斯检测、马尔可夫链蒙特卡罗方法(MCMC)、鲁棒主成分分析(PCA)等等,后面我们可以专门来详细讨论。

实验场景和环境的设计

实验场景和环境的设计要努力遵循以下三大设计目标:


  • 在生产环境运行实验

  • 持续自动化运行实验

  • 最小化实验场景的“爆炸半径”

实验场景设计

以下是亚马逊 AWS 云上常见的实验场景:


故障注入场景具体描述
依赖型故障AWS 托管服务异常:ELB/S3 / DynamoDB/Lambda,…
主机型故障EC2 实例异常终止,EC2 实例异常关闭,EBS 磁盘卷异常卸载,容器异常终止,容器异常关闭,RDS 数据库实例故障切换,ElastiCache 实例故障切换,…
操作系统内故障CPU、内存、磁盘空间、IOPS占满或突发过高占用,大文件,只读系统,系统重启,熵耗尽,…
网络故障网络延迟,网络丢包,DNS 解析故障,DNS 缓存毒化,VIP 转移,网络黑洞,…
服务层故障不正常关闭连接,进程被杀死,暂停/启用进程,内核奔溃,…
请求拦截型故障异常请求,请求处理延迟,…


这些场景的实施能力,依赖于实验工具和平台框架的选型,后面我们会专门来深入讨论。

实验环境设计


实验环境的不同,带来不同的业务风险。生产环境的业务风险最大,开发环境的业务风险最小,其他依次类推。我们会建议用户在生产环境上进行混沌工程实验,当然前提是这些实验场景和工具已经在开发/测试和预生产环境得到了验证。当然在生产环境上进行混沌工程实验也不是强制的,用户可以选择适合自己的推进节奏,逐步向生产环境靠拢。因为实验越接近生产环境,从结果中学到的越多。同时,为了体现实验对照的效果,在生产环境进行的混沌实验可以通过真实生产流量分支的方式,组建控制组和对照组,以此区分故障注入的影响,从一定程度上控制了爆炸半径。对于非生产环境的混沌工程实验,可采用模拟生产流量的方式,尽量和生产流量相似,来验证实验场景和工具的可靠性。


综上,本文是混沌工程专栏的第三篇,首先我们回顾了专栏前两篇中的重要结论,由此引申出“如何进行对照实验设计”这个实施性问题,并从实验可行性评估、观测指标设计与对照、实验场景和环境的设计三个维度,深入分析和讨论了混沌工程实验的对照设计原则和方法,后续我们还会针对特定专题进行剖析。


作者介绍:


黄帅


亚马逊 AWS 专业服务团队云架构咨询顾问。负责企业级客户的云架构设计和优化、DevOps 组织咨询和技术实施。在软件研发领域有多年架构设计和运维、团队管理经验,对 DevOps、云原生微服务治理框架、容器化平台运维、混沌工程实践等有深入的研究和热情。


本文转载自 AWS 技术博客。


原文链接:


https://amazonaws-china.com/cn/blogs/china/aws-cloud-chaos-engineering-experiment-designs-contract/


2019-09-30 15:20988
用户头像

发布了 1855 篇内容, 共 121.9 次阅读, 收获喜欢 78 次。

关注

评论

发布
暂无评论
发现更多内容

记录一起非数据热点引起的TiKV负载不均衡

TiDB 社区干货传送门

故障排查/诊断

解决tiup‘ssh: unable to authenticate’报错

TiDB 社区干货传送门

集群管理 管理与运维 故障排查/诊断 扩/缩容

代理IP在社媒营销中的重要作用

IPIDEA全球HTTP

头部保险公司国寿财核心系统采用 TiDB 实现信创替换并实现重大突破

TiDB 社区干货传送门

实践案例

什么是CSPO及成为CSPO的好处?

ShineScrum

断崖式领先!百度搜索登顶AI产品榜国内第一

Geek_2d6073

天融信与涛思数据达成战略合作,共筑数据安全新高地

TDengine

花2小时成tidb专家--云上资源特别贵kv业务的节省

TiDB 社区干货传送门

8.x 实践

GC异常导致空间不释放,如何通过 tikv-ctl recover-mvcc 修复

TiDB 社区干货传送门

故障排查/诊断

手把手教你修改 TiDB 监控告警阈值

TiDB 社区干货传送门

集群管理

如何使用C# 获取Windows系统信息以及CPU、内存和磁盘使用情况

哦豁完蛋了

从原理到实践,GraphRAG 如何提升 LLM 的摘要总结能力?

可信AI进展

我与tidb的十年,我的职业生涯中遇到的各式各样的数据库。

TiDB 社区干货传送门

社区活动 TUG 话题探讨

功能发布-事件分析之漏斗分析

ClkLog

数据分析 埋点 开源软件

TiDB v7.5.3 发版,听说升级后又可以躺平两年

TiDB 社区干货传送门

版本升级 新版本/特性解读 7.x 实践

首部顶级AI科学家创作的纯正科幻小说,一个元宇宙和AI时代的全新科学幻想!

博文视点Broadview

万界星空科技自动化运维管理---设备管理

万界星空科技

数据采集 mes 自动化运维 设备管理 万界星空科技

TiDB 执行计划代价模型分析

TiDB 社区干货传送门

性能调优 TiDB 底层架构

TiDB主键锁(primary key lock)问题诊断

TiDB 社区干货传送门

故障排查/诊断

告别杂音,从 AI 音频降噪开始

七牛云

AI降噪

适合新手进行接口与自动化测试练习的推荐网站!!!

EquatorCoco

接口 自动化测试

一年同行:我的TiDB社区之旅 

TiDB 社区干货传送门

人物访谈

我当初为什么选择了tidb抛弃了postgresql

TiDB 社区干货传送门

性能测评

北京银行如何利用 TiDB 实现20个关键业务系统的高效运行

TiDB 社区干货传送门

手摸手教你,从0到1开发一个Chrome浏览器插件

左诗右码

Chrome Extension

巴黎同款,六自由度技术还原赛场决定性瞬间!

快手技术

视频 渲染

TiKV 事务介绍

TiDB 社区干货传送门

TiKV 源码解读

花第1小时成tidb专家--云上资源特别,贵公司让我省钱ap篇

TiDB 社区干货传送门

8.x 实践

音乐制作工具:Studio One 6 (Win&Mac) 激活版

你的猪会飞吗

Studio One 许可证 Studio One 破解 Studio One 6下载

关于低代码这一技术的杂谈

秃头小帅oi

清晰易懂二分查找算法 你确定不看吗?

不在线第一只蜗牛

Java Python 算法

AWS云上混沌工程实践之对照实验设计篇_语言 & 开发_亚马逊云科技 (Amazon Web Services)_InfoQ精选文章