聊一聊程序员遇见的生产环境事故以及如何处理定位的?

2023-01-28 16:58:04 +08:00
 ppboyhai

这么多年程序员生涯各位大佬都遇见哪些生产事故?是否经历过事故后客户无休止电话轰炸与追问,是如何顶住压力解决生产事故的,都来唠嗑

首先说说我这边,曾经某一个周六,三个生产环境同一天崩溃,压力瞬间铺面而来,老板接到客户的电话一个接着一个。那瞬间真是需要莫大的心里承受能力。

三个生产环境的崩溃分别是:

1 、生产服务器遇到了 DDOS 攻击

2 、生产数据库参数被某某修改,查询贼拉拉慢,各种请求超时

3 、前端 Nginx 转发异常,请求各种不通

各位大佬还遇见哪些生产环境事故,是自己动手解决的还是呼叫炮火支援的

11544 次点击
所在节点    程序员
121 条回复
proxychains
2023-01-28 17:36:32 +08:00
@u21t20o15 运营: 这个家伙为什么这么开心
ppboyhai
2023-01-28 17:40:54 +08:00
@u21t20o15 这个思路简洁有效
kestrelBright
2023-01-28 17:49:28 +08:00
ddos 攻击;
sql 语句性能太差;
redis 持久化把盘写满了;
机房网络故障;


有人问线上出问题如何不登录线上服务器而快速定位问题,这个大佬们知道吗?
brianinzz
2023-01-28 17:58:29 +08:00
@Pantheoon 这个无解吧 redis 的 setnx 本身也没法设置过期时间
rushssss
2023-01-28 18:01:51 +08:00
@kestrelBright 监控的覆盖度如果够高,可以第一时间告警有故障的部分
546L5LiK6ZOt
2023-01-28 18:26:15 +08:00
如果问题不紧急,可以慢慢查,java 里面有万能的 arthas 。
如果很紧急,服务可能会雪崩那种,就先无脑对引发问题的接口限流,只要接口没流量进来,服务就不会挂。虽然影响用户体验,但是服务一旦挂了,就凉凉。
lawsiki
2023-01-28 18:29:18 +08:00
delete 条件缺失,大面积被删数据 😂
orzwalker111
2023-01-28 18:33:19 +08:00
MQ consumer 中 http 请求了第三方服务,没有设置 timeout ,失败后消费者线程假死
orzwalker111
2023-01-28 18:37:15 +08:00
有个系统 userid ,数据几十万,查询行数据命中这个 userid ,OOM
orzwalker111
2023-01-28 18:39:27 +08:00
修改“用户排名”系统的代码坏味道,误删除了 if 中的!,第二天全站用户排名乱了,老板带着高管站我 lead 旁边骂那种。。。
Leon821
2023-01-28 18:46:56 +08:00
ddos 攻击居多
zhuangzhuang1988
2023-01-28 18:50:23 +08:00
duan602728596
2023-01-28 18:52:11 +08:00
第一个事故是当时我在一家新闻网站负责发文系统。有编辑发 xi 大大的文章,内容是一组图片,使用文本编辑器的格式化文章功能,出现了图片缺少和重复的问题。发出去后被 wang_xin_ban 看到并批评了。大早上被领导打电话叫起来分析问题了。

第二个事故比较常见。早上收到警报电话,到单位后分析,发现是广告平台找回密码接口被不存在的账户调用过多,错误日志短时间太多触发了警报。
fengpan567
2023-01-28 19:30:17 +08:00
kafka 消费者有个特殊逻辑会耗时很长,还不是每次都触发,导致生产消费者动不动就 rebalance ,消息挤压上亿了😂
enchilada2020
2023-01-28 19:33:15 +08:00
全是鬼故事 卧槽小心脏受不了。。
DinnyXu
2023-01-28 19:57:09 +08:00
目前遇到最严重的是慢 SQL 拖垮服务器...
cutepig
2023-01-28 20:19:30 +08:00
cpp 程序员,最怕的是很难重复的问题。举几个这一类的 crash ,很多内存和多线程相关的问题
1. heap corruption
2. return address of local variable
zhoudaiyu
2023-01-28 20:36:08 +08:00
重启 /回滚 /隔离 /扩容
NoString
2023-01-28 20:39:22 +08:00
1.不小心把 USD 当成 JPY 发了出去,当时损失 2000w ,后追回 1400w 。发现 bug ,参加会议,书写复盘报告。
2.线上缓存击穿拖垮主库(不是我的代码,Master 不在我负责修复),投资人和剩下的几十万用户进不去 APP ,通过导出慢查询、恢复修正缓存策略恢复( C 端无法下单,损失不太好评估,按照环比交易量损失几十万)。
3.线上服务遭受 DDOS ,服务 CPU 拉爆进入假死状态,健康检查没配导致重启未生效,事处凌晨,持续了一个小时修复(直接损失百万)。后续修复了核心服务的心跳检查和新增了限流组件


我亲历过的 P0 就这么多,P1 、P2 有点数不胜数,包括但不限于 ClickHouse 、zookeeper 、Kafka 、Es 等中间件的各种问题。四年工作感觉就是行走的 bug 机。
NoString
2023-01-28 20:49:18 +08:00
关于之前比较大的事故我也有些流水账记录:

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/911105

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX