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