记录一次A商城失败项目的复盘

注：本案列用STAR解读，讲述完整的事件

看了很多大佬都在分享关于自己的成功项目复盘，学到了很多东西。那我来给大家分享一个参与过的失败项目的复盘，希望能与大家一同学习一同进步。

项目背景：

A商城作为一个临时紧急的战略性需求，但前期业务范围、项目节奏均未完全明确，需要在一个极短的时间内上线A商城项目，且涉及的部门、业务条线特别广，从而风险性在逐步提升。我在A商城项目中担任落地活动页中数据下发的角色，其中涉及到收品，推荐排序，配置过滤，信息下发等任务。

项目问题：

1.在A商城上线之后，业务反馈页面数据不稳定。结合现象以及配合A团队研发排查猜测可能是缓存问题（当用户pin加入缓存白名单之后数据正常下发）。虽然前期在和产品沟通时，产品表明同一个页面的特殊id是一致的，但后续和A侧产研沟通后发现A商城的关键入参特殊id是从c端获取的，从而在不同调用方中特殊id可能会不同，这样就会产生缓存问题。考虑A商城现有以及未来的调用量，去掉A商城原有2min的缓存逻辑，后续通过多方协同对压测方案进行评审与执行解决该问题。

2.后置的供应链改造（8月上线）因为通用入参覆盖问题影响已上线的A商城需求（7月上线），表现行为是A商城商品下发的价格错误，前台展示页面异常。

项目改进过程：

业务反馈后快速进行代码修复。修复完成后，我做了如下改进：

1.考虑到后续改造可能还会影响到现有A商城逻辑，积极拉齐A团队和我们产品以及领导进行沟通，将A商城融入通用的供应链改造流程中。

2.完善A商城的质量体系来保证系统的稳定性。主要是通过全链路监控，定时任务去巡检A商城数据是否下发正常和降级限流来避免系统影响。

项目改进后结果：

在后续A商城二期需求中A+项目接入，由于前期A+项目无正式商品，仓里也无数据，业务也无法提供。在A+项目新入驻并创建完商品后，定时任务巡检第一时间发现数据下发异常，通过全链路监控中发现是某上游接口地址参数解析问题，及时沟通上游进行处理并告知业务暂停配置活动页，避免了再一次的问题产生。

经验教训总结：

1.需求要抱有敬畏之心，任何一个细微的问题都可能造成业务上的损失。在用户基数如此大的背景下，任何一个细微的问题都可能对大批用户造成影响，造成业务上的损失，因此在需求开发中要慎之又慎，勤思考。

2.新上线的功能需要格外注意是否会影响到现有逻辑，并对可能影响的功能整体回归一轮。若现有逻辑不合理或者过于定制，考虑迁移到新的逻辑中，所以需要将新逻辑做的通用且健壮。

3.系统的正向流程十分重要，但是系统的异常流程也要格外关注，不仅要输出足够的异常信息来快速排查定位问题，而对一些用户关注的异常信息，更要将这些信息系统化输出，更一步前置到产品、业务或者用户。