阿里云崩 咸鱼崩 淘宝崩...运行集群缺点后智能复原测试之进程自我拉起应该怎样做 钉钉崩

往年的11月12日，也就是双十一的第二天，阿里云崩了!!!经常使用阿里云服务的一系列阿里软件，淘宝，咸鱼，天猫，钉钉、阿里云盘等阿里软件，全都崩了，一下就上了微博热搜，我司作为阿里云经常使用客户也遭到了影响，特意是mq等组件;

淘宝天猫自去IOE后取得渺小成功，阿里云也从蚂蚁个人的体系中独立进去给环球企业提供云服务，不久前在云栖大会上都还在分享阿里云如何如何的高效撑持业务，包含前几天的双十一阿里云也抗住了购物洪峰压力，然而没想到双十一第二天就崩了，这曾经是影响环球经常使用阿里云的客户的重小意外;

经过阿里云推送的信息显示整个事情环节

尊崇的客户：

您好!北京期间2023年11月12日 17:44起，阿里云监控发现云产品控制台

问及API调用出现意外，阿里云工程师正在紧急参加排查。十分道歉给您的经常使用带来不便，若有任何疑问，请随时咨询我们。

--停顿更新

17:50 阿里云已确认缺点要素与某个底层服务组件无关，工程师正在紧急处置中;

18:54 经过工程师处置，杭州、北京等地区控制台及API服务已复原，其他地区控制台服务逐渐复原中;

19:20 工程师经过火批重启组件服务，绝大局部地区控制台及API服务已复原;

19:43 意外管控服务组件均已成功重启，除一般云产品 (如信息队列MQ、服务MNS) 仍需处置，其他云产品控制台及API服务已复原;

20:12 北京、杭州等地区信息队列MQ已成功重启，其他地区逐渐复原中。

21:11 受影响云产品均已复原，因缺点影响局部云产品的数据 (如监控、账单等)或许存在提前堆送状况，不影响业务运转。

这次十分重大的P0级意外，以至经常使用阿里云服务的客户的损失十分之大。

上一次性阿里P0级意外是在10月24日的语雀平台缺点8小时，最后复原服务之后补救了用户6个月的会员;

上一次性阿里云大面积主机缺点的P0级意外是2022年12月，阿里云香港地区出现超越12小时的继续性缺点。经过以上缺点事情，在高可用的运行集群中，出现节点缺点，进程能否能够启动自我拉起从而成功复原呢? 我们当天聊聊运行集群缺点之进程自我拉起场景。

首先是进程概念：

一个正在运转的程序或许软件就是一个进程，它是操作系统启动资源调配的基本单位，也就是说每启动一个进程，操作系统都会给其调配必定的运转资源(内存资源)保障进程的运转。

运行集群缺点后智能复原测试之进程自我拉起测试场景：

当服务的进程意外挂掉后，能够智能将进程拉起，复原服务，成功高可用;

测试目的：

调查服务进程自我拉起有效性。

测试步骤：

1、测试场景驳回混合买卖模型买卖配比;

2、测试口头时，采取稳固压力施压，以被测试系统最大处置才干的80%或预设压力，稳固运转5分钟;

3、经过kill -9命令 kill 掉某进程;

4、场景继续运转5分钟，经过PS -ef|grep 服务称号，命令观察被kill 的进程能否智能拉起。

预期结果：

步骤3后，进程被Kill;

步骤4后，进程自我拉起。

监控点：

TPS、买卖失败率、系统资源经常使用率等。

测试目的：

服务进程自我拉起有效性(除了能够拉起还有时效要求，为60秒之内)为有效。