BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

拥抱故障,你可以吗?

| 作者 丁雪丰 关注 4 他的粉丝 发布于 2013年4月19日. 估计阅读时间: 4 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT