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

[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]

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