字节阿里腾讯都开始965了你却还在通宵上线

这些年我们与通宵上线的那些事儿

突然想写这个文章是因为最近一家公司，也是出现了类似通宵上线这样的事情。通宵也并非是真的通宵，而是搞得比较晚上线这种。总结一下通宵上线的事儿

第一种：自动化运维能力弱

本人工作比较早，最早的时候还没有运维自动化工具，那个时候还是比较落后的时代，需要达成jar包，然后发邮件给SCM审核，然后审批通过后发送给运维，手动传包上线。每次上线等到半夜开始，但是每次都有各种各样的问题，需要发布第二遍，第三遍，甚至第N遍。每次半夜给scm的同事打电话让她起来给我们批邮件，得亏还是个妹纸脾气好。然后给运维打电话给我们上线。经常熬通宵到第二天同事过来上班这种，甚至有时候一周两次。

怎么解决的呢？

后面自动化能力上来了，发布上线可以用发布系统了，这种人工操作就减少了很多，效率自然得到了一定的提升，但是还是没法解决业务的需要，因为业务要上班到12点，还是只能12点后发布。每次都把人搞那么惨，身体吃不消是一方面，不过那个时候人还年轻，大家都是这么过来的。另一方面呢，通宵完了，第二天是没法正常好好工作的，大家都摸鱼去了。团队是一个整体，需要有持久的战斗力，才能做好更多的工作，所以这种通宵上线的做法其实是非常错误的。

后面就开始做服务拆分，架构升级。将后端功能与业务功能拆分，业务功能中核心接入点等与非核心拆分，就是后面类似的微服务架构，那个时候还没有微服务这种特别火的概念。光拆分还没法解决通宵上线的问题。后面加上服务稳定性等需要，开始搭建多集群环境，灰度环境。上线前将用户切流到一个集群，发布成功后切到已发布的集群，然后再发布另一个集群这种形式。再加上自动化运维能力的提升，基本解决了大部分通宵上线的问题（注意是大部分）。因为不是所有的业务都是单纯的web请求，所以不是说ng自动切就能解决的问题，这里不过多聊。

第二种：敏捷没有做好

中间第三家公司，过去也是出现需要因为上线搞得很晚的情况。后面发现是因为应公司要求，必须两周一个迭代上线完成。两周时间，需要跟产品聊需求、做设计、写代码、联调、测试，跟台北那边异地沟通。最后算下来只有3天左右的时间开发加测试，这种显然是有问题的模式，3天完成开发自测，然后后面就是各种接口有问题改改改，这儿调整改改改。。。

解决

因为2周一个迭代，暂时肯定没法改变，只能改变敏捷的过程。后面拉齐台北，测试等，找出矛盾点，问题点。其实也并不是只有三天，因为他们想早点要到接口方便台北那边写代码联调。所以最后沟通就是，需求确定后一天内给出所有的接口信息，然后给出mock接口供使用，最后我们有了6天的开发时间和自测时间，质量得到了保证，上线也顺利了很多。从此也是基本脱离了很晚上线

第三种：业务与第一种类似

第四家公司业务与第一家类似，也是即时通讯相关，上线就比较麻烦，因为待状态。但是老大比较开发，允许晚上回家之后发布，远程沟通发布，但是要等到业务方没有使用了再开始。基本还是很晚，有时候1、2点。到这家公司之后，定了个目标，解决通宵上线的问题。因为公司也不大，想着继续沿用之前的模式，多集群来做。系统重构了一遍，该抽离的抽离，服务分层，分级都做了。准备开始做集群的时候呢，老大自己研究k8s，然后弄了一套特别方便的自动化上线工具，k8s用过的都应该清楚，服务发布好了以后再下线，整体还是非常友好的。然后有了这套基础架构以后呢，也没有去研究集群模式了，基本能够满足80~90%的发布是不用等到晚上12点以后了。后面通过普罗米修斯接入业务监控，监控业务指标，发现我们的业务在早上11~12，下午3~6点都是业务低峰，比晚上10，11点上线甚至影响更小。然后就非重大变更开始光明正大的上午跟下午发布上线。当然也有出现过问题的时候，敏捷迭代快步小跑的模式，肯定会出现发布上的问题。这个问题在最后环节来说。

不需要通宵上线的

第二段工作去了阿里，在阿里呢，就没有通宵上线这样一个概念，因为基础运维能力，基础架构能力，服务治理能力，服务上下线能力都非常好了，基本上是想上线随时可以上线。所以没有这种烦恼，但是在这儿呢，学会了怎么去上线。

重点来了

怎么上线，这个其实是决策问题，当然通常发布的checklist、发布顺序、发布后需要回归的功能等等基本的东西要备好，减少上线过程中出现问题。

这都不是重点是出了问题怎么搞？

其实可以任务整个发布到你发已经算是成功了，那验证有问题怎么办？或者说中间发布出问题了。这个时候应该来当成一个线上故障来看这个问题了，这样就很明确了。通常情况是什么呢，验证有问题了，A，B，C，D，测试，开发全部都盯着这个问题开始找，找问题来解决呀，开发有时候甚至是这次上线的负责人，都盯着这个问题来看怎么解决。如果我们把这个当成一个线上故障的逻辑，来做处理呢？而且这个问题比线上故障要好处理的多，因为你已经知道是什么问题造成的了。

当成线上问题处理：

第一件事情，负责人界定影响范围？留一个这块熟悉的或者这块谁负责的人来排差问题。测试继续测试剩下的。

第二，是否是阻断性的？如果影响范围很大，还是阻断性的，不用考虑，直接回滚就完了。

非阻断性的，少部分人影响，可以让人来查这个问题。测试继续测，可能还会出现其他问题。

整体都测试完成或者中间阻断了回滚的问题之后。定位问题，如果短时间内能够找到问题，问题修复比较简单，可以进行修复，如果改动多，就可以停下来了，考虑是否终止今天的上线？这些都是决策问题了。

很多研发甚至是决策人都比较轴，呃，有问题了，我要找出来修好。要多思考，这个问题是不是一定要修，影响程度不大，不一定能触发的，可以先放着。后面打个补丁修复即可。（此处是说明这是晚上上线，很多时候晚上找问题都非常费时间，费精力，加班太晚了头脑也会不清醒，改一个问题可能引起其他问题，无情无尽...）

写到最后：如果你发现你现在的工作还在很晚上线，应该来说是一个基础架构比较薄弱，自动化运维比较薄弱的公司，决策者比较薄弱的管理。