这是一个创建于 344 天前的主题，其中的信息可能已经有所发展或是发生改变。
说到夜晚发版这个事，有些时候事真的想不明白，为什么发版要夜晚发版？？？
后台不是有 负载均能、Nginx 、k8s 这么多手段可以无感更新，怎么还在夜晚发版
 |
1
InDom 344 天前
万一崩了，影响用户最少。
|
|
2
InDom 344 天前
哦，没注意看截图，那就再加一句，预案再好，测试的再完善，也不敢保证不出问题。
|
 |
3
x86 344 天前
人少呀
|
 |
4
FieldFarmer 344 天前  2
无感更新≠没有问题
|
 |
5
zhangkui OP #1 崩也是先崩一台，有其他的服务器，不是以上线就都崩了吧
#3 也有其他用户少的时间点吧，如果是流量大引起的，晚上发版也看不到吧 |
|
6
zhangkui OP #4 晚上更新≠没有问题
|
 |
7
shiguiyou 344 天前 via iPhone
凌晨发版的我都经历过……
|
 |
8
zhangfeiwudi 344 天前
晚上发版 确切的说是凌晨发版，用户最少 就只有这一个好处 其他任何时间都没凌晨的用户少
|
 |
10
x7DnVcd9bA706oWp 344 天前
@zhangkui 看到你回复：晚上更新≠没有问题
结帖吧 |
 |
11
dapang1221 344 天前 9
月黑风高杀人夜懂吧，晚上才方便动手，发版出了问题就当场鲨了祭天
|
 |
12
Rache1 344 天前
讨厌的不是凌晨发版，而是当天正常上班，凌晨发版，早上还要正常时间上班。
要是换成，当天只下午上班，第二天休息，那就没人讨厌了。 |
 |
13
luomao 344 天前
确实，以前还在手动发版的时候，必须停机一段时间，那就必须大晚上发版了。现在都用的 k8s 之类的，我们这里基本是想发就发，当然影响改动非常大（数据迁移、新旧业务无法兼容等等）还是要晚上发
|
 |
15
coderluan 344 天前
晚上发版虽然常见，但是并不是共识。对于这种类型的问题，广泛的讨论没意义。你感觉你项目的情况不需要这样，就去问问做决定的人为啥需要。可能是你不知道但是知道后认可的情况。也可能是你不认可但是可以讨论的情况，说不定是你说法了对方。也可能是你不认可但是无话可说的情况，“之前就这么干的”，“得让老板看见我们加班”。你问对实际情况不了解的网友，网友也只是猜谜，或者说一句，我们就不在晚上发呀。
|
 |
16
43n5Z6GyW39943pj 344 天前
"也有其他用户少的时间点吧",指的是什么时间
|
 |
17
weiweiwitch 344 天前 3
我以前做后端，现在做前端。
做前端的这段时间，给我的体会就是前端出错会造成的后果要比后端轻太多了，也不会有后端在用户规模上升导致复杂性指数级上升的问题。所以，大多数前端不理解后端的复杂性。 后端出问题要比前端出问题，多一个很大的烦恼，就是数据、状态、环境的恢复问题。 修 BUG 可能很简单，但是把数据修正确，以及新程序要在原数据环境下再次正确运行，是要折腾死人的。 后端系统之间是强交互的，一个系统出问题很大可能影响另一个系统。并且会引发雪崩。不是说一台崩了，其他还能继续运作。有可能要崩一起崩。 后端处理的数据是有关联性的，不是什么数据都能拆分成多个系统独立处理，也不是什么系统都能简单搞分布式平摊负载。因为并发问题和环境会出问题。不做相关设计，出了错，修数据是要死人的。 |
 |
18
whileFalse 344 天前 via Android 2
因为滴滴阿里为首的一大堆公司不如 lz 聪明，没能想到或者落实不了无感发版。
|
 |
19
amon 344 天前
其实你说的对，现在大多数场景是不需要夜晚发版的，比如很多业务量小的或者部分 toB 的压根不需要夜晚发版。
我记得之前公司，普通迭代版本基本都是白天发布，涉及重大业务和对接外部系统，才会选择夜晚发版。 只是夜晚发版本，是以前潜移默化下来的一个规定。 就像代码一行建议不要超过 80 或 120 个字符，那是因为以前显示器小，超过 80 、120 就无法显示了。 还有一点，发版一般细枝末节的问题都较多，弄不好就是几个小时，如果白天发版白天就没法干活了，夜晚发版能白嫖劳动力。 |
 |
