语雀这路子太野了

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

估计是阿里云上建不了旧规格的实例
shakoon
2023 年 10 月 25 日
@aper #68 这就是个风险控制的问题。举个可能你还不知道的例子，现在还在亚残运会期间，全国的国企都是禁止做系统变更的，处理紧急情况也要经过比平常的投产更高层级的审批。
rtx3
2023 年 10 月 25 日
这种等级的公司不会高峰时间发版的。这种多数是运维工具测试中把一些任务分配到了生产环境。。
RubyJack
2023 年 10 月 25 日
感觉应该不止一台 DB 服务器被下线，而是整个 DB 所有实例都下线了，然后从备份进行了一次完整恢复
fish267
2023 年 10 月 25 日
@codcrafts 数据没恢复前，不能对外呀，不然影响更恶劣
lovelive1024
2023 年 10 月 25 日
@Aliencn #16 不是说用了两个小时校验数据么，可能是通过日志将丢失的那部分恢复了
aper
2023 年 10 月 25 日
@shakoon 这个是特殊时期禁止发版，就像过年前一周禁止发版，完全不一样的事情。难道每天都 3 个小时都禁止发版，业务得吭哧吭哧半夜脑子一坨糊的时候跑来发版是吧
waringid
2023 年 10 月 25 日
从公告的内容来看，“服务语雀的数据存储运维团队在进行升级操作”这句的意思给人的感觉是第三方（或者说不是语雀自己的团队）由此推断：
1 、语雀团队更关注功能和日常的运行维护，不涉及存储管理（或者说只是使用存储资源）
2 、存储资源可能是第三方资源（阿里云或是蚂蚁内部存储资源），应该是分布式存储（类似于 ceph ）
3 、存储集群的服务器资源使用的是旧服务器（新服务器可能是另一个群集），旧群集基于之前的业务可能长时间都未更新升级（能用），也没有考虑逐步迁移的新群集
4 、旧存储群集出现问题（例如硬件故障导致磁盘空间或是同步故障等），受技术限制（内部没有技术资源长期维护旧版本）短时间无法迁移切换到新群集
5 、通过数据恢复的方式迁移切换到新的环境（但愿）
Folayi
2023 年 10 月 25 日
草台班子理论
pkoukk
2023 年 10 月 25 日
@nekoharuya #79
软件工程没有银弹，分布式不能解决所有问题。
加机器只能在一定范围内有效，随着数据规模和机器规模的增长，你会发现有太多问题是不可拆分的，费劲把他们拆开送到子节点，再回收回来带来的一致性等等问题成本远高于分布式的收益。
目前最简单的例子就是跑 AI ，大模型的任务没办法切分，只能靠 NVLINK 这样的方式强行把多台机器并成一个超大的单机来用。
Daniel17
2023 年 10 月 25 日
临时工
codcrafts
2023 年 10 月 25 日
@fish267 问题是一开始官网是无法访问的，下午 4 点多的时候，我再次进官网是 502 ，说明这个时候负载均衡啥的已经过了
timothyye
2023 年 10 月 25 日
问题不大，毕竟这个世界都是一个草台班子
R4rvZ6agNVWr56V0
2023 年 10 月 25 日
没准是裁员导致的管理问题。
bugmakerxs
2023 年 10 月 25 日
@nekoharuya 运维工具应该在不在应用所在的服务器上。运维工具权限很大很奇怪么，弹性扩缩容，服务自动迁移都需要运维工具管理一批机器。大公司运维平台迭代较快的话，很多 n 年老服务下线就是很难起来了，需要重新适配新的启停脚本/重做镜像之类。
lwjlol
2023 年 10 月 25 日
没必要咬文嚼字，这个公告就是给普通用户随便看看，真实的原因除了当事人谁会知道。
nekoharuya
2023 年 10 月 25 日
@pkoukk 拜托考虑下场景，语雀这样的在线文档/协作工具，面对的问题不是大模型那样的线性数据迭代，而是数据规模和用户并发压力
在这个背景下，把不同的数据表/块裂分到不同的主从服务器组里，各自承担对应部分的读写压力，再另起队列慢慢同步不属于自己负责区域的数据
单个主从服务器组炸了可以随时滚一个新的出来，也可以让其他组多承担一部分
这种简单有效低成本的设计，牺牲的只是一点磁盘空间，对于网络，cpu 性能，磁盘性能的要求，全部降低了不止一个数量级，单组机器只用抗住拆分后需要负责的数据规模，即使它炸了也能自动让其他组顶上
经典案例可以参考 telegram 的做法，每个用户的数据，都由不同的数据中心进行处理
utodea
2023 年 10 月 25 日
@4kingRAS #9 不太可能是应用级的问题，应用级的问题回滚一下就好了，再差顶多几十分钟一个小时也就处理完成了。
nekoharuya
2023 年 10 月 25 日
@bugmakerxs 我来北京以后，去的第一家公司，只待了一个月就跑路的原因，就是看着祖传遗产害怕，老板跟我说我工位的机器，是网易现在的技术总监当年用过的……到我手里都不知道多少手了，一大堆和业务强关联的工具链，根本不敢乱动，交接文档都由不同的人写了好些份……
julyclyde
2023 年 10 月 25 日
OP 大概是一路成长比较顺利，没见过这世界的背面
将来估计要吃大亏

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/985202

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX