混沌演练实践(二)-支付加挂链路演练

混沌,演练,实践,支付,加挂,链路 · 浏览次数 : 61

小编点评

**链路演练设计** **目标:** * 验证链路中部分系统发生故障时候的整体链路的表现。 * 对链路保持正常运作的能力进行校验和评估,提前识别未知隐患并进行修复。 * 提升整体场景功能的稳定性。 **演练方法:** 1. **链路梳理:**根据业务场景绘制系统交互图,整理链路图。 2. **接口梳理:**根据调链路调用关系,确定接口调用顺序和参数。 3. **演练计划:**制定混沌演练场景,包括故障方案、执行参数和监控指标。 4. **执行:**利用天权自动化运维平台进行混沌攻防演练。 5. **监控:**实时监控服务器性能状态,检查故障发生情况。 6. **反馈:**收集演练结果并进行复盘。 **场景设计:** **场景一:**精准触达系统-消息触达方法延迟增加30ms **场景二:**分流服务-JAVA进程满载,指定分流进程CPU满载 **其他配置:** * 设置故障参数,例如分流服务CPU满载率、失败阈值等。 * 监控系统层面的 CPU、内存等使用情况。 * 定期检查监控指标,及时发现异常情况。

正文

1. 背景

当前微服务架构下,各个服务间依赖高,调用关系复杂,业务场景很少可以通过一个系统来实现,常见的业务场景实现基本涉及多个上下游系统,要保证整体链路的稳定性,需要尽量减少系统之间的耦合性,避免因为单点失效引起整个链路的故障。

2. 目标

通过混沌演练验证链路中部分系统发生故障时候的整体链路的表现,对链路保持正常运作的能力进行校验和评估,提前识别未知隐患并进行修复,进而保障整个链路更好地抵御生产环境中的失控条件,提升整体场景功能的稳定性。

3. 演练链路

对真实的业务场景进行混沌演练,就需要对业务场景的相关服务和调用关系进行链路梳理,一般需要根据实际业务场景,画出系统交互图,通过链路串联、数据追踪、和上下游确认等方式整理链路图。

4. 演练计划

混沌演练之前,一定要好可行性评估,评估可以演练的服务部署环境、演练工具的成熟度、演练场景的爆炸半径等,然后决策演练场景,进行实践操作。

5. 内容加载演练实践

5.1 链路梳理

内容加载链路演练,通过内容加载的系统交互梳理出加载链路:摹略引擎执行-AB分流-CMS资源获取-鹰眼内容发送

5.2 接口梳理

根据调链路调用关系用梳理出具体的接口:

5.3 制定演练计划

演练时间:2023.03.28 14:00-22:00

演练攻击人员:孙X英、陈X然; 演练防守人员:张X雷、付X军、刘X、韩X

针对链路接口设计演练场景,一般根据系统特色来设计更容易发生的故障,比如应用偏计算比较消耗CPU的话,故障设计包含CPU满载,应用对于响应的时效有严格的要求的话一般包含方法延迟故障设计。

本次链路故障场景设计如下:

具体演练场景设计可参考:混沌实战演练(一)

5.4 演练执行

目前借助天权自动化运维平台进行混沌攻防演练,进入工具市场—演练类,选择不同的故障方案,点击“立即执行”;

如选择Java进程满载场景演练,选择满载率100%,满载核数为演练应用部署服务的CPU核数,演练时长是执行满载的持续时间,选择演练的具体应用和指定IP,执行演练计划。

演练示例,根据演练的场景配置好故障参数,如下图为精准触达系统-消息触达方法延迟增加30ms参数设定:

演练执行结果检查,下图为分流服务-JAVA进程满载,指定分流进程CPU满载,故障执行结果:

5.5 演练监控

使用监控工具实时收集服务器在混沌演练运行期间的性能状态,如系统层面的 CPU、内存等使用情况,观察方法的响应时间、成功率等指标,一方面验证在混沌场景执行期间系统状态是否达到预期的效果,同时记录演练期间发生的问题,记录现场,另一方面通过监控发现有风险问题进行人工干预,立刻终止演练。

场景一:精准触达系统-消息触达方法延迟增加30ms

演练监控方法执行的成功率和 TP 999:

场景二:分流服务-JAVA进程满载,指定分流进程CPU满载

监控平台实时观测系统的CPU使用率:

5.6 演练反馈

