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

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

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

不做有客户的项目

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

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

最重要的经验：

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

需要监控的可以分为：

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

@shakoon

drop 不写 binlog 吗？

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

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

@fiypig

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

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

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

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

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

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

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

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

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

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


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

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

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