20
XSDo 344 天前
多年后端，发版肯定选择人少的时候做比较好的，更新后，出问题了，错误数据量是最少的，数据出错了，就不是回滚代码那么简单的事情了，无状态 纯计算的服务 随便什么时候发版，一旦服务会影响到数据，出问题了，修数据分分钟要爆炸
|
 |
21
niubee1 344 天前
很多业务就几台服务器，一升级就没有冗余，那就只有等半夜人最少的时间来升级，复测。如果你的服务规模比较大，或者有足够的冗余，就可以搞灰度发布，先更新一组服务，然后先分流内部流量到新版本，再逐步扩大，最后全部升级。
|
 |
22
wjfz 344 天前 1
因为你是前端。
前端只要验收通过了，基本不会有太大的问题。 后端只要有一个 bug 就炸了。 |
 |
23
k9982874 344 天前
滴滴：你说什么？
|
 |
24
chaoschick 344 天前 via Android
白天更新影响用户使用 用户在做某些业务 不能停的那种
如果更新出问题 用户不满意可能就不交服务费了 如果晚上更新 出问题能进行版本回退 不影响第二天用户使用 |
 |
25
dishuibaby 344 天前 1
@weiweiwitch 这个老哥说的对，特别是数据的问题。出了问题，不是能不能回滚的问题。很多时候，不回滚有问题，回滚也有问题。所以只能尽可能做到影响最小。
还有很多数据是牵涉到钱的问题，就更复杂了。 而且，白天用户量上来的时候，发版过程中出问题，真的是要崩溃。 so ，每次发版之前，我都会先去趟 WC ，因为接下来可能就是真的没时间去厕所了~ |
 |
26
Light3 344 天前
因为 用户少 要验证数据
然后 又讲究团队 大部分时间 你没事 你也要陪伴性加班 其实这都没什么 最重要的可能还是 资本家把晚上上班到凌晨看成理所当然 没有应有的回报 比如次日上班时间 延后 补休 加班费等 |
 |
27
nieboqiang 344 天前
因为后端不是增量修改，不是每次修改一个问题，就新增接口，所以要跟着后端来。
|
 |
28
opentrade 344 天前
你一个前端，想他干嘛
|
 |
29
echoZero 344 天前
晚上发版== 业务低峰发版
只是为了降低发版带来的影响最小而已 |
 |
30
huijiewei 344 天前
不明白就别问了。前端也管不着这块。
|
 |
31
z1829909 344 天前
你说的负载均能、Nginx 、k8s 这些只是增加系统的可靠性, 但是谁也无法保证真的这些都没拦住就崩了. 而且肯定会崩的, 没哪个公司说自己从没崩过, 所以就把可能崩的损失尽量减少.
|
 |
32
zdt3476 344 天前
不是选在晚上发版，而是选在人少的时间发。
|
 |
33
jokie 344 天前
手动灰度
|
 |
34
tom8 344 天前 2
别说发版本 有时候服务重启下都起不来
|
 |
35
yosoroAida 344 天前
最爽的时候，一周有三天凌晨上线到 3 点，那周人都好像是飘的
|
 |
36
32 344 天前
我认为是因为"晚上"的时间定义无限长, 可以从 18 点到次日 10 点(上班前), 上线前出问题, 码农加班, 但是依然可以按照"计划"在某天晚上发版
|
 |
37
xiaoHuaJia 344 天前
因为你不是服务端，所以你不知道
|
 |
38
muchenlou 344 天前 2
切记，在程序员的视角，程序员是人；
在资本家的视角，程序员是耗材。 |
 |
39
tool2d 344 天前
后端有太多的历史服务，我都不敢随便重启服务器，就怕出问题起不了。
真的还是写前端爽，后端大半夜的，容易收到服务器报警短信，对幼小的心灵不好。 |
 |
40
PaulSamuelson 344 天前
建议换个做海外业务的公司，然后就是白天发版了。
|
 |
