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

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

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

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

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

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

@VB1 容器这里是我用词不准确，这里的语境是，不管是虚拟机还是物理机都是容纳数据的容器
当然，产生歧义是我不对
然后，从真实场景上看，你看上面的回复，大多数人认为，他们就是上了套 raid ，具体哪套 raid 不清楚，不过不重要，没有更多的信息，但是应该大差不差
我的观点是，这种不是独立环境的，可以称为一套/一台/一个机器

@lambdaq 语雀上线也不是一天两天了，大家上班也不是每天 24 小时都用什么钉钉飞书，他们后台肯定是有在线数据分析的，我觉得大概是更新的人觉得改动很小，不重视，没当回事，而且又是和用户没有直接关系的运维工具，从我的经验看，包括我自己，大部分人都会有这种蜜汁，然后闹出事故的经历的……不过这就是我瞎猜的了

@aper 碰啊，你翻翻我发的第一个帖子，如果能看懂，咱俩加个 v 聊聊 ai 撒，体系这种东西，你不碰，大概率就是别人代偿了，比如游戏公司一般是策划代偿了，我之前一路混到了独角兽公司的架构师岗位，现在在小创业公司做 CTO ，我管理水平也就半桶水，就之前被逼着学一点，主要还是靠写代码的硬实力

@NCZkevin 后来公司寄了，这大哥现在在 supercell 上班，希望他别把人服务器也删了

@NCZkevin 我想起之前公司，游戏内测第二天，老板打开谷歌云后台，自己瞎操作，把服务器删了……

@encro @encro 你这理论，微软听了沉默，谷歌看了流泪啊，张一鸣要是早点认识你，搞组织改革的钱都省了，大家把华为的书一扔，再也不搞什么 ipd 了

@pkoukk 加机器数量的成本肯定是比怼单台机器性能低的，这也是分布式能够存在的根本原因，然后，可能我用词不够准确，一套 raid ，不管是 015610 ，都是算作“单例”的，因为都不是独立的多个环境

@lambdaq 下午不下午不要紧，主要是周一，要么周末出去玩回来，忘了自己写啥了的情况下更新，要么早上摸摸鱼，下午直接更新，当然这是开玩笑，一般避开用户峰值，大多会选择周四什么的，不过这个不是很重要

@aper 不过这个问题不是那么重要，大家谁还不是个意识流了

@aper 周一下午更新确实是个奇怪的时间点，先参考敏捷体系，两周一个冲刺，冲刺完就更新，以周为单位，更新时间点当然不会是在周一，那 IPD 体系呢，IPD 体系纯瀑布流开发，所有设计在事先都规划好，所有的技术细节都通过假设和验证了，再进入开发，开发完了以后还有繁琐的测试，参考华为和甲骨文，所以 IPD 的概率也不大，不是主流体系，那就是意识流了，意识流开发，然后选择在周一下午这样的用户在线峰值时间段，做没有严格测试过的更新，所以是草台班子

@julyclyde 顺带一提这里参考的体系是微软

@julyclyde 这个不是努力目标啊……当然映射到个人可能是一种思想，但是在 2023 年，已经有很多成熟的框架和方案了，比如我说的分布式集群，结果他们就自己意识流开发，这是我说他野路子的根本原因啊……

@dolphintwo 重建存储服务+日志恢复+完整性校验，这个流程，在故障已经发生时，是没有问题的
我主要分析的是，他的故障以及故障处理流程透露出来的背后的架构方案，开发和运维模式
上面已经讨论过很多楼，感兴趣可以自己康康