线上事故
快来分享你的内容吧～
2024-08-20·后端
A股涨疯了，结果上交所系统被买崩了？
大家好，我是程序员鱼皮。 今天上午被一条消息刷屏了：**上交所 P0 事故直接宕机、连带着多家炒股软件也崩了！** <p align="center"><img src="https://pic.code-nav.cn/migrate_image/a62099d6df80c2fc8d9ae04df0068288.webp" alt="" width="100%" /></p> ### 咋回事呢？ 很多朋友应该也听说了，A 股这 3 天简直疯了！连涨 300 点重新站上 3000 点，白酒、地产板块甚至迎来 **涨停！** 前几天华尔街还在 “anything But china”，现在已经是 “all in，buy china” 了。 今天早上，A 股三大股指又是大幅高开。然而正当大家高呼 “牛回，速归！” 的时候，上午 10 点上证指数成交量 **急剧萎缩 90% 以上**，指数直接拉成了直线。 <p align="center"><img src="https://pic.code-nav.cn/migrate_image/bd6d5022cc71c7410003f9880f570161.webp" alt="image-20240927125312936" width="100%" /></p> 后面更是出现 **交易异常情况**，成交数据停止在 10:22 左右！ <p align="center"><img src="https://pic.code-nav.cn/migrate_image/faaa6588bccc96673affadf37ea807cc.webp" alt="企业微信截图_8e94786a-d06d-40c3-a07a-d5dd0a635d66" width="100%" /></p> 有业内人士认为市场委托量非常大，撤单委托可能无法及时收到明确结果，属于正常现象。 **也就是说真的是被买崩了？** <p align="center"><img src="https://pic.code-nav.cn/migrate_image/1b4ba10225aaae6a85479a5e49246cc3.webp" alt="" width="100%" /></p> 根据最新消息，11 点半收盘前后，上交所成交已陆续恢复，整个故障大概持续了 1 个小时左右： <p align="center"><img src="https://pic.code-nav.cn/migrate_image/f975dc0e978eb4dfeb4690cd1062588c.webp" alt="" width="100%" /></p> ### 聊点儿技术 根据网上的消息，本次故障的具体表现包括但不限于 “异常卡顿、交易延迟”。 另据财联社，有券商已向分支机构通报，即 “经公司技术监控发现，目前报单有延迟。各家券商均有反馈，属于 **行业共性问题**”。有业内人士分析，当前市场委托量非常大，客户的撤单委托可能无法及时收到撤单成功或失败的明确结果，**属于正常现象**。 在发生异常卡顿和交易延迟的情况下，主要原因通常是由于市场委托量激增导致的订单拥挤，进而引发 “塞单”。这种情况下，客户的撤单请求可能无法及时得到反馈，导致他们不确定委托状态，进而频繁撤单和重新申报，这进一步加剧了系统的流量压力，严重时还会造成雪崩！ <p align="center"><img src="https://pic.code-nav.cn/migrate_image/203bf2f219ed3e1b1fcd98d39588f23e.webp" alt="" width="100%" /></p> 历史上其他交易所也曾遇到类似情况，股市波动大的时候，系统压力也跟着大。 <p align="center"><img src="https://pic.code-nav.cn/migrate_image/b7ef78351397c2d4902d82c6b1f8ba18.jpeg" alt="" width="376px" /></p> 为有效优化和解决这类问题，一般交易所和券商系统都会采用分布式架构，以便在高峰期间更灵活地分散请求压力。而且最关键的是，下单请求一般都是利用消息队列实现 **排队和异步处理** 的，可以对系统进行削峰，减少瞬时负担。系统故障或重启后，还能够陆续捞回未处理的消息，重新处理未完成的交易。 其实有点儿设计秒杀系统的感觉了~ 这也是程序员朋友们经常在面试时被考察的问题，一旦并发量上来了，血压也就上来了。 <p align="center"><img src="https://pic.code-nav.cn/migrate_image/f0bfd4d803de13cb13b1b997019014cb.webp" alt="" width="100%" /></p> ## 更多 💻 编程学习交流：[编程导航](https://www.codefather.cn) 📃 简历快速制作：[老鱼简历](https://laoyujianli.com) ✏️ 面试刷题神器：[面试鸭](https://mianshiya.com)
网易云音乐故障 2 小时，这次到底谁背锅？（今天记得领补偿）
大家好，我是程序员鱼皮，8 月 19 日下午，网易云音乐突发严重故障，并登顶微博热搜，跟黑神话悟空抢了热度。 <p align="center"><img src="https://pic.code-nav.cn/migrate_image/e27324fdc9046eb6cc698b4d142cb34e.webp" alt="" width="100%" /></p> 根据用户的反馈，故障的具体表现为：用户无法登录、歌单加载失败、播放信息获取失败、无法搜索歌曲等等，几乎是无法使用了，妥妥的 P0 级事故！ <p align="center"><img src="https://pic.code-nav.cn/migrate_image/0b5c12918f23f9ffeccbdc3a34c3c239.webp" alt="" width="100%" /></p> 根据官方发布的说明，本次故障的主要原因是基础设施，导致网易云音乐各端无法正常使用： <p align="center"><img src="https://pic.code-nav.cn/migrate_image/c3411b50456e77d55d14cb3ce7fbc61a.webp" alt="" width="100%" /></p> 什么是基础设施？是指支持整个系统运行的基础性服务和资源，包括服务器、网络设备、数据库、存储系统、内容分发网络（CDN）、各种云服务、缓存、DNS、负载均衡等等。像之前 B 站和小红书大规模故障，就是因为某云服务商的网络出了问题，可见基础设施的重要性。 我不是内部人员，所以具体的故障原因不得而知，网上有很多猜测，什么 “开发删库跑路”、“搬迁到新机房产生了问题”、“裁员导致降本增笑” 等等，但这些说法被官方否认了。 根据网上的消息，这次的故障可能与网易云自研的 Curve 存储系统有关，当时网易官方称该存储系统上线 400 多天，从未出现数据不一致和丢数据的情况，数据可靠性达到 100%，服务可用性高达 4 个 9（99.99%）。 <p align="center"><img src="https://pic.code-nav.cn/migrate_image/02cf249b2307c568d9d45021877d1a8b.webp" alt="" width="100%" /></p> 按理说稳定运行了这么久的系统不应该自己出问题，据说是一位同学按照前人的文档执行了一个运维操作，导致了存储系统的故障。一般来说，这么重要的基础设施的变更发布需要走非常完备的流程，而且不会让不熟悉的人按照前人的文档执行，除非有一种情况，就是 “前人” 已经不在了。根据网上消息，该部门曾经历过裁员，更有小道消息说，该部门仅存的人员寥寥无几。 真相我们不得而知，不过听上去挺合理的。因为一般情况下，大厂内部是有灰度发布、容灾演练的，不会直接影响到所有用户。 - 灰度发布是指在更新 IT 基础设施时，采用逐步部署的方式，先在一部分设备上进行变更，观察其效果。如果一切正常，才逐步扩大变更范围。 - 容灾演练是指对基础设施在灾难发生时的应急响应和恢复能力进行测试和验证，确保在关键的基础设施发生故障或灾难时，系统能够迅速恢复，减少业务中断的影响。 大厂的架构师，尤其是基础设施团队的人员，一定是知道这些操作的，但为什么没有执行呢？可能是因为人手不够、也可能是因为懒、还可能是因为现在的人缺失经验、还有可能是前人留下的文档不全。总之，系统的稳定性和 “人” 有很大的关系。 让我又想到了上次微软全球蓝屏的事情，果然严重的 Bug 往往只需要一两名程序员、或者一些小的操作。 整个故障恢复历时整整 2 个小时，已经是比较慢了，采用预备方案恢复服务、或者屏蔽部分故障、或者回滚发布，应该都要不了这些时间，估计是数据出了问题吧。如果在故障中数据出现了损坏或不一致，恢复服务的难度的确会大大增加，为了确保数据完整性，可能需要进行数据恢复、重建索引、同步数据等操作，而这些都可能会延长故障恢复的时间。 目前还没有看到官方的故障报告，所以这一切只是猜测了。 故障恢复后，网易云音乐很快发布了补偿措施 —— 用户可以免费领取 7 天会员权益！ **注意，只能在 8 月 20 日领取！** <p align="center"><img src="https://pic.code-nav.cn/migrate_image/66b56fd43b0d11add99505dd04614b9a.webp" alt="" width="100%" /></p> 进入云音乐就能在搜索条看到领会员的入口了，虽然只有 7 天，差点儿意思，但作为一名网易云音乐 10 级会员，我必须领爆！ <p align="center"><img src="https://pic.code-nav.cn/migrate_image/7cd4bb41cfa311eb4cfd2d1002ac0a34.webp" alt="" width="100%" /></p> 从这个事情也能看出来，一旦故障发生了，头大的可不只有开发和运维人员！产品同学需要快速制定补偿策略，确保用户满意；运营和客服要紧急应对用户的疑问和投诉，安抚情绪；而公关则必须迅速应对舆论压力，控制事态发展，防止负面影响扩散。同时，管理层还需统筹协调各部门，确保问题得到全面处理。 我们自己也做了很多产品，也发生过故障，我们这小规模应对起来都汗流浃背了，很难想象网易云音乐这种国民级产品背后的团队，昨天承受了多大压力。劳力越戴，责任越大呀！ 朋友们，你们怎么看待这次故障，有怀疑过自己网络或设备的问题么？ ## 更多 💻 编程学习交流：[编程导航](https://www.codefather.cn) 📃 简历快速制作：[老鱼简历](https://laoyujianli.com) ✏️ 面试刷题神器：[面试鸭](https://mianshiya.com)
关于线上事故的一些碎碎念
<html> <head></head> <body> <div class="content ql-editor"> <p><span style="color: var(--primary-color); text-align: justify;">12年的项目经理</span></p> <p><br></p> <p>在3年前的时候，我在浪潮负责一个几个亿的业务。但是系统做的很烂。</p> <p>和我交接的是一个12年工作经验的项目经理。</p> <p> </p> <p>刚入职项目经理就给我一个工作任务，让我处理XX问题。然后给了我一个文档。</p> <p>我操作了一下，看不懂。</p> <p>项目经理：你怎么就看不懂呢？你说说，哪个地方看不懂？</p> <p>我也不知道为什么，那天就非要和项目经理对着干：我一个字都看不懂。</p> <p>项目经理：那为什么我能看得懂？我对你非常的失望。</p> <p> </p> <p>在1个周以后，用户给了一个需求，需要往生产环境写入一份数据。</p> <p>这个<strong style="color: var(--primary-color);">能看得懂</strong>的项目经理就瞧不上我（这个工作应该我处理），然后他就往数据库写入了数据。</p> <p>结果喜闻乐见：线上事故，给用户导出的数据差了几百万。（差了一个鱼皮公司的总资产）</p> <p> </p> <p>然后：甲方是腾讯云的，往死里call项目经理的电话。</p> <p>那个项目经理痛苦的说：我5天就睡了8个小时。你不理解我，你能不能给我分担点工作量？</p> <p> </p> <p><br></p> <h4 class="ql-align-justify"><span style="color: var(--primary-color);">问题解决</span></h4> <p><br></p> <p>后来是怎么解决的呢，是我解决的。</p> <p> </p> <p>项目经理他5天睡了8小时，拉着我加班。周六加班还不给加班费。</p> <p>烦得要死，我说我给你定位下。花了2天时间给他定位了故障原因：他导入数据的时候用的是excel，导入错了。</p> <p>导入了204条数据，这个项目经理错了15条。查一下diff就行了。</p> <p> </p> <p>这个事情再也没让项目经理插手。</p> <p> </p> <p><br></p> <h4 class="ql-align-justify"><span style="color: var(--primary-color);">复盘</span></h4> <p><br></p> <p>后来复盘这个线上事故的时候，他是这么说的：</p> <ol> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">懂业务的运维离职了，然后离职之前和他交接了一下；他不懂业务很正常</span></li> </ol> <p>线上事故之前你可不是这么说的啊，我可记得很清楚：他看得懂、能处理，对我很失望；</p> <p>等着出了线上事故的时候你立马转变态度。</p> <p> </p> <p>我也理解他的说法：</p> <ol> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">你不接吧，用户投诉不处理扣绩效；处理了吧能力又不够，改了就线上事故</span></li> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">出了线上事故是想敢作敢当来着，敢作敢当直接下岗。在浪潮干了12年了，突然就没了</span></li> </ol> <p>公司一年所有人工资也不到500W啊，你搞个500W的事故是啥意思……</p> <p> </p> <p>我觉得在这个情况下，大概率人性是经不起考验的；</p> <p> </p> <p><br></p> <h4 class="ql-align-justify"><span style="color: var(--primary-color);">线上数据修改</span></h4> <p><br></p> <p>后来有一次，用户要求改数据。改数据也正常业务，我立刻处理。</p> <p>写sql但是没保证原子性。先改的A表后改的B表。数据迁移的时候就会出现不一致</p> <p>修改的数据量很大，没法保证事务。</p> <p> </p> <p>用户当场投诉电话就过来了。项目经理当场就把我卖了。然后就开始问责。</p> <p> </p> <p>项目经理他懂个X的原子性，线上用户管你是在数据迁移还是什么，反正用户觉得有问题直接一个电话到项目经理那边。项目经理也不可能大包大揽，直接问责是最正常不过的。</p> <p> </p> <p>后来，我就永远不在白天进行任何线上操作。</p> <p>只要在线上进行敏感操作，用户就会出现线上恐慌；恐慌了以后就会投诉，投诉就背锅。</p> <p> </p> <p>你线上刷数据?可以，明天。</p> <p>今天不行嘛？今天不行？</p> <p>很急？很急也不行。</p> <p>我投诉到项目经理那边？投诉就投诉。</p> <p> </p> <p>线上数据修改，大部分情况下都不急；但是出了问题就立刻升级。</p> <p> </p> <p><br></p> <h4 class="ql-align-justify"><span style="color: var(--primary-color);">线上问题</span></h4> <p><br></p> <ol> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">我自己导致的，把全省的机房设备都发给枣庄了，where条件没带id</span></li> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">这个环境因为某个菜鸟写的垃圾程序崩溃了，导致了整个环境1天不可用</span></li> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">在处理这个bug的时候引入了一个新的bug，导致整个环境又崩了</span></li> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">然后也不知道为什么，hadoop主节点挂了起不来，7天没修复</span></li> </ol> <p> </p> <p>这玩意故障率还挺高……而且修起来都挺吓人</p> <p> </p> <p><br></p> <h4 class="ql-align-justify"><span style="color: var(--primary-color);">总结</span></h4> <p><br></p> <ol> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">默认项目经理是不懂技术的，他提的需求是有可能不可实现的；项目经理和pm说他懂业务，他懂个X的业务；出现线上事故，基本上项目经理和pm没有背锅的逻辑，都是直接分黑锅</span></li> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">宁肯得罪领导，也不能在线上环境上做敏感和不可逆的操作；付费和敏感业务。层层确认，测试环境确认，领导确认，用户确认，甲方确认。而且在晚上没人的时候进行操作，保证出了问题以后留时间余量</span></li> <li data-list="bullet"><span class="ql-ui"></span><span style="color: var(--text-color);">线上环境能不动就不动，线上事故出问题，之前多大功劳一笔勾销。</span></li> </ol> <p><br></p> </div> </body> </html>