语雀这路子太野了

[nekoharuya]

https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw
他们的公告的链接
考虑到 v 友的水平，我抛砖引玉分析一下
这帖子的意思大概是说，由于临时工在升级维护工具的时候，工具没有严格测试，直接上生产环境，工具的 bug 导致数据库服务器下线，联系硬件团队，硬件团队说上不了线，摆烂不玩了，你们自己恢复备份吧，然后花了四个小时恢复，俩小时验证数据，成功上线
我和几个朋友讨论了下，觉得非常的，不可思议
这是 2023 年的，语雀这个体量的公司，做出来的事情
正常的架构思维里，所有的服务，就不应该跑在同一台机器上，包括数据库，最次也该是个主从集群，集群下面的机器单例再考虑 raid 之类的东西
在这个设计下，不存在上不了线开不了机这种事情，机房被修卡军团占领了都没事
至于网上传的什么之前的技术负责人跑路了，新人不会操作
就正常的 devops ，后台管理面板里，全自动维护，包括版本控制，回滚，备份，集群，镜像，机器冗余，全部自动化管理
这不该是现在的标配吗
技术负责人跑路，新人不会操作，这句话假定的前提是，这一切都是手工完成的
语雀这么大公司，表现得跟路边三五个人创业的草台班子一样

[nekoharuya]

@lambdaq 研发和运维一体，就叫 Devops ，你看，这个词在这个帖子里，应该是我用得最多的了

[hancai]

上个月我们公司部分服务不可用 10 分钟，人事要扣我 50%的绩效。语雀的运维估计得开掉一批，换一批更坑的替代。

[kaedea]

再草包有人能纠错就不算草包，没人敢纠错的才是真草包。

[iugo]

> 导致华东地区生产环境存储服务器被误下线
> 升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成

"下线" 这个词应该就是下线, 没有数据丢失. 不能再次上线正是因为自动化工具不支持, 才导致的. 自动化工具应该之前做过升级, 后续就只支持新机器了.

语雀做的就是找了新机器, 备份了老机器上的数据, 在新机器上重新部署了老机器上的数据服务.

我觉得问题核心应该是 "及时升级" (无论是软件依赖还是底层硬件).

[lambdaq]

@nekoharuya s/devops/devoops/g

[hancai]

@iugo 不支持自动化工具，就采用老机器做数据迁移，是说不过去的。

[seeu2ex]

@lambdaq #90 国内中小公司少见工作时间发版吧

[lambdaq]

@seeu2ex 现状的确如此。但是我讨厌这个现状。

[VYSE]

@wangshushu #51 两家公司, 啥时蚂蚁把语雀卖给阿里云了

[jmljava]

目前的现状可能是只要东西能跑,这就是一个稳定安全的服务,至于什么时候暴雷,相信下一任的智慧

[huangzongzhuan]

修卡军团可还行 DOGE

[hancai]

@seeu2ex 我上家公司新来了个老大，说要做到上班时间发版， 出了一次生产事故后，发版时间反而比他来之前还延后了半小时...

[cmlx1014]

阿里的东西，不赚钱就不重视，结果出了大纰漏。前面的会员也是吐槽得不行，连玉伯都走了。

[KickAssTonight]

是人就会犯错

[dragondove]

再大的公司都会出纰漏的，gitlab 出现过线上库被删的问题。之前某 dns 提供商出错导致大量美国的网站没法访问。我觉得语雀这个算是比较轻的问题了

[silencil]

@cherbim 我建议别抨击这个，我以前待的一家公司开发的系统，每次都是晚上十点多开始升级，每一两周来一次，每次升级就是接近一个通宵。同为程序员，我觉得服务短期不可用不会死（做好了各种回滚策略，白天升级也不至于导致服务不可用），长此以往的熬夜升级服务是真的会猝死。

[seeu2ex]

@hancai #112 主要是加班一点福利都没，😑

[yulgang]

他们没有运维团队和灾备系统😁

[silencil]

说阿里草台班子也大可不必，至少从概率上来说，阿里的员工技术、架构等经验应当会大于大部分公司。程序员老是相轻，与我见过的理发师的做法是一样的，经常理发的时候理发师都要抨击一下上一任给我剪头发的剪的烂，实则自己也是下一次别人抨击的对象。

[codcrafts]

我有个问题没想明白，存储服务下线了，为啥官网也挂了呢？有没有大佬能解答一下的

[naomhan]

15:00 确认因存储系统使用的机器类别较老，无法直接操作上线

估计是阿里云上建不了旧规格的实例

[shakoon]

@aper #68 这就是个风险控制的问题。举个可能你还不知道的例子，现在还在亚残运会期间，全国的国企都是禁止做系统变更的，处理紧急情况也要经过比平常的投产更高层级的审批。

