拥抱故障,你可以吗?

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

看google,twitter的运维经验,其中强调一点#拥抱故障(事故)#,不知道你们的运维团队是怎样#拥抱故障#的。出现故障时,整个团队 的第一反应是要兴师问罪,还是集体齐心修复问题,又如何真正做到拥抱故障呢? @南非蜘蛛 @守住每一天 @sunli1223 @幸福山大 @wilbur井源 请赐教。

讨论大致分为了几个部分:

  1. 遇到故障时的处理方式
  2. 故障事前与事后的工作
  3. 故障与KPI的关系
  4. 在故障中学习成长

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

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

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

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

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

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

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

谈完KPI这么沉重的话题,再来谈谈成长,大家都认同故障是个学习的好机会,从一次故障中获得的经验,也许能比得上日常工作中的无数个日日夜夜,在发生故障时,越是冲在第一线的人,就越可能收获更多的东西。@幸福山大在微博中说到:

每次故障都是宝贵的改进机会。故障分故障前、中、后三个阶段,故障前预案充足,快速发现;故障中快速定位,恢复,止损,通告等;故障后深入分析,整理,回顾,改善预案,分享等。经常碰到故障的人往往成长的更快。

@CodeBox-腾讯为大家形象的描绘了一幅故障处理的人物速写:

默默解决故障的人、站着说话不腰疼的人、搅混水逃避责任的人、不懂装懂搞无理头的人、追究责任的人、事后诸葛亮的人,最后还有把总结邮件弄成CCTV表彰晚会儿的人。

亲爱的读者朋友,您会对应上述哪种人呢?您能否做到“拥抱故障”呢?不妨来分享一下您的故障处理经验吧。

丁雪丰 是InfoQ中文站编辑,满江红翻译组核心成员,出版过《Spring攻略》、《JRuby实战》等多部译著。主要关注领域:企业级应用、海量数据计算、动态语言应用等。

This entry was posted in Best Practices. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s