1.前言你的代码出过事故吗？老人说：常在河边走，怎能不湿鞋。只要是做编程和开发的工作，就一定会遇到或大或小的意外。当然，可能还有一些R&D同学，他们是比较传统的行业，或者是做业务的，用户基数不大。难遇有名事故。大多数都是线上的小bug，没有人能修复。问。但是如果你在更大的互联网公司，那么你负责开发的系统功能可能面对的是几百万、几千万的用户。即使你有一个小错误，它也会被迅速放大，导致大量客户投诉和更严重的财务损失风险。就像：拼多多“扫羊毛”事件在朋友圈被疯狂转发。昨天淘宝发现线上重大bug，S1级事故，疑似程序员故意埋地雷。您使用的程序为内测版，将于当地时间2020-03-28到期，到期后将无法使用，请尽快下载最新版本。GitHub忘记更新SSL证书，导致网站布局混乱，部分网站无法正常打开。此类事故可能是由于技术流程、方案实现、技术服务、运营配置等原因造成的。综合可归纳为以下几点：图19-1事故类型汇总功能流程设计类：通常指研发设计产品在实现逻辑功能过程中，因错误执行调用关系而导致的风险事故.技术方案实现类：在开发设计过程之后，每个功能点的实现方案会因人而异，由于理解偏差或理解不足，实现过程缺乏对运行时代码健壮性的评估.技术服务使用类：该类是指在开发和使用数据库服务、缓存服务、大数据服务、配置中心服务、发布在线服务时，对各种服务的配置和使用缺乏一定的了解，导致发生事故。后门违规操作类别：该类别取决于公司对研发规范的执行情况，是否存在此类风险。比如：有的R&D同学会开发一些后门程序，比如在ERP页面执行数据库语句，临时修改数据。由此带来的风险通常是非法操作后门，存在被驱逐的风险。操作失误：在研发中，我觉得公司里有些小伙伴会使用研发同学开发的操作系统来配置活动，改变用户，执行流程等操作，但一般来说，这样的系统缺乏一定的强规则验证，导致操作新手在操作过程中产生风险，导致事故发生。一般是网上配置错误的音量，或者给用户发送错误的短信等等，都会出现这种情况。可以说，大多数愚蠢的事故主要是个人责任问题。但对于那些有技术含量的事故，犯一次还是值得的。虽然公司很讨厌你出事，因为会给公司带来损失！但是这样一个有技术含量的意外，对于你的个人成长来说，是一个非常好的案例。不过禁制虽好，可不要贪多了！接下来付哥就带大家领略各种事故的风采，看看你遇到了什么场景，遇到了什么问题，如何解决，能学到什么！二、研发事故1、功能流程设计图19-2功能流程设计事故事故等级：P1事故判定：相应的研发和测试总结审核，对参赛伙伴购买棒棒糖罚款50元警告。事件名称：彩票积分支付流程不合理。事件现象：超额支付用户积分导致大量客户投诉。当天紧急检修，为用户补充积分。事故描述：该产品功能的后台可能参与了很大一部分的研发。简单来说，就是满足用户使用积分抽奖的需求。上图左侧是研发初期的设计流程。通过RPC接口扣除用户积分，扣除成功后进行抽奖。但是由于当天RPC服务不稳定，实际RPC调用成功，但是返回超时失败。每次调用RPC接口的uuid都是自动生成的，不具备调用的幂等性。因此，造成了用户积分多付的现象。事故处理：事故发生后修改开奖流程，先生成一张待开奖的彩票，从彩票ID调用RPC接口，保证接口的幂等性。当RPC接口失效时，通过定时任务补偿的方式进行抽奖。流程整改后，发现补偿任务每周出现1-3次，证明RPC接口确实存在可用性问题，也说明很早以前就有流程问题，但是现在没有反馈，因为很少有客户投诉。学习总结：调用的接口和发送的MQ不一定每次都成功。那么就要做好幂等性和失败后的补偿，让整个技术实现过程更加完善。就像小傅说的，擦屁股的纸有80%的面积，其实是为了保护双手！网友事故分享：二、技术方案实施类图19-3技术方案实施事故事故等级：P0事故判断：营销活动用户多，影响范围大。研究制定整改规范并进行审查。事件名称：秒杀计划独家竞争实施问题事件现象：用户看到就买，但一下单就活动太火爆。试试另一只小手。引发大量客诉，紧急调查线下活动。事故描述：本次商品闪购的实现方案初步设计是基于一个活动号ID进行锁定，在闪购时锁定，用户购买完成后释放。但是，当大量用户抢购时，秒杀分布式锁后的业务逻辑处理出现异常，锁释放失败。这样一来，所有的用户都无法再拿到锁，也就造成了有货不能下单的问题。问题排查：优化独占竞争状态为分段静态，使用活动ID+库存号作为动态锁标识。如果当前秒杀用户锁定失败，后续用户可以继续秒杀，不受影响。出现故障的锁会由工作人员进行补偿和回收，最终避免出现锁超卖和卖不出去的情况。学习总结：核心技术的落地需要经过大量的数据验证和压力测试，否则很难评估每个场景是否存在风险。当然，这不是唯一的实现方案，可以根据不同的场景进行不同的实现。网友事故分享：3.技术服务使用示意图19-4技术服务使用事故事故等级：P2事故判断：网友表示被抓了一会儿，问题不大！事件名称：扩容时忽略了连接池，导致连接池已满。事件现象：突然在线收到报警信息，打开电脑查看，简单查询界面超时，3分钟后返回。事故描述：幸运的是，监控和报警都已满载，及时收到报警信息。联系DBA查看后，发现是连接池满了。为了快速解决线上告警，临时扩大了连接池，先重启了服务。经过观察，连接池满了消失了。故障处理：检查应用数据库连接池的配置，检查不经常在线的附加服务。查询后发现所有应用的连接池最大配置超过了数据库分配的连接池数量。特别是定时任务扫描数据库的时间比较长，是直接导致连接池爆满的重要原因。学习总结：研发不仅仅是代码开发和实体人员，更重要的是对配套服务的理解和熟悉。合理使用，综合考虑，可以避免一些看似不应该发生的事故。网友事故分享：4.后门非法运行示意图19-5后门非法运行事故等级事故等级：P0事故判断：网友反馈，私自开发后门，sql执行错误，影响较大。火！事件名称：通过后门程序修改在线数据事件现象：本次修改的影响小于预期。由于缓存失效，只读取了部分数据，读取了数据库的活动信息。全是小部分顾客投诉活动与名字不符。事故描述：研发人员应运营要求修改在线配置错误的活动名称，但任何邮件记录并经负责人批准。所以自己只是通过后门程序私自开发并提交了sql语句修改，却忘了写where条件，导致同时修改了上千个activity名称。事故处理：事件发生后，紧急联系DBA通过binlog日志恢复数据。学习总结：研发人员应避免对在线数据进行操作，尤其是更改数据类。请勿开发更改数据、上线、上传配置文件等各种后门程序。相反，应严格遵守研发流程，紧急事项需报批。网友事故分享：5.操作失误示意图19-6操作失误事故事故等级：P2事故判断：网友表示金额太大，不能发！被喷了一会儿！事件名称：操作将优惠券配置为红包事件现象：网上用户投诉收不到百亿红包！事故描述：运营商配置了优惠券，但类型选择为红包，导致页面显示大量待领取红包，超过屏幕长度！事件处理：紧急线下活动，线上重构。同时，研发人员落实产品设计要求，提供清晰醒目的配置，以及完整的配置审核流程。如果你配置了红包和优惠券，会有检查优惠券是否存在和红包的最大数量限制。学习总结：好像是操作配置不对，但是从某种角度来说，也可以说是研发在做功能实现的时候，过于简单的完成了产品功能，没有进一步的考虑和易用性产品的使用。有时多一个问题意味着少一个风险！网友意外分享：3、总结，讲道理。发展没有意外，要么是没有用户量，要么是没有用户规模。不然只要你是人，就会有意外发生，要不是小虫子被你藏起来，要不就是大的意外被喷了或者送上了飞机。尽可能减少事故的方法就是尽可能按照一定的研发流程来实现功能逻辑。就像：设计审查，控制是实施过程，代码审查，控制是实施方案，配合完善监控报警。只有这样，才能减少不必要的事故。职场研发事故的这篇文章到此结束。感谢粉丝分享自己的意外，让大家互相学习，减少离职后被扣薪的风险。多多关注小傅，一个写出有价值的原创文章的人！
