24 Case Study：让线上故障沉淀为团队的经验

你好，我是农信数智副总裁/数字供应链总经理李玉福，一个拥有15年研发和管理经验的互联网老兵，目前主要负责公司的研发管理、项目管理、产品运营等工作。

俗话说吃一堑⻓一智，一个人如果不能从错误中吸取经验，那他则无法快速成⻓；一个团队如果不能从失败中总结并沉淀经验，那这个团队将无法快速前进。

针对失败和错误，最简单直接的办法就是惩罚，但是惩罚失败我们要讨论它的目的是什么。比如对银行而言，惩罚失败是有道理的，因为它的风险成本太高。对于互联网企业这样的创新型公司而言，惩罚失败只会带来一个结果：遏制创新。因为只要是创新就一定会有失败，而且它的失败率高于成功率，我们应该更关注失败对于团队经验的积累和沉淀，这就是我的出发点。

如何把这些经验快速沉淀下来并扩散到整个团队呢？我们可以使用一种叫做 Case Study（案例研究）的管理机制，来驱动团队愿意接受自己遇到的问题，并乐于总结、分享经验，建立团队的知识库。

出现Bug后错误的“打开方式”

Case Study 实施起来并不难，难就难在如何把事情做到位，这需要我们为团队建立起来一种团队交流和分享的氛围，其中最重要的一点就是对待Bug的态度和解决办法。

我们知道程序员的工作内容，主要分为三个部分：

1. 与产品沟通需求；
2. 系统模块设计；
3. 开发实现与测试，最终发布。

在这个过程中，即使是水平很高的技术人员，都难免因为在设计方面的缺陷和实现方面的疏忽，导致产品发布上线后出现一些 Bug。其中低级的功能 Bug 缺陷，往往在功能测试阶段就会被发现并解决掉，而一些认知、集成以及环境方面的 Bug，往往会因为我们缺乏经验，跟随系统发布到线上。

针对线上发生的问题，如果我们只是简单粗暴地执行相关的惩罚机制，比如公开批评、扣绩效等动作，对团队技术人员伤害是极大的，这会导致技术人员在接下来的工作中，因为担心犯错，做事畏首畏尾，技术上不敢创新，产品迭代速度变慢，影响整体产研进展。另一方面，他们也会因为担心影响绩效，不敢大胆地分析问题，甚至会把问题隐藏起来，导致经验没法沉淀，问题反复出现，影响用户体验。

作为管理层，如何打造一套团队乐于剖析问题，分享经验的文化机制呢？这里就可以用我们前面提到的故障分析管理方法论 Case Study。

Case Study 的背景和价值

Case Study 的雏形最早起源于医疗临床试验，后来商学院把 Case Study 应用于商业案例的分析，从而被大面积推广，尤其是 MIT，针对性地建立了财会、创业、企业领导力、运营管理、战略研究、可持续发展等系列商业案例库。

通过案例激发学生之间的辩论，来帮助学生模拟在实际管理工作情况下会做什么，不会做什么，为什么以及如何做。其目的是通过深度拆解过程，提炼出案例中导致失败的最重要的要素，来总结出失败案例中的一些错误的制度和行为，通过对案例的分享和宣传，降低一些低级错误给项目带来的损失。

同样地，我们可以把 Case Study 完美地复制到软件产品领域，通过线上的一些事故案例，来展开深度分析和总结，并分享给团队，从而让团队成员都对事故有认知，避免同样的问题在团队其它成员身上再次发生，影响产品和项目的交付质量。

另外还要注意一点，在实际的产品研发过程中，工程师、项目经理、经理不能只关注结果，还要关注过程是否完美。小项目中暴露出来的问题不及时弥补，到了大项目，往往会酿成重大恶果。Case Study 要求尽可能全面、深入地剖析问题，发现问题的本质，及时改进并沉淀经验，最终保证工作质量。

了解了 Case Study 的背景和价值，接下来我们来说说其在应用过程中的一些具体环节以及如何在工作中去推广。

在工作中如何去推广和应用 Case Study？

既然是 Case Study，一定是先有Case，什么情况可以被当作 Case 来讨论呢？

