企业网站建设方案如何,网站栏目建设调研,水电公司设计logo,公司业务推广目录
前言
案例
1、强弱依赖不合理
2、预案不生效
3、异常数据不兼容
4、监控体系缺陷
5、系统缺整体架构设计
总结 前言 我们公司从启动混沌工程到现在已经几乎覆盖了线上的所有核心业务#xff0c;先后进行过2000次演练共挖掘出120个漏洞。这些漏洞有些得了及时修复…目录
前言
案例
1、强弱依赖不合理
2、预案不生效
3、异常数据不兼容
4、监控体系缺陷
5、系统缺整体架构设计
总结 前言 我们公司从启动混沌工程到现在已经几乎覆盖了线上的所有核心业务先后进行过2000次演练共挖掘出120个漏洞。这些漏洞有些得了及时修复避免了生产故障的发生也有些因为各种原因推进缓慢没能在引爆之前得到修复通过血泪教训验证了混沌工程的价值。本篇将通过梳理这120个漏洞以及我们混沌中发现的一些共性的问题拿来一起分享下希望对大家有所帮助。
案例
1、强弱依赖不合理 我们在演练电商业务线时发现当某商品的库存服务不可访问时会导致该商品页无法正常打开这是个典型的强弱依赖不合理的经典案例。 在应用场景中商品信息与库存信息应该是弱依赖因为用户只是想浏览和了解商品而已凭什么因为不知道有多少货就不给用户看了呢库存信息与交易信息才是强依赖当用户真正决定购买时才涉及到有多少货的问题。 这种强弱依赖不仅是代码端做好降级判断等问题更理想的做法是做好服务拆分从物理上进行节点的隔离这样就能更好的根据强弱依赖进行不同等级的高可用设计。例如商品的评论服务节点对于所有的电商模块来说都是弱依赖那我们就可以在评论相关的资源配备上采用更激进的策略节约成本。
2、预案不生效 案例场景A调用B、B调用C当B调用不到C时就用本地缓存获取数据返回给A。 这个场景中B的设计就是典型的利用缓存做降级的预案设计每个研发可能都会信誓旦旦的表示这么简单的逻辑绝对不会有问题但我们在实际的混沌演练中确实发现此类预案没有生效不生效的原因基本都聚焦到对降级条件的判断上。B从C拿到不完整的数据要不要启用本地缓存B到C网路延时、延时多少要用缓存
3、异常数据不兼容 混沌工程在网络层面的故障注入常用的方法是模拟4层异常例如域名解析错误、网络延时、通信丢包、网络不通等这确实可以发现大部分因网络问题引发的故障但不能发现7层引发的问题例如异常的数据格式。 案例场景A调用B如果B返回200就从B的body中按协商好的Json格式进行解析。 那么问题来了当B返回非200A会怎样返回200但body无数据A会怎样body有数据但Json格式与协商不一样会怎样甚至说body返回的就不是一个Json会怎样这些异常是真实会发生而且一定会发生的那么演练一定要覆盖到所以这里就需要用到7层的网络异常注入了。
4、监控体系缺陷 有个成语叫“手眼通天”混沌工程中像ChaosBlade这类的异常注入工具只是我们的“手”手帮我们造成混乱但混乱造成的影响需要靠“眼”来看到监控体系就是混沌工程的“眼”。手的能力和眼的视野决定了混沌演练效果的上限。 实践中发现很多时候我们的“眼”是有缺陷的明明用户体验已经严重受损但我的监控健康度仍然100分明明用户体验一切正常但我们的告警已经达到灾难级或者演练时我们需要关注某些指标但我们提供不了这些都是现有监控系统需要优化改造的点。
5、系统缺整体架构设计 案例后端服务分别部署在两个集群节点对接同一套数据库前端通过主域名和备用域名的跨域名重试实现多节点容灾设计当我们模拟主节点到数据库网络异常时期望前端通过备用域名仍能提供稳定的用户体验。 如图 经过演练发现用户的前端界面在卡顿6秒后才能正常展示并不符合我们的预期于是逐层去分析原因。 前端先尝试主域名请求因为不清楚后端服务是否具备幂等性所以必须等待后端明确返回非200的状态码后才能进行跨域名重试。 后端数据库链接超时2秒重试3次3次都不成功返回500。 前后端的设计都合情合理甚至说无懈可击但组合在一起就造成了这6秒延时从系统架构来看明明可以快速失败进行跨域名重试从而提高用户体验的而这些设计并不是前端、后端具体某一个团队负责的需要整体架构设计与相应的规范。
总结 混沌工程是一种产生新数据的技术通过演练不仅能提前发现隐患避免故障的大范围爆发还能发现运维体系的盲区和整体架构设计的缺陷可以说混沌工程本身就是优秀架构设计的试金石。
