- 综合排序
- 最热优先
- 最新优先
- 来自专栏不一样的科技宅
Insert into select语句引发的生产事故
事故发生的经过。 由于数据数据库中order_today数据量过大，当时好像有700W了并且每天在以30W的速度增加。 事故还原 在本地建立一个精简版的数据库，并生成了100w的数据。模拟线上发生的情况。
2.6K11发布于 2020-07-07 - 来自专栏SpringBoot教程
由Long类型引发的生产事故
今天测试忽然在群里发了一个看似非常简单的线上问题，具体是：在后台通过订单编号(orderId)修改订单信息时，修改不成功 ，修改前后的订单数据完全没有发生变化。第一眼看到这个问题的时候，我心想后台实现逻辑并不就是一个updateById更新订单表的操作（简化了其他业务逻辑）吗？难道订单编号(orderId)在代码里给属性赋值赋错了，心想这么低级的错误“同事”应该不会犯吧，于是我就打开ide先去看了看对应方法的处理逻辑，整体更新操作 属性之间的赋值没有问题，难道又是一个”灵异事件“？说罢 我便想着在测试环境能不能复现一下这个bug，功能上线前功能肯定是测试通过的，于是我在测试环境点啊点，在页面上模拟了几十次更新操作也没有发现问题。
51030编辑于 2023-08-31 - 来自专栏编程大道
Redis bigkey导致生产事故！
一个Redis生产事故的复盘，整理这篇文章分享给大家。本期文章分析Redis中的bigkey相关问题，主要从以下几个点入手： 什么是bigkey？ 危害是什么？ 怎么产生的？ 但在实际生产环境中出现下面两种情况，我们就可以认为它是bigkey。 1.字符串类型：它的big体现在单个value值很大，一般认为超过10KB就是bigkey。 这就是造成生产事故的罪魁祸首！导致Redis间歇性卡死、影响线上正常下单！ 但是在生产环境中，开发和运维人员更希望自己可以定义bigkey的大小，而且更希望找到真正的bigkey都有哪些，这样才可以去定位、解决、优化问题。 实际生产的操作方式 在实际生产环境中发现bigkey的两种方式如下： 被动收集 许多开发人员确实可能对bigkey不了解或重视程度不够，但是这种bigkey一旦大量访问，很可能就会带来命令慢查询和网卡跑满问题
55820编辑于 2022-05-17 - 来自专栏中间件的探究
StringBuilder生产使用的一次事故
StringBuilder生产使用的一次事故 使用Java实现较长逻辑的代码中，无可避免会创建众多的String对象，又是为了节省内存空间以及优化程序效率，会选择使用StringBuilder或者StringBuffer value[c++] = 'u'; value[c++] = 'l'; value[c++] = 'l'; count = c; return this; } 以上就是一次事故给自己的一些思考
59340编辑于 2023-04-04 - 来自专栏是Kerwin啊
「生产事故」MongoDB复合索引引发的灾难
最终定位问题是由于：服务器自身磁盘 + 大量慢查询导致 基于上述情况，运维同学后续着重增强了对MongoDB慢查询的监控和告警 幸运的一点：在出事故之前刚好完成了缓存过期时间的升级且过期时间为一个月，C 端查询都落在缓存上，因此没有造成P0级事故，仅仅阻塞了部分B端逻辑 事故回放 我司的各种监控做的比较到位，当天突然收到了数据库服务器负载较高的告警通知，于是我和同事们就赶紧登录了Zabbix监控，如下图所示 ，截图的时候是正常状态，当时事故期间忘记留图了，可以想象当时的数据曲线反正是该高的很低，该低的很高就是了。
1.7K20发布于 2020-12-09 - 来自专栏MySQL解决方案工程师
由细嫩双手引起的IT环境生产事故
怎么样？标题够吸引人的吧，想了解内情请往下面看?。 前几日和一位MySQL的Oracle ACE聊天，谈到了一个所谓的“段子”。既然说到了Oracle ACE那我就先介绍一下ACE计划吧，想到哪儿写
99220发布于 2020-09-28 - 来自专栏是Kerwin啊
「生产事故」MongoDB复合索引引发的灾难
最终定位问题是由于：服务器自身磁盘 + 大量慢查询导致 基于上述情况，运维同学后续着重增强了对MongoDB慢查询的监控和告警 幸运的一点：在出事故之前刚好完成了缓存过期时间的升级且过期时间为一个月，C 端查询都落在缓存上，因此没有造成P0级事故，仅仅阻塞了部分B端逻辑 事故回放 我司的各种监控做的比较到位，当天突然收到了数据库服务器负载较高的告警通知，于是我和同事们就赶紧登录了Zabbix监控，如下图所示 ，截图的时候是正常状态，当时事故期间忘记留图了，可以想象当时的数据曲线反正是该高的很低，该低的很高就是了。
1.3K30发布于 2020-12-15 - 来自专栏沉默王二
深夜生产事故，人工多线程来救场！
我一直非常喜欢能够快速解决问题的程序员，我也乐于在各种生产出现问题的时候，第一时间去研究去分析。说一句不厚道的话，好程序员都是在解决问题中锻炼出来的，特别是生产环境出现问题时，能够站出来的程序员。 突发事故 凌晨的夜晚比较困，当我点起第三根烟的时候，负责迁移的这位程序员，急匆匆的跑过来找我了。 “强哥，出现问题了！” 心中一惊，猛吸一口烟，把烟掐灭，忙问到：“出现啥问题？” 如果在上午8：00 之前不搞定这个事情，那就完全是重大事故了。 那时候想，出现这么大的事故，老板把我们开除了都是小事，如何收场才是我们最关心的。工作丢了可以再找，事情不管怎样都是需要我们这批人来解决处理的。 人在高压高强度的环境中，哪怕很简单的动作可能都会变形，从而有可能引发更大的二次事故。 在高强度、高压力的环境下稳定保持一颗冷静分析的心，只有你自己沉静下来才能真正的发现问题解决问题。
46940发布于 2019-08-13 - 来自专栏Laoqi's Linux运维专列
一次生产事故的优化经历
在一次正常的活动促销之后，客服开始陆续反馈有用户反应在抢标的时候打不开网页或者APP，在打开的时候标的就已经被抢光了，刚开始没有特别的上心，觉得抢标不就是这样吗，抢小米手机的时候也不就这样吗？随着活动继续推进，有更多的用户强烈抗议，用户领了加息卷或者抵现卷之后抢不上标的，认为是平台作假故意不让使用以达到节省资源。 分析过程 其实以前也会有陆续的用户反馈不减少，给客户以小米抢手机为例子忽悠了过去，这次用户反馈太过强烈，才让我们重视了起来。我们前端一共三款产品，app、官网、H5，其中app使用量最大，官网其次
1.2K60发布于 2018-05-31 - 来自专栏小许code
雪花算法在生产环境中出事故啦！
时间滴答滴答过去，到点了，准备下班 不过今天安静的整体来说是不怎平静的，遇到了【雪花算法】的线上产生的事故 全文字数 : 3.6k+ ⏳ 阅读时长 : 5min 关键词 : 雪花算法、时钟回拨、NTP 同步、Leaf方案前言其实整个问题是使用雪花算法过程是遇到的，这次刚好把事故记下来，希望对没遇到过得同学有个提醒。 通过看优缺点，我们知道雪花算法有个致命问题【时钟回拨】线上事故处理事故现象运营反馈有用户使用我们系统第一次上传数据成功后，接下来无论怎么样都上传不了数据了，用户很疑惑，导致现在无法使用了！ 事故原因：时钟回拨简单说就是时间被调整回到了之前的时间，由于雪花算法重度依赖机器的当前时间，所以一旦发生时间回拨，将有可能导致生成的 ID 可能与此前已经生成的某个 ID 重复。 NTP时间同步流程如下解决方案我们接着看面对这种问题该如何处理呢，一般来说有以下几种方式直接抛异常在雪花算法原本的实现中，针对这种问题，算法本身只是返回错误，由应用另行决定处理逻辑，而这次事故中调用方却没有做对应的处理
1.3K30编辑于 2023-08-08 - 来自专栏ThoughtWorks
如果不想总是半夜爬起来抢修生产事故
真英雄，要么能赋能团队成员，提升他们处理生产事故的“救火”的能力，而不仅仅靠他一人；要么能把需要半夜爬起来抢修的生产事故，化解成一个个小任务，在白天上班时间给解决了。 有人会问，作为开发人员，如何才能把生产事故化解成一个个小任务呢？ 早在2008年，Netflix公司在把数据中心迁往亚马逊云平台的时候，踩了一个大坑，经常会出现生产事故。 试点业务 选择一个出现生产事故频率较高的业务系统，尝试混沌工程。因为事故的反复，出现会让发现与解决暗债的动力更大 基于能反映用户体验的业务稳态行为建立假设，而不是先聚焦于在系统内寻找弱点。 作为一名开发人员，如何能让自己能逐渐减少在半夜爬起来抢修生产事故的次数？可以尝试使用本文要介绍的8个谬误、12个反模式和12个模式。 如何让队友不会半夜把你喊起来帮着抢修生产事故？
42630编辑于 2021-12-17 - 来自专栏IT技术精选文摘
震惊，Spring官方推荐的@Transactional还能导致生产事故？
不瞒你说，我之前也一直是这样，直到使用@Transactional导致了一次生产事故，而那次生产事故还导致我当月绩效被打了D... @Transactional导致的生产事故 19年在公司做了一个内部报销的项目，有这样一个业务逻辑： 1、员工加班打车可以通过滴滴出行企业版直接打车，第二天打车费用可以直接同步到我们的报销平台 2、员工可以在报销平台勾选自己打车费用并创建一张报销单进行报销
51010编辑于 2021-12-09 - 来自专栏AustinDatabases
MYSQL 版本迁移带来 严重生产事故“的”分析
group by，union 等语句的撰写的变化，与此同时还要注意 SQL 执行计划的变化，无论是从低版本到高版本，还是高版本迁移到其他类MySQL数据库，一定要注意版本之间的差异，否则产生业务回滚或生产事故那就是必然的了
38910编辑于 2024-07-04 - 来自专栏故里学Java
生产事故：年终奖杀手虽迟但到！
事故描述： 上周客户的大促活动中，客户反馈，存在部分已发货的订单退款成功，造成了惨重的损失，直接影响在客户信任感。事后我们对这次事故进行了专项复盘。 通过对这次事故的复盘，针对这次的事故的解决方案如下： 接口异常及时抛出，供调用方进行对应业务逻辑处理 消息发送服务提供自动重试机制，如果发送失败，系统自动重试3次，对异常进行落库处理 对重要节点的异常提供短信和钉钉消息提醒 事故总结： 正视每一次事故，刨析事故原因，有针对性的解决事故原因，对于事故的预防工作该如何优化，避免下一次更严重的事故。希望技术人敬畏每一行代码！ - END -
51240发布于 2020-12-23 - 来自专栏陌溪教你学编程
大型生产事故,开源项目蘑菇博客差点被删库
前言 今天有个热心的小伙伴，通过 MySQL 图形化管理工具 SQLyog 进行远程数据库连接，成功进入了 蘑菇博客 的生产环境数据库。 问题缘由 问题出现的原因，是因为蘑菇博客生产环境的数据库使用的远程登录密码为 默认密码(mogu2018) 。
43930发布于 2021-03-22 - 来自专栏程序员千羽
不起眼的SQL导入，差点引发生产事故..
这个不经意的操作，也许一个不起眼的SQL导入动作如何差点引发生产事故，以及我们可以从中学到的教训。 1. 背景 这里简单介绍SQL导入的常见场景和背景。 导致事故的原因： 在运行MySQL导致操作的时候，将原来的数据删除，再insert进去。导致把当天的测试数据丢失。 其关键的隐藏点在于：有一个drop操作 事故的影响： 对测试数据造成的潜在破坏。 处理测试数据的DROP语句是为了清理测试环境，避免对生产数据造成不可逆的影响。 最佳实践： 在批量导入之前，应该删除DROP语句！！ 结语 通过分享这个真实案例和对应的教训，我们希望同行能够更加警觉，提高SQL导入的操作水平，确保数据迁移过程中不会对生产环境造成潜在威胁。
57510编辑于 2024-01-31 - 来自专栏悟空聊架构 | 公众号
PassJava 小破站生产级事故，请放弃这个 CDN 吧！
墨菲定律 我们生产环境前几个月爆过一次雷，客户反馈后台管理系统崩了，也是因为引用这个站点的 JS 脚本文件加载不出来的问题。 但昨天下午读者又反馈长时间不能访问，那这个就是生产级 T0 的事故了。 这就是墨菲定律啊！如果事情有变坏的可能，不管这种可能性有多小，它总会发生。 报错截图如下所示： 遇到这种情况怎么办？
98320编辑于 2022-07-01 - 来自专栏Java项目实战
生产事故江湖再现,CTO扬言干掉一条业务线
还记得上次我发表的生产事故么order by 字段到底要不要加索引?[大坑],定位问题知道是索引问题产生的，那么新业务线上的事故为何又再现呢？ 一个平静的下午，17:48生产报障群出现报障，本以为是一次小小的数据不一致问题，但接下来的运维故障以每秒1个，到每秒3个，然后以每秒5个bug的速度爆出，上游业务，影响范围全国，相关服务全部挂掉，然后逐步开始在故障群解决 涉及主表数据量1182万条，次主表数量1000万条，上报DBA执行时，将现有索引删除时，还未来得及添加索引，此索引为覆盖索引，由于数据量巨大，当删除索引时，在维护索引的同时，还要将整张表的数据重建，那么可以想象在生产上不断增加数据的同时去删掉索引成本多么的巨大 由运维紧急通知全国范围业务，将线上服务杀死，此时删除索引秒完成，且重建索引，重新启动服务，由报障时间起到报障解决恢复时间1小时，报障11900条，此次重大bug，CTO扬言再出现此类问题，10分钟不能解决生产问题的 反思：除了开发人员应引以为戒之外，对生产环境保持敬畏之心，那么bug这个问题，从公司角度是影响全部产品线，导致用户满意度下降，大局观是如此的，影响范围不仅是开发眼中的数据问题，而是一笔笔真实的订单，那么问题不应该反思到合理的产品评估
50230发布于 2021-09-10 - 来自专栏JavaEdge
生产事故！几百万条消息在MQ积压了半天！
3 性能优化 性能优化主要在生产者和消费者这俩业务逻辑。 MQ自身性能，作为API使用者，无需过于关注。因大多MQ业务，MQ本身处理能力>>业务系统。 3.1 生产端 此端的业务代码处理性能，和MQ关系不大，都是先执行业务逻辑，最后再发消息。 若你的代码发送消息的性能上不去，优先检查是否为发消息前的业务逻辑耗时太多。 若消费速度跟不上发送端生产消息速度，就会造成消息积压。若这种性能倒挂的问题是暂时的，问题不大，只要消费端性能恢复后，超过发送端的性能，积压的消息是可逐渐被消化的。 若消费速度一直比生产速度慢，系统就会异常： MQ存储被填满无法提供服务 消息丢失 所以设计系统，要保证消费端消费性能＞生产端发送性能。
5.4K30编辑于 2022-01-15 - 来自专栏码农沉思录
又出生产事故！那些年我曾犯过的错-SecureRandom
本人上周亲手写下了一个牛逼的bug，直接导致的结果是，晚上12点升级后台接口以后，第二天早上7点多开始，所有的app页面出现卡顿，白屏。
5.1K20发布于 2019-12-05
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号