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