就拿线上Bug这个场景来说吧，我列举几种需要 Case Study 的典型案例。

1. 某产品线的在线服务升级，遇到意外情况，导致升级完全失败或部分失败，或对预期的升级进度产生严重影响，这几种情况下，需进行 Case Study。
2. 某产品线的新功能上线后，根据各方面反馈，发现由于某些 Bug 或者理解偏差与预期效果严重不符，需进行 Case Study。
3. 技术总监/部⻔经理/项目经理认为需要进行 Case Study 的情况。

当在线服务出现故障或者发现线上 Bug 这样的 Case 发生后，为了探讨意识、流程、技术等方面的不足，总结由此带来的经验教训，探讨可能的具体改进措施，需要相关产品线的技术经理、项目经理或负责人组织 Case Study。

组织Case Study的形式及参会人

Case Study 的形式相对是比较灵活的，最好的方式就是召集相关人员开会讨论，同时针对不同的具体情况也可以采用经理与直接责任人当面沟通、邮件讨论等形式。对于时效性来说，一般情况下，Case Study 要求在事故或线上Bug发生后的三个工作日内进行，趁热打铁，及时总结。

针对每一次项目的 Case，与会人员应当是RD项目组所有成员、Testing 部⻔的相关人员、PM部⻔的相关人员，以及项目经理或技术经理、总监认为其他应当参加的有关人员。

会议过程的关注点及注意事项

会议开始前，需要先明确此次 Case Study 的目标，提前确定要讨论的问题，把握好方向，通过设问的方式来引导大家讨论。重点关注意识层面及流程规范方面的问题，并且在会议过程中要引导大家提出具体的、可行的改进方案，最后确定解决方案并敦促相关负责人严格执行。

另外还要注意 Case Study 的终极目标是修炼内功，精益求精，所以一定不要一味强调一些客观原因或者其他部门配合方面的问题。不然会议就会变成追究责任和推脱责任的战场，也就失去它原本的意义了。

最后强调一点，Case Study 一定要对事不对人，不然就会变成人人都想逃避的屠戮场。 相反如果 Case Study 卓有成效我们还要夸赞相关的责任人，为我们提供了这么有意义的案例。这一举动能让员工意识到犯错不可怕，它可以变得非常有意义。

Case Study 产出的文档

正式的召集会议形式的 Case Study，应由直接责任人或负责人需撰写规范样式的 Case Study报告，由项目经理、技术经理或技术总监审阅修改后，分发给参加 Case Study 会议的人员以及RD项目组成员，抄送给App部⻔负责APM更新汇总的负责人，并由该负责人提交到APM中的“App 知识库”对应的栏目中。如果是其他形式的 Case Study，需要由当事人或者责任人随后撰写 minutes 或总结文档，以邮件形式发给所在项目组成员。

Case Study 的改进计划应有相关产品线的项目经理或负责人监督执行，根据各个部⻔的相关规定，需要将执行情况汇总到项目经理工作周报中。

产出文档示例见附录

持续推进，形成团队习惯和文化

实践过程中，往往会由于时间问题，导致 Case Study 制度的执行力度不够。这是因为团队还没有将与 Case Study 相关联的工程师的六大意识（质量意识、求实意识、时间意识、进取意识、团队意识、沟通意识）做到月月讲、周周讲、日日讲。只有让 Case Study 成为大家日常工作的一种习惯，就不会感受到由 Case Study 带来的压力了。

小结

在我们公司，Case Study 给团队带来的不仅仅是对于问题和故障的重视，更多的是给团队带来了一种开放、共享的学习成长氛围，很多公司都推崇技术文化，我对技术文化宏观层面的感知就是开放、向上、有激情，是一种引导团队积极向上的隐形力量，通过日常的一些行为动作去贯彻和落地，最终体现在每个人的行为规范上，对于细节的处理就是文化的体现。

技术管理者要想打造积极向上的工程师文化，就需要打造这样的一种环境，找到一些关键的有意义的案例，让大家在这个环境里自由、开放地交流。我觉得 Case Study 就是这样一种非常有趣的活动，你不妨尝试一下。

思考题

最后给你留两道思考题，你来思考一下。