41
mxT52CRuqR6o5 344 天前
晚上发版好处就是出现问题影响小，坏处就是如果回家后才发现出了问题解决问题速度就会慢
|
 |
42
ODESZA 344 天前
我们面向 B 端服务，都是凌晨发版
|
 |
43
zengguibo 344 天前
晚上用的人少，流量低，有事的话影响的人少，现在的服务太多了，根本做不到无损更新
|
 |
44
cyrivlclth 344 天前 1
晚上发版，人都是麻的，出问题的几率增大，增加工作难度，有利于升职涨薪。。。
|
 |
45
weiwenhao 344 天前
大多数应用的高峰期 早上 7 ～ 9 点左右，中午 12 ~2 点， 晚上 6 ～ 12 点 这些休息时段
|
 |
46
exonuclease 344 天前
因为业务范围只在国内
全球都提供服务的话就只能老老实实搞灰度发布了 |
 |
47
SoyaDokio 344 天前
老哥发帖时间是 11:28:05 AM 合理怀疑昨晚发版了
昨晚前项目组发版，我正好加班路过看见全项的人几乎都在惊呆了 |
 |
48
pkoukk 344 天前
后端如果发出什么问题数据要回滚，肯定要停掉所有业务才能回滚啊，不然不断有新数据往里写，怎么滚的动？
半夜人少，停了损失小，高峰期用户数量那么多，谁敢停啊 |
 |
49
wushigejiajia01 344 天前
因为这些手段都是为了面试的吹逼的，
实际运行都会出问题 参考最近阿里云跟滴滴的事情 平时这些大厂总是创造一个个概念、名词，结果实际遇上还是自己也会出问题 哈哈，都是 CJB |
 |
50
frankkly 344 天前
我们是小公司，每周五下午 4 点开始发，5 点结束，6 点下班
|
 |
51
Hf1G1sGBYS8QSLN8 344 天前
这问题真的是搞 IT 的人问出来的么？
为了提高系统的可靠性和持续运行能力，有了“负载均能、Nginx 、k8s ”等等技术。但是最容易出问题的可能往往就是这些“负载均能、Nginx 、k8s ”。 |
 |
52
ccagml 344 天前 via Android
不会发完版，第二天还要上班吧？
|
 |
53
tokoy 344 天前
因为其实还有很多服务是单点的，你发版就得中断服务再启动服务。而且用户一多就涉及到客诉，万一出问题，半夜发没几个用户投诉，白天估计直接电话给你打爆。没有什么是没有万一的，再稳定的服务都可能出现宕机
|
 |
54
nicholasxuu 344 天前
看机会成本了，出问题几率 x 万一出问题后的损失 = 机会损失。
灰度是个基础，不是 100%解决问题的。我们还发生过 99%灰度都不会有问题，100%的那一瞬间会崩溃的问题呢。 |
|
55
InDom 344 天前
没有过升级出错修数据的经历，可能确实很难理解这个原因。
|
 |
56
kdd0063 344 天前
无状态应用那点复杂性当然无所谓。但是有状态应用，同时又存在比较高的一致性需求的时候，搞出问题就很吓人了，有时连回滚的可能都没有，因为找不到一所有相关方都认同的一致状态。
这个问题上研究了少说有几十年了，有银弹大家早用了，难不成谁当真喜欢熬夜顶着黑眼圈和发翁的脑袋上线？ No silver bullet! |
 |
57
ochatokori 344 天前 via Android
用户是金主，开发算哪根
|
 |
58
wherewhale 344 天前
来做后端就懂了
|
 |
59
retrocode 344 天前
夜晚用户量小, 更新更出产线问题你还能有时间回退, 白天发版出问题, 你就知道什么叫度秒如年了.
|
 |
61
xiangbohua 344 天前
我猜可能跟前端的使用场景和技术特点有关吧？
前端产品是不是跟直接一些，因为大部分效果可以直接看见？ JS 报错之后有些场景不影响使用？只是体验变差，要求低一些的场景被追责的情况少？ “前端是干啥的？就是掉调接口的嘛” （玩笑话，逃。。。） 大部分场景前端不需要对具体交易负责？ OP 是个绝对意义上的技术大佬，vim 写代码不测试一遍过。 请补充 |
|
62
xiangbohua 344 天前
@zhangfeiwudi 我们有时候是两点-四点，因为 0 点往往有 JOB 再跑。
@dapang1221 不不不，恰恰相反，0 点发布搞出问题来了还有时间修复，哪怕有问题第二天老板过来砍人的时候还可以求饶：老板，已经修好了。要是中午发班，刚出问题老板提刀过来了不好解释。哈哈 @weiweiwitch @XSDo 比如一些搞 WMS ，白天发版有问题了，会有几百号人感谢你给了他休息时间。 |
 |
