这是一个创建于 395 天前的主题，其中的信息可能已经有所发展或是发生改变。
https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw
他们的公告的链接
考虑到 v 友的水平，我抛砖引玉分析一下
这帖子的意思大概是说，由于临时工在升级维护工具的时候，工具没有严格测试，直接上生产环境，工具的 bug 导致数据库服务器下线，联系硬件团队，硬件团队说上不了线，摆烂不玩了，你们自己恢复备份吧，然后花了四个小时恢复，俩小时验证数据，成功上线
我和几个朋友讨论了下，觉得非常的，不可思议
这是 2023 年的，语雀这个体量的公司，做出来的事情
正常的架构思维里，所有的服务，就不应该跑在同一台机器上，包括数据库，最次也该是个主从集群，集群下面的机器单例再考虑 raid 之类的东西
在这个设计下，不存在上不了线开不了机这种事情，机房被修卡军团占领了都没事
至于网上传的什么之前的技术负责人跑路了，新人不会操作
就正常的 devops ，后台管理面板里，全自动维护，包括版本控制，回滚，备份，集群，镜像，机器冗余，全部自动化管理
这不该是现在的标配吗
技术负责人跑路，新人不会操作，这句话假定的前提是，这一切都是手工完成的
语雀这么大公司，表现得跟路边三五个人创业的草台班子一样
他们的公告的链接
考虑到 v 友的水平，我抛砖引玉分析一下
这帖子的意思大概是说，由于临时工在升级维护工具的时候，工具没有严格测试，直接上生产环境，工具的 bug 导致数据库服务器下线，联系硬件团队，硬件团队说上不了线，摆烂不玩了，你们自己恢复备份吧，然后花了四个小时恢复，俩小时验证数据，成功上线
我和几个朋友讨论了下，觉得非常的，不可思议
这是 2023 年的，语雀这个体量的公司，做出来的事情
正常的架构思维里，所有的服务，就不应该跑在同一台机器上，包括数据库，最次也该是个主从集群，集群下面的机器单例再考虑 raid 之类的东西
在这个设计下，不存在上不了线开不了机这种事情，机房被修卡军团占领了都没事
至于网上传的什么之前的技术负责人跑路了，新人不会操作
就正常的 devops ，后台管理面板里，全自动维护，包括版本控制，回滚，备份，集群，镜像，机器冗余，全部自动化管理
这不该是现在的标配吗
技术负责人跑路，新人不会操作，这句话假定的前提是，这一切都是手工完成的
语雀这么大公司，表现得跟路边三五个人创业的草台班子一样
 |
101
nekoharuya OP @lambdaq 研发和运维一体，就叫 Devops ，你看，这个词在这个帖子里，应该是我用得最多的了
|
 |
102
hancai 2023-10-25 15:37:09 +08:00
上个月我们公司部分服务不可用 10 分钟，人事要扣我 50%的绩效。语雀的运维估计得开掉一批，换一批更坑的替代。
|
 |
103
kaedea 2023-10-25 15:39:41 +08:00 via Android
再草包有人能纠错就不算草包，没人敢纠错的才是真草包。
|
 |
104
iugo 2023-10-25 15:49:48 +08:00
> 导致华东地区生产环境存储服务器被误下线
> 升级硬件版本和机型，实现离线后的快速上线。该措施在本次故障修复中已完成 "下线" 这个词应该就是下线, 没有数据丢失. 不能再次上线正是因为自动化工具不支持, 才导致的. 自动化工具应该之前做过升级, 后续就只支持新机器了. 语雀做的就是找了新机器, 备份了老机器上的数据, 在新机器上重新部署了老机器上的数据服务. 我觉得问题核心应该是 "及时升级" (无论是软件依赖还是底层硬件). |
 |
105
lambdaq 2023-10-25 15:53:21 +08:00
@nekoharuya s/devops/devoops/g
|
 |
109
VYSE 2023-10-25 16:21:58 +08:00
@wangshushu #51 两家公司, 啥时蚂蚁把语雀卖给阿里云了
|
 |
110
jmljava 2023-10-25 16:25:54 +08:00
目前的现状可能是只要东西能跑,这就是一个稳定安全的服务,至于什么时候暴雷,相信下一任的智慧
|
 |
111
o562dsRcFqYl375i 2023-10-25 16:49:58 +08:00
修卡军团可还行 DOGE
|
|
112
hancai 2023-10-25 16:50:55 +08:00
@seeu2ex 我上家公司新来了个老大，说要做到上班时间发版， 出了一次生产事故后，发版时间反而比他来之前还延后了半小时...
|
 |
