这是一个创建于 666 天前的主题，其中的信息可能已经有所发展或是发生改变。
这么多年程序员生涯各位大佬都遇见哪些生产事故？是否经历过事故后客户无休止电话轰炸与追问，是如何顶住压力解决生产事故的，都来唠嗑
首先说说我这边，曾经某一个周六，三个生产环境同一天崩溃，压力瞬间铺面而来，老板接到客户的电话一个接着一个。那瞬间真是需要莫大的心里承受能力。
三个生产环境的崩溃分别是：
1 、生产服务器遇到了 DDOS 攻击
2 、生产数据库参数被某某修改，查询贼拉拉慢，各种请求超时
3 、前端 Nginx 转发异常，请求各种不通
各位大佬还遇见哪些生产环境事故，是自己动手解决的还是呼叫炮火支援的
 |
101
ETiV 2023-01-29 15:38:13 +08:00 via iPhone  4
@gkiwi
> 在用户那里，拉下来内容发现有一个字符被替换了。。 你这就是 bit flip ，被来自宇宙的高能射线击中了…… ===== 看了全部评论，感觉还是我最猛：直接跑去机房把别人（不知道谁的）服务器给格了… 2010 年项目要上线，公司领导跟其他集团借了俩服务器，我们驱车从上海去宁波机房…到了机房，小工带着我们到了机柜面前，指着机柜下方的两台机器和我说就是这两俩，在确认之后我就开始干活儿了… 过了许久他回到了我身边，观察了一下，面色凝重的跟我说机器指错了…… ==== 再说说 bit flip 把我们数据库炸了： 基础设施在 AWS 新加坡…发现的过程就是业务几乎全部超时，而后发现 Aurora （ AWS 性能很强的 mysql 兼容数据库产品）实例 CPU 持续跑满…当时搞不懂问题出在哪，因为 slow query 会在执行完才会打印出来。 事后看 slow query ，它在更新一个有几千万行的表，整个表的每一行数据都被更新了，用了两个多小时，可是这个库我们是当 KV 库用的：读取和写入都会带上 where id=xxx ，不可能更新整表… 还好我们当时也遇到了些性能问题，线上会对超 1 秒的 sql 记下 sql 原始内容。 经过对比，我们发现业务里的日志：update a=1,b=2,c=3,… where id=xxx ，而 Aurora 里的 slow query：update a=1,b=2,c=#,… where id=xxx 3 被替换成了# ，而#之后的全被 Aurora 当成了注释，where 没起作用，把整个表更新了… 在当时，这种问题我曾在 dropbox 的一篇 blog 里看到过，说的就是因为 dropbox 的客户端太多了，样本足够大，所以他们也会偶尔发生这种类似问题，所以对这个问题下的结论就是“被宇宙射线击中了”，不怪任何人…… 字符 3 的二进制：00110011 字符 # 的二进制：00100011 |
 |
103
direction 2023-01-29 15:58:57 +08:00
定时任务处理借款订单，接口侧没做幂等校验，请求重复发送，导致直接 500w 放出去，后面打电话追回了 300w
|
 |
104
xuyang2 2023-01-29 17:42:14 +08:00
|
 |
106
yyttrr 2023-01-29 18:06:41 +08:00
访问三方链接没释放，导致集群公网出连接数达到上限
访问白嫖的免费第三方太频繁，导致集群公网出口被对方屏蔽 生产环境部署了某个开源软件使用了官方镜像，写死了镜像 tag:v2.2.0 ，资源紧张 pod 重启后不可用，仔细排查后发现，镜像内的版本变成了 v2.2.1,部分接口参数有变动 |
|
107
xuyang2 2023-01-29 18:07:51 +08:00
|
 |
108
JRay 2023-01-29 18:22:20 +08:00
用 clickhouse 的时候大表用了 select * ，直接内存爆炸，排查了几天。。加多少内存爆多少。
后面根据查询日志排查发现狗日的列式数据库是查多少字段就拿了总数据的那列所有数据出来。 一条 sql 占用内存 1.5G 。 |
 |