[rtx3]

这种等级的公司不会高峰时间发版的。这种多数是运维工具测试中把一些任务分配到了生产环境。。

[RubyJack]

感觉应该不止一台 DB 服务器被下线，而是整个 DB 所有实例都下线了，然后从备份进行了一次完整恢复

[fish267]

@codcrafts 数据没恢复前，不能对外呀，不然影响更恶劣

[ily433664]

@Aliencn #16 不是说用了两个小时校验数据么，可能是通过日志将丢失的那部分恢复了

[aper]

@shakoon 这个是特殊时期禁止发版，就像过年前一周禁止发版，完全不一样的事情。难道每天都 3 个小时都禁止发版，业务得吭哧吭哧半夜脑子一坨糊的时候跑来发版是吧

[waringid]

从公告的内容来看，“服务语雀的数据存储运维团队在进行升级操作”这句的意思给人的感觉是第三方（或者说不是语雀自己的团队）由此推断：
1 、语雀团队更关注功能和日常的运行维护，不涉及存储管理（或者说只是使用存储资源）
2 、存储资源可能是第三方资源（阿里云或是蚂蚁内部存储资源），应该是分布式存储（类似于 ceph ）
3 、存储集群的服务器资源使用的是旧服务器（新服务器可能是另一个群集），旧群集基于之前的业务可能长时间都未更新升级（能用），也没有考虑逐步迁移的新群集
4 、旧存储群集出现问题（例如硬件故障导致磁盘空间或是同步故障等），受技术限制（内部没有技术资源长期维护旧版本）短时间无法迁移切换到新群集
5 、通过数据恢复的方式迁移切换到新的环境（但愿）

[Folayi]

草台班子理论

[pkoukk]

@nekoharuya #79
软件工程没有银弹，分布式不能解决所有问题。
加机器只能在一定范围内有效，随着数据规模和机器规模的增长，你会发现有太多问题是不可拆分的，费劲把他们拆开送到子节点，再回收回来带来的一致性等等问题成本远高于分布式的收益。
目前最简单的例子就是跑 AI ，大模型的任务没办法切分，只能靠 NVLINK 这样的方式强行把多台机器并成一个超大的单机来用。

[Daniel17]

临时工

[codcrafts]

@fish267 问题是一开始官网是无法访问的，下午 4 点多的时候，我再次进官网是 502 ，说明这个时候负载均衡啥的已经过了

[timothyye]

问题不大，毕竟这个世界都是一个草台班子

[GeekGao]

没准是裁员导致的管理问题。

[bugmakerxs]

@nekoharuya 运维工具应该在不在应用所在的服务器上。运维工具权限很大很奇怪么，弹性扩缩容，服务自动迁移都需要运维工具管理一批机器。大公司运维平台迭代较快的话，很多 n 年老服务下线就是很难起来了，需要重新适配新的启停脚本/重做镜像之类。

[lwjlol]

没必要咬文嚼字，这个公告就是给普通用户随便看看，真实的原因除了当事人谁会知道。

[nekoharuya]

@pkoukk 拜托考虑下场景，语雀这样的在线文档/协作工具，面对的问题不是大模型那样的线性数据迭代，而是数据规模和用户并发压力
在这个背景下，把不同的数据表/块裂分到不同的主从服务器组里，各自承担对应部分的读写压力，再另起队列慢慢同步不属于自己负责区域的数据
单个主从服务器组炸了可以随时滚一个新的出来，也可以让其他组多承担一部分
这种简单有效低成本的设计，牺牲的只是一点磁盘空间，对于网络，cpu 性能，磁盘性能的要求，全部降低了不止一个数量级，单组机器只用抗住拆分后需要负责的数据规模，即使它炸了也能自动让其他组顶上
经典案例可以参考 telegram 的做法，每个用户的数据，都由不同的数据中心进行处理

[utodea]

@4kingRAS #9 不太可能是应用级的问题，应用级的问题回滚一下就好了，再差顶多几十分钟一个小时也就处理完成了。

[nekoharuya]

@bugmakerxs 我来北京以后，去的第一家公司，只待了一个月就跑路的原因，就是看着祖传遗产害怕，老板跟我说我工位的机器，是网易现在的技术总监当年用过的……到我手里都不知道多少手了，一大堆和业务强关联的工具链，根本不敢乱动，交接文档都由不同的人写了好些份……

[julyclyde]

OP 大概是一路成长比较顺利，没见过这世界的背面
将来估计要吃大亏

[xzysaber]

@hancai 哈哈哈，同样，OP 应该是大厂的，所以这样认为。

[reeco]

前端写的系统，稳定性能好到哪里去

[CoffeeY]

