1.建立稳定状态的假设
2.要多样的现实世界事件做验证
3.在生产环境中进行实验
4.自动化实验以持续运行
5.最小化爆炸半径
稳定状态——人的稳定状态——血压、稳定——IO、内存——必要但不充分——系统指标
稳定状态——人的稳定状态——运动、思考——响应程度——充分——业务指标
我们正在流失用户吗?
用户目前可以操作网站的关键功能吗?
目前存在较高的延迟致使用户不能正常使用我们的服务吗?
收入指标
指标和底层架构的关系——分布式服务的pod中的CPU与Node的CPU
收集相关数据需要的工作量——每次请求的健康程度——日志爆了
指标和系统接下来的行为之间的时间延迟——每月的月活与业务今天的健康程度毫无关系
建立假设——金丝雀发布——建立告警
硬件故障
功能缺陷
状态转换异常(例如发送方和接收方的状态不一致)
网络延迟和分区
上行或下行输入的大幅波动以及重复风暴
资源耗尽
服务之间部长长的活着预料之外的组合调用
拜占庭故障(例如性能差或有异常的节点发出有错误的响应、异常的行为、对调用者随机地返回不同的响应等)
资源竞争条件
下游依赖故障
同时采用故障域概念具有一定的乘数效应
对服务调用失败的模拟——验证该服务对缺陷代码的弹性——验证高负载、错误配置、异常终止
混沌工程成熟度模型
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。