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