63
qiuhang 344 天前 4
我个人觉得是一将无能，累死千军。某些公司的领导迷信加班加点，把程序员当耗材用，对于灰度上线有这发自内心的抵触，不了解也不愿意去引入。评论区说什么晚上用户少，出问题容易回滚之类的，有一定道理。但是更大的问题来了，晚上人员状态和心态都不在状态，首先出问题的概率就比较高，这是必然的。
最重要的是，难道上线后不报错就算成功了？ 系统不报错但是数据逻辑有问题怎么办？上线之后谁来观测业务数据？谁来验收？谁来保证有异常第一时间介入？ 难道大晚上的上完，回家睡觉，第二天来在发现数据不对，又风风火火地去打补丁修复？如果放在白天灰度上线，上万业务方验收，各方有足够的精力和时间和客观条件去检测 各种系统或者是数据异常，有问题可以第一时间扼杀在萌芽里面。 按你们的逻辑，那些业务遍及全球的企业，白天夜里都有人用，他们的产品是不是不用发布了？ |
 |
64
sgiyy 344 天前
大公司还有灰度发布等措施优化上线操作，但小公司的上线很多是真的要停服务的。
|
 |
65
n18255447846 344 天前
都一样，不然为什么多 nightly 。前端还有缓存，真要回退了也很麻烦
|
 |
66
xiubin 344 天前
哎，为啥我们公司晚上不能发版、周末不能发版，只让工作时间发版？
有个好处是上线后有问题可以及时处理啊，晚上发版后发现问题，不会大半夜把人 call 起来排查吗？ |
 |
67
guo4224 344 天前 via iPhone
很多互联网业务就没有人少的时刻
|
 |
68
kakki 344 天前
正常，游戏维护不也是大半夜。
|
 |
69
aper 344 天前
因为技术不行
|
 |
70
iomect 344 天前
白天更新 有问题=损失钱
半夜更新 有问题=损失了几只 24h oncall 的程序员脑细胞而已 |
 |
71
cosmain 344 天前
不敢怼上司，搁着发帖算什么？
|
 |
72
declandragon 344 天前
规范：周五下午 6 点以后不发版
实际：周五晚上 10 点还在改 BUG ，一定要今天发布 |
 |
73
springz 344 天前
前端很难理解，理解这个想法。其实就是怕出问题污染数据。前端随便写，只要请求能发出去格式对就完事了。后端万一出现问题引入了脏数据，大半夜没几个人用恢复起来容易一点，高峰期哪怕只有一条脏数据，也得停机花一段时间看怎么往回滚，一环套一环老难了。
|
|
74
springz 344 天前
前端可以随时发版吧，后端除非是极其简单的业务变更或者只是新业务没动旧业务，不然都得找个时间窗口小心发版。
|
 |
75
kiwi95 344 天前 via Android
因为领导不用参与半夜发版，对领导百利而无一害那就给定了半夜发版了呗，不是什么半夜风险更小，只是因为半夜不用三倍工资，甚至不用给工资。
|
 |
76
StephenHe 344 天前
就算是前端静态资源发版也会影响用户呀。用户正在用，你发版静态资源替换了，用户切换菜单，懒加载的路由资源就找不到了，人肉运维之类的太多了。
|
 |
77
IvanLi127 344 天前
因为他们想停机更新，所以选晚上。
他们不想停机的话，凌晨大概率没多少人用，服务器压力小，更新的时候不太容易卡崩掉。 |
 |
78
zhw2590582 344 天前
主要是后端吧，前端无所谓
|
 |
