centOS一次版本升级事故记录和复盘

336 阅读3分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第17天,点击查看活动详情

故障背景

    1、git仓库不支持在centOS 5.7版本的系统上部署代码

    2、目前前端机器系统均为cenOS 5.7,php尚处于php5.6,我们最新的稳定版操作系统为centOS 7.3 ,php 7.1.8

    3、我们的sessionkey加解密代码需要用到mcrpto模块组件,该组件因为设计有缺陷在php 7.2的版本中将会被移除不再支持,所以

我们再升级前端服务器生成环境之前,必须对加解密代码进行更新,使用openssl和新加密算法进行替换

故障具体情况

从机器的cpu负载情况上来看,事故发生在22日凌晨0点半,然后引起机器的连锁反应,所有前端ECS服务器宕机,直到凌晨3点客服接到第一通反馈,而相关技术人员接到反馈的时间是22日8点30,中间定位问题修复服务用了1~2个小时,所有业务直到22日10点才逐渐回复正常,而中间时间段因为升级故障而导致的服务可不用一共产生了104个差评,根据淘宝服务市场的规则,我们大概需要新增5000多个好评才能消除这些差评对我们应用的评分影响。

故障发生原因:

  • 2月份前端机器升级centOS7 php7因为osc连接问题失败,生成环境由centOS5升级至centOS7又回退centOS5;

  • centOS7用户为aiyong,centOS5用户为root,回退时项目权限更变找不到相对权限的用户,默认所属人为1000

企业微信截图_13ead0fa-4ab3-48c3-8eed-c9924433f307.png

  • 新加解密算法升级后,为了快速验证功能是否稳定,清理了所有相关日志,并重启php-fpm,nginx重新生成和刷新opcache缓存

  • 日志被清理,并且php-fpm重启,因为项目用户所有权为1000,sms.aiyongbao.com项目在$this->loginfo 时得不到文件打开权限无法输出日志,从而产生慢php-fpm

D9565B56-7365-4A2B-8B6F-6DAF46FFDF89.png

  • 前端php-fpm的max_chilrend为200,因为慢php-fpm的原因进程堵塞,所以前端机在修复中时而业务正常,时而业务499处于不可用状态

  • 为文件重新赋予权限,重启php-fpm解决该故障。。。。

总结和今后应避免故障的几个措施:

        该次故障影响面比较重大,而且不易被测试测出,21日当晚升级时因为压力问题均没有及时报出类似问题,上线后虽然关注了phpError日志,但是并没有关注slow日志才导致机器负载在凌晨达到瓶颈从而爆发问题。而且因为咱们监控不到位的原因,得到有效反馈和开发进行技术支持的时间已经是第二天早上8点以后了。为了防止今后的重大、平常升级又会造成如此影响,我们决定试行一下措施:

    1、监控业务不能只关注机器的高负载、压力情况,还需要全面监控到业务的执行,需要监控到所有业务是否正常活动,并输出有效的可视化界面;

    2、升级以后需要查阅至少半小时所有相关业务执行日志,包括且不仅限于access、error和slow

    3、有重大影响的发布(服务器升级、业务功能模块重构……)要写相对于的发布方案;

所有发布需要有慢节奏等比例的灰度发布方式;

         为了减少故障产生后影响,也为了及时得到寻常测试触达不到的业务压力点,今后所有发布和升级必须放到早上发布,方便及时处理和及时得到用户反馈;

    4、发布和升级需要有完善的回滚方案以及灾备的预案;