共计 5491 个字符，预计需要花费 14 分钟才能阅读完成。
作者：小傅哥
博客：https://bugstack.cn
积淀、分享、成长，让本人和别人都能有所播种！????
一、前言
你的代码出过事变吗？
老人言：常在河边走哪有不湿鞋。只有你在做着编程开发的工作就肯定会遇到事变，或大或小而已。
当然可能有一部分研发同学，在绝对传统的行业或者做着用户体量较小的业务等，很难遇到让人闻名的事变，少数都是一些线上的小 bug，修复了也就没人问了。
但如果你在较大型的互联网公司，那么你负责的开发的零碎性能，可能面对的就是成百万、上千万级别用户体量。哪怕你有一点小 bug 也会被迅速放大，造成大批量的客诉以及更重大的资金损失危险。就像：
- 拼多多“薅羊毛”事件，朋友圈疯狂转发。
- 淘宝昨现重大线上 bug，S1 级事变，疑似程序员成心埋雷。
您应用的程序是内测版本，将于当地工夫 2020-03-28 到期，到期后将无奈应用，请尽快下载最新版本。 - GitHub 遗记续订 SSL 证书导致网站排版凌乱，局部网站不能失常关上。
相似这样事变的呈现，可能是因为技术流程、计划实现、技术服务以及经营配置等等起因产生的。综合能够概括为以下几点：
- 性能流程设计类：通常指的是研发在设计产品逻辑性能实现流程中，谬误的执行调用关系而造成的危险事变。
- 技术计划实现类：在研发设计好流程后，每一个性能点的实现计划会因人而异，也会因为了解偏差或有余，而导致实现过程中短少了对代码在运行过程中健壮性的评估。
- 技术服务应用类：这一类说的是在研发应用数据库服务、缓存服务、大数据服务、配置核心服务以及公布上线服务等时，对各项服务的配置以及应用上短少肯定的理解，而造成的事变。
- 后门违规操作类：这一类因公司对研发标准的执行强度不同，而是否会有此类危险。例如：有些研发同学会开发一些后门程序，比方能够在某个 ERP 页面执行数据库语句，长期批改数据。这样造成的危险，通常为后门违规操作，会有开革危险。
- 经营操作失误类 ：在研发认为还有一部分公司内的搭档会应用研发同学开发的经营零碎，配置流动、变更用户、执行流程等操作，但个别状况下这类零碎短少肯定的强规定验证，导致经营小白在操作过程中造成危险，从而引发事变。 个别线上配置出谬误卷，或者推错短信给用户等等，都是这样产生的。
能够说，大多数比拟蠢的事变次要是集体责任心问题。但那些有技术含量的事变，犯一次还是挺值得的。尽管公司很厌恶你造成事变，因为会给公司带来损失嘛！但这样具备具备技术含量的事变，却对你个人成长十分好的案例。不过禁酒虽好，可不能贪杯！
接下来，小傅哥就带着你领略下各类事变的风采，看看在什么场景、遇到什么问题、怎么解决的以及能学到什么！
二、研发事变
1. 性能流程设计类
- 事变级别：P1
- 事变判责：相应的研发、测试总结复盘，罚款 50 元给加入的会议的搭档买棒棒糖以示正告。
- 事变名称：抽奖积分领取流程不合理
- 事变景象：用户积分多领取，造成批量客诉，当天紧急排查修复，并给用户补充积分。
- 事变形容：这个产品性能的背景可能很大一部分研发都参加开发过，简略说就是满足用户应用积分抽奖的一个需要。上图左侧就是研发最开始设计的流程，通过 RPC 接口扣减用户积分，扣减胜利后进行抽奖。但因为当天 RPC 服务不稳固，造成 RPC 理论调用胜利，但返回超时失败。而调用 RPC 接口的 uuid 是每次主动生成的，不具备调用幂等性。所以造成了用户积分多领取景象。
- 事变解决：事变后批改抽奖流程，学生成待抽奖的抽奖单，由抽奖单 ID 调用 RPC 接口，保障接口幂等性。在 RPC 接口失败时由定时工作弥补的形式执行抽奖。流程整改后发现，弥补工作每周产生 1~3 次，那么也就是证实了 RPC 接口的确有可用率问题，同时也阐明很久之前就有流程问题，但因为用户客诉较少，所以没有反馈。
- 学习总结：调用的接口、发送的 MQ，并不一定会每次都胜利。那么肯定要做好幂等性以及失败后的弥补，来把整个技术实现流程做的更加欠缺。就像小傅哥说的，擦屁屁的纸 80% 的面积其实都是爱护手的！
网友事变分享：
| 事变名称 | 事变形容 | 事变后果 |
|---|---|---|
| 业务流程搞错 + 代码频繁开拓线程池 | 业务流程搞错导致的问题就是改变特地大，有点相似重构代码了哎西，导致服务宕机很久，客户疯狂反馈 | 疯狂加班改业务，加了不晓得多少个早晨，因为是菜狗子，写的代码太垃圾了，被大佬给疯狂叼 |
| 线上批改用户收货地址失败（共事须要的问题，也能够借鉴下 ^v^） | 场景：客服反馈用户须要把收货地址从河北省改为浙江省（因为疫情），公司要求批改线上数据须要提交工单，因而 l 到审核平台提交申请等一系列流程。问题：工单显示批改后果胜利，然而数据没有改过来，多为共事一起查看 sql 发现 sql 编写没有问题。解决过程：查看 sql 是否正确，平台是否批改胜利，又查看了数据是否正确，还查看了批改工夫是没有问题的。 | 首先，疏忽了一个问题，这个订单数据是淘宝下单同步到咱们订单这边的，数据批改的后，淘宝又同步也数据过去，把批改正确的数据又改为了河北的地址。而后就狐疑 sql 审核平台问题。到这里故事曾经讲完了。论断：想通知大家要置信代码，多查看不确定的状况，不要钻到死胡同，老是狐疑审核平台问题，多查看本身问题。 |
| 业务相干事变 | 刚退出一个新的团队，没有深刻理解他人的代码就进行复用，没有了解业务的场景就限度条件，相似的状况很多，只能说，再简略的代码都要放弃敬畏，因为你不晓得哪里会出问题 | 用户投诉、领导批评 |
2. 技术计划实现类
- 事变级别：P0
- 事变判责：营销流动推广用户较多，影响范畴较大，研发整改代码并做复盘。
- 事变名称：秒杀计划独占竞态实现问题
- 事变景象：用户看到能够购买，但只有一点下单就
流动太火爆，换个小手试试。造成了大量客诉，紧急下线流动排查。 - 事变形容：这个一个商品流动秒杀的实现计划，最开始的设计是基于一个流动号 ID 进行锁定，秒杀时锁定这个 ID，用户购买完后就进行开释。但在大量用户抢购时，呈现了秒杀分布式锁后的业务逻辑解决中产生异样，开释锁失败。导致所有的用户都不能再拿到锁，也就造成了有商品但不能下单的问题。
- 事变解决：优化独占竞态为分段动态，将流动 ID+ 库存编号作为动静锁标识。以后秒杀的用户如果产生锁失败那么前面的用户能够持续秒杀不受影响。而失败的锁会有 worker 进行弥补复原，那么最终会防止超卖以及不能售卖。
- 学习总结：外围的技术实现须要通过大量的数据验证以及压测，否则各个场景下很难评估是否会有危险。当然这也不是惟一的实现计划，能够依据不同的场景有不同的实现解决。
网友事变分享：
| 事变名称 | 事变形容 | 事变后果 |
|---|---|---|
| gc 疯狂回收 | 最近调整了本人业余我的项目，跑一段时间就内存狂涨，还不能被动诱发 | dump 内存中 |
| 反复扣入账 | 并发数过多，数据库连贯满，期待超时，session 断开。事务未提交，捞出持续干 | 500 块，深刻并发编程，目前并发模型在我心中，欢送 battle |
| 数据笼罩 | 循环更新数据时，开启事务，持续时间过长，而后笼罩掉了用户在继续事务中提交的数据 | 没影响，就是多加了几天班 |
| 数据穿透 | 第三分应用脚本海里申请并发造成数据穿透 | 削峰天谷，应用队列解决申请 |
| 这序列号咋反复了？？ | 序列号应具备全局的惟一，一条数据代表一条支出，序列号生成规定 + 代码 bug 导致序列号反复，影响了几万单支出核查 | 一级事变，回溯 + 通报 |
| 业务流程数据笼罩 | 启流程是一个公共类，各种交易都在这个外面做，公共类一开始没有通过设计，有一个办法返回了这个模板类型字段，同时这个办法又是一个测验类，过后加了一个测验返回成错误码了，导致所有的交易都启不了流程。 | 挨批长忘性。。。 |
| simpledateformat 的线程不平安导致多线程定时工作解析日期出错 | 某定时工作运行时，须要做一些日期解析动作，就用了一个公共变量 simpledateformat，来格式化，后果工作常常间歇性报错，几天报一次或者一两周报一次，没啥法则。看异样信息才发现解析日期的字符串很奇怪，经常出现很多奇奇怪怪的数字。 | 定时工作报错，不过还好，定时工作只是为了做缓存而已，不波及到数据库的更新，仅仅是查问而已。 |
| 前端解析主键异样 | 因为 Long 类型最大 19 位而 JavaScript 最大接管数字为 16 位，固存在精度失落问题 | 对立解决将 id 转字符串再返回前端 |
| list 遍历删除 | 遍历删除清空 list 数组，为了节俭计数器那小小一点内存，日了 | 报错被叼了呗，为啥不必计数器？不香吗？ |
| 商品超卖 | 售卖一个兄弟部门的电子券商品，同步库存的代码有问题，导致了超卖 对客户造成了损失 | 罚款 1000 元 |
3. 技术服务应用类
- 事变级别：P2
- 事变判责：网友说被叼了一会，问题不大！
- 事变名称：扩容时疏忽了连接池梳理，导致连接池被打满
- 事变景象：线上忽然收到报警短信，关上电脑一看，简略的查问接口超时到 3 分钟才返回。
- 事变形容：幸好监控报警加的全，及时收到了报警短信，分割 DBA 查看发现连接池被打满了。为了疾速解决线上报警，优先长期扩容了连接池以及把服务重启。察看后连接池打满隐没了。
- 事变解决：查看利用数据库连接池配置，以及额定不常常上线的服务一并排查。经查问发现所有的利用加起来连接池的最高配置超过数据库调配的连接池数量。尤其是定时工作较长时间扫库解决，是间接导致连接池打满的重要起因。
- 学习总结：研发不仅是代码开发搬砖人员，还要理解相熟与之配套的服务。正当的应用、全面的考量能力防止一些看似不应该呈现的事变问题。
网友事变分享：
| 事变名称 | 事变形容 | 事变后果 |
|---|---|---|
| 应用 fastjson | 全身上下都是高危破绽，一年不停降级版本打补丁 | 珍惜生命，远离 fastjson |
| 微信名存储 bug | 微信名的 emj 头等存入 mysql 编码是 utf8 的库报错 | 被怼了！改成 utf8mb4 编码 |
| 磁盘有余 | 数据库集群磁盘空间有余，提前两周提交扩容申请，甲方运维没提交下来，最初某台机器空间有余，导致整个集群彻底不能工作，体验一把某国产号称能够不便横向扩容的某 idb 的优越性 | 罚款，责任归零碎建设方 |
4. 后门违规操作类
- 事变级别：P0
- 事变判责：网友反馈，擅自开发后门，执行 sql 谬误，影响较大。开革！
- 事变名称：通过后门程序修改线上数据
- 事变景象：这次批改影响范畴比设想的要小，只有局部数据因为缓存生效了，才读取数据库的流动信息。所有有少部分客诉说流动与名称不合乎。
- 事变形容：研发人员应经营要求批改线上配置谬误的流动名称，但任何邮件记录以及负责人审批。所以只是研发擅自通过后门程序提交 sql 语句批改，但遗记写 where 条件，造成几千条流动名称被同时批改。
- 事变解决：预先分割 DBA 紧急通过 binlog 日志进行数据修复。
- 学习总结：研发人员应防止操作线上数据，尤其是变更数据类。也不要开发各类改数据、上线、传配置文件等后门。而应该严格遵守研发流程，紧急事件须要申请批准解决。
网友事变分享：
| 事变名称 | 事变形容 | 事变后果 |
|---|---|---|
| 删除整个我的项目目录文件 | 测试区，测试删除文件时目录写错，导致整个 weblogic 子项目目录被删 | 请我的项目中负责集成部署的公司帮忙重新部署，测试区瘫痪了两天 |
| 误更新生产订单数据 3 万多条 | 上班前，未带外围过滤条件，导致误更新 3 万多条订单数据，偷偷利用 binlog 复原了，耗时 3 个小时 | 完满复原数据 |
| 线上库整库误删除 | 应业务方要求要在线上环境创立线上联调库，应用了导出数据库 DDL 语句后，间接执行，导致执行了 exists drop 语句，删除了线上库所有数据，数据量大表均在千万级，APP、网站全线瘫痪。 | 应用前一天的备份正本数据恢复，下载 binlog 日志按操作避开事发工夫点宰割后编译，导入数据，而后再修复事变之后的数据，共计耗时 48 小时。 |
5. 经营操作失误类
- 事变级别：P2
- 事变判责：网友说，金额太大没收回去！被喷了一会！
- 事变名称：经营把券配置成红包
- 事变景象：线上用户客诉，看到几百亿大的红包，领不到！
- 事变形容：经营人员配置优惠券，然而类型选成了红包，导致页面展现出超大额的红包金额待支付，都超出屏幕长度了！
- 事变解决：紧急下线流动，重新配置上线。同时产品设计需要，由研发人员实现对于此类配置提供明确、醒目的配置和残缺的审核流程。如果配置红包、优惠券，会有校验此券的是否存在以及红包最大金额限度。
- 学习总结：看上去是经营配置谬误，但从某个角度看其实也能够说是研发在做性能实现时，太过于繁多实现产品性能，而没有加深思考以及产品的易用性。有时候多问一句就少一个危险！
网友事变分享：
| 事变名称 | 事变形容 | 事变后果 |
|---|---|---|
| 业务破绽 | 业务乱配优惠券，能够叠加，超级优惠，而后被薅羊毛 | 部门帮着查羊毛记录，解决订单，挽回损失。而后对外发布告声称是被部门的风控系统误杀的。 |
| 贷款费率 | 经营配置 T + 1 日结算贷款费率谬误，导致用户贷款金额产生谬误。 | 上线新费率替换旧费率，曾经产生的费率谬误分割贷款用户修复。 |
| 多流动互斥 | 三个部门的都做流动，但最初导致反复发奖。一个用户邀请他人处分，变成了三份处分。 | 产品提供渠道和互斥性能，让经营本人抉择是否能够并行发放处分。 |
三、总结
- 讲道理，开发没事变，不是没用户体量，就是没用户规模。否则只有是人就肯定会呈现事变，要不是小 bug 被你匿影藏形暗藏了，或者是大事变被喷了或者送飞机了。
- 而尽可能减少事变的形式是须要尽可能依照肯定的研发流程来实现性能逻辑。就像：
设计评审，把控的是实现流程、代码评审，把控的是实现计划，在配合上欠缺的监控和报警。只有这样能力更少的缩小不必要的事变。 - 对于研发退职场中的事变本文就讲到这了，感激粉丝分享出本人的遇到的事变，让大家能够互相学习，缩小到职扣工资的危险。???? 多关注小傅哥，一个写有价值原创好文章的男人！
四、系列举荐
- 一次代码评审，差点过不了试用期！
- 握草，你居然在代码里下毒！
- 谁说今天上线，这货压根不晓得开发流程！
- 工作 3 年，看啥材料能月薪 30K？
- 90% 的程序员，都没用过多线程和锁，怎么成为架构师？
正文完