113
cmlx1014 2023-10-25 16:55:31 +08:00
阿里的东西，不赚钱就不重视，结果出了大纰漏。前面的会员也是吐槽得不行，连玉伯都走了。
|
 |
114
KickAssTonight 2023-10-25 16:57:12 +08:00
是人就会犯错
|
 |
115
dragondove 2023-10-25 17:01:02 +08:00
再大的公司都会出纰漏的，gitlab 出现过线上库被删的问题。之前某 dns 提供商出错导致大量美国的网站没法访问。我觉得语雀这个算是比较轻的问题了
|
 |
116
silencil 2023-10-25 17:02:24 +08:00
@cherbim 我建议别抨击这个，我以前待的一家公司开发的系统，每次都是晚上十点多开始升级，每一两周来一次，每次升级就是接近一个通宵。同为程序员，我觉得服务短期不可用不会死（做好了各种回滚策略，白天升级也不至于导致服务不可用），长此以往的熬夜升级服务是真的会猝死。
|
 |
118
yulgang 2023-10-25 17:04:33 +08:00
他们没有运维团队和灾备系统😁
|
|
119
silencil 2023-10-25 17:12:17 +08:00  1
说阿里草台班子也大可不必，至少从概率上来说，阿里的员工技术、架构等经验应当会大于大部分公司。程序员老是相轻，与我见过的理发师的做法是一样的，经常理发的时候理发师都要抨击一下上一任给我剪头发的剪的烂，实则自己也是下一次别人抨击的对象。
|
 |
120
codcrafts 2023-10-25 17:18:19 +08:00
我有个问题没想明白，存储服务下线了，为啥官网也挂了呢？有没有大佬能解答一下的
|
 |
121
naomhan 2023-10-25 17:20:44 +08:00
15:00 确认因存储系统使用的机器类别较老，无法直接操作上线
估计是阿里云上建不了旧规格的实例 |
 |
122
shakoon 2023-10-25 17:22:34 +08:00
@aper #68 这就是个风险控制的问题。举个可能你还不知道的例子，现在还在亚残运会期间，全国的国企都是禁止做系统变更的，处理紧急情况也要经过比平常的投产更高层级的审批。
|
 |
123
rtx3 2023-10-25 17:22:37 +08:00
这种等级的公司不会高峰时间发版的。这种多数是运维工具测试中把一些任务分配到了生产环境。。
|
 |
124
RubyJack 2023-10-25 17:22:52 +08:00
感觉应该不止一台 DB 服务器被下线，而是整个 DB 所有实例都下线了，然后从备份进行了一次完整恢复
|
 |
127
aper 2023-10-25 17:58:13 +08:00
@shakoon 这个是特殊时期禁止发版，就像过年前一周禁止发版，完全不一样的事情。难道每天都 3 个小时都禁止发版，业务得吭哧吭哧半夜脑子一坨糊的时候跑来发版是吧
|
 |
128
waringid 2023-10-25 17:59:20 +08:00 2
从公告的内容来看，“服务语雀的数据存储运维团队在进行升级操作”这句的意思给人的感觉是第三方（或者说不是语雀自己的团队）由此推断：
1 、语雀团队更关注功能和日常的运行维护，不涉及存储管理（或者说只是使用存储资源） 2 、存储资源可能是第三方资源（阿里云或是蚂蚁内部存储资源），应该是分布式存储（类似于 ceph ） 3 、存储集群的服务器资源使用的是旧服务器（新服务器可能是另一个群集），旧群集基于之前的业务可能长时间都未更新升级（能用），也没有考虑逐步迁移的新群集 4 、旧存储群集出现问题（例如硬件故障导致磁盘空间或是同步故障等），受技术限制（内部没有技术资源长期维护旧版本）短时间无法迁移切换到新群集 5 、通过数据恢复的方式迁移切换到新的环境（但愿） |
 |
129
Folayi 2023-10-25 18:02:59 +08:00
草台班子理论
|
 |
130
pkoukk 2023-10-25 18:17:58 +08:00
@nekoharuya #79
软件工程没有银弹，分布式不能解决所有问题。 加机器只能在一定范围内有效，随着数据规模和机器规模的增长，你会发现有太多问题是不可拆分的，费劲把他们拆开送到子节点，再回收回来带来的一致性等等问题成本远高于分布式的收益。 目前最简单的例子就是跑 AI ，大模型的任务没办法切分，只能靠 NVLINK 这样的方式强行把多台机器并成一个超大的单机来用。 |
 |
