首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  nekoharuya  ›  全部回复第 2 页 / 共 4 页
回复总数  62
1  2  3  4  
❮ ❯
2023-10-25 14:50:26 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@NCZkevin 我想起之前公司，游戏内测第二天，老板打开谷歌云后台，自己瞎操作，把服务器删了……
2023-10-25 14:47:29 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@encro @encro 你这理论，微软听了沉默，谷歌看了流泪啊，张一鸣要是早点认识你，搞组织改革的钱都省了，大家把华为的书一扔，再也不搞什么 ipd 了
2023-10-25 14:35:48 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@pkoukk 加机器数量的成本肯定是比怼单台机器性能低的，这也是分布式能够存在的根本原因，然后，可能我用词不够准确，一套 raid ，不管是 015610 ，都是算作“单例”的，因为都不是独立的多个环境
2023-10-25 14:22:32 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@lambdaq 下午不下午不要紧，主要是周一，要么周末出去玩回来，忘了自己写啥了的情况下更新，要么早上摸摸鱼，下午直接更新，当然这是开玩笑，一般避开用户峰值，大多会选择周四什么的，不过这个不是很重要
2023-10-25 14:17:52 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@aper 不过这个问题不是那么重要，大家谁还不是个意识流了
2023-10-25 14:15:56 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@aper 周一下午更新确实是个奇怪的时间点，先参考敏捷体系，两周一个冲刺，冲刺完就更新，以周为单位，更新时间点当然不会是在周一，那 IPD 体系呢，IPD 体系纯瀑布流开发，所有设计在事先都规划好，所有的技术细节都通过假设和验证了，再进入开发，开发完了以后还有繁琐的测试，参考华为和甲骨文，所以 IPD 的概率也不大，不是主流体系，那就是意识流了，意识流开发，然后选择在周一下午这样的用户在线峰值时间段，做没有严格测试过的更新，所以是草台班子
2023-10-25 14:10:04 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@julyclyde 顺带一提这里参考的体系是微软
2023-10-25 14:08:04 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@julyclyde 这个不是努力目标啊……当然映射到个人可能是一种思想，但是在 2023 年，已经有很多成熟的框架和方案了，比如我说的分布式集群，结果他们就自己意识流开发，这是我说他野路子的根本原因啊……
2023-10-25 14:01:18 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@dolphintwo 重建存储服务+日志恢复+完整性校验，这个流程，在故障已经发生时，是没有问题的
我主要分析的是，他的故障以及故障处理流程透露出来的背后的架构方案，开发和运维模式
上面已经讨论过很多楼，感兴趣可以自己康康
2023-10-25 13:46:31 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@julyclyde 你 44 层的分析我认真看过了，这其实还是我最开始说的架构设计的问题，机器是物理机还是虚拟机，横竖都只是个容器，上层上个集群，下面的容器怎么更新都没关系，把机房拆了都行，语雀这种单例设计是我主要喷的点
然后你说的人的眼神，还有设计上无状态有状态的变化，这是不是很符合我说的，完全无法避免是个人一定会出错
既然不能避免，就更应该自动化，去依赖化
至于工具的一证永证当然指的是相同条件下，外部条件变了自然要重新开发，也就是我认同你说的依赖工程师解决全新的问题
2023-10-25 13:18:16 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@julyclyde 我们其实是基于两种假设
我的假设是，人工操作不可靠，是人就一定会出问题，信任人的技能熟练程度不如信任工具的完善程度，因为工具的更新是一证永证的
你的假设是，问题持续在变化，能用工具覆盖的问题本身就不应该出现，所有出现的问题都是未知的，只能依赖工程师抢救
我觉得你的想法挺有道理的，就不争论这个了
回到问题本身，我认为语雀这个故障和处理方法，不管是哪种假设，它都不应该出现，因为完善的架构方案和工具链实在很多
2023-10-25 13:01:35 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@julyclyde 小公司自己手动操作确实居多，我以前的时候，也是从手动操作->自动脚本->gui 工具，这样积累起来，但是，语雀这么大个公司
2023-10-25 12:57:02 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@nothingistrue 别光喷呀，有何高见
2023-10-25 12:48:22 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@julyclyde 这其实是我的经验之谈，你不信任精心设计和经过反复测试和验证的自动化处理，却相信凭经验和感觉的人工手动操作吗
2023-10-25 12:33:19 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@mazyi 一种我目测最合理的可能，运维工具把那台机器的环境搞炸了，机器又是祖传的，根本恢复不动，服务跑不起来，所以上不了线，备份也不是真的备份，就是原始数据，他们新搭了个机器，在全新的，干净的环境里，起了服务，导入了数据
2023-10-25 12:18:09 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@pengtdyd 别光喷呀，有何高见
2023-10-25 12:08:30 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@pkoukk 是容器还是直接在物理机上，在这个问题上，我认为是无关紧要的，而且这种体量，正常的思维必然是上集群来扩容，不管是加物理机器还是加容器都一样，数据库分布式的存储在不同的机器上，查询的时候也有很多便利的算法可以用，再给每个节点上个从属服务器，自动同步，在这个设计下，机器是新的是旧的，几台机器炸了，或者一两个机房被修卡军团占领了，都无关紧要的
2023-10-25 11:54:08 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@Mess1ah 别光喷呀，有何高见
2023-10-25 11:49:46 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@pengtikui 机器太老了，上不了线，这个事情本身就是有点不可思议的，你看前几楼的回复，他们都认为是跑在阿里的 ECS 上，而不是自建机房才能通过删除 ECS 实例达成上不了线这个结果，但是看他们公告，他们的说法明显是自建机房，可能我技术很菜吧，我理解不了他这句话是怎么做到的，机器都在自己手里，是下线了又不是删库了，那我只能理解成摆烂不玩了
2023-10-25 11:38:38 +08:00
回复了 nekoharuya 创建的主题 › 程序员 › 语雀这路子太野了
@yhxx 你这个分析太离谱了，首先，跑在容器里的服务，绕过阿里云的账户权限管理，把容器给删了，这个事情是做不到的，那就只能是拥有后台权限的人自己操作，删库跑路了
1  2  3  4  
❮ ❯
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5448 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 18ms · UTC 09:01 · PVG 17:01 · LAX 01:01 · JFK 04:01
Developed with CodeLauncher
♥ Do have faith in what you're doing.