79
zlkent 344 天前
因为我们也曾经尝试过白天发版，但每次最后关头 QA 总能测出新的 bug ，然后开始修，觉得小 bug 应该很快，然后就拖到下午，越后面发现问题越大，QA 在下午又发现了几个 bug ，开发只能硬着头皮修，一直修到晚上，觉得可以发了，QA 做最后一次收尾测试，然后发现 bug 改好了，又出新 bug ，就这么来到凌晨，老板给大家买了宵夜，吃完想着一鼓作气马上结束了可以回家了，结果 bug 还是没修好。最后只能权衡利弊，把一些新出的不是太影响的 bug 放到下一版，然后草草发布。并祈祷发布的版本别出问题，然后拖着疲惫的身体，在公交站，看着马路对面公交站刚下车准备上班的打工人，坐着相反的公交回家。
|
 |
80
yhxx 344 天前
直接群嘲一下
晚上发版 === 架构师是个废物 淘宝甚至下午 5 点之后不允许发，必须白天发完 |
 |
81
v2exe2v 344 天前
为了让你加班呀小笨蛋
|
|
82
yhxx 344 天前 1
总之就是不把员工当人看
能用员工的血汗解决的问题就不会优先考虑其他方案 |
 |
83
unregister 344 天前
楼上那么多扯什么晚上发班影响用户小的，在 China 很多公司晚上发班就是免费加班到大半夜是吧，说好有调休，最后说什么人手不够没的休。
|
 |
84
akira 344 天前
中午你饿了，准备打开软件点个外卖，显示系统升级中，请稍后再试
等了 2 个小时，点了个单，过了一小时还没送到，一看下的单子不见了， 再过了一会，软件打不开了 |
 |
85
duluosheng 344 天前
白天发版，不出事则已，出事了就要滚蛋啊
|
 |
86
izToDo 344 天前
感觉还是要看有没有规范的流程和稳定的架构。
我们这小公司都是晚上发，方便及时抢救，晚上崩了影响也小。 不同业务对于发版时间应该也不尽相同，用户群体、高峰都不一样。 |
 |
87
DeWjjj 344 天前
都是半夜运维的，别想了。
就是无缝链接也要半夜运维。 |
 |
89
zzerd 344 天前 via Android
不应该灰度更新吗…
|
 |
90
wupher 344 天前
晚上没人用，有故障方便快速回滚？
我们 App 正好相反，都是晚上，节假日用，于是变成白天发版。 |
 |
91
nexo 344 天前
看你們是 c 端還是 b 端了 c 端其實 12 點反而人不少...
|
 |
92
Perry 344 天前
在国外其实还是工作时间发版的多，不管前端还是后端。
|
 |
93
jiannei 344 天前
算是多一层保险，保不准有前期测试没覆盖的场景，有缓冲时间可以修复。我刚刚就是蹲到凌晨发布站点更新，发现还有 30 多人在线，也不知道这个点他们在逛什么 😮💨
|
 |
94
tonytonychopper 343 天前
本质上是挑某个最少用户在使用的时间段，避免上线之后出现重大事故
|
 |
95
Inn0Vat10n 343 天前
阿里是必须白天发版，晚上敢自己发等着吃 3.25 吧
|
 |
96
iorilu 343 天前
其实用户最少的时候是早上,比如 6-8 点
问题是, 没人愿意这时候起来发把 晚上发 , 唯一解释就是, 还有时间挽回错误 |
 |
97
Yunsheng 343 天前
前端本身影响范围有限，发现 bug 可以及时修复，问题很表象。但是如果后端的 bug 那就难度很大了，有些发现后可能当下都不能及时修复的只能回滚。所以尽量找用户少的时间点。
|
 |
98
ecloud 343 天前
啊？我们昨天晚上要发版（但是没发成）……
你不会是我们公司的吧…… |
 |
99
TArysiyehua 343 天前
支持 63 楼，80 楼，晚上发版就是无能的表现。
1. 灰度去哪了？ 2. 晚上没有用户验证就没问题了？ 3. 架构师、负责人是傻逼 |
 |
100
hansomeneil 343 天前 1
这本质是管理问题，流程兜底的公司一般不强调大半夜 release ，而个人能力兜底的公司喜欢这么干，前者说明管理水平还可以，后者分情况讨论：初创团队可以理解，但是，公司成立一两年，甚至三五年了，还停留在“灵活”阶段，ok ，那他大概率存在五花八门的管理上的问题，相比之下，半夜发版实在是。。。微不足道
|
Select Language