大家好，我是君哥。
最近我担任的系统出了一次性消费意外，这次意外居然是由于流水号重复造成的。当天来给大家分享一下。
这个流水号的经常使用场景是抢先系统调用下游接口时传入一个惟一 ID，流水号这个参数在联调或定位疑问时很繁难。
咱们系统中的流水号是一个 32 位的字符串，为了能让高低游系统联动，下游系统接到抢先传上来的这个 ID 后，会取前 23 位，再自己拼接剩下 9 位，传到自己要调用的下游系统，这样整个调用链经过恳求 ID 就可以极速串起来。
在我的系统中，自己定义流水号的后 9 位，为了能够更明晰地从流水号中看到恳求链上的系统调用相关，咱们把流水号后 9 位定义成了系统编号(3位) + 子系统编号(2位) + 自增序列(4 位) 。
如下图，我的系统生成的流水号前 23 位来自抢先，后 9 位是 001(系统编码) + 01(子系统编码) + (0 ~ 9999自增)。
在咱们的业务场景中，抢先系统调用我的系统，我的系统有 10000 个流水号，撑持 10000 笔买卖，通常上足够经常使用了。
可怜的，系统中的业务开发共事并没有留意到流水号生成规则，由于流水号生成工具是一个成熟的 util 类，大家间接调用失掉流水号。
而这一次性的意外中，咱们的业务是一个批量业务，收到抢先系统的恳求后，咱们的处置逻辑是读取协作方推送的文件，而后对每一个文件调用下游接口启动处置。每一个文件处置要求调用下游四个接口，每一个接口都要求新的流水号。
这样咱们就能看到流水号生成工具的瓶颈了，假设超越 2500 个文件，10000 个流水号就会被用完。而流水号生成工具的逻辑是假设流水号用完，就会从 0 开局重重生成，形成了流水号重复。
下游系统会对流水号启动判别，收到重复的流水号，间接前往接口调用失败。由于失败的调用比拟多，触发了消费告警。
比拟庆幸的是，这次意外并没有形成买卖阻断、现金损失、客户体验差等疑问。还有一点幸运是正好赶在上线窗口前发现了，没有走紧急上线流程。要知道，紧急上线对团队和团体的绩效考核都会发生影响。
但买卖失败的三方文件会影响合规审核，必需启动买卖补救。
咱们团队做的修停任务是及时修正了流水号生成规则，咱们把前面 6 为定义成自增的序列，这样足够满足一切场景的经常使用了，而咱们保管系统编码，对系统买卖链路追踪是十分必要的。
上线后，请抢先系统再次触发接口调用，对之前失败的三方文件启动补救处置。
无论在国企、银行还是互联网公司任务，消费意外的出现，都或许会影响到公司反常业务的展开，甚至让业务遭受损失。重大的，意外当事人会收到严厉处分，甚至被淘汰掉。
除了对考核的影响，处置缺点的环节也是十分耗时的。
在没有定位到疑问之前，必需先采取紧急措施接触消费告警，免得形成大的业务损失。应急措施包含但不限于重启服务、口头应急脚本、业务升级等。
驳回应急手腕处置缺点后，就要开局定位疑问了。有的疑问或许不太好定位，尤其是一些老代码，作者曾经离任，也没有留下什么具体的文档。接手人或许之前看过代码，然而过了很长期间又记不清了。
再复杂的疑问，最终必需能定位到要素。接着就是评价业务影响，这一步也是必要求做的，由于少数状况下，对业务的影响大小选择了这次意外的级别，这项任务普通会有业务介入。
比如我过往的一家公司规则，缺点超越 15 分钟，影响超越 100 笔订单的缺点定义为一级缺点。
接着就是给指导汇报，甚至要求层层汇报。这一步可以说是最难做的。
首先要求明白疑问责任人或许责任团队，由于缺点或许会影响到绩效考核，所以很多时刻会遇到扯皮或帅锅的状况，没有一个指导情愿让自己的团队背锅。有时刻把锅甩给两边件，数据库或其余底层组件，也是一个选用。
撰工笔外报告也是十分耗时的一个任务，指导无法能像技术人员一样经过看代码了解意外要素，他们要求缺点报告能够明晰易懂，甚至几句话就能讲明白。
意外复盘是为了让团队能够了解到缺点的基本要素，作为阅历经验，防止再犯。
当蠢才享了我在任务中遇到的一次性消费意外。消费意外除了影响业务反常运行，处置意外的环节也是十分破费期间和精神的。齐全不出意外是无法能的，假设能对历史缺点吸取经验，多花心理钻研自己的系统，可以有效降落缺点率。