面试常见问题-线上故障处理

March 29th 2019 | 日常

1、发现问题。需要完善的监控系统、对网络,服务器cpu、负载、io、内存、连接数(文件句柄数)以及应用系统性能、异常日志进行全访问

2、定位问题。分析问题发生的根源,思考是否对网络、硬件、应用进行升级,或者超过系统的承载量导致问题的发生

3、解决问题。尽快处理问题,恢复系统的正常运行,降低因系统故障对平台造成的损失

4、消除影响。恢复应急过程中对系统临时性改变,尽快的采取补救的措施,降低对客户的影响

5、回顾问题。分析问题的发生原因,如何解决,怎么避免问题再次发生

6、采取措施。对问题发生的原因,避免方法采取行动、执行相应措施

实例

  在一个阳光明媚的周一上午,当我们正准备开始一周工作的时候,运维组的突然跑过来告诉我,

十万火急的问题出现了,销售,采购,库存这几个核心模块都无法使用了,早上9点前还好好的,现

在运维组的电话都已经爆线了,所有人都手忙脚乱的向用户道歉。

       我马上找组里的开发和配置人员进行确认,有没有人动过数据库脚本并让配置人员进行了发布,

因为公司现在有权限的直接操作PRD数据库和PRD环境的人比较有限,一般都需要通过配置人员来

完成操作,其他人是不会有权限直接执行的。

       配置组的同事告诉我,刚才的确是执行了一个脚本,但是这个脚本是在QAS环境执行通过了的

而且只花费了几秒钟时间,刚才他在PRD环境执行时,却执行很慢,而且他终止了执行。

       一查才知道,上周有个任务让他优化数据库的查询,他考虑将客户表的索引改变下,由于是周

一,用户量比较大,而且执行的脚本是先将原索引去掉,然后再建,但是新索引没有建好就失败了。

所以进销存模块进入时都超时了,系统业务无法完成了。

       原因找到了,那就要马上采取相应的对策了,我们和运营组的协商后,在运维老大的许可下决定

马上将所有在线用户从服务器上踢掉,然后关闭服务端,立即执行脚本,再开启所有的服务端,所有

操作需要在10分钟内完成。

       很幸运,我们用5分钟的时间完成了所有操作,总算解决了燃眉之急,松了一口气。不过接下来

我们要做的是对这次的事故总结,因为有人不小心,没有按照操作流程做了一件自认为很简单的事

情,在晚间执行或者在测试环境,当然没有什么影响,但是PRD环境就不一样了。所以我们在发布

系统或者执行脚本及其他操作时,一定要考虑PRD环境的特殊情况。而且执行这些任务一定要在规

定的时间进行,当然有特事特办的情况,但是也要酌情考虑。