131
Daniel17 2023-10-25 18:18:06 +08:00
临时工
|
|
132
codcrafts 2023-10-25 18:52:36 +08:00 1
@fish267 问题是一开始官网是无法访问的，下午 4 点多的时候，我再次进官网是 502 ，说明这个时候负载均衡啥的已经过了
|
 |
133
timothyye 2023-10-25 18:55:51 +08:00
问题不大，毕竟这个世界都是一个草台班子
|
 |
134
GeekGao 2023-10-25 19:14:11 +08:00
没准是裁员导致的管理问题。
|
 |
135
bugmakerxs 2023-10-25 19:23:33 +08:00
@nekoharuya 运维工具应该在不在应用所在的服务器上。运维工具权限很大很奇怪么，弹性扩缩容，服务自动迁移都需要运维工具管理一批机器。大公司运维平台迭代较快的话，很多 n 年老服务下线就是很难起来了，需要重新适配新的启停脚本/重做镜像之类。
|
 |
136
lwjlol 2023-10-25 19:24:58 +08:00
没必要咬文嚼字，这个公告就是给普通用户随便看看，真实的原因除了当事人谁会知道。
|
|
137
nekoharuya OP @pkoukk 拜托考虑下场景，语雀这样的在线文档/协作工具，面对的问题不是大模型那样的线性数据迭代，而是数据规模和用户并发压力
在这个背景下，把不同的数据表/块裂分到不同的主从服务器组里，各自承担对应部分的读写压力，再另起队列慢慢同步不属于自己负责区域的数据 单个主从服务器组炸了可以随时滚一个新的出来，也可以让其他组多承担一部分 这种简单有效低成本的设计，牺牲的只是一点磁盘空间，对于网络，cpu 性能，磁盘性能的要求，全部降低了不止一个数量级，单组机器只用抗住拆分后需要负责的数据规模，即使它炸了也能自动让其他组顶上 经典案例可以参考 telegram 的做法，每个用户的数据，都由不同的数据中心进行处理 |
|
139
nekoharuya OP @bugmakerxs 我来北京以后，去的第一家公司，只待了一个月就跑路的原因，就是看着祖传遗产害怕，老板跟我说我工位的机器，是网易现在的技术总监当年用过的……到我手里都不知道多少手了，一大堆和业务强关联的工具链，根本不敢乱动，交接文档都由不同的人写了好些份……
|
 |
140
julyclyde 2023-10-25 20:03:15 +08:00 3
OP 大概是一路成长比较顺利，没见过这世界的背面
将来估计要吃大亏 |
 |
142
reeco 2023-10-25 21:45:00 +08:00 1
前端写的系统，稳定性能好到哪里去
|
 |
143
CoffeeY 2023-10-25 22:29:19 +08:00
等下故意的呢？这波 IT 圈到处讨论，各种卖课公众号也是各种讲。
顺便分析一波你们对语雀的依赖情况·🤪 |
 |
144
gransh 2023-10-25 23:13:25 +08:00 1
看看俄罗斯再看看以色列，世界的本质就是草台班子组成的啊
|
 |
146
akatale 2023-10-26 00:01:13 +08:00
想想当年 gitlab 更寄
https://www.bilibili.com/video/BV1uM4y1e7Mo/ |
 |
147
chaleaochexist 2023-10-26 00:18:53 +08:00
歪个楼, 那我是不是可以白嫖六个月会员啊??
|
 |
148
ysw 2023-10-26 01:04:09 +08:00
觉得可能是旧机器被删了，新机器盘符映射路径不对，导致数据损坏？
|
 |
149
daimiaopeng 2023-10-26 09:19:42 +08:00
@minami #3 下个月加急
|
 |
150
gosling 2023-10-26 09:44:39 +08:00
@aeli 感觉有可能，之前我们团队也是引入了 terraform ，有一个参数没看文档就直接上了，导致集群所有机器都给删除了。重新买了一批启动了半小时。。
|
 |
152
yh7gdiaYW 2023-10-26 09:59:52 +08:00
以语雀的体量，运维肯定不是自己 BU 的人，硬件团队又是另一伙儿，楼主你对大公司的扯皮不熟悉啊
|
 |
