故障管理工作方法和技巧分享

做故障管理这么久,对怎样才能做好这个工作有一些切身感受,除去一些只可意会不可言传的部分,这次我把能想到的工作技巧都总结出来了。 由于这个岗位不是互联网公司6大核心工种(产品、技术、运营、设计、市场销售、职能类),为了大家能够理解这个岗位是做什么的,我从这6个工种中找了个亲戚,就是“运营”。 故障管理工作可以做为产品运营工作的补充,或者是从另外一个方向进行的特殊运营工作。 为什么这么说呢? 运营是通过正面的、友好的的方式对网站产品进行干预,核心目的是:拉用户使用产品-让用户用到爽-愿意留下来-愿意多呆一会-沉默和走掉的用户愿意再回来。 而故障带来的影响往往是负面的、伤害用户的,运营卖萌装嫩写段子,砸钱做活动传口碑,可是一个大故障就足以让运营所有的努力打水漂。 故障管理的核心工作是“降损止损”,经过我们的干预,少发生这种容易给用户心理造成影响的伤害事件、让已经发生的负面事件对用户功能使用、体验、和心情上的伤害尽量减少。目标和运营是完全一致的:请用户留继续留下来,还和我们一起玩。 另外一方面,运营的工作繁杂、苦逼、多变、高压、要随时当临时工争抢热点,要半夜看群盯老板的新关注点,处理VIP用户的特殊需求,帮着小明星加个橙V啥的。 故障组的工作几乎一样,随时待命、马上组织人救火、半夜招呼起一帮程序猿处理某明星公布离婚让我们服务器君群死翘翘的问题,有时当客服联系用户问他到底怎么了?有时扮演攻城狮向用户道歉,有时给运营专员处理个紧急需求,迅速找人查查老板在国外咋发不了图等等。 所以我总结的这些技巧,如果对非故障管理岗的同学也部分试用,那就太好了。 故障管理工作技巧共10点: 1. 【积极主动】 在大型互联网公司,一些不涉及KPI 、干了不出彩倒容易出故障、 不干也没人追没人愿意认领的活其实有很多,做这个工作如果没有积极主动的推进精神,那不管是问题跟进、故障响应、还是故障讨论都根本无法进行。 2.【要事第一】 Ø 如果故障来了,你还盯着一个小BUG不依不饶,那真是没救了 Ø 在我们这,救火同样如救命,容不得你左思右想,顾此失彼延误故障上报可不是闹着玩的 3.【遵循流程】 Ø 所有工作都需要按照现有流程来,不能随意改动 Ø 要知道这些流程是多少人踩过坑,罚过款,流过泪后总结出来的 4.【明确问题】 Ø 负责“指哪打哪”的故障组首先弄清楚现在到底发生了什么事情,然后再快速准确传达出去,没有比这个更关键的了 Ø 如果所有人报上来的问题,故障组不加任何分辨、筛选、甄别、测试就直接当故障报给技术,轻则让程序猿日夜不得安宁,重则直接把技术带沟里,明明是FEED问题,却说成登陆问题,完全是不同的两拨程序猿负责,因此带来的故障时长增长、用户流失、收入损失都是无法挽回的 5.【高效执行】 Ø 疑似故障响应不到位,最后演变成故障的数量就会增多 Ø 故障跟进不到位,就会导致故障级别升高 Ø 故障原因挖掘不到位,就无法有针对的提出改进措施 Ø 改进措施落实不到位,同类故障还会发生 6.【信息共享】 Ø 故障和问题的持续性、复杂性、跨部门等特点 Ø 故障组值班内部交接班容易漏掉信息 Ø 故障时团队多人分工合作,只有列出已做事项,才能避免重复和遗漏工作 Ø 故障组接受北京、广州、天津三地客服报障,点对点联系会导致沟通效率低下,多方信息不对称 Ø 故障时无法及时记录每个操作步骤,信息共享方便通过完整聊天记录对故障进行复盘 Ø 方便未参与处理同事通过记录对故障快速了解,及时补位 7.【持续跟进】 Ø 问题和故障响应切忌“等待”“自以为” Ø 故障往往不会一下就定位原因,需要持续和多部门沟通进展 Ø 故障即使在原因初步定位后也不能放松警惕,原因定位可能出现偏差 Ø 故障解决后仍需客服继续关注投诉,故障组继续关注监控,以验证问题是否彻底解决 Ø 疑难问题短时间无法彻底解决,需要阶段性的跟进解决方案 Ø 当跟进遇到困难时,不能退缩,需要报告主管寻求帮助,确保问题得到持续跟进 Ø 当工程师未明确给出问题已经解决答复时,不要“自以为”问题已经解决。 8.【不断质疑】 我们不是传声筒,而是会思考、有想法、能判断、求真像的独立个人。 遇事请多问几个为什么? Ø 事情是对方说的那样吗 Ø 故障原因说得通吗 Ø 故障关键时间点正确吗 Ø 改进措施制定得合理吗 Ø 故障为什么没能提早发现 Ø 有监控为何还是没能报出故障 Ø Dashboard起作用了吗 Ø 本次故障和历史故障有哪些不同和相似 Ø 本次故障暴漏了哪些问题 9.【保持敏捷】 故障组同学需要有极强的故障敏感性,当一个事件刚开始出现时要有判断是否会演变成故障的能力。 Ø 影响产品重要功能吗 Ø 是V用户或者重要身份用户吗 Ø 涉及账号安全、隐私吗 Ø 涉及现金货币吗 Ø 影响公司形象吗 Ø 涉及数据丢失吗 Ø 问题有演变成故障的趋势吗 Ø 故障有演变成AB级的趋势吗 Ø 马航等突发事件有服务压力激增风险吗 10. 【团队合作】 请时刻记得:你不是一个人在战斗! Ø 故障管理组全员都是你的坚强后盾,严重故障时全组同学都会参与响应! Ø 主辅、外包和组内要求明确分工,通力合作、故障响应要求快速、故障通报要求严谨专业、避免工作重复且不能落下重要环节、避免多人同时通知同一位工程师 Ø 根据故障阶段提前准备通报内容、多个渠道通报内容要求一致 Ø WB-消防队有好几百号人,平时从不闲聊,故障时都会第一时间出现! 正是因为有你们的支持和配合,多少个并不美妙的夜晚和我们一起渡过,所以今年Q1的可用性才达到好几个9,每一个9都有你的一份贡献!

