微信号:infoqchina

介绍:有内容的技术社区媒体

拥抱故障,你可以吗?

2013-04-18 16:20 InfoQ

4月14日,百度工程师@肖平_Jacky发布了一条微博,立刻引来大量的评论和转发,阿里、腾讯、百度、新浪等公司的运维工程师纷纷发表了自己的观点,微博内容如下:


看google,twitter的运维经验,其中强调一点#拥抱故障(事故)#,不知道你们的运维团队是怎样#拥抱故障#的。出现故障时,整个团队的第一反应是要兴师问罪,还是集体齐心修复问题,又如何真正做到拥抱故障呢?


新浪的高级运维工程师@守住每一天表示,在遇到故障时应该做到沉着冷静,着急容易引起更多的问题,按照故障流程处理,判断故障级别并通知相关人员,一切以保证业务为最高优先级。待故障过去之后,再来分析故障的原因:


有成熟的模板,需要写明深层的原因,与改进建议,完成时间点。其实有故障对平台来说也算半个好事吧。其实最难的地方就是原因,有些不想写实际原因,这个可能会导致问题复发的。


事后分析的重要性不言而喻,@运维老周将其提升一个高度——“故障后的深入分析做得好坏,最能体现一个运维团队的责任心意识。”支付宝@灵魂黑客_舵主的一句“要做好故障分析而不是故障责任分析,同一问题不要再犯”道出了大家的心声,故障分析会之后,就应该做到避免同类故障再度发生,19楼的@幸福山大为大家分享了他眼中的预案:


这是预案的处理,预案不仅仅是故障预案,预案需要充分评估系统的设计和风险,需要分析各层依赖,需要考虑各种情况下面的应对方式,需要各方资源来协作,预案也需要不断地演习验证和改进,预案做好比故障更难。


在很多公司,故障都会与绩效挂钩,谈到故障,自然也免不了谈谈KPI。去哪儿网的孙立就表示:


我们有统一的故障处理流程。出现故障第一步是要快速修复故障,把损失降到最低。故障处理完毕,需要参与的所有人一起review,分析原因,监控,怎么避免这类问题等等。不能容忍的是同一个故障老出。处理故障的能力可以和kpi挂钩。


除了故障处理能力,故障本身也会和KPI有关联,故障KPI往往直接由运维团队承担,但其实开发团队也该来分担一部分压力,大家都注重线上故障。土豆网的@老黄就认为这是“公司根儿上的问题”,不容易轻易被改变。公司越大,大家则越难真正“拥抱故障”。


拥抱故障,你可以吗?点击“阅读原文”查看更多内容并吐槽吧。

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 解决首次启动程序白屏时间过长的问题 MainDexList产生过程源码分析 从大佬一抓就死说起 达内培训课程的高端合作支持,你造吗 最全大数据学习资源整理