周六下午处理了个故障，我发现，真的故障了，就说明那些所谓稳定性保障措施，已经不 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
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论