一句话总结：

先看这个需求是否合理：需求评审会，再看这个需求给谁做：排期，那你打算怎么做：技术评审，做的怎么样：code review，测试介入。发布这个需求：上线

需求评审会：

这个实习生都不一定能参与，其实就是产品提完需求之后，大家一起聊一下这个需求的合理性，可行性和价值。一起对其一下对这个项目的理解。

排期：

看谁最近手里有空闲时间，就把这个需求给谁做。大厂内部都有一个类似日历的东西，相当于需求的时间管理表。你要和各个同学，比如产品，前端，测试协调好时间。

比如你说你1.6-1.9预估完成这个需求，那前端是不是预估1.9-1.10完成前端需求？测试是不是预估1.10-1.11完成这个需求？

技术评审：

聊一下你打算怎么做这个新需求。一般来讲后端同学都会出一份文档：

• 架构设计：要不要拆服务？用什么中间件（Redis/Kafka/ES）？
• 改动点：你都要对哪些服务进行修改？都会修改哪些东西？
• 数据库设计：新增哪些表？索引怎么建？会不会有分库分表需求？
• 接口设计：和前端 / 第三方系统的接口定义（入参、出参、异常码）；
• 风险点：高并发场景怎么防雪崩？数据一致性怎么保证？有没有兼容老系统的坑？
• 测试点：哪些场景要重点测？

说实话，这一步一定要认真写，不然后期写代码会很痛苦，很多需求跟自己设计方案里面想的不一样。尤其是刚去公司的实习生会犯这个错误，总想着赶快糊弄完技术评审文档。结果真正写代码的时候不停踩坑，需求不断延期。

codeReview：

拉个会议大家一起看一看你的代码写的怎么样，一起看看有没有什么你没想到的坑。

提测：

CR没问题之后，就可以交给测试同学测试了。验证功能完整性，有问题就返工修改。没问题的话就又可以进入下一个环节。

上线：

现在大厂内部的流水线已经很完善了。所以基本都是点点点就完成上线了。不需要你会各种命令。这里需要注意的是：灰度测试+流量低峰发布。

在正式发布之前，你会填一个表单之类的东西。相当于告诉所有人你要发布新版本了，这段时间内其他同学不要对这个服务搞事情，不然容易引发事故。

灰度测试：逐渐按照比例发布新版本。每发布一批之后都要观察监控数据（接口响应时间、报错率、服务器 CPU / 内存）。如果线上有异常之后方便回滚。

流量低峰发布：降低上线时候如果新版本有bug的影响面。

如果有问题了，就需要回滚，一般也还是点点点。不过如果你回滚了，一般会自动触发办公软件拉群。你需要解释一下你为什么回滚，遇到什么异常了？影响面是什么？

发布完之后，一般会再观察监控一两天，看一看还有没有什么问题。至此你就完成了一次完整的后端需求流程。

总结：

我是程序员牛肉，。文章来自我的学习笔记《牛牛八股》。如果你对后端有任何疑问的话，都欢迎私信我哦。希望我可以帮到你。

关注我，带你了解更多代码之外的生存之道。欢迎订阅我的专栏（目前免费），后续也会持续更新。如果这篇文章帮到了你的话，就送我朵花花吧。