作者： rydbl
博客： https://bugstack.cn
沉淀、分享、成长，让自己和他人都能得到！
目录一、前言
二.研发事故
1 .功能流设计类
2 .技术方案实现班
3 .技术服务使用班
4 .后门违章操作类
5 .运用错误类
三.总结
四.系列推荐
一、前言你的代码出事故了吗？
老人说：没有鞋子总是在河边走不湿。 只要你从事编程开发工作，就一定会遇到事故。 或大或小。
当然，一些研发同学可能很难遇到著名的事故，比如比较传统的行业和用户体量比较小的业务。 很多是在线上的小bug，修复后谁也听不见。
但是，如果您位于大型互联网公司，则开发的系统功能可能面临数百万和数千万个用户卷。 只要你有一点小bug就会迅速扩大，引起大量索赔和更严重的资金损失风险。 就像这样：
“薅羊毛”事件频发，朋友圈疯狂转发。
昨天，一个严重的在线bug，一级事故，疑似程序员故意埋雷。 您的程序是内部测试版本，将在当地时间2020-03-28到期。 过期后将无法使用，请尽快下载最新版本。
GitHub忘记更新SSL证书，导致网站排版混乱，一些网站无法正常打开。
由于技术流程、方案实现、技术服务和运营配置等原因，可能会发生此类事故。 综合起来可以归纳为以下几点。
功能流程设计类：通常是指研发在设计产品逻辑功能实现流程时，意外执行调用关系而导致的风险事故。
技术实现类：对流程进行研发设计后，各功能点的实现方案因人而异，有时理解不准，有时缺乏对实现过程中代码执行过程中健壮性的评价。
技术服务使用类：该类用于开发和使用数据库服务、缓存服务、大数据服务、配置中心服务、在线服务等时，对各项服务的配置和使用缺乏一定的了解而发生的事故
后门操作班：这个班是否存在这样的风险，因为公司对研发规范的执行强度不同。 例如，一些研发同学会正在开发一个后门程序，可以在某个ERP页面上执行数据库语句，并临时修改数据。 这种风险通常是后门违章操作，有开除风险。
操作错误类别：在研发中，一些公司内部的合作伙伴认为使用研发同学开发的操作系统进行活动配置、用户变更、流程执行等操作，但一般来说，这类系统缺乏一定的强规则验证通常，这种情况会发生，例如在线配置错误的卷，或者向用户推送错误的消息。
可以说很多愚蠢的事故主要是个人责任感的问题。 但是，技术性事故，值得一试。 公司讨厌你出事故，但会给公司带来损害哦。 但是这样有技术含量的事故对你的个人成长是一个非常好的案例。 但是，戒酒可以，但不能贪杯！
接下来，rydbl带你体验各种事故风采，在什么场景，遇到什么问题，怎么解决，能学到什么！
二、研发事故1 .功能流程设计类
事故等级： P1
事故判定责任：集中播放相应的研发、测试，罚款50元给参加会议的合伙人买棒棒糖示警。
事故名称：抽奖积分支付流程不合理
事故现象：用户积分支付较多，引起大量索赔，当日紧急排查修复，为用户补分。
事故说明：该产品的功能背景可能是大部分研发都参与过开发。 简而言之，就是满足用户使用积分抽奖的需求。 上图左侧是研发的第一个流程，从RPC界面扣除用户积分，扣除成功后进行抽签。 但是，由于当天的RPC服务不稳定，RPC的实际调用成功，但返回超时失败。 另一方面，调用RPC接口的uuid每次自动生成，不具有幂等性。 所以，引起了用户积分多支付的现象。
事故处理：事故发生后修改抽签流程，老师成为等待抽签的抽选单，从抽选单ID中调用RPC接口，保证接口幂等性。 在RPC接口失败的情况下，以定时任务得到补偿的方式执行抽签。 过程改进后证明，补偿任务每周发生1~3次，即RPC接口存在可用率问题，也表明以前就存在过程问题，但由于用户投诉少，没有反馈。
学习总结：调用的界面、发送的MQ，不一定每次都成功。 那么，必须做好幂等性和失败后的补偿，使整个技术实现过程更加完善。 正如rydbl所说，擦屁股的纸的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被你销声匿迹隐藏了，或者是大事故被喷了或者送飞机了。
而尽可能减少事故的方式是需要尽可能按照一定的研发流程来实现功能逻辑。就像：设计评审，把控的是实现流程、代码评审，把控的是实现方案，在配合上完善的监控和报警。只有这样才能更少的减少不必要的事故。
关于研发在职场中的事故本文就讲到这了，感谢粉丝分享出自己的遇到的事故，让大家可以互相学习，减少离职扣工资的风险。????多关注rydbl，一个写有价值原创好文章的男人！
PS：如果觉得我的分享不错，欢迎大家随手点赞、在看。