为什么凌晨做服务变更更容易出事故

晚上10点以后是人类休息和放松的时间，在这个时间做服务升级不顺应人性，一切不顺应人性的事情都不会长久，也不会往好的方向发展。当然领导也会陪同升级，但是他们不用抗压，也不需要承担后果，他们只需要坐在那里看看新闻，偶尔走到运维/负责发布人员跟前，说个段子、讲个笑话，逗下大家，而且拥有随时离开的权利，在或者不在其实并没有什么本质上的区别。

站在老板们角度来看，他们根本不关心早上还是晚上做变更，考虑更多是技术人员保证好服务的稳定性。另外很多公司之所以有这个晚上做变更的文化，因为这种方式可以压榨员工的休息时间，从而完成更多的工作；多数技术公司的普遍方式是头一天晚上升级，第二天上午不用来上班；如果7点下班，假设服务变更发生在11点，一切顺利的话1点全部完成，总共持续了6个小时；第二天多睡一上午，9-12点总共就3个小时。

站在技术人员的角度，对自己没有信心，凌晨用户少，影响也小，拥有反悔的权利。所以用自己身体的健康换取服务的健康是值得的，特别是如果能给钱就更好了。

拼身体本身并没什么问题，每个技术人员基本都是靠身体吃饭的。

说下我自己的经历，之前作为其中一个开发人员参与过一个项目，这个项目大概10个左右的服务/进程组成；两个月变更一次，每次变更，必出问题，东边不亮西边亮，不是配置不对，就是sql脚本没有变更，更让人生气的是本地没问题，线上有问题.... 一次变更基本可以从晚上1点搞到凌晨5点。偶尔还无法逃脱回滚的命运，搞的运维焦头烂额；关键是半夜吵醒其它人起来帮忙解决问题，身心焦虑。自己对这个事情做过反思，主要在于项目前期规划不清晰，中间没有流程，事后也没有日志、监控告警等工具做稳定性保障。总结下：全靠人，人也不靠谱。

从技术上来说，开发人员做东西的时候没有梳理清楚，这个配置和sql语句是否能跟线上数据/服务兼容，不兼容应该如何处理？应该如何增加服务的鲁棒性，无论怎么玩都不会出现故障或者即使出现问题不会造成任何影响。开发的时候没有梳理清晰，上线必出问题。

从流程上来说，负责人应该清晰团队的能力水平。换一种方式说，一次本来做10个功能的，现在改成一次做2个，增加发布频率，降低出现错误的概率。当然增加发布频率可能牵涉的人员太多，整体成本都会升高，是不是因为发布效率存在问题，CD工具调研一下，想保持现有的一成不变，又想提高效率，就现有的这种人员流失速度，只能靠自动化工具去保证。据我所了解，多数中小企业嘴上喊着敏捷、CI/CD、DevOps... 多数停留于口号层面，并没有与之匹配的工具和文化。

扪心自问下，服务有这么重要吗？如果非常真的非常重要，我们为什么不能做个灰度发布呢？一提到灰度发布，大家都会想到金丝雀、蓝绿发布，对应解决方案是：云原生、K8S、容器化技术靠拢，这些东西太复杂，人力成本太高，没有对应的技术储备。

看上图可能感觉还是很抽象，简单来说可以在 NGINX 中引入一个 nginx_blance_lua 当我匹配到固定的标识就把你路由到新服务，否则都转发到老版本服务中，然后经过一个增量过程，最终完成发布。

如果感觉还是复杂，也可以在服务中做一些开关，只有特定标识的用户才能执行对应的代码，其它一律绕行。河南赋红码事件了解一下（染色发布的原理）。总而言之，尽量在正常工作时间完成这个变更。

如果主要是为高层表演团结一致，甘愿为公司奉献的精神。这种文化本身非常可怕，而且大错特错了，周公子是个老实人，已经为我们指明了方向，社会的本质是资源互换，这种表演式工作可以带来一时夸赞，但它不长久，而且不会产生任何效益。所以作为员工更应该站在公司的角度（更是自身的发展），考虑如何提升整体效率，让公司需要你。

最后的最后，一段感悟，都2222年了，我们要学会利用技术红利，享受生活，降低心智负担；消灭刀耕火种和不必要的亲力亲为。