• 做 Case Study 的本质是解决技术管理中的什么问题 ？
• 如果团队对 Case Study 的任务比较排斥，根本的原因在于哪里？

欢迎你在评论区留下自己的思考，也欢迎你把这节课分享给需要的朋友。

---

附录：Case Study 的产出文档示例

《一个502服务的Case Study案例》

案例描述

某一个网关接口服务502

事故过程说明

2022年01月17日 9:30 公司群通知通过直选小程序领取春节大礼包，紧接着客户群反映home、企店访问不了。

技术分析说明

通过某个应用访问报错信息发现网关服务502。

1. 对比Nginx 16号和17号访问日志，访问量增加了2倍多。

1. 对比16号和17号JVM状态，发现线程数超出服务器默认配置。

PeakThreadCount：线程数量峰值

ThreadCount：当前线程数量

服务器默认配置

• maxThreads：最大线程数

每一次HTTP请求到达Web服务器，Web服务器都会创建一个线程来处理该请求，该参数决定了应用服务同时可以处理多少个HTTP请求，tomcat默认为200。

• accepCount：最大等待数

当调用Web服务的HTTP请求数达到tomcat的最大线程数时，还有新的HTTP请求到来，这时tomcat会将该请求放在等待队列中，这个acceptCount就是指能够接受的最大等待数，默认100.如果等待队列也被放满了，这个时候再来新的请求就会被tomcat拒绝（connection refused）。

• maxConnections：最大连接数

这个参数是指在同一时间，tomcat能够接受的最大连接数。一般这个值要大于maxThreads+acceptCount。

进一步分析原因，怀疑跟早上上线的礼包领取功能有关，分析获取人员入职接口，发现大量请求时间超过10S。

通过与XX沟通，直选小程序在未登录状态下调用接口，返回了全量数据。

解决方案说明

完整解决：

1. 直选小程序增加未登录校验 - 已上线
2. 企联网增加用户信息校验 - 已上线
3. 修改网关tomcat线程默认配置 - 测试环境验证中
   修改到多少？400 100
4. 网关超时设置失效 - 待压测复现
5. 异步接收请求

根本原因

1. 接口调用方和提供方都未做基本的校验
2. 网关超时设置失效

预防措施

• 服务线程超限报警（假死状态）
• 加强网关接口管理
• 限流、熔断功能

扩展会议结论

1. 新增网关接口超时不超过10S -前端
2. 超时失效压测-预生产
3. 熔断、异步开发计划
4. 统一springboot服务器参数配置
5. 线程报警数下调、报警名单
6. 网关缓存用户token（0125根据token获取boId超时导致终端收银员退出）

精选留言（5）

• 石云升 👍（6） 💬（1）

  做 Case Study 的本质是解决技术管理中的什么问题 ？ 不要在同一坑里掉两次。为了做到这个，不是靠个人的意识，而是用流程来规避问题。比如清单。 如果团队对 Case Study 的任务比较排斥，根本的原因在于哪里？ 有多种方面吧，开会的目的是复盘问题，还是追责? 一旦让人感觉是追责会或者推荐卸责任会，那就没人愿意开了。另一个就是执行效果，如果开了会跟没开一样，大家都是走过场，那大家也会排斥。

  2022-12-29


• 蟹忑 👍（2） 💬（0）

  复盘的目的，避免是一个人犯过的错误，本人或者团队其他成员重复犯。既然是将一件事深化到团队内心，就要强调对事不对人，没必要强调犯错者，否则容易变成追责会，批斗会。个人惩罚问题可以私下沟通

  2023-02-01


• yanger2004 👍（1） 💬（0）

  知识和经验共享，共同提高。大家担心会追责，公开批评甚至影响绩效和晋升。

  2022-12-28


• 俞海军 👍（0） 💬（0）

  Case study 机制在团队已经推行一年，团队成员已经养成定期自我复盘，思考的习惯，在软件交付过程中解决问题的能力明显得到提升。

  2025-01-08


• 李二木 👍（0） 💬（0）

  跟事后复盘一个道理，原则就是同一个错误怎么避免再次发生。

  2024-07-15