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

[ppboyhai]

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

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

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

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

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

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

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

[ppboyhai]

推出这个主题，主要还是想交流下经验，看是否有必要在 github 上开通个项目，来聊一聊职业生涯中的那种突发事件与解决方案

[chenqh]

count(*)数据量太多卡住了

[chenqh]

请求远程 http 请求没有重试,网络波动超时了

[chenqh]

tornado redis 没用异步,lock 把,结果因为 lock 执行的时间太长把进程卡住了

[ppboyhai]

@chenqh 这个很典型

[xyloading]

机房断电，iptables 规则被重置，导致服务网络通讯异常

[chenqh]

再来个 celery 如果使用 redis 做 broker 的话,如果长时间没有消息的话, celery worker 就不再工作了

[guanzhangzhang]

https://zhangguanzhang.github.io/ 😁我日常遇到和处理的问题基本都会写成博客，不喜欢写那种纯理论的文章

[ppboyhai]

@xyloading 这个是内伤，哈哈哈

[ppboyhai]

@guanzhangzhang 超级赞

[proxychains]

RAID 卡开了 write back, 但是时间就阵列卡电池没电了, 服务器无法连接后, 尝试强制关机. 结果数据丢了.
不过还好找回了一部分. 从那以后打死不开 write back. :(

[proxychains]

@proxychains 时间久阵列卡电池没电了. 抱歉打错了字

[rrfeng]

redis 用的太狠，网卡打爆了……死活查不到为啥 get 超时。

[Pantheoon]

redis 锁不是原子的,加上锁以后没有自动删掉,导致后面同样的一个 key 再也加不上,这个问题搞了一天,找 dba 拉了很多 redis 执行的数据,最后发现有几个 key 线上没有设置超时时间,再一看代码,那个 redis lock set key 和 expire 是两条命令

[demoBastard]

每天内存不断增大，但是不是栈内内存而是堆外内存，线上排查。。。

[adoal]

上级信息管理部门买的蜜罐服务器忘了把我们的 Oracle RAC 服务器的 IP 地址排除出去，然后抢了其中一个拿来搞伪装…于是我们业务系统有半数访问堵死，半数正常。夜里 10 点，供应商的国内技术支持人员都不在岗，转给另一半球大头朝下倒立着的老外工程师远程连线排查。

[ppboyhai]

@demoBastard 线上排查 有尝试过阿里的 arthas 工具么

[dream4ever]

1. 早上上班后发现阿里云 Windows 服务器上的 IIS 出故障了，所有网站不可访问，上网查了一圈资料无解，重启后无法进入系统，试了各种方法都不行。而且闹心的是用系统盘 C 盘所有可用的快照恢复后，一开机还是有同样的问题，进不去系统。还好网站和数据都放在 C 盘以外的地方。先临时新开了台备用服务器，把几个关键的网站和数据复制过去，然后再给主服务器装系统。这个问题最后也没法找到原因了，但是重视了快照和运维工作，每周定期重启一次服务器，同时增加了快照的保留份数和保留时长。
2. 还是那台阿里云 Windows 服务器，发现 CPU 时不时地就会 100%，经过对运行的各个网站逐个排查，发现是用 ASP 编写的旧网站有漏洞，用特殊路径访问的话就会出现这种问题，最后把这类请求屏蔽解决问题。
3. 还是这台服务器，CPU 又是时不时地会 100%，在阿里云网页端控制台查看进程，发现是 MySQL 相关进程。因为不知道该从什么方向切入，所以又是 Google ，又是买网上 MySQL 方面的实操课程，最后发现是慢查询导致的，再深入数据库，发现是同事没有给表中的常用字段加索引导致的，加上索引后问题瞬间解决。

[u21t20o15]

运维把域名给干掉了，导致客户访问不到服务...重新备案走流程要一个多星期
解决方案是弄了个国外服务器做跳转

[u21t20o15]

好奇，遇到问题的时候大家是什么状态？我是很亢奋那种，导致运营看到我在出严重事故的情况下还嬉皮笑脸投诉到领导那😁

[proxychains]

@u21t20o15 运营: 这个家伙为什么这么开心

[ppboyhai]

@u21t20o15 这个思路简洁有效

[kestrelBright]

ddos 攻击；
sql 语句性能太差；
redis 持久化把盘写满了；
机房网络故障；


有人问线上出问题如何不登录线上服务器而快速定位问题，这个大佬们知道吗？

[brianinzz]

@Pantheoon 这个无解吧 redis 的 setnx 本身也没法设置过期时间

[rushssss]

@kestrelBright 监控的覆盖度如果够高，可以第一时间告警有故障的部分

[546L5LiK6ZOt]

如果问题不紧急，可以慢慢查，java 里面有万能的 arthas 。
如果很紧急，服务可能会雪崩那种，就先无脑对引发问题的接口限流，只要接口没流量进来，服务就不会挂。虽然影响用户体验，但是服务一旦挂了，就凉凉。

[lawsiki]

delete 条件缺失，大面积被删数据 😂

[orzwalker111]

MQ consumer 中 http 请求了第三方服务，没有设置 timeout ，失败后消费者线程假死

[orzwalker111]

有个系统 userid ，数据几十万，查询行数据命中这个 userid ，OOM

[orzwalker111]

修改“用户排名”系统的代码坏味道，误删除了 if 中的!，第二天全站用户排名乱了，老板带着高管站我 lead 旁边骂那种。。。

[Leon821]

ddos 攻击居多

[zhuangzhuang1988]

@dream4ever
很早之前博客园就写过了，阿里云的
https://www.cnblogs.com/cmt/p/8267799.html
https://www.cnblogs.com/cmt/p/3766545.html

[duan602728596]

第一个事故是当时我在一家新闻网站负责发文系统。有编辑发 xi 大大的文章，内容是一组图片，使用文本编辑器的格式化文章功能，出现了图片缺少和重复的问题。发出去后被 wang_xin_ban 看到并批评了。大早上被领导打电话叫起来分析问题了。

第二个事故比较常见。早上收到警报电话，到单位后分析，发现是广告平台找回密码接口被不存在的账户调用过多，错误日志短时间太多触发了警报。

[fengpan567]

kafka 消费者有个特殊逻辑会耗时很长，还不是每次都触发，导致生产消费者动不动就 rebalance ，消息挤压上亿了😂

[enchilada2020]

全是鬼故事 卧槽小心脏受不了。。

[DinnyXu]

目前遇到最严重的是慢 SQL 拖垮服务器...

[cutepig]

cpp 程序员，最怕的是很难重复的问题。举几个这一类的 crash ，很多内存和多线程相关的问题
1. heap corruption
2. return address of local variable

[zhoudaiyu]

重启 /回滚 /隔离 /扩容

[NoString]

1.不小心把 USD 当成 JPY 发了出去，当时损失 2000w ，后追回 1400w 。发现 bug ，参加会议，书写复盘报告。
2.线上缓存击穿拖垮主库（不是我的代码，Master 不在我负责修复），投资人和剩下的几十万用户进不去 APP ，通过导出慢查询、恢复修正缓存策略恢复（ C 端无法下单，损失不太好评估，按照环比交易量损失几十万）。
3.线上服务遭受 DDOS ，服务 CPU 拉爆进入假死状态，健康检查没配导致重启未生效，事处凌晨，持续了一个小时修复（直接损失百万）。后续修复了核心服务的心跳检查和新增了限流组件


我亲历过的 P0 就这么多，P1 、P2 有点数不胜数，包括但不限于 ClickHouse 、zookeeper 、Kafka 、Es 等中间件的各种问题。四年工作感觉就是行走的 bug 机。

[NoString]

关于之前比较大的事故我也有些流水账记录：

[NoString]

https://kelovp.tech/nostring/blog/1196/
https://kelovp.tech/nostring/blog/1172/

[enchilada2020]

@NoString 卧槽 USD 当 JPY 可太吓人了。。。

[dusu]

事故长期积累后 可以形成自己的一套报警机制的
什么问题都可以思考是否有必要监控起来
甚至出了问题是否能做到自动修复
久而久之 你看到故障报警 压力也不会这么大了

[wonderfulcxm]

被黑删除网站并且没有备份

[dusu]

@dusu 拿题主三个故障来说
1. 提前做好 nginx 状态监控 响应时间超过阈值就报警，同时提前部署 waf 相关系统
2. 监控数据库响应和连接数 异常就报警 提前预案
3. 监控部分资源是否能正常返回 超时或者状态码异常就报警 或者做一套前后端故障自动切换方案

[kaneg]

@orzwalker111 我们有一个服务出现过类似的错误，对外的 API 请求超时默认一分钟，该 API 平时一般在 1 秒内就可以返回，所以很长一段时间都风平浪静。但有一次该 API 服务挂了，我们的 API 请求都被挂住 1 分钟，线程池很快就被耗光，所有依赖线程池的其他业务都被连累了。

[collen]

查询是不是我前段时间写的 BUG 爆发了现在的 BUG
还真 TM 的是 赶紧找个奇怪的借口

[MeteorCat]

文件描述符导致 504

[maojun]

@adoal 看到你这笑出声 😂

[chenqh]

再来个 python redis lock 没有设置 lock 时间,导致 key 被 lock 的时候,进程重启之后,key 永远不释放了

[LawlietZ]

op 最后怎么解决的 也分享一下啊

[ppboyhai]

@kestrelBright 遇见的事儿多了，经验就来了，都是这么积攒的泪史

[ppboyhai]

@orzwalker111 哈哈哈哈哈哈哈哈，狠好的经历

[ppboyhai]

@NoString 经历丰富的很啊，老兄

[sss15]

生产上 win 服务器，加了一块云磁盘，分配磁盘空间的时候，分区搞错了，就打算删除掉重新分配，结果误操作吧整个磁盘分区表弄丢了，数据库、web 服务、文件全在服务器上，故障持续 1.5 天，晚上睡觉都在想明天怎么办，期间淘宝和网上找了数据恢复公司在线恢复，没有一个能成功的。最后连蒙带猜加上计算机基础知识，通过算扇区大小竟然重新重建了分区表。

[ppboyhai]

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

生产环境是 gitlab 和其他中间件共存的服务器，由于 gitlab 属于被高频率漏洞攻击的中间件，发现被植入了 ddos 肉鸡病毒，每当肉鸡操控者想攻击某某的时候就会调用各肉鸡的流量去攻打，此时 CPU 和内存会瞬间拉至封顶。
解决方案：首先是人工清除，定位异常进程，找到进程触发的病毒脚本，然后逐个清理后，恢复正常。
之后采用阿里的安全组件，10 分钟结束战斗，每月每台服务器多花 120 块钱的样子。

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

呼叫了集团 DBA 半天才定位某个参数，各种拉日志定位问题。

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

这个还是由于公司一些工程师经验不足导致 nginx.conf 配置错误，但是又没有很好的备份上个版本。
建议处理方案：采用 nginx web ui 记录每一次修改记录，也可以快速回滚到上个版本

最后想说的是：一定要敬畏生产环境，才能睡个好觉，睡的安心。

不要嫌麻烦，各类监控组件一定怼上！ 告警一定要先于业务发现，否则惨兮兮

@LawlietZ

[corcre]

遇到过一个, 域账号验证超时, 但是几个站点用的是同一个域服务器, 只有一个站点登录不上, 别的站点很顺畅, 本地 debug 发现请求发送到域服务器以后就超时了, 域服务器状态也很正常, 查了一上午也没查出来为啥, 后来重启了一下又没事了(到现在都不知道是为啥

[corcre]

还有一个机房空调坏了把室温都烤到 50 度所有服务器全部宕机算吗🐶
解决方案: 修空调🐶🐶🐶

[fiypig]

最近一个定时器的问题，搞崩好几次 General error: 2006 MySQL server has gone away

[corcre]

你这么一说我就又想起来一个, 在老东家的时候, 客户说硬盘满了, 数据装不下了什么的, 然后实施过去了, 看着人家两盘位的 NAS, 把人家的硬盘带电拔下来一个, 准备装个大容量的上去, 结果就是装上去了没反应, 原来的硬盘装上去了识别不了, 主管老板大老板一个个排着队跑过去被客户叼了一顿, 后来我也不知道怎么处理的...
这是我职业生涯里面看过最搞笑的生产环境事故...

[ppboyhai]

@corcre 同样遇见过空调问题 😂

[huluhulu]

用 32bit 记录消息毫秒时间戳用来当消息先后标志，当设备连续运行超过 49 天时，溢出导致前后消息的时间戳大小异常，会丢几个消息，恰好丢的时关键信息时，会引起不必要的 log 。

[shakoon]

听说过一个略搞笑的严重事故。dba 使用一高权限用户在用完 navicat 后本来是想关闭连接的结果点错成了删除，然后库就没了。这事搞笑在，本来这个库有很复杂的多点备份策略，本地副本异地副本若干个，但都因为这个正常发出 drop 给同步到了各个副本，所有的也被 drop 了。一群人黑着脸花了好久用半天前的全库离线备份归档+binlog 给慢慢恢复回来的。后来听说他们使用这种高权限用户时都是一人操作一人旁边盯死还有一人完成后复核，navicat 也被禁用了，找了个开源的其他工具魔改，delete 、drop 这些提交时要三个账号密码验证。

[dog82]

我碰到过 redis 里面就几千条数据，但是占用 4G 内存的情况

[matepi]

简单做的：
报警监控先一眼，确定具体节点和影响程度。重启回退扩容三板斧弄一把。

几乎每周都有分析深度的：
还不行就 threaddump 拉一拉，gclog/oom 看一看，lsof 查一查，数据库报告拉一个。然后各种联系开发查。

[matepi]

@shakoon
能被同步的是不应该叫备份、应该叫冗余。
备份是不应该被短时间内同步的，要逐步时间级别地、增量备份。
冗余和备份各有作用，不能互相替代。

[Light3]

小外包给大公司做的微信活动(真送 1000 块钱的鞋)砍一刀
直接给垃圾服务器 砍挂了..

[TUNGH]

好问题

[dqzcwxb]

@brianinzz #24 都是用 lua 脚本实现的加锁与设置超时时间的原子性,sping 有对应的实现可以直接用 lua 脚本都给你写好了

[NoKey]

@orzwalker111 很好奇，你们没有代码检视入库么，特别是这种旧代码判断逻辑的修改，应该是相对严格的审核才对

[LxnChan]

遇到的问题基本都会写 blog
https://lxnchan.cn

[awalkingman]

@sss15 大难不死 必有后福（听得我心惊胆战的

[cwcc]

事故分很多级别，有的很小，比如前端页面错乱，格式炸了的小问题，但不影响主体使用。这个占多数，就是网站 css 改炸了。还有运营事故比如光纤被动物咬断，跑了个死循环也比较常见。后面几种大事故一般都是缩小定位，但死循环这个需要代码有很好的模块式分离，耦合过大就比较难定位了。敏捷开发快速迭代时最好在生产环境装上调试工具以备不时之需。

[ppboyhai]

@cwcc “在生产环境装上调试工具以备不时之需” 这个想法不错

[sadfQED2]

1 、mysql 机房交换机故障，偶发丢包。导致各种神奇的 MySQL 慢查询。研发、运维、DBA 我们一群人排查了一个多月才找到问题。

2 、线上服务机房 IP 写错了，公司核心服务基本全崩溃。

[NoKey]

@NoString 我看了你这两篇博文，有几个问题想了解一下，绝非杠，单纯从开发角度来讨论：
1. 既然你们的服务涉及的用户，金额都是大量的，为什么没有严格的代码 review ，测试，预发布环境等上线前的质量把控
2.看到有地方提了 mysql 的编码问题，这个量级的用户、金额，应用开发前就应该统一所有编码，这个是项目启动的基本要素

能出这些问题，感觉你们技术负责人很野啊~

[orzwalker111]

@NoKey 是有的，一来自己大意没注意这块，另一方面 review 这些现在更多是看业务逻辑了，不太有精力和时间逐行检查逻辑了。再就是恰逢组织架构调整，最后就给发生了。。。后来立了一堆这个排名系统的代码上线规范

[Naruto129]

@u21t20o15 之前也有过类似的情况，我们都是要做复盘的，然后会上投诉他们干扰排查，这个时候我们需要减少干扰，搞过一两次好多了。

[gkiwi]

先说个诡异的的 CDN 相关的 bug ，好几年了。

记得是个国庆期间，当时负责的平台，有用户反馈白屏，尝试了回滚、重新上线怎么都有零星用户报页面白屏（而且是不同地区，但主要集中在两三个地方），而且之前是没有过的，报白屏的用户稳定复白。

最后实在无奈，给用户电话，加了 QQ 远程调试了下他的页面，发现一个 cdn 上的 js 报错，但是报错位置拉下来傻眼了，引用同样的 url ，在北京拉下来一个内容，在用户那里，拉下来内容发现有一个字符被替换了。。后来拉着公司 CDN 同学排查也是无解。后来解决方案是把线上 CDN 全部手动清理，之后回源然后就好了。（根 case 没找到，因为当时重新上线也不行，很诡异）

[zhoudaiyu]

@fiypig 咋解决的啊

[8355]

说说超级经典的吧
1.前公司的前端老哥把购物车提交按钮 id 删掉了 导致无法下单 直到运营周报发现变化测试之后 把测试老大和前端老大公开处刑.
2.两个大市场的运营大促发海量 push 本来是不同国家客户按照时差会错峰发送 结果撞到一起 运维流量暴涨 机器打爆了 我们恰好上了代码运维以为是代码问题喊我们排查,最后查到原因拉出来排排站
3.app 端用错触发事件 单客户端列表接口 1 秒 30 次调用 grafana 拉爆

[Naccl]

1. 老服务的烂 SQL 迁到新服务后，新服务用的 MySQL 性能比老的差了几倍，慢调用过多把数据库打崩了，开了 SQL 限流把其它接口稳住了
2. 有个从来没调用过的接口，有一天突然被不带参数地调用了，SQL 没限制条件，拖了全表数据直接 OOM ，拿 dump 文件定位到的
3. 请求量激增，consumer 线程太少 + consumer 中 http 调了三方接口 + 三方接口超时，MQ 消息堆积，最终服务不可用，后来加了一堆实例

[zoharSoul]

不做有客户的项目

[Bingchunmoli]

分布式项目里面不知道谁提交的 redislockutil 用的 redis ，然后所有定时项目都是用它，完成抽奖功能出现多发 bug

[ukpkmk]

@transactional 注解使用不当,事务处理时间过长导致锁表

[encro]

最重要的经验：

1,想办法写日志；
2,分析日志预警；

[encro]

需要监控的可以分为：

1,请求日志（耗时，频率）
2,错误日志（频率）
3,慢日志（数量，频率，top ）
4,资源状态（内存，cpu ，iops ，带宽，队列数量等等）

[encro]

@shakoon

drop 不写 binlog 吗？

[fiypig]

@zhoudaiyu 还没处理，先关闭这个定时器了，tp5 的 有些说开启断线重连，我到时候看看，不行就用 go 来做了

[sampeng]

首先，是别慌，其次，别慌，最后，别慌。
就这 3 个原则。

[encro]

@fiypig

看同样时间点的 mysql 日志有什么，
你使用了 swoole 之类的长连吗？
搜索 mysql 参数设置超时，可能是超长时间没有交互，也可能是错误次数太多被断开。

[DingJZ]

说几个我印象深刻的，前端方向
1. 邮箱没有管理
公司内部应用 iOS 端都是通过集团的企业证书分发的，突然某一天企业证书被苹果 ban 了，各业务老板都打电话来找，一下子懵逼了，后来临时又找了一个证书签名，折腾了一天。
后来回头去查，苹果不可能连个警告都没有就把证书停掉，客服回复会提前发邮件，给 15 天整改期，然后发现集团那边当时用的邮箱早就被回收了，根本没有管理。
2. 域名没有管理
内网应用和公网应用用的同一个域名，解析都走阿里云的 DNS ，某天机房外网挂了，结果内网很多服务也受影响。
3. chrome bug
遇到过至少两个 chrome 的 bug 影响业务的。一个是在 windows 下某个版本获取到的用户时区不正确，导致页面上的时间不对，只好在代码里把客户端时区固定设置在上海。
另一个是打印预览的 bug ，打印出来的内容和页面的布局不一样，好在是公司内部几个人用的功能，让他们临时降版本用

[NoString]

@NoKey 之前我也在 v 站发过帖子，大家一致认定为管理和流程的锅，首先作为工作半年的应届生掌管订单、支付、优惠券系统的 Master 权限本就不合理，测试、代码 Review 等事项也没有一点对线上的敬畏心，出于前期过于良好的表现加上刚过完年的松懈导致我的直属老大忽略了这部分内容。团队混乱狂野你说的都正确，经过这个我是非常建议应届生去流程规范、做事有章法的标准厂。

mysql 编码这个事情我也觉得很离谱，不过后来结合公司的情况我居然认为这是情理之中。

我们的技术负责人从背景看都挺行的，什么阿里 p8 、Google 资深研发之类，他们在团队中把大部分时间花在了应付老板、和兄弟部门演甄嬛传上。风格野太正常不过，或许我说水浅王八多你可能会发笑，但是确实是我亲身经历。

[fiypig]

@encro 看错误日志好像没发现什么，用的就 thinkPHP5 的普通查询，配合定时器，可能我代码上的问题，还是你说那样，到时候优化看看了，哎。

[S4msara]

win cmd 启动，sql 日志太多，同步日志，cmd 来不急打，全线延时…

[linvaux]

头天晚上上线的时候发现有个小伙伴加的配置导致数据库 cpu 暴增，sql 执行 1h 都执行不完，阻塞其他业务运行。找 dba 重启后，屏蔽了相关配置，然后顺利上线。但是到家之后收到 IM 消息，配置又被这兄弟悄悄改回来了，好家伙，我直接手机静音睡觉。第二天早上起来发现手机上七八个未接，但是，这关我 p 事，冤有头，债有主[\dog]

[Vkery]

客户机房内网安全软件更新，导致防火墙策略改变，各服务器之间网络不通

[qinghou]

当年在某金融公司，某天突然大笔还款，还款笔数多，还款层数也多（投资订单可以专卖）。还款的服务扛不住压力爆了，导致很多人到期没收到钱，客服电话瞬间打爆。还款服务是我和一个同事在维护，他那天请假。于是面对蜂拥而来的用户压力，CTO 、CEO 、甚至幕后的老板，全部跑到我座位后面看我处理。当时心跳到 180 不止，一直低声告诉自己冷静下来。难点主要是服务炸了以后，数据乱了，十几张表，几十万用户的数据，需要梳理正确。那天从下午搞到第二天早上才把数据对好，还款服务恢复，限流慢慢重新跑完。


之后为了避免再次发生这个问题，用 rabbitmq 把整个还款流程，拆分成 N 多个环节，这样不同环节的数据和服务都可以分别部署，就再没发生过高并发的压力问题。重写还款服务这段时间，要维护线上服务，还要设计开发新服务，每天的精神压力很大，可谓禅精竭虑。最后弄完以后，业务分析能力，系统架构设计能力，编码能力都感觉提高了一大截。

[linvaux]

@dog82 这特么是一个 key 里面放了一部电影吧

[ppboyhai]

@linvaux 这兄弟在作死的路上 意志坚定的狠