这些年我们与通宵上线的那些事儿
突然想写这个文章是因为最近一家公司,也是出现了类似通宵上线这样的事情。通宵也并非是真的通宵,而是搞得比较晚上线这种。总结一下通宵上线的事儿
第一种:自动化运维能力弱
本人工作比较早,最早的时候还没有运维自动化工具,那个时候还是比较落后的时代,需要达成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,测试,开发全部都盯着这个问题开始找,找问题来解决呀,开发有时候甚至是这次上线的负责人,都盯着这个问题来看怎么解决。如果我们把这个当成一个线上故障的逻辑,来做处理呢?而且这个问题比线上故障要好处理的多,因为你已经知道是什么问题造成的了。
当成线上问题处理:
第一件事情,负责人界定影响范围?留一个这块熟悉的或者这块谁负责的人来排差问题。测试继续测试剩下的。
第二,是否是阻断性的?如果影响范围很大,还是阻断性的,不用考虑,直接回滚就完了。
非阻断性的,少部分人影响,可以让人来查这个问题。测试继续测,可能还会出现其他问题。
整体都测试完成或者中间阻断了回滚的问题之后。定位问题,如果短时间内能够找到问题,问题修复比较简单,可以进行修复,如果改动多,就可以停下来了,考虑是否终止今天的上线?这些都是决策问题了。
很多研发甚至是决策人都比较轴,呃,有问题了,我要找出来修好。要多思考,这个问题是不是一定要修,影响程度不大,不一定能触发的,可以先放着。后面打个补丁修复即可。(此处是说明这是晚上上线,很多时候晚上找问题都非常费时间,费精力,加班太晚了头脑也会不清醒,改一个问题可能引起其他问题,无情无尽...)
写到最后:如果你发现你现在的工作还在很晚上线,应该来说是一个基础架构比较薄弱,自动化运维比较薄弱的公司,决策者比较薄弱的管理。