蝴蝶效应: 是美国气象学家爱德华·洛伦兹(Edward N.Lorenz)1963年提出的一个效应:一只南美洲亚马逊河流域热带雨林中的蝴蝶,偶尔扇动几下翅膀,可以在两周以后引起美国得克萨斯州的一场龙卷风。用来形容不起眼的一个小动作却能引起一连串的巨大反应。
老朋友应该知道我所处的公司近来变化较大,最近更是事故频出,压力山大。最近发生的一起小事故很有意思,特意分享给大家。
事情是这样的~
事情的起因是生产技术架构优化,我们将生产web机模块的服务器,分拆出来1/2的机器改造为swoole,同时将一部分耗时较长的长时接口分流到特定的服务器。
理论上这是一次不大不小的变更,且能实现平滑无感知。但在实际操作过程中还是出问题了,本质原因是我们没有匹配的测试环境做上线模拟,背后的原因和本质原因都不是我们本次要讨论的重要,我要分享的是出问题后的处理过程。
这次的配置变更主要是通过修改nginx配置实现。nginx的配置生成我们也早已经通过模板工具批量生成实现,在生产环境的统一管理验证下来,效果还不错。
但是....
最近几个月,频繁的线上架构改造和问题修复,工具已经离线大概有2周了,而本次变更的目标也是统一配置,上线配置工具。这意味着:
因此,还是有一定风险的。
那理论上正确的做法应该是:
但是...
我们只做了6、7。
这导致直接的后果上,配置刚上线就发现有问题~ 最近老板盯的紧,且按照规则,我们决定回退代码和nginx配置。
但是...
我们发布平台最近在做迁移,新的发布平台还不支持回滚操作,而业务运维却并不知晓....
业务运维决定手动回滚版本~
这时...
业务负责人提醒到,回滚版本明天记得邮件出来说明回滚原因...
这一句话份量太重,大家接不住...所以,大家决定硬着头皮修复问题...
但是这时...
老板已经发现app异常,且越来越多的同事也发现问题并围了过来。压力陡增,而这时已经没有退路。好在,20分钟后问题修复。而这20分钟和真是度分如年。。。
其实当时备份下发布平台不坏就好了,回滚2分钟...
其实当时备份下每台服务器的nginx配置就好了,回滚2分钟...
其实当时业务负责人不补刀邮件的事情,回滚2分钟搞定...
其实没有那么多其实了
运维是业务对外的最后一道保障,又是上帝权限。没有那么多其实和如果,有的只有万全的准备工作,检查再检查,周全再周全!
附赠一份checklist的模板,大家的需要的可以文末留言,需要的朋友多的话,我尝试找找原版。
checklist
其次,互联网网人应该了解的几大法则,看看大家了解几个,欢迎留言补充 :