语雀这路子太野了

2023 年 10 月 25 日
 nekoharuya
https://mp.weixin.qq.com/s/WFLLU8R4bmiqv6OGa-QMcw
他们的公告的链接
考虑到 v 友的水平，我抛砖引玉分析一下
这帖子的意思大概是说，由于临时工在升级维护工具的时候，工具没有严格测试，直接上生产环境，工具的 bug 导致数据库服务器下线，联系硬件团队，硬件团队说上不了线，摆烂不玩了，你们自己恢复备份吧，然后花了四个小时恢复，俩小时验证数据，成功上线
我和几个朋友讨论了下，觉得非常的，不可思议
这是 2023 年的，语雀这个体量的公司，做出来的事情
正常的架构思维里，所有的服务，就不应该跑在同一台机器上，包括数据库，最次也该是个主从集群，集群下面的机器单例再考虑 raid 之类的东西
在这个设计下，不存在上不了线开不了机这种事情，机房被修卡军团占领了都没事
至于网上传的什么之前的技术负责人跑路了，新人不会操作
就正常的 devops ，后台管理面板里，全自动维护，包括版本控制，回滚，备份，集群，镜像，机器冗余，全部自动化管理
这不该是现在的标配吗
技术负责人跑路，新人不会操作，这句话假定的前提是，这一切都是手工完成的
语雀这么大公司，表现得跟路边三五个人创业的草台班子一样
32873 次点击
所在节点    程序员
183 条回复
julyclyde
2023 年 10 月 25 日
@cherbim 白天升级比晚上好。晚上人的状态不好，而且经常人数工种不齐全
julyclyde
2023 年 10 月 25 日
另外，对于寄希望于“点点面板就可以”，我只能说这种大众认知其实正是事故隐患的来源
fatekey
2023 年 10 月 25 日
有效信息太少，没法评价
julyclyde
2023 年 10 月 25 日
@mazyi 具体情况不知道。不过你问的这种情况确实有可能发生：

比如语雀作为赖着不走的用户占用一个虚拟机，这个虚拟机的宿主是一个旧硬件，已经被阿里云列入淘汰计划
这次语雀用户升级时，在没注意到里面有些“本地存储数据”的情况下，释放了这个虚拟机，然后其宿主机直接被自动化踢出，甚至格式化了

这种情况，即使之前做过演练也不一定能发现，因为演练的时候不一定会伴随发生 IaaS 层的变化，虚拟机里的本地存储数据在演练时也不一定重要到能看出事故的程度
nekoharuya
2023 年 10 月 25 日
@julyclyde 这其实是我的经验之谈，你不信任精心设计和经过反复测试和验证的自动化处理，却相信凭经验和感觉的人工手动操作吗
nothingistrue
2023 年 10 月 25 日
文档服务，你搞数据库主从集群，你这路子更野。
julyclyde
2023 年 10 月 25 日
@nekoharuya 你这样说其实是假设面板都经过反复测试验证了
这种事能随便假设么
nekoharuya
2023 年 10 月 25 日
@nothingistrue 别光喷呀，有何高见
zachary99
2023 年 10 月 25 日
应该是当初设计架构的可能都走了，这块从来没做过，没交接下来
nekoharuya
2023 年 10 月 25 日
@julyclyde 小公司自己手动操作确实居多，我以前的时候，也是从手动操作->自动脚本->gui 工具，这样积累起来，但是，语雀这么大个公司
julyclyde
2023 年 10 月 25 日
@nekoharuya 其实大公司也有大公司的问题
提倡使用面板，看似是减少误操作，其实也减少了人员的训练
把“工程师”降成了“操作员”
一旦出现问题，很可能会发现他们连紧急抢救的技能都忘了
adoal
2023 年 10 月 25 日
小团队小草台，大团队大草台，老系统老屎山，新系统新屎山
KcKXpykSg2777f5I
2023 年 10 月 25 日
语雀早就被钉钉团队合并了，其实原来内部是竞合关系，收编之后语雀的人走了很多
nekoharuya
2023 年 10 月 25 日
@julyclyde 我们其实是基于两种假设
我的假设是，人工操作不可靠，是人就一定会出问题，信任人的技能熟练程度不如信任工具的完善程度，因为工具的更新是一证永证的
你的假设是，问题持续在变化，能用工具覆盖的问题本身就不应该出现，所有出现的问题都是未知的，只能依赖工程师抢救
我觉得你的想法挺有道理的，就不争论这个了
回到问题本身，我认为语雀这个故障和处理方法，不管是哪种假设，它都不应该出现，因为完善的架构方案和工具链实在很多
julyclyde
2023 年 10 月 25 日
@nekoharuya 首先，工具的更新并不是一证永证的
因为现实中的工具只是人的眼神，人有多大权限，工具最多也就有多大权限
语雀肯定管不了阿里云啊

假设我前面 44 层的猜测正确，那么阿里云提供抽象的服务，没有任何过错；
语雀的程序实际有本地状态却按无状态来处理，没有揭示风险给工具开发者，导致工具和被运维的目标不配套，但二者都是他们自己开发的，他们自己应该负全责。在这种情况下假设工具正确没有什么意义

甚至可能出现，刚开始二者是配套的，后来服务程序被谁改成了有本地状态，而工具依然按无状态来做，导致故障。这就是典型的违反你的一证永证假设的情况
dayeye2006199
2023 年 10 月 25 日
多大的事儿，谷歌都全网挂过，各种分布式容灾，但还是挂了
binaryify
2023 年 10 月 25 日
玉伯都去字节了
nekoharuya
2023 年 10 月 25 日
@julyclyde 你 44 层的分析我认真看过了，这其实还是我最开始说的架构设计的问题，机器是物理机还是虚拟机，横竖都只是个容器，上层上个集群，下面的容器怎么更新都没关系，把机房拆了都行，语雀这种单例设计是我主要喷的点
然后你说的人的眼神，还有设计上无状态有状态的变化，这是不是很符合我说的，完全无法避免是个人一定会出错
既然不能避免，就更应该自动化，去依赖化
至于工具的一证永证当然指的是相同条件下，外部条件变了自然要重新开发，也就是我认同你说的依赖工程师解决全新的问题
dolphintwo
2023 年 10 月 25 日
抱歉，我个人觉得这个流程似乎没什么问题，时间上重建存储服务+日志恢复+完整性校验，作为只有单点冗余的结构
7 个小时应该是正常的。后面也说了会换两地三中心，除了删库这个时间点，暂时没看出有什么可喷的。

大家都是草台班子，谁也别笑谁。
julyclyde
2023 年 10 月 25 日
@nekoharuya 你说的去依赖等等，都是“化”，是要去努力的目标
而不是现状

不能把这些作为现状去做假设，并在这种未经验证的假设之下去做其他事
更不能在此假设下自废武功

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

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

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

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

© 2021 V2EX