等下故意的呢？这波 IT 圈到处讨论，各种卖课公众号也是各种讲。
顺便分析一波你们对语雀的依赖情况·🤪

[gransh]

看看俄罗斯再看看以色列，世界的本质就是草台班子组成的啊

[kingjpa]

@Aliencn 当年有赞还说没有丢数据呢，事实可不是这个样子

[akatale]

想想当年 gitlab 更寄
https://www.bilibili.com/video/BV1uM4y1e7Mo/

[chaleaochexist]

歪个楼, 那我是不是可以白嫖六个月会员啊??

[ysw]

觉得可能是旧机器被删了，新机器盘符映射路径不对，导致数据损坏？

[daimiaopeng]

@minami #3 下个月加急

[gosling]

@aeli 感觉有可能，之前我们团队也是引入了 terraform ，有一个参数没看文档就直接上了，导致集群所有机器都给删除了。重新买了一批启动了半小时。。

[ysy950803]

@minami 这句话有道理，特意上来点赞。

[yh7gdiaYW]

以语雀的体量，运维肯定不是自己 BU 的人，硬件团队又是另一伙儿，楼主你对大公司的扯皮不熟悉啊

[siyang601165858]

@aaronkk 确实 刚领的

[Rorysky]

@minami #3 真理，人类就是草台班子

[haoyli]

@Aliencn 是这样，工作中很多地方都是，大家都知道有一些东西存在隐患但人没敢优化，无功有过，ROI 低，于是所有人都不管，直到哪天被引爆。这种情况无法避免，因为在高速迭代业务的进程中，业务第一，支持业务才能拿到绩效，至于说排雷，who cares ？

[wtfedc]

服务升级升一半，有环节出问题，上不去下不来，也还算正常吧。

旧 ECS 装不上软件的问题我碰到过，完全是始料未及，你如果有 5000 台机器，30 台旧机器，你甚至都不好验证。停掉服务不一定是服务都不可用，有可能是为了保证严格数据一致性直接下线。

语雀的存储体量和成本预算，能不能支持多活都不好说，有个灾备，恢复数据保证不丢失已经不错了。多活也是针对服务说的，至于存储，数据结构有变化，多活也得一块升级，要不同步就会出问题。

有状态的服务回滚，也容易出问题，这还是以存储为主的服务。reddit 升级 k8s 还宕机过几小时呢，不是说出了问题，一键回滚就可以，尤其在非应用层面。

有时候问题完全是不可知的，可以说它前期验证不严格，但是不可能所有的东西都能验证到。抱着学习的态度可以，说人草台班子就格局太小了，毕竟人家也服务千万级别的用户，何况提供的信息不明确。

[kknd22]

这个世界破破烂烂，总是有人修修补补

[Light3]

首先楼主恶意造谣
试问哪个员工会领着工资说 上不了线 摆烂了 不玩了？这是人 最基本的职业道德
可能楼主是这样的人把 反正我从来没遇到过 从来没有

其次从一个公司发展时间时间来看 肯定会存在新的机器与旧的机器
升级出现失败 很正常 启不开也很正常
自己买的电脑也会昨天好好的 今天突然打不开
回滚？我也会回滚 问题是打不开了咋办？
所有的系统都是保证 99.99%的可用性

所以我不懂楼主既暴露自己的无知 愚蠢 又抨击他人的做法

[tietou]

下午升级 也是够可以的呀

[mumubin]

在服务和数据安全的情况下,选择修复数据是正确的选择.

Youtube 还两三年挂个半天一天的,toc
AWS 的某个 region 还经常某个服务挂个七八个小时呢.导致全美小公司的产品半天一天访问不了
这俩服务不比语雀重要的多?

不过可以喷阿里系,天天吹牛,又没做到

[yy77]

收入不好看，需要砍费用的情况下，先把异地多活给砍了呗。

[JinTianYi456]

@yyzh #4 对的，技术是有很牛逼的方案的。但有木有用上就是另一回事。我公司就没有。但也不妨碍 10W 日活

[mumubin]

@tietou 下午升级挺好的,说明自信,对产品和运维要求高,也说明技术负责人愿意承担风险.
都这样的话,运维岗就不会那么苦逼,凌晨上线,周末上线

[blessingsi]

除了当事人谁也不清楚事情根因是啥样的，没必要抨击别人水平不够。google ，Facebook ，cloudflare 这几年都有过大规模服务不可用的情况，更何况是语雀。蚂蚁的工程师肯定明白分布式和高可用基础理论，支付宝的可用性也算是很好的了，但是到了实践中谁能保证不犯错呢。反正没必要太信任这些云端服务，自己的数据还是在本地有一份比较放心。

[realpg]

语雀这么大公司，表现得跟路边三五个人创业的草台班子一样