153
siyang601165858 2023-10-26 10:08:37 +08:00
@aaronkk 确实 刚领的
|
 |
155
haoyli 2023-10-26 10:27:15 +08:00
@Aliencn 是这样，工作中很多地方都是，大家都知道有一些东西存在隐患但人没敢优化，无功有过，ROI 低，于是所有人都不管，直到哪天被引爆。这种情况无法避免，因为在高速迭代业务的进程中，业务第一，支持业务才能拿到绩效，至于说排雷，who cares ？
|
 |
156
wtfedc 2023-10-26 10:38:19 +08:00
服务升级升一半，有环节出问题，上不去下不来，也还算正常吧。
旧 ECS 装不上软件的问题我碰到过，完全是始料未及，你如果有 5000 台机器，30 台旧机器，你甚至都不好验证。停掉服务不一定是服务都不可用，有可能是为了保证严格数据一致性直接下线。 语雀的存储体量和成本预算，能不能支持多活都不好说，有个灾备，恢复数据保证不丢失已经不错了。多活也是针对服务说的，至于存储，数据结构有变化，多活也得一块升级，要不同步就会出问题。 有状态的服务回滚，也容易出问题，这还是以存储为主的服务。reddit 升级 k8s 还宕机过几小时呢，不是说出了问题，一键回滚就可以，尤其在非应用层面。 有时候问题完全是不可知的，可以说它前期验证不严格，但是不可能所有的东西都能验证到。抱着学习的态度可以，说人草台班子就格局太小了，毕竟人家也服务千万级别的用户，何况提供的信息不明确。 |
 |
157
kknd22 2023-10-26 11:12:54 +08:00
这个世界破破烂烂，总是有人修修补补
|
 |
158
Light3 2023-10-26 11:16:29 +08:00 2
首先楼主恶意造谣
试问哪个员工会领着工资说 上不了线 摆烂了 不玩了？这是人 最基本的职业道德 可能楼主是这样的人把 反正我从来没遇到过 从来没有 其次从一个公司发展时间时间来看 肯定会存在新的机器与旧的机器 升级出现失败 很正常 启不开也很正常 自己买的电脑也会昨天好好的 今天突然打不开 回滚？我也会回滚 问题是打不开了咋办？ 所有的系统都是保证 99.99%的可用性 所以我不懂楼主既暴露自己的无知 愚蠢 又抨击他人的做法 |
 |
159
tietou 2023-10-26 11:20:10 +08:00
下午升级 也是够可以的呀
|
 |
160
mumubin 2023-10-26 13:09:51 +08:00
在服务和数据安全的情况下,选择修复数据是正确的选择.
Youtube 还两三年挂个半天一天的,toc AWS 的某个 region 还经常某个服务挂个七八个小时呢.导致全美小公司的产品半天一天访问不了 这俩服务不比语雀重要的多? 不过可以喷阿里系,天天吹牛,又没做到 |
 |
161
yy77 2023-10-26 13:16:03 +08:00
收入不好看，需要砍费用的情况下，先把异地多活给砍了呗。
|
 |
162
JinTianYi456 2023-10-26 13:17:39 +08:00
@yyzh #4 对的，技术是有很牛逼的方案的。但有木有用上就是另一回事。我公司就没有。但也不妨碍 10W 日活
|
|
163
mumubin 2023-10-26 13:17:59 +08:00
@tietou 下午升级挺好的,说明自信,对产品和运维要求高,也说明技术负责人愿意承担风险.
都这样的话,运维岗就不会那么苦逼,凌晨上线,周末上线 |
 |
164
blessingsi 2023-10-26 13:22:47 +08:00
除了当事人谁也不清楚事情根因是啥样的，没必要抨击别人水平不够。google ，Facebook ，cloudflare 这几年都有过大规模服务不可用的情况，更何况是语雀。蚂蚁的工程师肯定明白分布式和高可用基础理论，支付宝的可用性也算是很好的了，但是到了实践中谁能保证不犯错呢。反正没必要太信任这些云端服务，自己的数据还是在本地有一份比较放心。
|
 |
165
realpg 2023-10-26 13:44:01 +08:00
语雀这么大公司，表现得跟路边三五个人创业的草台班子一样
请不要侮辱我们草台班子 我们总共就俩人，一切操作都是 00：30-04：30 |
 |
166
codingbody 2023-10-26 14:35:58 +08:00
我们就是上午、下午、晚上都有发布时间窗口。
|
 |
