cloud2021-08-31李老师，我有些困惑。我们公司现在很多时候复盘也复盘了，也制定了一些措施，避免后续不再犯此类错误。但是一段时间之后，似乎又回到了老样子，如何让复盘后的措施，在团队中持续有效，这方面您有什么经验么?作者回复: 要么落实到流程、要么落实到工具和系统，不能依赖人
共 2 条评论6
王同学2021-02-10问题源头承担主责，问题放大者承担主责分不清楚。比如上游的数据格式出错，导致下游需要用数据的服务都有问题，那么是上游源头主责，还是下游放大问题者主责。上游定主责没问题，因为产生了错误的数据。下游定主责也可以，因为下游没有兼容缺陷数据。这个时候怎么定责作者回复: 你要看下游有没有放大问题，注意是放大，而不是说出错，因为上游数据格式出错，正常来说下游肯定出错，只要没放大就没问题。
共 4 条评论5
菜心19862021-02-14复盘什么频率做一次？复盘的归因和追责部分要到什么程度？ 这里的追责结果是否代表个人本身有问题？或者本人能力不行？ 多大的问题要追责，比如一周没事是否也要找个问题来汇报？ 追责是否都是底层人人员，领导或者老板会有问题可以复盘么？作者回复: 1. 这里讲的是线上问题复盘，事件触发模式，不需要定期举行。 2. 多大问题要追责，实行什么样的奖惩措施，是公司或者团队要预先制定规则的。 3. 看问题大小来复盘和追责，支付宝5.27全网宕机的事故，总裁都要担责。
4
周平2021-04-11复盘的目的是找到问题的原因并改进，避免同样的问题反复出现，降低问题的发生的概率和影响。 我觉得，如果定不好责，特别影响复盘的目的，走偏。 想想以前被定过的责，好像是公平的，让人口服的，至少从逻辑上是找不出什么毛病来。 又一想，领导嘛，总能想出一些手段，做到逻辑上走通没毛病，再加上信息不对称，以及作为下属的弱势，总有办法让你说不出什么。 同时，又感到，做的事越多，越容易被人揪住辫子，追责。总的感受，我做了那么多事情，那么努力，结果奖励没见多少，还受罚了。 本文定责的原则，对我很有用，至少能帮我确定一些原则和边界。 同时，应从大利益的维度去考虑事情，不要太计较这些。 我自己还有个问题，心里特别怕出错，好像出了个错，好像天要塌下来一样。 其实，想想看，不需要看的那么重。 看来，定责是领导的一个技能，不是做事儿的人的技能，怎样定责也不在做事儿的人的影响范围内。 事情该做就做，重要的还是自己的成长。 回想了一下自己受过的责，也没几件。 这些受责是否影响了自己的成长和晋升呢？ 我觉得最关键的还是自己的学识，认知。这方面的瓶颈，更大的影响了自己的晋升和成长。作者回复: 被别人定责的时候，明确定责标准再根据标准找事实，基本上能够避免背黑锅。 你对定责的理解已经到了新的境界，点赞👍🏻 其实我也出过事单过责，但长期来看，关键还是自己成长，某次担责并不可怕，有时候担责反而让自己理解更深，印象更深
共 3 条评论3
🍭2021-07-12作为研发怎么判断产品提出的需求是否合理呢，可以从哪几部分进行分析？作者回复: 并没有很好的方法，更多靠个人的积累，如果遇到自以为是的产品或者运营，沟通很麻烦，我在阿里都遇到很多这样的产品，能力一般还很自信，开口闭口乔布斯、苹果之类的
共 3 条评论2- 菜心19862021-02-14这里的技术负责人都是底层研发吧。管理层，比如经理没有承担责任么？ 另外，团队合作时，比如测试遗漏怎么定？比如需求文档没有明确要求，测试是不是不需要关心了，出了问题也是无责任？ 或者这个因公司而异，都可以？
作者回复: 1. 团队leader也要承担连带责任 2. 大部分公司以结果导向，即使需求文档没写，如果是正常需求需要考虑的，在设计和测试的时候都要覆盖，需求文档不可能事无巨细全部覆盖到。
共 2 条评论1 
qinsi2021-02-09“问题放大者承担主责”不是很理解。如果A是问题源头，B放大了问题，这时候是源头主责还是放大者主责呢？作者回复: B的主责肯定是跑不掉，至于A是不是主责，要看A造成的问题大小。举个例子，如果A的问题只持续了1分钟就解决了，那不需要承担主责，如果A本身也导致了30分钟的问题，那么也是要承担主责的。
1
一个帅哥2023-06-21 来自广东工作已经4年了，还没出过线上事故。归根结底，就是因为自己胆小，总是怕出问题，所以方案梳理，代码改动都会评估影响的范围。 身边的例子：偷偷加代码，不通知qa测试，导致出了问题。作者回复: 做事细致认真值得赞赏，但也不要过于谨小慎微。
千锤百炼领悟之极限2023-03-25 来自广东复盘目标： 1.事实：讲清楚事实 2.分析：全面深入地分析原因 3.定责：得出让各方都心服口服的定责结论 4.改进：制定可落地执行的改进措施 四线复盘法 时间线：问题发生到结束的经过 问题链：问题的传导路线 - 业务流程 web->A服务->B服务->C服务 - 项目流程 开发->测试->产品->运维 责任链：责任人之间关系 - 定责标准： - 违反规章/制度/流程 负主责 例如：系统规定要经过灰度测试才能全量上线，没有经过灰度测试就全量上线导致出问题。 - 重大失误纰漏 负主责 例如：测试漏测试一个重要功能，导致上线后出问题。测试，产品负主责 - 问题源头 负主责 例如：A服务故障导致B，C，D服务故障 - 问题放大者 负主责 例如：A服务故障导致B服务故障，但A服务故障几分钟后修复，B服务却触发了自己的bug导致继续故障2小时，B服务需要负主责 改进线：制定可落地执行的改进措施作者回复: 很用心，记得保存在自己的笔记上
Jeeffi2023-02-22 来自浙江场景： 1. 业务线A和业务线B存在公共的底层代码。 2. 业务线A的项目中涉及底层公共逻辑的调整。并同步了业务线B。 3. 业务线A的开发在公共逻辑中引入了bug，但是在业务线A的case中不会出现，只业务线B功能的部分机型上存在功能不work。 两个问题： 1. 像这个case如何定责呢。业务线A觉得自己尽到了同步责任，改动了也回测了自身case. 业务线B觉得是外部改动引入的，且是机型问题，自己回测过只是没有多机型足够覆盖。 2. 一般定责分为产生责任和发现责任等，那么引入bug的开发需要承担产生责任吗。产生责任和发现责任哪个一般是主责。作者回复: 1. B主责，A次责。因为A没法做B的覆盖测试，只有B能够自己做，B没做好机型不够，本身就说明B有问题，这次是A的bug触发了，下次可能是其它原因导致B出问题。 2. 开发乱改测试不知道，那当然是开发的责任；开发正常写代码也给了测试，测试没测出来，那当然是测试的责任。否则如果每个问题都要求开发不出bug，那还要测试干嘛？干脆裁掉测试部门看看测试部门是否同意 ：）