检查系统故障发生时候监控手段是否完善,研发人员是否可以根据系统告警,快速的定位并解决问题。检查团队的响应、协同效率。

邮件事故告警:

事故恢复告警:

5.7 环境恢复

场景演练可等待演练时长结束后自行中止,也可根据手工取消、终止演练场景。

演练完成后建议需要重启容器,保证服务恢复正常状态。

5.8 演练复盘

演练结束之后,我们需要对演练进行复盘。不同的故障下,系统的表现以及整体业务场景所受到的影响,演练过程中所发现的问题,需要在复盘报告中呈现出来。

6.总结

链路演练通过提前主动注入故障,发现系统之间的强弱依赖,对链路进行检验,降低生产环境中故障发生的概率。

“居安思危,思则有备,有备无患。”

作者:京东科技 孙民英

内容来源:京东云开发者社区

与混沌演练实践(二)-支付加挂链路演练相似的内容:

混沌演练实践(二)-支付加挂链路演练

当前微服务架构下,各个服务间依赖高,调用关系复杂,业务场景很少可以通过一个系统来实现,常见的业务场景实现基本涉及多个上下游系统,要保证整体链路的稳定性,需要尽量减少系统之间的耦合性,避免因为单点失效引起整个链路的故障。

混沌演练实践(一)

混沌工程是通过主动制造故障场景并根据系统在各种压力下的行为表现确定优化策略的一种系统稳定性保障手段,简单说就是通过主动注入故障的方式、提前发现问题,然后解决问题规避风险。

RocketMQ为什么要保证订阅关系一致

这篇文章,笔者想聊聊 RocketMQ 最佳实践之一:保证订阅关系一致。 订阅关系一致指的是同一个消费者 Group ID 下所有 Consumer 实例所订阅的 Topic 、Tag 必须完全一致。 如果订阅关系不一致,消息消费的逻辑就会混乱,甚至导致消息丢失。 1 订阅关系演示 首先我们展示正确

[转帖]【混沌工程】 docker环境下模拟网络延迟和丢包

https://cloud.tencent.com/developer/article/1616202?areaSource=&traceId= 原文地址:https://www.chenquan.me/archives/315 混沌工程最早是Netflix引入的,用来验证服务稳定性的工程。地址:h

助力618-Y的混沌实践之路

混沌工程,是一种提高技术架构弹性能力的复杂技术手段,旨在将故障扼杀在襁褓之中,也就是在故障造成中断之前将它们识别出来。通过主动制造故障,测试系统在各种压力下的行为,识别并修复故障问题,避免造成严重后果。

[转帖]中国混沌工程调查报告2021(观点摘要,调查背景和混沌工程应用现状)

https://www.jianshu.com/p/9de94066ab46 随着分布式架构的普及以及云计算技术的成熟,国内企业应用云原生化推进业务系统的迭代速度越来越快,后端系统架构日趋复杂,服务间的依赖越来越多,调用的链路越来越长。宕机引发巨额损失、严重影响用户体验的新闻层出不穷,为了让云基础设

[转帖][译] 基于 Envoy、Cilium 和 eBPF 实现透明的混沌测试(KubeCon, 2019)

http://arthurchiao.art/blog/transparent-chaos-testing-with-envoy-cilium-ebpf-zh/ 译者序 本文内容来自 2019 年的一个技术分享 Transparent Chaos Testing with Envoy, Cilium

主动发现系统稳定性缺陷:混沌工程

这是一篇较为详细的混沌工程调研报告,包含了背景,现状,京东混沌工程实践,希望帮助大家更好的了解到混沌工程技术,通过混沌工程实验,更好的为系统保驾护航。

[转帖]Nginx惊群效应引起的系统高负载

https://zhuanlan.zhihu.com/p/401910162 原创:蒋院波 导语:本文从进程状态,进程启动方式,网络io多路复用纬度等方面知识,分享解决系统高负载低利用率的案例 前言: 趣头条SRE团队,从服务生命周期管理、混沌工程、业务核心链路治理、应急预案、服务治理(部署标准化、

[转帖]没 K8s 用不了 Chaos Mesh?试试 Chaosd

https://cn.pingcap.com/blog/cannot-use-chaosmesh-without-k8s-then-try-chaosd Chaosd 是什么? 相信大家对 Chaos Mesh 已经比较了解了:支持多种类型的混沌实验,有 Dashboard web 界面直接管理实验