纪录一次真实的系统故障总结

Posted by 启示录 Blog on May 31, 2016

2016年5月29日,这个是第一次遇到系统商业故障。以前只在书中和微博上面看到过这样的案例,没有想到会发生在自己身上。这是一次宝贵的经验。

事故原因:在阿里云购买服务器之后再次升级配置。如果需要配置生效,需要重新启动系统。而系统重新启动只能依靠阿里云控制面板去软重启,不能在系统中执行reboot命令重新启动。正是因为如此导致系统多次启动失败。

事故结果:所有系统下线,门店无法正常收银,线上无法下单。持续时间2小时

事故处理流程:事故发生时间是中午12时02分。当事故发生2分钟后发现第二次重启无法正常启动时,通知运营人员收银时手工记账处理,线上售卖系统瘫痪。10分钟后多次启动无效,提交阿里云工单并且电话咨询。整个工单处理持续三十分钟,给出的阿里云服务官方提供的解决方案是:重新初始化服务器。从13点开始初始化服务器,重新配置环境上线。14:03分通知运营人员基本运行,保证基本运营。15:00左右恢复所有服务,正常运行。

回顾整个事件,总结出以下几点:

  1. 遇到紧急故障,最好的是平复一下心情。保持思路清晰。否则会导致越来越混乱。最样的事情一次两次无法学习到,但需要让自己去这样处理
  2. 线上发布的代码版本需要预留备份,多份预留。可以使用git,拥有可撤销服务的网盘等.对于关键性的配置信息也需要留备份存档。节省恢复事件
  3. 上线时,应对系统进行临时的优先级划分。譬如在这个过程当中,先上线主服务,保证线上与线下售卖,然后再依次上线计划调度任务、备份服务等
  4. 服务器升级或系统升级更新时需要做备份服务,服务器升级无法正常服务器启用临时服务器继续提供服务,系统发布时留有备份,新版本有问题时立即回滚。在这个过程中,在更新版本时我是按照日期的形式命名。
  5. 服务尽量拆分,值得庆幸的是。数据库服务使用的是RDS。数据没有受到影响。但是缓存服务是自己搭建。把尽量把故障的单位缩小。
  6. 思考时想到此种解决方式的最坏情况。当思考好之后,要做出果断的决定。不要犹豫。
  7. 对于线上服务升级更新时,估量业务的高峰时段,避免业务高峰期。否则会损失更加严重。
  8. 阿里云不是万能的,云服务也有不可靠的时候,如果有资金最好是多选择一个篮子存放“鸡蛋”。在提交工单后,售后工程师说可能需要重置服务时,当看到回复就想到阿里云那边可能也无法解决。这时候要立即改变思路,开始准备重做服务。经过10分钟之后售后工程师说还是无法启动需要重新初始化,而这时已经完成了系统初始化开始配置环境。
  9. 在优化系统时,不能忽略系统的可用性和性能之间的关系。多想一想是否只优化性能没有优化其它的方面。虽然每次优化性能,性能有所提升,但是相对于服务不可用来说,性能在这里就显得没有那么重要了。在做系统可用性时,当时只考虑到软件的可用性而没有考虑到服务器的可用性。可用性是一个整体,不应只分软硬。需要做到真正的服务可用性。
  10. 敢于承担责任。