167
WashFreshFresh 2023-10-26 15:36:16 +08:00
下午上线确实少见，可能是做灰度出现的问题。
|
 |
169
proxytoworld 2023-10-26 17:28:19 +08:00
我阴谋论一下
某个有更改工具权限的人看着一堆老机器、屎山没人敢管，索性直接来波大的，直接靠宕机来升级设备！（仅仅开开玩笑）反正出会员经费的是公司 |
 |
170
Euthpic 2023-10-26 18:50:56 +08:00 via Android
@aper 只要变更，就有可能出问题，非高峰发布可以降低故障成本。如果你只是单纯吐槽发版要加班，可以理解，如果你是单纯认为下午发版没问题，那你不太适合这个行业
|
 |
171
mailshenzhw 2023-10-26 19:33:37 +08:00 1
> 由于新的运维升级工具 bug ，导致华东地区生产环境存储服务器被误下线。
被你说成 > 由于临时工在升级维护工具的时候， 不知道楼主在哪里看到的临时工几个字 |
 |
172
Flobit 2023-10-26 19:37:42 +08:00 via iPhone
这个世界本来就是一个巨大的草台班子
|
 |
174
levelworm 2023-10-26 19:40:39 +08:00 via Android
我和你说，所有的公司，对就是所有的，都是草台班子。
|
 |
175
Inn0Vat10n 2023-10-26 19:44:51 +08:00
很多人不了解阿里系，至少从我接触过的大多数 BU ，变更时间是必须在白天 9 点-下午 17 之间的，半夜、周末变更是红线不可能做的。任何变更都要求是能灰度的，白天变更风险远不如半夜把其他团队系统搞挂结果没人修、发现晚、响应慢来的严重。另外这次这种事件缺乏灰度导致整个系统宕机这么久, 舆情影响这么大，估计今年绩效难逃 3.25 了。
|
 |
177
Beats 2023-10-26 22:50:29 +08:00
|
 |
178
dt1 2023-10-27 11:33:55 +08:00
@nekoharuya 为什么更新时间点选在周一是个问题？难道要周五发，然后周六，日待命以防万一？
周一时间点不错，当然周二更好。至于下午更新，说明他们有自信，支持无影响的服务热更新与替换，更是技术水平的体现。至于出了问题，那是意外了，证明了还是有未预期的问题。 但说草台班子，什么班子才叫不草台，谷歌是吗，还是 Oracle ，还是微软？ |
|
179
nekoharuya OP @dt1 你可以看我#79 楼的回复，一个合格的团队，无计划的更新是绝对不可能允许的，当然我也不是推崇谷歌那种一个小改动立项个把月的做法，甲骨文那种随便改一下就要测试半年才允许更上去的我知道在你眼里肯定也是反面典型
|
|
180
Inn0Vat10n 2023-10-27 18:30:33 +08:00
@nekoharuya 大厂一般成熟的发布体系都是可以控制灰度百分比逐渐生效的，基本不存在“高峰期”影响面问题。阿里这种一个 BU 正常一天几百上千次变更的，你要都堆在特定时间发布更是不现实。另外你半夜发个 BUG 推全量，第二天起来才发现的后果，拼多多的优惠券事件就是前车之鉴。阿里这么多年了到现在的体量，总结出来的发布规范都是一个个坑踩出来的，这次这种纯粹是员工没遵守规范，和发布流程本身关系真不大。
|
|
181
nekoharuya OP @Inn0Vat10n 经验总结和书面性质的规范是没有意义的，只有从工具链上硬性限制，没有测试验收的代码不提供任何渠道发布到生产环境，至于发布时间，我的角度是他发布的时间点表明他周一上班干了一早上，下午直接推上去了，至于是不是全量，是不是高峰期，不是我关注的点，当然其他楼很多人关注这个点，另外这个问题相对于他们架构设计上的问题太小了，不值一提，没什么好关注的，谁还没有过几次蜜汁自信直接莽上去然后造成事故的经历
|
|
182
nekoharuya OP @Inn0Vat10n 另外员工有没有遵守规范这个问题，这就回到了是信任工具还是信任工程师的问题，我的观点始终是人一定会出错，你把比雅尼大爷叫来他一样会写 bug ，人出错了，扣点工资，或者了不起把人开了，可事故已经发生了，做这些事情对于事故本身没有意义，能自动化的东西就应该杜绝对人的依赖
|
|
183
dt1 2023-10-28 11:43:05 +08:00
|
Select Language