故障处理为什么要以人为本?

阅读数:1 2020 年 3 月 17 日 22:12

故障处理为什么要以人为本?

周六下午处理了个故障,我发现,真的故障了,就说明那些所谓稳定性保障措施,已经不 work 了,已经失效了,因为真的 work,就不会故障。

既然既有手段已经失效,咋办?唯一的办法,就是靠人,靠有经验的人。

在最短的时间,找到最正确的那个人或那几个人,才是最关键的。

为什么这么说?昨天我大致统计了下,25 分钟在讨论该找谁协调和推进,找到了(因为是云的技术同学),花了 15 分钟授权,并从外网登上来,然后 10 分钟确认问题,5 分钟解决问题,20 分钟打电话找各个业务方确认问题是否解决。

你看,其实整个环节里面,真正靠技术解决的环节只占了很少一部分,而找到正确的人之后,往往比工具更好使,真正解决问题的时间也很短。

但是从整体上讲,如果真的想缩短故障时间,整个响应处理的环节上都有很大的改进空间,不要老想着一定要通过那些高大上的技术手段才能解决问题。

为了保障系统在线,建设确保关键角色能够随时在线的机制,或许跟技术层面的稳定性建设是一样重要的。

其实从 SRE 的角度,国外大厂即使已经那么牛了,还要建立起严格的为什么要建设严格的 oncall 机制?

这说明,即使有再完善的稳定性保障性技术体系,仍然都是辅助手段,其实核心还是人,靠有经验的人。我觉得这个短期内,各种 AIOps,或者什么智能手段,短期内替代不了人的作用的。

我再说两个国内的例子,也可以从侧面印证这个逻辑:

我之前给运营商服务的时候,也是三天两头被诟病,甚至被喷处理问题效率慢,故障时间长等等,后来为了提升响应效率,PE 和开发同学,到了家马上打开电脑,拨上 vpn,甚至直接登录到某些经常出问题的系统主机上,为了保证超时不断,还要自动执行些任务,或者通过 terminal 的防中断功能,就是为了半夜有问题,接了电话马上就能上去处理,效率确实提升很多。

前几天,我跟团队前阿里的同学聊,也就几年前,阿里的 PE 和开发也是这么干的,没办法,出问题了真的要争分多秒。

第二个例子是钉钉,钉钉在每天早上会有一波使用高峰,因为很多政府或事业单位上班比较早,8-9 点就工作了,而这个点正好是互联网公司员工上班路途上,之前就出现过,出了故障,客户不能用钉钉,但是人都在路上没法处理问题,导致故障时间过长。

所以后来,为了保证及时响应,大家都是分批上班,有一批人就是从早上 6、7 点开始盯在电脑前面,有问题第一时间响应,然后另外一批就准时上班,到了公司,在家值守的同学开始陆续从家里出发,可能是 10 点或 11 点等等。

这种错时保障机制,我们自己在大促期间也经常用,就是确保关键角色必须在线,随时应急响应。

所以,可以更深刻的理解一下 oncall 机制,背后核心是人,且有高效的流程机制保障人员在线(能找到且快速上线),再辅以高效和完善的技术体系和工具支撑,整个机制体系要经过不断的演练磨合改进。

现在很多情况是,大家都去搞工具了搞技术,反而忘了人这个关键因素,既没有流程机制保障,也没有演练磨合,出了问题,任你技术再完善,还是两眼一抹黑~

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/zcPG3q85gO7j2Tu6btKIqA

评论

发布