写点什么

配置引起事故复盘

用户头像
风翱
关注
发布于: 2021 年 03 月 20 日

记一次线上事故的复盘:一个配置引发的血案。


一天晚上的业务高峰期,app 出现了超时(数据加载不出来的情况)。

联想到前一天有发版的工作,一:功能上并没有太大的调整,此次发版内容更多的是新增的功能,用户使用量也较少,基本可以排除因功能导致的问题;二:是否中间件出现问题,因数据的交互,有 80%是和 redis 交互,从慢日志查询中未发现有异常情况;三:隐约有人说过用于负载的服务,昨天发版关闭掉了一台。

通过 netstat -an |grep 'ESTABLISHED' |grep -i 'port' |wc -l,可查看连接数的情况。

从上面的命令查看到当台服务已经到了瓶颈,然后立即从配置中查看,确实只有一台对外在运行着的。

处理方法:立即启动另外一个服务,修改配置后,验证。业务已正常运行。

 

和昨晚参与发版的人员核对,昨晚关闭掉一台负载的原因。说是因为启动两台时,出现新加的功能,调用新的服务会出现报错的情况。因未找到原因,和运维沟通后,最后决定只起一台服务。

听完说明后,第一个联想到的就是配置的 ip 和端口是否正常? 一看配置,ip 是本地 IP,问题已定位。修改本地 IP 为域名,功能正常。


此次事故,有多个环节可避免掉事故的发生。结果各个环节上都出现了疏漏,导致了此次事故的发生。

一、上生产环境的 IP 配置,统一采用域名的方式。这个是约定,因开发人员不清楚线上域名的情况,未能执行好。

二、运维是部署线上环境的第一人,各服务运行在那台对应的机子上,是最为清楚的一个人,对配置的检查,需要把好最后一道岗。因习惯,未对新增的配置进行审查。

三、对于此次问题的处理,在一定程度上也是可行的方案。但是缺少了数据的支持,未做好测试、评估的工作。在用此方案处理后,未及时反馈给相关人员。

四、对线上运行环境有一定了解的技术(开发)人员未在场。

 

对于以上问题,解决的方法有很多种。但方法是对于特定问题,而提出的解决方案,是针对特定的场景和特定的人的,对于场景和人的依赖性比较大。有没有什么其他方式可以采用呢?


将方法上升到流程规范,让它具有一定的普适性,有具体的步骤或标准,让每个人都可以执行。减少对人的依赖。

例如:

一、上面的问题,规范上加上明确的说明(可增加上线检查清单),生产环境只能采用域名的方式。开发人员或运维人员,其中一人都可以排除此问题。

二、对线上环境的调整,需要根据数据(业务高峰期的访问量等指标)进行评估、验证,才能进行调整。调整后需要通知(反馈)给相关人员。

 

流程规范,是可以提高团队效率的,避免一些问题的。 从个体来看,因为流程规范的存在,可能存在效率降低的情况,但从团队的角度来看,好的流程规范是可以提高效率的。

上面的问题,通过制定规范去避免,执行得当,是可以提高效率避免问题的。多一步的检查,却少了线上问题的出现,也减少了其他人员排查定位的时间,可谓一举多得。


发布于: 2021 年 03 月 20 日阅读数: 18
用户头像

风翱

关注

还未添加个人签名 2017.11.24 加入

勇于尝试,持续成长

评论

发布
暂无评论
配置引起事故复盘