拥抱故障，你可以吗？

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

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

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

1. 遇到故障时的处理方式

2. 故障事前与事后的工作

3. 故障与KPI的关系

4. 在故障中学习成长

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

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

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

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

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

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

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

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

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

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

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

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