作为一个前端，一直不明白为什么要晚上发版？

[zhangkui]

说到夜晚发版这个事，有些时候事真的想不明白，为什么发版要夜晚发版？？？

后台不是有 负载均能、Nginx 、k8s 这么多手段可以无感更新，怎么还在夜晚发版

[InDom]

万一崩了，影响用户最少。

[InDom]

哦，没注意看截图，那就再加一句，预案再好，测试的再完善，也不敢保证不出问题。

[x86]

人少呀

[FieldFarmer]

无感更新≠没有问题

[zhangkui]

#1 崩也是先崩一台，有其他的服务器，不是以上线就都崩了吧

#3 也有其他用户少的时间点吧，如果是流量大引起的，晚上发版也看不到吧

[zhangkui]

#4 晚上更新≠没有问题

[shiguiyou]

凌晨发版的我都经历过……

[zhangfeiwudi]

晚上发版 确切的说是凌晨发版，用户最少 就只有这一个好处 其他任何时间都没凌晨的用户少

[shiguiyou]

@shiguiyou 产品验证到两三点没问题就回家，有问题搞到早上六七点。

[x7DnVcd9bA706oWp]

@zhangkui 看到你回复：晚上更新≠没有问题
结帖吧

[dapang1221]

月黑风高杀人夜懂吧，晚上才方便动手，发版出了问题就当场鲨了祭天

[Rache1]

讨厌的不是凌晨发版，而是当天正常上班，凌晨发版，早上还要正常时间上班。

要是换成，当天只下午上班，第二天休息，那就没人讨厌了。

[luomao]

确实，以前还在手动发版的时候，必须停机一段时间，那就必须大晚上发版了。现在都用的 k8s 之类的，我们这里基本是想发就发，当然影响改动非常大（数据迁移、新旧业务无法兼容等等）还是要晚上发

[luomao]

@Rache1 是的，我们这边是晚上发版，第二天早上可以不用来

[coderluan]

晚上发版虽然常见，但是并不是共识。对于这种类型的问题，广泛的讨论没意义。你感觉你项目的情况不需要这样，就去问问做决定的人为啥需要。可能是你不知道但是知道后认可的情况。也可能是你不认可但是可以讨论的情况，说不定是你说法了对方。也可能是你不认可但是无话可说的情况，“之前就这么干的”，“得让老板看见我们加班”。你问对实际情况不了解的网友，网友也只是猜谜，或者说一句，我们就不在晚上发呀。

[43n5Z6GyW39943pj]

"也有其他用户少的时间点吧",指的是什么时间

[weiweiwitch]

我以前做后端，现在做前端。
做前端的这段时间，给我的体会就是前端出错会造成的后果要比后端轻太多了，也不会有后端在用户规模上升导致复杂性指数级上升的问题。所以，大多数前端不理解后端的复杂性。

后端出问题要比前端出问题，多一个很大的烦恼，就是数据、状态、环境的恢复问题。
修 BUG 可能很简单，但是把数据修正确，以及新程序要在原数据环境下再次正确运行，是要折腾死人的。

后端系统之间是强交互的，一个系统出问题很大可能影响另一个系统。并且会引发雪崩。不是说一台崩了，其他还能继续运作。有可能要崩一起崩。

后端处理的数据是有关联性的，不是什么数据都能拆分成多个系统独立处理，也不是什么系统都能简单搞分布式平摊负载。因为并发问题和环境会出问题。不做相关设计，出了错，修数据是要死人的。

[whileFalse]

因为滴滴阿里为首的一大堆公司不如 lz 聪明，没能想到或者落实不了无感发版。

[amon]

其实你说的对，现在大多数场景是不需要夜晚发版的，比如很多业务量小的或者部分 toB 的压根不需要夜晚发版。
我记得之前公司，普通迭代版本基本都是白天发布，涉及重大业务和对接外部系统，才会选择夜晚发版。

只是夜晚发版本，是以前潜移默化下来的一个规定。
就像代码一行建议不要超过 80 或 120 个字符，那是因为以前显示器小，超过 80 、120 就无法显示了。

还有一点，发版一般细枝末节的问题都较多，弄不好就是几个小时，如果白天发版白天就没法干活了，夜晚发版能白嫖劳动力。

[XSDo]

多年后端，发版肯定选择人少的时候做比较好的，更新后，出问题了，错误数据量是最少的，数据出错了，就不是回滚代码那么简单的事情了，无状态 纯计算的服务 随便什么时候发版，一旦服务会影响到数据，出问题了，修数据分分钟要爆炸

[niubee1]

很多业务就几台服务器，一升级就没有冗余，那就只有等半夜人最少的时间来升级，复测。如果你的服务规模比较大，或者有足够的冗余，就可以搞灰度发布，先更新一组服务，然后先分流内部流量到新版本，再逐步扩大，最后全部升级。