原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2015-04-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据架构师专家

七字诀,不再憋屈的运维

2403
来自专栏睿哥杂货铺

DevOps 漫谈:从作坊到工厂的寓言故事

谈到 DevOps 概念,有几本书是绕不过去的,《凤凰项目:一个IT运维的传奇故事》(The Phoenix Project:a Novel About IT,...

4228
来自专栏大数据文摘

用脑电波代替密码的时代来临了吗?

1691
来自专栏CSDN技术头条

专访天数科技创始人兼CEO李云鹏:充分尊重工程师的个性差异

李云鹏,天数科技创始人兼CEO;曾任美国甲骨文公司全球研发总监,从事甲骨文数据库10g至12c的研发工作。日前,笔者采访了李云鹏,请他分享国内外数据库发展的差异...

2257
来自专栏大数据钻研

稀土

致每一位加入稀土团队的你,我们到底在为怎样的一群人服务? 每一个公司、每一个产品都有它创立的意义,这篇文章只是希望帮助加入稀土的你们了解我们是一个怎样的公司,在...

3065
来自专栏Fred Liang

2018.7.22 每周分享

仓库网址:https://github.com/google/data-transfer-project 官网:https://datatransferpro...

853
来自专栏工科狗和生物喵

一个机械人到半只程序猿的进化之旅

开篇语 好吧,名字是不是很有新意?写出来的刹那我差点在自习室感动到落泪,但是后来想想,好像有点文不对题啊~~但是谁叫这个标题这么帅呢?一向务实的我都忍不住败倒在...

45010
来自专栏腾讯技术工程官方号的专栏

TDSQL在巴黎ICDE上设立展台,掌声送给它!

4087
来自专栏罗超频道

微信支付触手可及:与招商银行“打通”

罗超为雷锋网、虎嗅网及爱科技网撰稿,发表于2013年4月8日雷锋网、虎嗅网及爱科技网首页。 前几天笔者发表《类微信APP,移动互联网第三大入口?》一文后,有一个...

3766
来自专栏Java学习网

程序员应该扪心自问的10个问题

程序员应该扪心自问的10个问题 想成为一名web开发人员?那么,扔掉《24小时突击掌握xx语言》这类骗子书籍。你应该养成一个习惯,每天问问自己下面这10个问题。...

2635

扫码关注云+社区

领取腾讯云代金券