109
dqzcwxb 2023-01-29 21:32:51 +08:00
@xuyang2 #107 用 lua 脚本做分布式锁不仅仅是需要 set ex 还要 get 和判断等等,set 支不支持 ex 都不影响必须使用 lua 脚本保证多个命令的原子性
|
 |
110
mypchas6fans 2023-01-29 23:08:59 +08:00
前司 b2c 一个 case ，去年热乎的，知道的那一定是熟人：
大促前没有沟通好，结果开始促销了正好有个定时任务在跑…… 然后跑的这个阿里云 PG 库又比较特殊没有搞只读实例…… 然后 tmd 这个库显示索引正常但是其实有一个分库没加上……（这个后来应该是阿里云的锅） 总之大促一开始就挂了。后面各种发券请用户再来一遍 前前司搞咨询，不是 IT 互联网，但又还要给客户做信息化系统，这骚操作可就浪得飞起了， 大量生产操作是业务同事手工执行，包括但不限于： 误删 oracle 生产数据，幸亏有高权限用户，远程教他用 flashback 救回来了； 查生产数据的时候 5 表 join ，结果后面的 where 条件没被选中执行，等于取 5 表全表 join 数据……我 nm 数据库卡死不说，IO 都卡爆了。我找到了问题原因，那也只能找到客户端杀掉解决，幸好只是查询啥也没丢。后面老板去安抚客户擦屁股 |
 |
111
srivendare 2023-01-29 23:52:05 +08:00
SQL 占内存这个事情 倒是很常发生 团队小的话就互相问一下了
|
 |
113
gkiwi 2023-01-30 10:29:53 +08:00
@ETiV #101 学习了。当时不知道这个点，忘记记录具体的字符了，看介绍感觉是同一个。具体细节无法记不清楚了，只能说宇宙射线厉害啊~~
|
|
114
gkiwi 2023-01-30 10:32:01 +08:00
@clown007 #112 白屏 case 场景很多，比如机房故障，比如小流量实验，比如广告投放都有可能导致，感觉自己遇到过上百次各种白屏了。。
|
 |
115
LXGMAX 2023-01-30 11:34:15 +08:00
设备部署到某机关单位，被客户发现 bug ，然后自己到工厂装配间顶着三十几度高温吹着大风扇改代码...
客户老板还在旁边看着，压力巨大，发现是一些逻辑没考虑到，当场重写整个函数 不过经历这些之后面对各种情况都很淡定了，整盘代码逻辑过了一遍，出现问题也能快速定位 |
 |
116
proxychains 2023-01-30 13:25:58 +08:00
@lawsiki delete 不加 where 是吧... 😂
|
|
117
proxychains 2023-01-30 13:35:02 +08:00
@ETiV 牛皮
|
 |
118
christin 2023-01-30 15:14:02 +08:00
都是现在公司的几件事，挺有意思的。
1. 刚入职做活动就碰上一个 bug ，那时候在家办公，半夜 11 点测试组长给我开着语音盯着我改，完事之后一身汗。 2. 业务方一个功能用的好好的非说有 bug ，大半夜起来排查，手贱乱改代码导致用户的日志都发不出去了，后面回滚代码就没事了。 3. 找用户搞内测，但是几个月前后端把 iOS 那边线上充值的沙盒打开忘记关了，被人刷走了 10w 左右吧，后面也不知道怎么搞了。 4. 有几个域名到期忘记续费了，第二天早上用户反馈，正好赶上运维去医院，还打了麻药，拖了几个小时才解决。 碰到问题一定要冷静再冷静，慌是解决不了问题的。 |
 |
120
mmdsun 2023-01-30 18:45:38 +08:00 via iPhone
生产线安装 docker ，然后一个重要服务突然线下。
消息也挤压、也拖垮了的几个服务，客户各种投诉 最后发现是 docker 安装后默认生产的网卡和内网 ip 有冲突。 |
 |
121
demoBastard 2023-03-14 14:10:16 +08:00
@ppboyhai 当时不知道这个东西，这个东西确实是有帮助的
|
Select Language