这篇实习日志是1月9日的。写这些字的时候是晚上十点半我刚从公司出来坐在回住处的公交车上手机备忘录里已经码了满满一屏的草稿。今天一整天几乎没写什么新功能代码但我觉得是实习三周以来收获最大的一天上午独立排查了一个线上订单状态异常的事故下午第一次全程参与了自己的Code Review晚上又整理了一份以后每次排查问题都会用到的Bug记录模板。如果你也在实习或者马上要去实习这篇日志里的排查思路、评审被批的坑、日志写法大概率能帮你少走几步弯路。1. 晨会接手的陈年Bug已支付订单被定时任务误关1.1 事故背景与工单内容先说清楚我们组在做什么。组里维护的是电商后台的订单服务订单流转大概是这么一条线用户下单生成了待支付订单用户去支付支付渠道回调我们更新订单状态同时有个定时关单任务每天扫描超时未支付的订单把它们置为已关闭并释放库存。这条链路平时很稳但出问题的从来不是主链路而是主链路之间的状态同步缝隙。早上晨会组长把一个工单转到我名下。内容大致是某用户昨晚22点14分完成支付凌晨1点订单却被定时关单任务置为已关闭。订单被关闭后系统自动退还了优惠券用户今天一早发现非常不满。客服已经和支付渠道核实过扣款成功钱没丢问题锁定在我们订单服务的状态判断上。更麻烦的是这已经是第二次出现了上一次紧急修复后大家以为解决了结果今天又复发。1.2 为什么实习生会被点名接这个工单说实话当时我第一反应是这不该轮到实习生吧。入职三周我写的最复杂的代码也就是改个状态枚举、补两个单元测试日志平台都是上周才学会用的。但组长说了句话让我印象很深上次排查的同事把步骤都写进文档了你去照着走一遍走不通再叫人。这句话的潜台词是这次事故虽然级别高但排查路径已经被前人趟平了让我去跑一遍既是处理问题也是借这个真实案例练我。后来我发现这其实是带实习生最常见的套路把一条有确定答案的复杂路径交给你走练的是你走路的姿势而不是让你从零开路。1.3 接手后先做的三件事我没有直接去翻代码而是先按组里的规矩做了三件事。第一件读排查手册。上次同事留下的文档一共有三页记录了事故发生的时间段、涉及的服务名、日志查询方式以及他怀疑过的几个方向。虽然里面没写最终结论但至少帮我圈定了战场。第二件搭时间线。我打开日志平台先查了那个订单从创建到今天早上所有的关键事件按时间顺序列出来订单创建于20:02状态待支付22:14支付渠道回调成功数据库订单状态更新为已支付22:15系统下发支付成功通知然后01:00:03定时关单任务读取订单状态判断为待支付于是执行关闭操作释放库存退还优惠券01:00:08关闭动作完成状态落库为已关闭。这条时间线一列出来问题就非常清晰了关单任务在01:00读到的是待支付可数据库在22:15就已经是已支付了。也就是说任务读到的状态和数据库的真实状态不一致。要么是读取层的缓存出了问题要么是任务自己有一段本地状态判断要么是批量任务之间出现了串数据。下一步就是逐层验证这三种可能。2. 三个小时的离线排查从日志堆里把根因捞出来2.1 第一轮从关单任务日志入手确认读到了旧状态我先去翻关单任务的代码。任务逻辑不复杂扫描待支付订单对于每笔订单先查Redis里有没有订单状态缓存有就直接用缓存值判断没有再查数据库。为什么要加这层缓存因为关单任务每分钟跑一次如果每次都对数据库做全量查询压力很大所以上个季度的性能优化里引入了状态缓存缓存命中就直接跳过。查到这段逻辑之后我立刻去日志平台查01:00:03那一条日志。日志显示orderIdxxx, cacheHittrue, cachedStatus待支付, dbStatus已支付。关键信息来了——缓存命中了但缓存里的状态是待支付和数据库的已支付冲突。这就说明不是任务本身写错了而是任务在读一个过期的、错误的缓存。2.2 第二轮查支付回调日志发现回调根本没碰缓存那缓存里的待支付是怎么来的我带着这个疑问去查支付回调服务。按理说支付成功后服务应该做的事是更新数据库订单状态、清掉或更新Redis里的订单状态缓存、发消息通知下游。我翻了回调服务的代码发现它只做了两件事更新数据库、发消息。Redis里的状态缓存它压根没动。看到这里我大概有数了缓存的写入只发生在订单创建那一刻写入值是待支付写入时设了一个过期时间。如果这个过期时间足够短凌晨一点任务执行时缓存早就过期了就会走数据库查询读到已支付问题就不会发生。可现在缓存不仅没过期还准确命中了待支付说明这个Key的TTL被设得极长或者过期时间参数本身出了问题。顺着这个思路我去查了订单创建时的缓存写入代码。2.3 真正的根因把15分钟的过期时间写成了15天根因在三行代码里。订单创建服务在写完数据库后有一段这样的逻辑往Redis写订单状态缓存注释写着缓存15分钟防止关单任务频繁查库。但实际代码里调用Redis SDK时传的参数是15配合TimeUnit.DAYS——过期时间单位从分钟被改成了天。等于说这个缓存一旦写入15天后才会过期。这个改动是哪来的我查了提交历史发现是上周一次性能优化提交里某位同事想延长缓存时间以提升命中率把单位改成了天但注释和文档都没同步更新。更要命的是支付回调服务不清缓存这件事一直存在以前缓存15分钟过期最多只影响15分钟内的状态判断侥幸没出事改成15天后影响窗口被放大到两周事故就必然爆发了。这次能抓出来完全是因为我沿用了上一篇排查文档的步骤把缓存TTL也列进了检查清单。2.4 修复方案与验证过程修复分三步走每一步我都说下为什么。第一步先把订单创建服务的缓存过期时间改回15分钟用常量定义而不是裸数字比如ORDER_STATUS_CACHE_TTL_MINUTES 15并且注释写明为什么是15分钟而不是更长关单任务对状态实时性要求高缓存过长会放大状态不一致的窗口。第二步在支付回调服务里补上删除订单状态缓存的逻辑。这是治本的一步。缓存存在的意义是加速但状态一旦变化缓存就必须失效否则任何TTL都有可能是错的。第三步上线后验证。我写了一小段验证脚本创建一个测试订单等支付回调完成后立刻查Redis确认缓存Key不存在再等关单任务下一轮扫描确认它读到的是数据库里的已支付。两个检查点都过了我才敢把工单状态改成已修复。这一步也让我意识到修复线上问题不是改完代码就结束验证闭环才是真正结束的标志。3. 下午的Code Review我被自己的代码批了三处3.1 第一处魔法数字15分钟被写成了15上午修复完我提交了一个MR自认为逻辑清晰、注释也写了。下午组里例行Code Review我的MR第一次被拉出来完整过了一遍带教导师和另一个资深同事轮流发言结果我被批得体无完肤但心服口服。第一处是魔法数字。我在常量定义里写了ORDER_STATUS_CACHE_TTL 15但没写单位。资深同事直接问15是分钟还是秒还是小时我解释说是分钟他继续问那为什么是15不是10、不是30我答不上来因为我只是照搬之前的参数。正确做法是把单位也写进常量名比如ORDER_STATUS_CACHE_TTL_MINUTES 15再配一段注释说明这个值是从关单任务扫描频率状态实时性要求推导出来的任务每分钟扫一次15分钟意味着最多有15分钟的脏读窗口属于业务可以接受的范围如果改成1分钟数据库压力会增大一个量级。没有理由的参数review时一定会被问。3.2 第二处日志只有一句删除缓存等于没日志我原来的日志长这样logger.info(delete order status cache success)。带教导师问了我三个问题哪个订单删的哪个Key删的是Redis里的哪个namespace我一句话都答不上。他说你这条日志如果上线下次再出问题排查的人根本不知道是哪个订单、哪个Key、删没删成功只能重新查一遍支付流水。正确做法是把关键上下文全部带进日志订单号、缓存Key、删除前的TTL剩余值、删除结果甚至可以把根本原因也打进去。我顺手查了一下组里的日志规范发现我们用的日志框架支持结构化字段logger.info(delete cache, orderId, orderId, key, key, ttl, ttl, result, result)这种格式在日志平台里可以直接按字段筛选。原来我一直把日志当成证明程序跑过的东西这次之后才明白日志是写给未来的排查者看的上下文越全排查时间越短。3.3 第三处删缓存和更新数据库的顺序与失败兜底第三处批评最扎心。我在支付回调里写的顺序是先更新数据库再删除缓存。资深同事问如果删缓存失败怎么办程序会报错重试吗还是直接吞掉异常我说我加了try-catch失败就记日志。他摇摇头记日志等于没处理下次问题还会复现因为你没解决缓存残留。正确的思路是给这个操作设计一个失败兜底。常见做法有两种第一种先删缓存、再更新数据库如果更新失败下次查询会因为缓存不存在而回源数据库读到旧状态也没问题因为旧状态本来就是待支付不会产生错误关闭第二种如果先更新数据库再删缓存那删缓存失败就必须走重试机制或者依赖一个短暂的TTL让脏数据自然过期。结合我们这次事故最优雅的方案其实是删除缓存本身失败的概率很低但为了万无一失我给删除操作加上重试同时把缓存TTL保持在一个足够短的范围内两个手段互为兜底就算重试也失败了缓存最迟15分钟后也自然消失。Review结束后我把这三点全部改掉重写了版本重新过了Review。这次没人再挑毛病。4. 从第1篇到第9篇我的实习日志写法迭代4.1 一套四个板块的日志骨架说实话今天要不是为了写这篇实习日志我也不会回头去看之前的日志。但晚上复盘的时候我把第1篇到第8篇从头翻了一遍发现自己的写法经历了明显的变化前几篇全是流水账第5篇开始有了一点问题描述从第7篇开始才真正有认知。所以我想把现在这套用着最顺的骨架记下来给大家一个参考。我的日志现在固定分四块事实、问题、认知、计划。事实写今天具体完成了什么事做了哪几个任务改了什么文件必须可量化问题写今天卡住我的技术难点卡了多久最后怎么解决的解决思路是什么认知写今天推翻或建立的一个认知比如Cache不是永久正确的东西TTL就是脏读窗口计划写明天要做什么以及今天遗留的尾巴。这四个板块的顺序其实是按时间倒排的晨会立目标时我觉得今天是计划晚上写日志时事实已成定局问题是从事实里提炼出来的认知是从问题里沉淀的。写了一个星期之后我发现这种结构最大的好处是每篇日志都能变成一份可以被检索的记录而不是情绪垃圾桶。4.2 新手写日志最容易犯的三个毛病回看我自己和周围实习生的日志最容易犯三个毛病。第一个是记流水账。上午看了文档下午改了一个Bug晚上回家——这种日志写一百天也不会有什么成长因为你没有强迫自己回答为什么。第二个是只写情绪不写证据。今天被骂了很难受或者今天很有成就感——情绪是真实体验的一部分但日志的价值在于把情绪背后的具体事件写清楚不然第二天你自己都不知道当时为什么难受。第三个是只写结论不写过程。今天发现缓存过期时间设置错了已修复——这是最可惜的一种。排查过程才是最有价值的资产你是怎么一步步从日志定位到那三行代码的你怀疑过哪几个方向哪些方向被排除了这些一旦不写下次遇到类似问题你还是得从零开始。我中午刚被Review批的时候情绪很差差点在日志里只写被批评了以后注意。但晚上整理的时候我逼自己把三个批评点逐一写成了可以执行的动作立刻就觉得今天没有白挨批。4.3 日志的核心价值写给一个月后的自己最后说一个我到现在才想明白的事实习日志不是写给带教导师看的也不是用来证明我今天在干活的它是写给一个月后的自己的。人记性真的很差上周修过的Bug一周后看到相似代码可能完全想不起来当初是怎么解决的。我当时把上一篇排查文档当成救命稻草就是因为写文档的人认真留了过程我这周才能沿着走。我如果也想让未来的自己受益现在就该养成把过程留下来的习惯。这也是为什么这篇日志写得比前八篇长很多——今天的事件值得完整记录而记录本身就是一把钥匙以后类似的故障我不用再依赖别人自己翻日志就能快速进入状态。5. 今晚整理出的Bug排查记录模板附完整示例5.1 模板字段与填写要点因为今天的排查过程足够完整我晚上花了一个小时把之前随手记的排查笔记整理成了一份可复用的模板。以后不管接手什么工单我都打算按这个格式填大概长这样现象用户看到了什么复现环境能不能复现线上还是测试环境影响范围涉及订单数、用户数、时间窗口关键日志时间线事件时间、日志内容、涉及服务根因直接原因和更深层原因分开写修复动作每一步做了什么为什么这么做验证闭环怎么证明修好了复发性预防这类问题以后怎么避免再次发生每条字段为什么重要我简单说说。现象帮你和用户对焦复现环境决定你能不能在线调试影响范围决定处理优先级时间线是破案的主线根因如果不区分直接原因和深层原因很容易只修表象验证闭环是很多人漏掉的最后一步复发性预防则是把个人经验转化为团队资产的关键。5.2 今天这次事故按模板填出来长什么样拿今天的事故举个例子我填出来的版本是这样的现象用户已支付订单在凌晨被误关闭优惠券被系统退还。复现环境无法直接复现属于定时任务与支付回调时间窗口交叉触发只能通过日志复盘。影响范围本次共影响3笔订单时间窗口为过去两周内支付且在缓存过期前被关单任务扫描到的订单。关键日志时间线22:14支付回调成功数据库状态已更新01:00:03关单任务命中缓存读到待支付01:00:08状态落库为已关闭。根因直接原因是支付回调未清理订单状态缓存深层原因是订单创建时的缓存TTL单位被误改为天导致脏缓存存活时间从15分钟放大到15天。修复动作过期时间改回15分钟并常量化管理支付回调增加删除缓存逻辑删除失败增加重试。验证闭环测试订单支付后缓存Key不存在关单任务下一轮扫描读到数据库正确状态。复发性预防在订单状态变更处统一强制清缓存禁止任何服务绕过排查手册补充检查缓存TTL单位这一项。5.3 明天开始要做的三件事最后给明天的自己列个清单。第一件把这份模板同步给同组另外两个实习生让大家以后统一用这个格式记录工单排查这样即使休假或转岗经验也不会断。第二件和带教导师约一个十分钟的沟通想请他看看我下午Review重写后的代码确认我对事务边界和失败兜底的理解没有偏差。这算是我主动要的一次复查机会。第三件把今天学到的日志要带上下文这个原则应用到我所有旧代码里把之前写的那些山寨日志统一补上关键字段。这不是导师布置的任务但我知道日志早晚是要还的现在不补出事的时候补的成本更高。写到这儿公交快到站了。1月9日这一天我从一个只会按文档操作的实习生变成了一个大概知道为什么要这么查的人。明天还有新的任务但至少今天这篇实习日志我可以安心归档了。
这篇实习日志是1月9日的。写这些字的时候是晚上十点半我刚从公司出来坐在回住处的公交车上手机备忘录里已经码了满满一屏的草稿。今天一整天几乎没写什么新功能代码但我觉得是实习三周以来收获最大的一天上午独立排查了一个线上订单状态异常的事故下午第一次全程参与了自己的Code Review晚上又整理了一份以后每次排查问题都会用到的Bug记录模板。如果你也在实习或者马上要去实习这篇日志里的排查思路、评审被批的坑、日志写法大概率能帮你少走几步弯路。1. 晨会接手的陈年Bug已支付订单被定时任务误关1.1 事故背景与工单内容先说清楚我们组在做什么。组里维护的是电商后台的订单服务订单流转大概是这么一条线用户下单生成了待支付订单用户去支付支付渠道回调我们更新订单状态同时有个定时关单任务每天扫描超时未支付的订单把它们置为已关闭并释放库存。这条链路平时很稳但出问题的从来不是主链路而是主链路之间的状态同步缝隙。早上晨会组长把一个工单转到我名下。内容大致是某用户昨晚22点14分完成支付凌晨1点订单却被定时关单任务置为已关闭。订单被关闭后系统自动退还了优惠券用户今天一早发现非常不满。客服已经和支付渠道核实过扣款成功钱没丢问题锁定在我们订单服务的状态判断上。更麻烦的是这已经是第二次出现了上一次紧急修复后大家以为解决了结果今天又复发。1.2 为什么实习生会被点名接这个工单说实话当时我第一反应是这不该轮到实习生吧。入职三周我写的最复杂的代码也就是改个状态枚举、补两个单元测试日志平台都是上周才学会用的。但组长说了句话让我印象很深上次排查的同事把步骤都写进文档了你去照着走一遍走不通再叫人。这句话的潜台词是这次事故虽然级别高但排查路径已经被前人趟平了让我去跑一遍既是处理问题也是借这个真实案例练我。后来我发现这其实是带实习生最常见的套路把一条有确定答案的复杂路径交给你走练的是你走路的姿势而不是让你从零开路。1.3 接手后先做的三件事我没有直接去翻代码而是先按组里的规矩做了三件事。第一件读排查手册。上次同事留下的文档一共有三页记录了事故发生的时间段、涉及的服务名、日志查询方式以及他怀疑过的几个方向。虽然里面没写最终结论但至少帮我圈定了战场。第二件搭时间线。我打开日志平台先查了那个订单从创建到今天早上所有的关键事件按时间顺序列出来订单创建于20:02状态待支付22:14支付渠道回调成功数据库订单状态更新为已支付22:15系统下发支付成功通知然后01:00:03定时关单任务读取订单状态判断为待支付于是执行关闭操作释放库存退还优惠券01:00:08关闭动作完成状态落库为已关闭。这条时间线一列出来问题就非常清晰了关单任务在01:00读到的是待支付可数据库在22:15就已经是已支付了。也就是说任务读到的状态和数据库的真实状态不一致。要么是读取层的缓存出了问题要么是任务自己有一段本地状态判断要么是批量任务之间出现了串数据。下一步就是逐层验证这三种可能。2. 三个小时的离线排查从日志堆里把根因捞出来2.1 第一轮从关单任务日志入手确认读到了旧状态我先去翻关单任务的代码。任务逻辑不复杂扫描待支付订单对于每笔订单先查Redis里有没有订单状态缓存有就直接用缓存值判断没有再查数据库。为什么要加这层缓存因为关单任务每分钟跑一次如果每次都对数据库做全量查询压力很大所以上个季度的性能优化里引入了状态缓存缓存命中就直接跳过。查到这段逻辑之后我立刻去日志平台查01:00:03那一条日志。日志显示orderIdxxx, cacheHittrue, cachedStatus待支付, dbStatus已支付。关键信息来了——缓存命中了但缓存里的状态是待支付和数据库的已支付冲突。这就说明不是任务本身写错了而是任务在读一个过期的、错误的缓存。2.2 第二轮查支付回调日志发现回调根本没碰缓存那缓存里的待支付是怎么来的我带着这个疑问去查支付回调服务。按理说支付成功后服务应该做的事是更新数据库订单状态、清掉或更新Redis里的订单状态缓存、发消息通知下游。我翻了回调服务的代码发现它只做了两件事更新数据库、发消息。Redis里的状态缓存它压根没动。看到这里我大概有数了缓存的写入只发生在订单创建那一刻写入值是待支付写入时设了一个过期时间。如果这个过期时间足够短凌晨一点任务执行时缓存早就过期了就会走数据库查询读到已支付问题就不会发生。可现在缓存不仅没过期还准确命中了待支付说明这个Key的TTL被设得极长或者过期时间参数本身出了问题。顺着这个思路我去查了订单创建时的缓存写入代码。2.3 真正的根因把15分钟的过期时间写成了15天根因在三行代码里。订单创建服务在写完数据库后有一段这样的逻辑往Redis写订单状态缓存注释写着缓存15分钟防止关单任务频繁查库。但实际代码里调用Redis SDK时传的参数是15配合TimeUnit.DAYS——过期时间单位从分钟被改成了天。等于说这个缓存一旦写入15天后才会过期。这个改动是哪来的我查了提交历史发现是上周一次性能优化提交里某位同事想延长缓存时间以提升命中率把单位改成了天但注释和文档都没同步更新。更要命的是支付回调服务不清缓存这件事一直存在以前缓存15分钟过期最多只影响15分钟内的状态判断侥幸没出事改成15天后影响窗口被放大到两周事故就必然爆发了。这次能抓出来完全是因为我沿用了上一篇排查文档的步骤把缓存TTL也列进了检查清单。2.4 修复方案与验证过程修复分三步走每一步我都说下为什么。第一步先把订单创建服务的缓存过期时间改回15分钟用常量定义而不是裸数字比如ORDER_STATUS_CACHE_TTL_MINUTES 15并且注释写明为什么是15分钟而不是更长关单任务对状态实时性要求高缓存过长会放大状态不一致的窗口。第二步在支付回调服务里补上删除订单状态缓存的逻辑。这是治本的一步。缓存存在的意义是加速但状态一旦变化缓存就必须失效否则任何TTL都有可能是错的。第三步上线后验证。我写了一小段验证脚本创建一个测试订单等支付回调完成后立刻查Redis确认缓存Key不存在再等关单任务下一轮扫描确认它读到的是数据库里的已支付。两个检查点都过了我才敢把工单状态改成已修复。这一步也让我意识到修复线上问题不是改完代码就结束验证闭环才是真正结束的标志。3. 下午的Code Review我被自己的代码批了三处3.1 第一处魔法数字15分钟被写成了15上午修复完我提交了一个MR自认为逻辑清晰、注释也写了。下午组里例行Code Review我的MR第一次被拉出来完整过了一遍带教导师和另一个资深同事轮流发言结果我被批得体无完肤但心服口服。第一处是魔法数字。我在常量定义里写了ORDER_STATUS_CACHE_TTL 15但没写单位。资深同事直接问15是分钟还是秒还是小时我解释说是分钟他继续问那为什么是15不是10、不是30我答不上来因为我只是照搬之前的参数。正确做法是把单位也写进常量名比如ORDER_STATUS_CACHE_TTL_MINUTES 15再配一段注释说明这个值是从关单任务扫描频率状态实时性要求推导出来的任务每分钟扫一次15分钟意味着最多有15分钟的脏读窗口属于业务可以接受的范围如果改成1分钟数据库压力会增大一个量级。没有理由的参数review时一定会被问。3.2 第二处日志只有一句删除缓存等于没日志我原来的日志长这样logger.info(delete order status cache success)。带教导师问了我三个问题哪个订单删的哪个Key删的是Redis里的哪个namespace我一句话都答不上。他说你这条日志如果上线下次再出问题排查的人根本不知道是哪个订单、哪个Key、删没删成功只能重新查一遍支付流水。正确做法是把关键上下文全部带进日志订单号、缓存Key、删除前的TTL剩余值、删除结果甚至可以把根本原因也打进去。我顺手查了一下组里的日志规范发现我们用的日志框架支持结构化字段logger.info(delete cache, orderId, orderId, key, key, ttl, ttl, result, result)这种格式在日志平台里可以直接按字段筛选。原来我一直把日志当成证明程序跑过的东西这次之后才明白日志是写给未来的排查者看的上下文越全排查时间越短。3.3 第三处删缓存和更新数据库的顺序与失败兜底第三处批评最扎心。我在支付回调里写的顺序是先更新数据库再删除缓存。资深同事问如果删缓存失败怎么办程序会报错重试吗还是直接吞掉异常我说我加了try-catch失败就记日志。他摇摇头记日志等于没处理下次问题还会复现因为你没解决缓存残留。正确的思路是给这个操作设计一个失败兜底。常见做法有两种第一种先删缓存、再更新数据库如果更新失败下次查询会因为缓存不存在而回源数据库读到旧状态也没问题因为旧状态本来就是待支付不会产生错误关闭第二种如果先更新数据库再删缓存那删缓存失败就必须走重试机制或者依赖一个短暂的TTL让脏数据自然过期。结合我们这次事故最优雅的方案其实是删除缓存本身失败的概率很低但为了万无一失我给删除操作加上重试同时把缓存TTL保持在一个足够短的范围内两个手段互为兜底就算重试也失败了缓存最迟15分钟后也自然消失。Review结束后我把这三点全部改掉重写了版本重新过了Review。这次没人再挑毛病。4. 从第1篇到第9篇我的实习日志写法迭代4.1 一套四个板块的日志骨架说实话今天要不是为了写这篇实习日志我也不会回头去看之前的日志。但晚上复盘的时候我把第1篇到第8篇从头翻了一遍发现自己的写法经历了明显的变化前几篇全是流水账第5篇开始有了一点问题描述从第7篇开始才真正有认知。所以我想把现在这套用着最顺的骨架记下来给大家一个参考。我的日志现在固定分四块事实、问题、认知、计划。事实写今天具体完成了什么事做了哪几个任务改了什么文件必须可量化问题写今天卡住我的技术难点卡了多久最后怎么解决的解决思路是什么认知写今天推翻或建立的一个认知比如Cache不是永久正确的东西TTL就是脏读窗口计划写明天要做什么以及今天遗留的尾巴。这四个板块的顺序其实是按时间倒排的晨会立目标时我觉得今天是计划晚上写日志时事实已成定局问题是从事实里提炼出来的认知是从问题里沉淀的。写了一个星期之后我发现这种结构最大的好处是每篇日志都能变成一份可以被检索的记录而不是情绪垃圾桶。4.2 新手写日志最容易犯的三个毛病回看我自己和周围实习生的日志最容易犯三个毛病。第一个是记流水账。上午看了文档下午改了一个Bug晚上回家——这种日志写一百天也不会有什么成长因为你没有强迫自己回答为什么。第二个是只写情绪不写证据。今天被骂了很难受或者今天很有成就感——情绪是真实体验的一部分但日志的价值在于把情绪背后的具体事件写清楚不然第二天你自己都不知道当时为什么难受。第三个是只写结论不写过程。今天发现缓存过期时间设置错了已修复——这是最可惜的一种。排查过程才是最有价值的资产你是怎么一步步从日志定位到那三行代码的你怀疑过哪几个方向哪些方向被排除了这些一旦不写下次遇到类似问题你还是得从零开始。我中午刚被Review批的时候情绪很差差点在日志里只写被批评了以后注意。但晚上整理的时候我逼自己把三个批评点逐一写成了可以执行的动作立刻就觉得今天没有白挨批。4.3 日志的核心价值写给一个月后的自己最后说一个我到现在才想明白的事实习日志不是写给带教导师看的也不是用来证明我今天在干活的它是写给一个月后的自己的。人记性真的很差上周修过的Bug一周后看到相似代码可能完全想不起来当初是怎么解决的。我当时把上一篇排查文档当成救命稻草就是因为写文档的人认真留了过程我这周才能沿着走。我如果也想让未来的自己受益现在就该养成把过程留下来的习惯。这也是为什么这篇日志写得比前八篇长很多——今天的事件值得完整记录而记录本身就是一把钥匙以后类似的故障我不用再依赖别人自己翻日志就能快速进入状态。5. 今晚整理出的Bug排查记录模板附完整示例5.1 模板字段与填写要点因为今天的排查过程足够完整我晚上花了一个小时把之前随手记的排查笔记整理成了一份可复用的模板。以后不管接手什么工单我都打算按这个格式填大概长这样现象用户看到了什么复现环境能不能复现线上还是测试环境影响范围涉及订单数、用户数、时间窗口关键日志时间线事件时间、日志内容、涉及服务根因直接原因和更深层原因分开写修复动作每一步做了什么为什么这么做验证闭环怎么证明修好了复发性预防这类问题以后怎么避免再次发生每条字段为什么重要我简单说说。现象帮你和用户对焦复现环境决定你能不能在线调试影响范围决定处理优先级时间线是破案的主线根因如果不区分直接原因和深层原因很容易只修表象验证闭环是很多人漏掉的最后一步复发性预防则是把个人经验转化为团队资产的关键。5.2 今天这次事故按模板填出来长什么样拿今天的事故举个例子我填出来的版本是这样的现象用户已支付订单在凌晨被误关闭优惠券被系统退还。复现环境无法直接复现属于定时任务与支付回调时间窗口交叉触发只能通过日志复盘。影响范围本次共影响3笔订单时间窗口为过去两周内支付且在缓存过期前被关单任务扫描到的订单。关键日志时间线22:14支付回调成功数据库状态已更新01:00:03关单任务命中缓存读到待支付01:00:08状态落库为已关闭。根因直接原因是支付回调未清理订单状态缓存深层原因是订单创建时的缓存TTL单位被误改为天导致脏缓存存活时间从15分钟放大到15天。修复动作过期时间改回15分钟并常量化管理支付回调增加删除缓存逻辑删除失败增加重试。验证闭环测试订单支付后缓存Key不存在关单任务下一轮扫描读到数据库正确状态。复发性预防在订单状态变更处统一强制清缓存禁止任何服务绕过排查手册补充检查缓存TTL单位这一项。5.3 明天开始要做的三件事最后给明天的自己列个清单。第一件把这份模板同步给同组另外两个实习生让大家以后统一用这个格式记录工单排查这样即使休假或转岗经验也不会断。第二件和带教导师约一个十分钟的沟通想请他看看我下午Review重写后的代码确认我对事务边界和失败兜底的理解没有偏差。这算是我主动要的一次复查机会。第三件把今天学到的日志要带上下文这个原则应用到我所有旧代码里把之前写的那些山寨日志统一补上关键字段。这不是导师布置的任务但我知道日志早晚是要还的现在不补出事的时候补的成本更高。写到这儿公交快到站了。1月9日这一天我从一个只会按文档操作的实习生变成了一个大概知道为什么要这么查的人。明天还有新的任务但至少今天这篇实习日志我可以安心归档了。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