[wjfz]

因为你是前端。

前端只要验收通过了，基本不会有太大的问题。
后端只要有一个 bug 就炸了。

[k9982874]

滴滴：你说什么？

[chaoschick]

白天更新影响用户使用 用户在做某些业务 不能停的那种
如果更新出问题 用户不满意可能就不交服务费了
如果晚上更新 出问题能进行版本回退 不影响第二天用户使用

[dishuibaby]

@weiweiwitch 这个老哥说的对，特别是数据的问题。出了问题，不是能不能回滚的问题。很多时候，不回滚有问题，回滚也有问题。所以只能尽可能做到影响最小。

还有很多数据是牵涉到钱的问题，就更复杂了。

而且，白天用户量上来的时候，发版过程中出问题，真的是要崩溃。

so ，每次发版之前，我都会先去趟 WC ，因为接下来可能就是真的没时间去厕所了~

[Light3]

因为 用户少 要验证数据
然后 又讲究团队 大部分时间 你没事 你也要陪伴性加班

其实这都没什么 最重要的可能还是
资本家把晚上上班到凌晨看成理所当然 没有应有的回报
比如次日上班时间 延后 补休 加班费等

[nieboqiang]

因为后端不是增量修改，不是每次修改一个问题，就新增接口，所以要跟着后端来。

[opentrade]

你一个前端，想他干嘛

[echoZero]

晚上发版== 业务低峰发版
只是为了降低发版带来的影响最小而已

[huijiewei]

不明白就别问了。前端也管不着这块。

[z1829909]

你说的负载均能、Nginx 、k8s 这些只是增加系统的可靠性, 但是谁也无法保证真的这些都没拦住就崩了. 而且肯定会崩的, 没哪个公司说自己从没崩过, 所以就把可能崩的损失尽量减少.

[zdt3476]

不是选在晚上发版，而是选在人少的时间发。

[jokie]

手动灰度

[tom8]

别说发版本 有时候服务重启下都起不来

[yosoroAida]

最爽的时候，一周有三天凌晨上线到 3 点，那周人都好像是飘的

[32]

我认为是因为"晚上"的时间定义无限长, 可以从 18 点到次日 10 点(上班前), 上线前出问题, 码农加班, 但是依然可以按照"计划"在某天晚上发版

[xiaoHuaJia]

因为你不是服务端，所以你不知道

[muchenlou]

切记，在程序员的视角，程序员是人；
在资本家的视角，程序员是耗材。

[tool2d]

后端有太多的历史服务，我都不敢随便重启服务器，就怕出问题起不了。

真的还是写前端爽，后端大半夜的，容易收到服务器报警短信，对幼小的心灵不好。

[PaulSamuelson]

建议换个做海外业务的公司，然后就是白天发版了。

[mxT52CRuqR6o5]

晚上发版好处就是出现问题影响小，坏处就是如果回家后才发现出了问题解决问题速度就会慢

[ODESZA]

我们面向 B 端服务，都是凌晨发版

[zengguibo]

晚上用的人少，流量低，有事的话影响的人少，现在的服务太多了，根本做不到无损更新

[cyrivlclth]

晚上发版，人都是麻的，出问题的几率增大，增加工作难度，有利于升职涨薪。。。

[weiwenhao]

大多数应用的高峰期 早上 7 ～ 9 点左右，中午 12 ~2 点， 晚上 6 ～ 12 点 这些休息时段

[exonuclease]

因为业务范围只在国内
全球都提供服务的话就只能老老实实搞灰度发布了

[SoyaDokio]

老哥发帖时间是 11:28:05 AM 合理怀疑昨晚发版了
昨晚前项目组发版，我正好加班路过看见全项的人几乎都在惊呆了

[pkoukk]

后端如果发出什么问题数据要回滚，肯定要停掉所有业务才能回滚啊，不然不断有新数据往里写，怎么滚的动？
半夜人少，停了损失小，高峰期用户数量那么多，谁敢停啊

[wushigejiajia01]

因为这些手段都是为了面试的吹逼的，
实际运行都会出问题
参考最近阿里云跟滴滴的事情

平时这些大厂总是创造一个个概念、名词，结果实际遇上还是自己也会出问题
哈哈，都是 CJB

[frankkly]

我们是小公司，每周五下午 4 点开始发，5 点结束，6 点下班

[Hf1G1sGBYS8QSLN8]

这问题真的是搞 IT 的人问出来的么？
为了提高系统的可靠性和持续运行能力，有了“负载均能、Nginx 、k8s ”等等技术。但是最容易出问题的可能往往就是这些“负载均能、Nginx 、k8s ”。

[ccagml]

不会发完版，第二天还要上班吧？

[tokoy]

