《代码之外程序员重启人生》· 第07篇上一世系统正在不断扣错用户余额。所有人却忙着证明出问题的代码不是自己写的。等责任终于查清事故已经扩大了十倍。周四晚上八点零七分。林川刚走出地铁站手机突然连续震动。第一条是监控告警积分账户扣减失败率超过15%。第二条来自客服群多名用户反馈兑换失败但积分已经被扣除。第三条来自项目经理周凯所有人立即进事故群线上出问题了。林川停在路边打开监控面板。兑换请求量没有明显上涨。数据库连接正常。第三方优惠券接口成功率也在正常区间。但积分扣减接口出现了一种非常奇怪的现象同一个兑换请求在第一次调用超时后会自动重试。第二次请求返回成功。可第一次请求实际上也已经在数据库中完成了扣减只是响应没有及时返回。结果是用户只兑换了一次商品积分却可能被扣两次。林川继续查看日志。八点零九分。异常订单17笔。八点十分。异常订单31笔。八点十一分。异常订单已经增加到54笔。每过一分钟都有新的用户受到影响。他立刻进入事故群。此时群里已经有二十多人。消息不断刷新。产品经理这是刚上线的兑换重试功能导致的吗测试负责人测试环境没有复现过重复扣减。赵明我负责的订单模块没有直接操作积分。前端同事前端只提交了一次请求浏览器日志可以证明。运维服务器和数据库目前都正常不像基础设施问题。周凯发出一条消息这段重试代码是谁改的群里突然安静了几秒。随后赵明回复重试框架不是我写的我只调整了订单状态。另一名后端说积分接口是林川之前负责的但这次版本不是我发布的。测试负责人说我们按照产品提供的用例全部测过应该是开发实现问题。产品经理说需求里明确写了失败后允许重试但没有要求重复扣积分。所有人都在证明自己不属于事故源头。没有人问现在异常还在继续吗林川看了一眼监控。异常订单已经达到73笔。上一世也是同样的晚上。也是同样的问题。事故群里所有人花了二十多分钟争论谁提交了代码谁做了代码评审测试为什么没发现产品需求是否写清楚运维发布是否有问题直到八点三十六分才有人提出要不要先把兑换入口关掉那时已经有四百多名用户积分异常。客服开始接到大量投诉。运营不得不暂停整个积分商城。后续数据核对、积分返还和用户补偿持续了整整三天。事故复盘会上所有人都说当时群里太乱没有人统一指挥。可真正的原因不是没人指挥。而是事故发生后的第一个问题就问错了。系统正在流血。大家第一时间想的却不是止血。而是谁先开的第一枪。这一世林川没有回答代码是谁写的。他直接在事故群里发了一句话先停止新增损失责任后面再查。立即执行一级止损。一、事故发生时最贵的不是Bug而是所有人都在等待别人负责周凯很快回复什么叫一级止损先确认是不是代码问题。林川没有和他争论。直接列出操作项前端关闭积分兑换入口。网关暂停兑换创建接口只保留订单查询。停止失败订单自动重试任务。暂停积分扣减消费队列。保留当前日志、消息和数据库快照。已经成功兑换的订单不做批量回滚等待核对。周凯问直接关闭入口会不会影响业务活动林川回答当前每分钟新增约20笔异常。继续运行十分钟预计新增200笔以上。关闭入口会造成短期无法兑换不关闭会持续产生真实用户损失。业务负责人很快说道先关闭。林川立即前端负责人两分钟内关闭入口完成后回复时间。运维网关禁用创建接口保留查询接口完成后回复时间。赵明暂停订单重试任务不删除任务数据。积分模块负责人暂停积分扣减消费者保留消息积压。每一项操作都有明确负责人。没有使用大家赶紧处理一下。也没有说谁方便先看一下事故现场最危险的一种状态是所有人都知道应该做事却不知道具体由谁执行。结果往往是大家都以为别人正在处理。两分钟后前端回复兑换按钮已关闭20:15生效。运维回复网关已禁止新建兑换请求20:16生效。赵明回复自动重试任务已暂停。积分模块负责人回复扣减消费者已停止队列消息保留。八点十七分。监控中的异常数量停止增长。最终停在126笔。从林川进入事故群到新增损失停止一共用了六分钟。上一世同样的事故扩大到四百多笔。这一世问题仍然发生了。但事故的边界被迅速封住。事故处理的第一目标从来不是立刻找到Bug。而是不让Bug继续产生新的损失。二、“先找到责任人”听起来负责实际上可能最不负责止损完成后周凯发来一句现在可以查是谁改的了吧林川看着这句话。他并不反对调查责任。代码为什么出问题评审为什么没发现测试为什么没有覆盖都必须查清楚。但不是现在。此时还有三个更紧急的问题第一已经产生的126笔异常订单具体影响是什么第二积分是否全部被重复扣除还是只有部分状态不一致第三暂停任务后是否还有延迟消息正在进入系统如果这些问题没有答案事故并没有真正稳定。只是暂时停止了新增请求。林川回复先确认影响范围和数据状态。责任归属不影响当前恢复方案放到复盘阶段处理。周凯问不知道谁改的怎么定位林川说定位代码需要Git记录、日志和调用链不需要先让每个人在群里自证。随后他新建了一份事故处理记录。第一行写下事故开始时间20:07。第二行止损完成时间20:17。第三行当前已知影响126笔兑换请求存在积分重复扣减或状态不一致风险。第四行当前状态新增请求已停止系统影响范围暂时稳定。然后他把人员分为四组。第一组业务止损组负责人产品经理、业务负责人。任务关闭活动入口准备用户公告暂停营销推广通知客服统一话术第二组技术定位组负责人林川。成员积分模块开发订单模块开发运维数据库人员任务还原调用链确认重复扣减条件分析消息和数据库状态第三组数据核对组负责人赵明、测试负责人。任务提取受影响订单对比订单状态与积分流水区分可自动修复和需人工确认的数据第四组恢复验证组负责人测试负责人。任务构造事故场景验证修复方案确认恢复条件周凯问我负责什么林川回答负责整体协调、业务决策和对上同步。每十五分钟发布一次状态。这一次没有人继续争论代码归属。每个人都有明确任务。事故群终于从一个互相解释的聊天群变成了一个真正的作战现场。三、线上事故最先暴露的往往不是技术问题而是组织本能八点二十五分。技术定位组完成第一轮分析。调用链显示用户发起兑换后订单服务先调用积分服务扣减积分。积分服务完成数据库事务后返回结果。如果响应超过两秒订单服务会认为调用失败并重新发起一次请求。问题在于第一次请求虽然超时但数据库事务已经提交成功。第二次请求携带的是新的请求编号。积分服务无法识别两次请求属于同一笔业务操作。于是再次扣减积分。从技术上看这是一个典型的幂等问题。但事故能够进入生产并不只是某一行代码写错。它穿过了多层防线产品只写了“失败后自动重试”没有定义重复执行风险技术方案没有要求业务唯一标识开发使用了每次重新生成的请求号代码评审只关注重试次数没有检查幂等性测试模拟的是明确失败没有模拟“服务端成功但客户端超时”上线后没有配置重复扣减监控活动入口也没有一键关闭能力如果一定要问这是谁的问题最准确的答案是它是整个交付链条共同漏掉的问题。但人在事故现场很难接受这种答案。因为“共同问题”听起来像没人负责。管理者会本能地寻找一个具体的人。最好是最后提交代码的人。这样问题就会变得简单某个人粗心。某个人能力不足。某个人没有测试好。只要批评他、处罚他、要求他以后认真就好像事故已经得到解释。可这种解释没有价值。因为下一次只要系统中仍然缺少幂等机制、异常场景测试和快速止损能力换一个程序员写代码事故仍然可能发生。林川在事故记录中写道初步原因订单服务在积分接口超时后生成新请求编号重试积分服务缺少基于业务订单号的幂等校验导致已成功但响应超时的请求被重复执行。他没有写某某程序员编写了错误代码。因为在根因没有完整确认之前把人的名字放在原因前面只会让调查变成自我保护。一旦大家开始害怕自己被定责接下来的信息就会变得不再可靠。有人会淡化自己参与过的决策。有人会强调曾经提出过不同意见。有人会选择性遗忘评审过程。有人甚至会先删除不利于自己的聊天记录。事故调查最需要真实信息。追责压力却最容易摧毁真实信息。四、用户损失还没有恢复领导却已经开始准备复盘结论八点三十二分。部门负责人进入事故群。他没有查看前面的处理记录。进群后的第一句话是这次问题非常严重开发和测试必须给出解释。测试负责人立刻回复我们测试环境没有出现重复扣减需求用例中也没有这个场景。积分模块开发说重试逻辑不在积分服务积分服务只是正常执行请求。订单模块开发说重试需求是产品提出的代码也经过评审。群里的气氛再次发生变化。刚才还在核对数据的人开始停下来解释自己。林川立刻发出一条消息当前仍处于事故处置阶段。请各组继续执行任务不在群内讨论责任。当前优先级P0确认影响范围。P1修复异常数据。P2验证修复和恢复业务。P3事故根因分析。P4责任与流程改进。部门负责人回复责任也是事故处理的一部分。林川说是但不是当前最紧急的一部分。如果现在要求每个人解释责任数据核对和恢复会同时停止。建议先在一小时内恢复用户权益再安排完整复盘。业务负责人也说道先处理用户影响责任后面再查。部门负责人没有再坚持。但他发了一条私聊给周凯这个事情你要控制好不能最后变成谁都没责任。林川后来才从周凯那里看到这句话。他一点也不意外。很多管理者害怕“系统性问题”。因为系统性问题意味着需求流程需要改技术架构需要补测试方法需要升级上线机制需要调整管理方式也可能有责任这些都很复杂。相比之下把问题归结为某个人不认真要简单得多。只要写一份检讨扣一次绩效召开一次警示会。组织看起来已经采取了行动。可下一个事故仍然会从另一个缺口进入。五、林川没有急着回滚因为回滚也可能制造第二次事故八点四十分。开发人员已经找到问题代码。最直接的解决方式是关闭自动重试。然后重新发布上一版本。赵明问直接回滚行不行上一版没有重试。周凯立刻说道那就赶紧回滚。林川没有同意。“先确认上一版本和当前数据库结构是否兼容。”这次上线除了重试逻辑还增加了一个订单状态字段。数据库中已经存在新版本生成的数据。如果直接回滚应用旧代码无法识别新状态可能把部分订单错误地判定为失败。另外暂停的消息队列中还有一百多条订单消息。回滚后重新启动消费者旧版本是否能正确处理也没有验证。事故处理中人们非常喜欢“回滚”。因为回滚听起来像回到一个安全状态。但真实系统中代码可以回滚数据未必能回滚。外部调用无法回滚。已经发送的消息无法回滚。用户已经看到的状态也无法回滚。一个未经验证的回滚可能让第一次事故变成第二次事故。林川说不直接回滚。采用最小修复方案。方案包括订单服务重试时复用原业务请求号。积分服务基于兑换订单号增加唯一约束。对重复请求返回首次执行结果不重复扣减。增加重复扣减检测日志。恢复前先在隔离环境复现并验证。积分模块开发说增加唯一约束会不会影响现有数据“先检查是否已有重复订单号。”数据库人员执行查询。发现生产库中已经存在12条历史重复数据。如果直接增加唯一索引发布会失败。林川调整方案先在服务层增加幂等表完成历史数据清理后再补数据库唯一约束。周凯看着时间。“这样要多久”“开发四十分钟验证三十分钟预计九点五十分恢复灰度。”“直接回滚可能十分钟就好了。”“也可能十分钟后出现更严重的数据状态问题。”周凯明显有些着急。“业务一直关着损失也很大。”林川回答“关闭业务入口的损失是可见的。”“错误恢复造成的数据损失现在无法评估。”“事故处理不能为了让监控尽快变绿制造一个更难发现的问题。”业务负责人最终支持了林川。“按验证后的方案恢复。”技术团队继续处理。六、真正的专业不是最快改代码而是知道什么时候不能急九点零五分。数据核对组完成第一版名单。126笔异常订单中83笔发生重复扣减27笔订单成功但页面显示失败11笔处于处理中状态5笔实际未扣减仅前端提示异常林川要求将四类订单分别处理。第一类重复扣减83笔自动返还多扣积分并保留补偿记录。第二类成功但显示失败27笔同步修正页面状态不重复发放商品。第三类处理中11笔结合积分流水、商品发放记录逐笔确认。第四类未扣减5笔订单标记失败允许用户重新兑换。产品经理问能不能全部直接把积分退回最简单林川摇头。“不能。”“成功订单如果全部退款用户可能已经获得商品同时积分也被返还。”“会造成新的资金和权益损失。”业务负责人问那83个用户除了返还积分要不要补偿产品经理建议每人额外补100积分减少投诉。林川说可以但补偿和数据修复要分开执行。“为什么”“修复是恢复用户原本权益补偿是业务决定。”“如果混在同一个脚本中后续无法区分正常返还和额外赠送也不利于审计。”技术人员在事故现场很容易陷入一种状态只要数据最终看起来对了就算解决。但涉及用户资产、订单、支付和积分时处理过程必须可追溯。谁的积分为什么增加。哪些是回滚。哪些是补偿。哪些是人工调整。都需要留下明确记录。否则事故当天解决了几个月后对账时还会再次出问题。九点二十分。修复代码完成。测试开始在隔离环境模拟第一次请求成功返回第一次请求成功但响应超时第一次明确失败第二次重复请求并发重复请求消息重复消费之前没有覆盖的场景这一次全部加入验证。九点四十九分。测试通过。林川没有立即全量恢复。而是先开放给内部白名单账号。十名测试人员连续执行五十次兑换。没有出现重复扣减。随后开放1%的用户流量。观察十分钟。错误率正常。再扩大到10%。继续观察。十点二十一分。积分商城恢复全部流量。从事故开始到业务恢复共两个小时十四分钟。时间不算短。但所有受影响数据已经分类。修复方案经过验证。业务恢复也采用了灰度方式。没有发生第二次事故。七、恢复之后所有人第一反应又是赶紧删掉事故群里的话业务恢复后事故群终于安静下来。有人发了一个“终于结束”的表情。赵明在私聊中对林川说你刚才在群里顶领导不怕被记住林川问我顶什么了“你说不要讨论责任还给事故排了P0到P4。”“这是事实优先级。”“但部门负责人肯定会觉得你在挑战他。”林川看着事故群中的消息。上一世事故结束后所有人都想做一件事整理聊天记录。有人删除情绪化表达。有人撤回自己对错误原因的判断。有人私下提醒同事刚才那句话不要放进复盘材料。周凯也要求最终报告不要写“二十分钟后才停止入口”而是改成事故发现后项目组第一时间采取止损措施。这样写更体面。也更像一支训练有素的团队。可正是这种体面的总结让组织失去了真正学习的机会。如果“第一时间止损”就不需要追问为什么实际等了二十分钟。如果“团队快速响应”就不需要讨论事故群为什么充满甩锅信息。如果“个别人员操作失误”就不需要改进整个交付流程。这一世林川没有删除任何记录。他把关键时间线整理出来20:07首次监控告警。20:09确认存在积分重复扣减可能。20:11事故群开始讨论代码责任。20:13发布一级止损指令。20:17新增异常停止。20:25确认初步技术原因。20:40完成影响范围初步统计。21:20修复代码完成。21:49隔离环境验证通过。22:21生产流量全部恢复。他在时间线下面写了一句事故发现后的前四分钟团队主要在讨论责任归属未形成统一止损指令。周凯看到后打来电话。“这句话必须写吗”“必须。”“只耽误了四分钟。”“这四分钟新增了五十多笔异常。”“但写进去会显得事故管理很混乱。”林川回答“当时确实很混乱。”“复盘不是为了证明我们表现得很好。”“是为了找出为什么事故会扩大。”周凯语气沉了下来。“你不能只记录问题也要考虑团队形象。”林川问“如果为了形象删掉这个事实下次事故发生后大家还会先问是谁改的代码。”“然后再浪费同样的四分钟。”电话那边沉默了一会儿。“你现在真是什么都不愿意糊弄过去。”林川说“事故可以结束。”“问题不能糊弄过去。”八、复盘会上所有人都在等那个“责任人”被点名第二天下午三点。事故复盘会。部门负责人、业务负责人、项目经理、产品、研发、测试和运维全部到场。林川先介绍事故过程。没有情绪。没有评价。只有事实发生了什么影响了多少用户如何止损如何修复为什么恢复用了两个小时哪些处理有效哪些环节存在问题随后进入原因分析。大屏幕上显示着五层原因。第一层直接技术原因订单服务超时重试时生成了新的请求编号。积分服务缺少以业务订单号为基础的幂等控制。第二层设计原因技术方案将“接口超时”等同于“业务执行失败”。没有区分请求未到达请求执行失败请求执行成功但响应丢失第三层测试原因测试覆盖了明确失败和正常成功。没有覆盖成功后响应超时、消息重复和并发重试。第四层发布与监控原因上线前没有对用户资产类接口建立幂等检查清单。上线后也没有重复扣减实时监控。第五层事故响应原因事故初期优先讨论责任归属未立即形成统一止损指令。部门负责人听完问“最后是谁写的重试代码”会议室里所有人都看向订单模块开发小王。小王明显紧张起来。林川回答“小王完成了具体实现。”“我参与了技术方案评审。”“赵明参与了代码评审。”“测试团队按照当时的用例完成验证。”“产品提出了失败重试需求。”“最终代码经过完整流程上线。”部门负责人皱眉。“你的意思是没有个人责任”“有个人职责。”林川说道。“小王在实现时没有考虑业务幂等。”“我在方案评审时没有明确唯一业务标识。”“代码评审没有识别重复请求风险。”“测试没有补充不确定结果场景。”“这些都需要分别改进。”“但如果把原因归结为小王写错了代码下一次其他开发仍然可能犯同样的错误。”部门负责人问“总要有人承担主要责任吧”林川没有躲避。“如果一定要指定事故技术负责人我承担。”小王猛地抬头。周凯也有些意外。林川继续说道“我是该模块的技术负责人方案完整性和技术门禁属于我的职责。”“但我不建议把整改措施写成‘加强个人责任心’。”“真正有效的措施应该进入流程和系统。”他说完切换到整改清单。九、真正有效的复盘不是找一个最适合被批评的人整改清单一共有九项。1. 所有用户资产类接口必须实现业务幂等不允许仅依赖随机请求编号。必须使用订单号、支付单号或业务流水号作为唯一约束。2. 技术方案增加“不确定结果”分析所有外部调用必须区分明确成功明确失败结果未知结果未知时不能直接重试业务操作。3. 测试增加异常组合场景包括成功后响应超时消息重复投递并发重复请求服务重启部分链路成功数据库提交后网络断开4. 发布检查增加幂等与补偿项涉及支付、积分、库存、优惠券和权益的功能必须完成专项检查。5. 增加重复扣减实时监控同一业务订单出现多次资产变化时立即告警并自动拦截。6. 建立业务一键止损能力产品或运维可以快速关闭活动入口订单创建自动重试资产扣减外部发放不再依赖临时修改代码。7. 建立事故指挥角色每次事故必须明确一名指挥者。其他人按照分组执行不在主群展开责任争论。8. 事故期间禁止追责式提问将谁改的改成当前影响是否还在扩大将谁的责任改成现在最优先停止什么将为什么没测出来改成还缺少哪些信息才能恢复9. 事故恢复后再进行责任分析先恢复业务和用户权益。再基于证据讨论职责、流程和改进。部门负责人看着最后两条。“禁止追责式提问会不会让大家没有责任感”林川回答“只是事故处置阶段不讨论。”“恢复以后照样分析责任。”“区别在于现场先解决问题复盘再解决责任。”“如果系统正在持续损失第一时间问谁写的代码不会减少一笔损失。”测试负责人点头。“而且当时一问责任大家都停下来解释了。”产品经理也说道“如果再晚几分钟关闭入口受影响用户会更多。”业务负责人最终表态“事故现场先止损这个原则没问题。”部门负责人没有继续反对。他看向小王。“这次你也要认真总结。”小王点头。“我会补充幂等设计和异常场景。”会议没有变成公开批斗。也没有人完全逃避自己的职责。每个人都承认了自己所在环节的遗漏。但事故没有被压缩成一句某开发人员责任心不足。这一次组织真正留下了一套下次可以使用的机制。十、会议结束后小王问他为什么替我承担散会后小王追上林川。“川哥。”“嗯”“刚才为什么说你承担技术负责人责任”林川看着他。“因为我是技术负责人。”“但代码确实是我写的。”“代码是你写的方案是我审核的。”“你不可能对所有系统性缺口一个人负责。”小王低下头。“可要不是我没考虑幂等就不会出事故。”林川问“你以前独立处理过这种接口超时场景吗”“没有。”“方案里有人要求你使用业务唯一号吗”“没有。”“代码评审有人提出这个问题吗”“没有。”“测试用例里有成功后超时吗”“也没有。”林川说“这不代表你没有责任。”“但你的责任是理解这次错误以后不再犯。”“不是成为所有人结束复盘的答案。”小王沉默了一会儿。“我还以为今天肯定要背处分。”“处分有时能让人记住教训。”“但一个人害怕写错代码并不会让系统自动变可靠。”“反而可能让所有人以后遇到问题先隐藏。”林川拍了拍他的肩膀。“把事故场景整理成团队案例。”“下周你来讲幂等和不确定结果处理。”小王愣住。“让我讲”“你现在是团队里对这个坑最熟悉的人。”“犯过错误的人不应该永远被定义为错误。”“真正有价值的是他能不能让整个团队不再重复踩坑。”小王点了点头。“我会准备好。”林川看着他回到工位。上一世这次事故后负责重试代码的开发被评为低绩效。两个月后他主动离职。团队重新招了一个新人。没人再提这次事故。也没有建立幂等检查和快速止损机制。半年后优惠券发放又出现了类似的重复问题。只是那一次换了另一个程序员背锅。惩罚了一个人。系统什么也没有学会。十一、为什么事故现场的人都喜欢问“谁干的”因为这个问题可以迅速缓解焦虑。当一个复杂系统突然失控时所有人都会产生强烈的不确定感。如果能够找到一个具体的人问题就会显得重新可控是他写错了。把代码修好就行。以后让他认真一点。这种解释简单、直接也符合人的直觉。但软件系统很少因为一个人的单一错误就发生严重事故。真正的重大事故通常需要多个条件同时成立错误设计进入方案代码实现没有防护评审没有发现测试没有覆盖发布没有拦截监控没有及时识别事故响应又不够迅速一个错误能够穿过所有防线本身就说明系统存在问题。这并不意味着个人不需要负责。而是责任不能替代根因。个人责任回答谁在哪个环节没有完成应尽职责系统根因回答为什么一个人的错误能够直接影响生产用户两个问题都要回答。但顺序不能颠倒。否则组织会非常勤奋地处罚每一次犯错的人。却从不修复那个允许错误不断穿透的系统。十二、事故处理中最重要的五个顺序林川把这次经验整理成一张卡片发到技术群。第一止损先阻止影响继续扩大。关闭入口、切断调用、暂停任务、降级服务。第二稳定确认异常数量不再增长。保存日志、数据和现场信息。避免未经验证的频繁操作。第三恢复基于验证过的方案逐步恢复。优先灰度不盲目全量。第四修复用户影响数据核对、资产返还、业务补偿和用户沟通。技术恢复不等于事故结束。第五复盘与责任分析基于完整证据分析直接原因、系统原因和个人职责。不是不追责。而是不在最需要解决问题的时候把所有注意力放在追责上。这五个顺序看起来很简单。但事故发生时人的本能经常相反。先问是谁。再争论原因。接着着急改代码。最后才想起还有用户正在受到影响。真正成熟的事故管理不是要求现场所有人没有情绪。而是用明确流程让团队即使在情绪和压力中也知道下一步应该做什么。写在最后线上事故最考验一个团队的不只是技术能力。而是它面对错误时的本能。一个缺乏安全感的团队事故发生后会立刻寻找责任人。每个人先保护自己。信息开始变形。问题被隐藏。真正的恢复反而越来越慢。一个成熟的团队会先问影响还在扩大吗怎样最快停止新增损失哪些数据需要保留谁负责指挥恢复方案验证过吗等系统稳定下来再认真讨论哪个环节失守了谁应承担什么职责怎样让下一个人不再犯同样的错误这不是纵容错误。而是承认一件事在复杂系统里惩罚一个人永远比修复一套机制容易但也永远没有修复机制有效。程序员可以为自己写错的代码负责。技术负责人可以为方案缺陷负责。测试可以为覆盖不足负责。项目经理可以为事故组织混乱负责。但任何责任分析都不应该抢在用户止损之前。系统正在流血时最没用的问题就是这是谁干的真正应该问的是现在谁来止血林川的重启仍在继续。下一次他将面对程序员职场里另一个更隐蔽的问题。领导对他说“这个项目你先牵头做好了以后晋升的事情肯定优先考虑你。”上一世他承担了技术负责人、项目经理和救火队长的全部工作。项目成功后领导却说“你还缺少正式带团队的经验。”这一世他决定在接受“牵头”之前先问清楚这个职位到底只有责任还是也有权限、职级和回报本篇留一句话事故发生时先问“谁的责任”只会让所有人忙着证明自己无辜先问“如何止损”团队才有机会真正解决问题。