从需求到上线全流程

为什么会有流程

团队规模和流程

需求阶段：团队决策
开发阶段：协作配合
测试阶段：产品交付，Bug修复
发布阶段：版本和流量控制
运维阶段：应急响应，处理用户反馈和线上问题

传统的瀑布模型

类似马其顿方阵，是一个最直观的流程模型。每一阶段都要等上一阶段做完再开始做。

优点：可以尽可能保证产品的质量。是流程的理想化模型。
缺点：非常低效。

敏捷开发

更现代的流程模型。

特点：

以小团队快速迭代
团队成员之间的合作更加紧密
以人为本，和用户沟通

SAFe简介

SAFe是一套管理框架。

精益产品开发
敏捷软件开发
系统思考

字节团队的流程

RD：研发，PM：产品经理，PRD：需求文档， UED：用户体验设计，QA：测试，Scrum1：敏捷团队1，P0/P1：优先级0/优先级1，Backlog：规划列表。

有哪些流程

需求阶段

不要浪费时间讨论不应该存在的问题。

MVP（最小化可行产品）思想

站在用户的角度思考
收集用户反馈，快速迭代

四象限安排目标

重要且紧急（20%-25%）、重要但不紧急（60%-80%）、不重要不紧急（15%）、紧急但不重要（<1%）

开发阶段

云原生的发展，深刻改变了后端开发的工作。

云原生下的开发

以前——传统虚拟机

在物理主机虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
运维人员负责维护和交付虚拟机
每个虚拟机中都要安装相应的依赖环境

现在——容器化

容器是在操作系统中虚拟出来的
通过cgroup,namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
应用和其依赖作为一个整体，打包成镜像交付

以前——单体架构

多个模块共同组成一个服务，服务体量较大
模块之间直接调用，不需要RPC通信
服务整体扩缩容量
多人开发一个代码仓库，需要充分集成测试

微服务架构

各个功能在不同的服务中
不同模块需要进行RPC通信
不同模块可以独立扩缩容
每个服务的代码仓库仅有少部分人维护

开发环境

FasS、PaaS等技术，让开发逐渐从本地IDE向线上转变
通过WEB IDE等技术，环境为了将会开箱即用

团队的分支策略

制定使用什么样的分支、在什么阶段分配的规范。

代码规范、自测和文档

要有规范的代码风格
进行单元测试、功能环境测试和测试数据构造
大型改造需要有技术设计文档、方案评审，好的接口文档能更方便地和前端进行沟通

测试阶段

测试金字塔：单元测试->集成测试->系统测试->UI测试
越早发现缺陷修复的成本越低
功能环境、集成环境、回归环境

发布阶段

发布负责人、变更服务的相关RD、值班同学

各种发布模式

蛮力发布简单粗暴、直接用新版本覆盖老版本
金丝雀发布由于金丝雀对瓦斯极其敏感，因此矿工开矿下洞前，会先放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来。这种方法相对简单，可以用少量用户验证新版本功能。
滚动发布每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑。
蓝绿发布把服务分为蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级。
红黑发布和蓝绿发布类似，但是发布时会动态扩容出一组新的服务，而不需要常备两组服务。
总结：没有强大发布系统和服务器资源不足的公司一般使用蛮力发布或者金丝雀发布，有强大的发布工具和服务器资源充足的公司一般使用滚动发布和蓝绿发布。

运维阶段

-背景：用户量增加引起流量洪峰（如12306抢票）、数据库表的数据量增长导致查询速度变慢、内存/进程泄漏导致服务器资源不足、光缆被挖断

解决办法：对关键动作进行止损->周知->定位->修复，也可以通过日志进行跟踪

怎样优化流程

DevOps：开发运维形成闭环，可以持续集成交互CRCV。
效率竖井：流程中实际产生价值的部分很短，大量时间用在等待和传递上，人和人之间沟通很慢
全流程自动化：

通过效能平台串联各个阶段
- 需求发起研发过程的自动化
- 写代码、测试环境部署的自动化
- 自动化测试触发和报告分析
- 发布过程可观测融入流程
减少无价值的等待
- 分析整个流程的耗时、计算真正产生价值的时间
- 不断优化流程，让有价值的流程时间占比上升

后端开发的一周：

周一——产品功能演示和反思会：PM和UED准备明天要规划的需求列表
周二——Grooming会议：PO和PM阐述需求价值，Scrum　Master和架构师确认需求里的技术任务，制定分工
周三——提交火车发布车票：提交测试和火车发布申请，修复代码缺陷
周四——发布：检查发布异常，保证顺利发布，代码有问题要回滚和修复
周五——Planning：针对周二的需求进行工作量评估，然后进行排期

从需求到上线全流程 | 青训营笔记