因为其实还有很多服务是单点的，你发版就得中断服务再启动服务。而且用户一多就涉及到客诉，万一出问题，半夜发没几个用户投诉，白天估计直接电话给你打爆。没有什么是没有万一的，再稳定的服务都可能出现宕机

[nicholasxuu]

看机会成本了，出问题几率 x 万一出问题后的损失 = 机会损失。
灰度是个基础，不是 100%解决问题的。我们还发生过 99%灰度都不会有问题，100%的那一瞬间会崩溃的问题呢。

[InDom]

没有过升级出错修数据的经历，可能确实很难理解这个原因。

[kdd0063]

无状态应用那点复杂性当然无所谓。但是有状态应用，同时又存在比较高的一致性需求的时候，搞出问题就很吓人了，有时连回滚的可能都没有，因为找不到一所有相关方都认同的一致状态。
这个问题上研究了少说有几十年了，有银弹大家早用了，难不成谁当真喜欢熬夜顶着黑眼圈和发翁的脑袋上线？ No silver bullet!

[ochatokori]

用户是金主，开发算哪根

[wherewhale]

来做后端就懂了

[retrocode]

夜晚用户量小, 更新更出产线问题你还能有时间回退, 白天发版出问题, 你就知道什么叫度秒如年了.

[JackLiang]

@frankkly 我最不能理解的就是周五下班前发，难道准备周末加班吗

[xiangbohua]

我猜可能跟前端的使用场景和技术特点有关吧？
前端产品是不是跟直接一些，因为大部分效果可以直接看见？
JS 报错之后有些场景不影响使用？只是体验变差，要求低一些的场景被追责的情况少？
“前端是干啥的？就是掉调接口的嘛” （玩笑话，逃。。。）
大部分场景前端不需要对具体交易负责？
OP 是个绝对意义上的技术大佬，vim 写代码不测试一遍过。
请补充

[xiangbohua]

@zhangfeiwudi 我们有时候是两点-四点，因为 0 点往往有 JOB 再跑。
@dapang1221 不不不，恰恰相反，0 点发布搞出问题来了还有时间修复，哪怕有问题第二天老板过来砍人的时候还可以求饶：老板，已经修好了。要是中午发班，刚出问题老板提刀过来了不好解释。哈哈
@weiweiwitch @XSDo 比如一些搞 WMS ，白天发版有问题了，会有几百号人感谢你给了他休息时间。

[qiuhang]

我个人觉得是一将无能，累死千军。某些公司的领导迷信加班加点，把程序员当耗材用，对于灰度上线有这发自内心的抵触，不了解也不愿意去引入。评论区说什么晚上用户少，出问题容易回滚之类的，有一定道理。但是更大的问题来了，晚上人员状态和心态都不在状态，首先出问题的概率就比较高，这是必然的。
最重要的是，难道上线后不报错就算成功了？ 系统不报错但是数据逻辑有问题怎么办？上线之后谁来观测业务数据？谁来验收？谁来保证有异常第一时间介入？
难道大晚上的上完，回家睡觉，第二天来在发现数据不对，又风风火火地去打补丁修复？如果放在白天灰度上线，上万业务方验收，各方有足够的精力和时间和客观条件去检测
各种系统或者是数据异常，有问题可以第一时间扼杀在萌芽里面。
按你们的逻辑，那些业务遍及全球的企业，白天夜里都有人用，他们的产品是不是不用发布了？

[sgiyy]

大公司还有灰度发布等措施优化上线操作，但小公司的上线很多是真的要停服务的。

[n18255447846]

都一样，不然为什么多 nightly 。前端还有缓存，真要回退了也很麻烦

[xiubin]

哎，为啥我们公司晚上不能发版、周末不能发版，只让工作时间发版？
有个好处是上线后有问题可以及时处理啊，晚上发版后发现问题，不会大半夜把人 call 起来排查吗？

[guo4224]

很多互联网业务就没有人少的时刻

[kakki]

正常，游戏维护不也是大半夜。

[aper]

因为技术不行

[iomect]

白天更新 有问题=损失钱
半夜更新 有问题=损失了几只 24h oncall 的程序员脑细胞而已

[cosmain]

不敢怼上司，搁着发帖算什么？

[declandragon]

规范：周五下午 6 点以后不发版
实际：周五晚上 10 点还在改 BUG ，一定要今天发布

[springz]

前端很难理解，理解这个想法。其实就是怕出问题污染数据。前端随便写，只要请求能发出去格式对就完事了。后端万一出现问题引入了脏数据，大半夜没几个人用恢复起来容易一点，高峰期哪怕只有一条脏数据，也得停机花一段时间看怎么往回滚，一环套一环老难了。

[springz]

前端可以随时发版吧，后端除非是极其简单的业务变更或者只是新业务没动旧业务，不然都得找个时间窗口小心发版。

[kiwi95]

