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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

建了个SRE群，第一个已经满了，没法再加人，开了第二个，大家如果有兴趣可以加我微信，我邀请进群，我的微信号，关注公众号就可以看到，或者回复“微信”关键字。