前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >故障管理工作方法和技巧分享

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

作者头像
小小科
发布2018-05-02 16:24:15
1.1K0
发布2018-05-02 16:24:15
举报
文章被收录于专栏:北京马哥教育北京马哥教育

做故障管理这么久,对怎样才能做好这个工作有一些切身感受,除去一些只可意会不可言传的部分,这次我把能想到的工作技巧都总结出来了。 由于这个岗位不是互联网公司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都有你的一份贡献!

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2015-04-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 马哥Linux运维 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档