nekoharuya

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

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

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

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

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

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

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

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

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