因为领导不用参与半夜发版，对领导百利而无一害那就给定了半夜发版了呗，不是什么半夜风险更小，只是因为半夜不用三倍工资，甚至不用给工资。

[StephenHe]

就算是前端静态资源发版也会影响用户呀。用户正在用，你发版静态资源替换了，用户切换菜单，懒加载的路由资源就找不到了，人肉运维之类的太多了。

[IvanLi127]

因为他们想停机更新，所以选晚上。

他们不想停机的话，凌晨大概率没多少人用，服务器压力小，更新的时候不太容易卡崩掉。

[zhw2590582]

主要是后端吧，前端无所谓

[zlkent]

因为我们也曾经尝试过白天发版，但每次最后关头 QA 总能测出新的 bug ，然后开始修，觉得小 bug 应该很快，然后就拖到下午，越后面发现问题越大，QA 在下午又发现了几个 bug ，开发只能硬着头皮修，一直修到晚上，觉得可以发了，QA 做最后一次收尾测试，然后发现 bug 改好了，又出新 bug ，就这么来到凌晨，老板给大家买了宵夜，吃完想着一鼓作气马上结束了可以回家了，结果 bug 还是没修好。最后只能权衡利弊，把一些新出的不是太影响的 bug 放到下一版，然后草草发布。并祈祷发布的版本别出问题，然后拖着疲惫的身体，在公交站，看着马路对面公交站刚下车准备上班的打工人，坐着相反的公交回家。

[yhxx]

直接群嘲一下
晚上发版 === 架构师是个废物
淘宝甚至下午 5 点之后不允许发，必须白天发完

[v2exe2v]

为了让你加班呀小笨蛋

[yhxx]

总之就是不把员工当人看
能用员工的血汗解决的问题就不会优先考虑其他方案

[unregister]

楼上那么多扯什么晚上发班影响用户小的，在 China 很多公司晚上发班就是免费加班到大半夜是吧，说好有调休，最后说什么人手不够没的休。

[akira]

中午你饿了，准备打开软件点个外卖，显示系统升级中，请稍后再试
等了 2 个小时，点了个单，过了一小时还没送到，一看下的单子不见了，
再过了一会，软件打不开了

[duluosheng]

白天发版，不出事则已，出事了就要滚蛋啊

[izToDo]

感觉还是要看有没有规范的流程和稳定的架构。
我们这小公司都是晚上发，方便及时抢救，晚上崩了影响也小。

不同业务对于发版时间应该也不尽相同，用户群体、高峰都不一样。

[DeWjjj]

都是半夜运维的，别想了。
就是无缝链接也要半夜运维。

[cyitao]

@StephenHe 前端现在 js css 文件放 cdn 托管算是基操了，发了新版本，旧版本的 js cdn 链接也是正常访问。所以不会有你说的问题。

[zzerd]

不应该灰度更新吗…

[wupher]

晚上没人用，有故障方便快速回滚？

我们 App 正好相反，都是晚上，节假日用，于是变成白天发版。

[nexo]

看你們是 c 端還是 b 端了 c 端其實 12 點反而人不少...

[Perry]

在国外其实还是工作时间发版的多，不管前端还是后端。

[jiannei]

算是多一层保险，保不准有前期测试没覆盖的场景，有缓冲时间可以修复。我刚刚就是蹲到凌晨发布站点更新，发现还有 30 多人在线，也不知道这个点他们在逛什么 😮‍💨

[tonytonychopper]

本质上是挑某个最少用户在使用的时间段，避免上线之后出现重大事故

[Inn0Vat10n]

阿里是必须白天发版，晚上敢自己发等着吃 3.25 吧

[iorilu]

其实用户最少的时候是早上,比如 6-8 点

问题是, 没人愿意这时候起来发把

晚上发 , 唯一解释就是, 还有时间挽回错误

[Yunsheng]

前端本身影响范围有限，发现 bug 可以及时修复，问题很表象。但是如果后端的 bug 那就难度很大了，有些发现后可能当下都不能及时修复的只能回滚。所以尽量找用户少的时间点。

[ecloud]

啊？我们昨天晚上要发版（但是没发成）……

你不会是我们公司的吧……

[TArysiyehua]

支持 63 楼，80 楼，晚上发版就是无能的表现。
1. 灰度去哪了？
2. 晚上没有用户验证就没问题了？
3. 架构师、负责人是傻逼

[hansomeneil]

这本质是管理问题，流程兜底的公司一般不强调大半夜 release ，而个人能力兜底的公司喜欢这么干，前者说明管理水平还可以，后者分情况讨论：初创团队可以理解，但是，公司成立一两年，甚至三五年了，还停留在“灵活”阶段，ok ，那他大概率存在五花八门的管理上的问题，相比之下，半夜发版实在是。。。微不足道