请不要侮辱我们草台班子
我们总共就俩人，一切操作都是 00：30-04：30

[codingbody]

我们就是上午、下午、晚上都有发布时间窗口。

[WashFreshFresh]

下午上线确实少见，可能是做灰度出现的问题。

[hancai]

@realpg 你们这发布时间，容易人没了

[proxytoworld]

我阴谋论一下

某个有更改工具权限的人看着一堆老机器、屎山没人敢管，索性直接来波大的，直接靠宕机来升级设备！（仅仅开开玩笑）反正出会员经费的是公司

[Euthpic]

@aper 只要变更，就有可能出问题，非高峰发布可以降低故障成本。如果你只是单纯吐槽发版要加班，可以理解，如果你是单纯认为下午发版没问题，那你不太适合这个行业

[mailshenzhw]

> 由于新的运维升级工具 bug ，导致华东地区生产环境存储服务器被误下线。

被你说成

> 由于临时工在升级维护工具的时候，


不知道楼主在哪里看到的临时工几个字

[Flobit]

这个世界本来就是一个巨大的草台班子

[aper]

@Euthpic 看了你的简历，我觉得你没啥资格说这句话。如果业务需要半夜才发版，说明基架做的太差了，多学学吧

[levelworm]

我和你说，所有的公司，对就是所有的，都是草台班子。

[Inn0Vat10n]

很多人不了解阿里系，至少从我接触过的大多数 BU ，变更时间是必须在白天 9 点-下午 17 之间的，半夜、周末变更是红线不可能做的。任何变更都要求是能灰度的，白天变更风险远不如半夜把其他团队系统搞挂结果没人修、发现晚、响应慢来的严重。另外这次这种事件缺乏灰度导致整个系统宕机这么久,　舆情影响这么大，估计今年绩效难逃 3.25 了。

[yfixx]

@realpg 凌晨这样熬夜发布人受得了吗

[Beats]

@cherbim 我解答下吧
1 、一般大公司发布都是白天，禁止晚上发布，晚上发布要说明原因，还早走层层审批。
2 、听旁边人说好像是回滚方案在语雀文档里面，然而语雀文档自身挂了（不知道真假）

[dt1]

@nekoharuya 为什么更新时间点选在周一是个问题？难道要周五发，然后周六，日待命以防万一？
周一时间点不错，当然周二更好。至于下午更新，说明他们有自信，支持无影响的服务热更新与替换，更是技术水平的体现。至于出了问题，那是意外了，证明了还是有未预期的问题。
但说草台班子，什么班子才叫不草台，谷歌是吗，还是 Oracle ，还是微软？

[nekoharuya]

@dt1 你可以看我#79 楼的回复，一个合格的团队，无计划的更新是绝对不可能允许的，当然我也不是推崇谷歌那种一个小改动立项个把月的做法，甲骨文那种随便改一下就要测试半年才允许更上去的我知道在你眼里肯定也是反面典型

[Inn0Vat10n]

@nekoharuya 大厂一般成熟的发布体系都是可以控制灰度百分比逐渐生效的，基本不存在“高峰期”影响面问题。阿里这种一个 BU 正常一天几百上千次变更的，你要都堆在特定时间发布更是不现实。另外你半夜发个 BUG 推全量，第二天起来才发现的后果，拼多多的优惠券事件就是前车之鉴。阿里这么多年了到现在的体量，总结出来的发布规范都是一个个坑踩出来的，这次这种纯粹是员工没遵守规范，和发布流程本身关系真不大。

[nekoharuya]

@Inn0Vat10n 经验总结和书面性质的规范是没有意义的，只有从工具链上硬性限制，没有测试验收的代码不提供任何渠道发布到生产环境，至于发布时间，我的角度是他发布的时间点表明他周一上班干了一早上，下午直接推上去了，至于是不是全量，是不是高峰期，不是我关注的点，当然其他楼很多人关注这个点，另外这个问题相对于他们架构设计上的问题太小了，不值一提，没什么好关注的，谁还没有过几次蜜汁自信直接莽上去然后造成事故的经历

[nekoharuya]

@Inn0Vat10n 另外员工有没有遵守规范这个问题，这就回到了是信任工具还是信任工程师的问题，我的观点始终是人一定会出错，你把比雅尼大爷叫来他一样会写 bug ，人出错了，扣点工资，或者了不起把人开了，可事故已经发生了，做这些事情对于事故本身没有意义，能自动化的东西就应该杜绝对人的依赖

[dt1]

@Euthpic 170 楼， @aper 173 楼，不用说看啥简历，就事论事，我支持你的观点。
但凡有信心的，就要做到随时发版。如果要限制非忙时发版，只有说明技术还是不太行。
拿 gogole 来看看，做全球市场的，你说哪个时间段不算下午（忙时）？