一次因生产事故与chatGpt的对话

【一次因生产事故与chatGpt的对话】的更多相关文章

一次 select for update 的悲观锁使用引发的生产事故

1.事故描述本月 8 日上午十点多,我们的基础应用发生生产事故.具体表象为系统出现假死无响应.查看事发时间段的基础应用 error 日志,没发现明显异常.查看基础应用业务日志,银行结果处理的部分普遍很慢,大都在十分钟以上. 2.AWR 报告向 DBA 要了一下那个时间段的 AWR 报告,发现以下三个地方有些异常: 2.1.CPU 利用率过高如上图所示,CPU利用率:1883.25分钟DB时间/(16核心*119.45分钟采样时间段时间) = 98.54%,CPU 利用率过高. 2.2.行锁…

生产事故（MongoDB数据分布不均解决方案）

可以很明显可以看到我们这个集合的数据严重分布不均匀. 一共有8个分片,面对这个情况我首先想到的是手动拆分数据块,但这不是解决此问题的根本办法. 造成此次生产事故的首要原因就是片键选择上的问题,由于片键选择失误,在数据量级不大的时候数据看起来还是很健康的,但随着数据量的暴涨,问题就慢慢浮出了水面,我们使用的组合片键并不是无规律的,片键内容是线性增长的,这就导致了数据的不正常聚集.由于数据分布不均匀,我们有两个分片的磁盘使用率接近80%,数据还在持续增长,这个问题必须尽快解决. 涉及到此次事故的集合…

记一次重大生产事故，在那 0.1s 我想辞职不干了！

一.发生了什么? 1.那是一个阳光明媚的下午,老婆和她的闺蜜正在美丽的湖边公园闲逛(我是拎包拍照的). 2.突然接到甲方运营小妹的微信:有个顾客线上付款了,但是没有到账,后台卡在微信支付成功(正常状态是充值成功). 我第一反应是第三方充值系统挂了吧(之前第三方系统接口经常超时,各种小问题),然后让运营小妹查下后台的异常提示. 3.过了2分钟之后,我还是不放心,用手机(当时没有背电脑出门)登陆后台看了下,发现后台已经进不去了,猜测可能是我的网络不好(公园的移动信号不给力,只有1格信号). 4.过了…

从一次生产事故说起——linux的单用户模式，救援模式等等

伴随着今年linux上面最大一个安全漏洞bash漏洞的出现,我们公司也開始了风风火火的漏洞修复工作,机器一多,也就easy出问题,有台64位的linuxserver一不小心就升级了32位 bash 的rpm,因为root,oracle这些用户默认都是通过/bin/bash来登陆的.这就造成了用户不能登陆server造成了极大的困扰,以下就是应对的办法,因为在生产环境解决的时候没法截图,通过虚拟机的环境来模拟当时的情况: 我们通过删除bash的rpm包的方式来模拟生产商bash包装错的情况: 在这…

「生产事故」MongoDB复合索引引发的灾难

前情提要 11月末我司商品服务的MongoDB主库曾出现过严重抖动.频繁锁库等情况. 由于诸多业务存在插入MongoDB.然后立即查询等逻辑,因此项目并未开启读写分离. 最终定位问题是由于:服务器自身磁盘 + 大量慢查询导致基于上述情况,运维同学后续着重增强了对MongoDB慢查询的监控和告警幸运的一点:在出事故之前刚好完成了缓存过期时间的升级且过期时间为一个月,C端查询都落在缓存上,因此没有造成P0级事故,仅仅阻塞了部分B端逻辑事故回放我司的各种监控做的比较到位,当天突然收到了数据库服…

Insert into select语句引发的生产事故

前言 Insert into select请慎用.这天xxx接到一个需求,需要将表A的数据迁移到表B中去做一个备份.本想通过程序先查询查出来然后批量插入.但xxx觉得这样有点慢,需要耗费大量的网络I/O,决定采取别的方法进行实现.通过在Baidu的海洋里遨游,他发现了可以使用insert into select实现,这样就可以避免使用网络I/O,直接使用SQL依靠数据库I/O完成,这样简直不要太棒了.然后他就被开除了. 事故发生的经过. 由于数据数据库中order_today数据量过大,…

【生产事故调查】优化出来的bug-合并集合重复项

本来是要修复前一个代码bug,修复的过程中发现原本的代码又丑又长,复用性差(但是能用),出于强迫症忍不住的去优化,测试还不充分,火急火燎的发到生产了,结果掉井了!导致多个订单线下物流发货发多了.... 万一有个别用户不管订单数量是不是自己下单的,直接签收了,再往回要就难了,那时还要加上来回运费. 当时提桶跑路的心都有/(ㄒoㄒ)/~~,但这个东西逃不掉,而且问题越拖越严重.这个时候就不能再去顾虑别人对自己的看法了,事情已经这样了,可奈何 ?不如主动承认错误,尽早解决降低损失. 最后硬着头皮向领导…