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

这是我参与「第三届青训营-后端场」笔记创作活动的第7篇笔记。

1. 为什么要有流程

1.1 团队规模和流程的关系

复杂项目没有流程会有什么问题：

• 需求阶段：每个人都有自己的想法，团队决策需要有一个过程。
• 开发阶段：多人/多端协作开发，每个人有自己的安排，相互配合需要有一个流程。
• 测试阶段：产物怎样交付，测试如何开展，BUG怎么修复都需要流程。
• 发布阶段：怎样确保发布过程平稳，版本和流量如何控制，都需要有规范。
• 运维阶段：线上问题如何应急响应，处理用户反馈和线上问题需要有流程。

1.2 传统的瀑布模型

瀑布模型是工作流程的直观表达，定义了标准的研发阶段。它是以流程为本的理想化的模型。

流程：需求->开发->测试->发布->运维

优点：在重视流程的项目中有用，如银行、支付等。上线流程严格，层层审批，保证了不出事故。

缺点：效率低下。

1.3 敏捷开发

敏捷软件开发宣言：我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观。个体和互动高于流程和工具；工作的软件高于详尽的文档；客户合作高于合同判读；相应变化高于遵循计划。也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷开发方法以小团队快速迭代，团队成员之间的合作更加紧密，注重以人为本、和用户沟通。是更现代的流程模型。

具体方法如scrum、kanban等。

The Scaled Agile Framework(SAFe)简介： SAFe是一套管理框架，有多个scrum相互配合，共同完成项目。这个框架更加有利于精益产品开发、敏捷软件开发和系统思考。

现代的Scrum包含敏捷教练(Scrum Master)、产品负责人(Product Owner)、敏捷团队(Scrum Team)、敏捷发布火车(Agile Release Train)。

1.4 人员&名词解释

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

1.5 会议解释

• 代办事项整理会议（Backlog Grooming Meeting）：产品负责人（PO)描述下个迭代希望实现的用户故事，PM提出需求列表。
• 迭代计划会议（Sprint Planning Meeting）：选择迭代的任务和估算工作量。
• 每日站会（Standup Meeting）：昨天做了什么？今天要做什么？有什么需要帮助的地方？
• 评审会（Review Meeting）：小组向产品负责人展示迭代工作结果。
• 反思会（Retrospective Meeting）：在每个迭代后召开简短的反思会，总结哪些事做得好，哪些事做的不好。

2. 有哪些流程

2.1 需求阶段

1. 不要浪费时间讨论不应该存在的问题：有些需求一开始就不合理，因此需要砍掉无用的需求。
2. 最小化可行产品(minimum viable product,MVP)思想：先给顾客一个整体的抽象的架构，然后不断丰富内容。不要给客户一个具体的、部分内容，因为顾客看不到全貌。实现MVP思想需要站在用户的角度思考问题，收集用户的反馈快速迭代。
3. 四象限法：x轴从不紧急到紧急，y轴从不重要到重要。将事情分在四个象限中。事情的重要性不变而紧急性会变，尽量不要把事情拖到紧急。

2.2 开发阶段

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

传统虚拟机（传统）

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

容器化(云原生)

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

单体架构（云原生前）

• 多个模块共同组成一个服务，服务体量较大。
• 模块之间直接调用，不需要RPC通信。（优势：调用不需要网络；进程结构为线形，简单清晰）
• 服务整体扩缩容量。
• 多人开发一个代码仓库，需要充分继承测试。

微服务架构(云原生，将大型服务分解为多个子服务)

• 各个功能在不同的服务中。
• 不同模块需要进行RPC通信。（每个子服务都配置在独立的服务器上，网络开销大）
• 不同模块可以独立扩缩容。
• 每个服务的代码仓库仅有少部分人维护。

云原生下的开发

• 开发环境逐渐云原生化：环境逐渐部署于线上，用户远程调用而不需要本地配置。
• FaaS，PaaS等技术让开发逐渐从本地IDE向线上转变。
• 从入职领到电脑搭建完一套完整的开发环境需要很久，通过WEB IDE等技术，环境未来将会开箱即用。

团队的分支策略

• 多个团队成员之间各自用什么分支开发？
• 修改之间有冲突怎样解决？
• 出了问题的代码如何回退到之前版本？

代码规范

• 养成良好的注释习惯，人很难想起三个月前的代码在写什么
• 不要有魔法数字、魔法字符串。将它们定义成常量，方便阅读的人的理解。
• 重复的逻辑抽象成公共的方法，不要copy代码。代码分散在各个地方当修改起来将难以寻找，封装成函数只需要改一处。
• 正确使用IDE的重构功能，防止修改错误。
• 遵守团队的开发规范。

自测：单元测试、功能环境测试、测试数据构造。

文档：大型改造需要有技术设计文档，方案评审；好的接口文档能更方便的和前端进行沟通。

2.3 测试阶段

测试金字塔模型，从上到下为UI（用户界面）测试、系统测试、集成测试（不同人写的不同模块各自没有问题，但组合起来可能会发生问题）、单元测试。越底层功能越简单，但总体数量更多。如单元测试只可能只测一个函数，UI测试可能调用上万个函数。同时，上层的出错都是因为底层的出错，底层函数错一个可能为上层引入多个错误。因此越早发现缺陷修复的成本越低。

功能环境

• 需要一个能模拟线上的环境并行开发和测试。
• 环境和环境之间能够隔离，不影响其它功能的开发和测试。

集成环境

• 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷。
• 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷。

回归环境

• 确保新功能不对老功能产生影响。
• 回归测试一般会借助自动化测试脚本。

2.4 发布阶段

发布和回滚引发的问题往往是最多的。

调查服务端的bug例子：

1. 使用开发者工具（F12)可以看到一个请求的返回状态。
2. 使用curl检验接口，确定出问题的服务器。
3. 查看配置信息，定位具体成因。

发布负责人

• 负责按照计划执行发布
• 需要通知各个相关人员发布进展
• 观察各个服务的发布状态，及时处理异常

变更服务的相关RD

• 按照上线checklist检查服务的日志，监控，相应上线过程中的告警。
• 对于自己负责的改动，在小流量或者是预览环境进行功能验证。
• 执行发布计划中的其它操作（如线上配置，数据处理等）。

值班同学

• 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起。
• 如果有变更引起的告警或者用户反馈，需要及时中止发布。

发布模式	蛮力发布	金丝雀发布	滚动发布	蓝绿发布	红黑发布
方式	简单粗暴，直接用新版本覆盖老版本	对少部分用户试用，无问题再全用户覆盖	每个实例都通过金丝雀的方式逐步扩大流量，对用户影响小，体验平滑	把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组。最终两组全部升级。	与蓝绿发布相似，但发布时动态扩容出一组新的服务器，而不需要常备两组服务
优点	简单、成本低	相对简单、能够用少量用户验证新版本功能	发布过程中用户体验不会中断、可以充分验证服务功能	发布速度快，流程相对简单	发布速度快、流程相对简单
缺点	发布过程中服务会中断、出了问题会影响全部用户	发布过程中服务会中断、发现不了随用户量增大才会暴露的问题	流程较复杂，对发布系统有较高的要求。发布速度较慢、新老版本不兼容的情况下不能用	需要有一半机器承担所有流量的能力、出问题会影响全部用户	对机器数量仍有要求，需要能扩容一倍。出问题会影响全部用户
适用	测试环境部署、小公司或者非核心业务服务	测试环境部署、小公司或者非核心业务服务	发布系统能力较强，可以平滑切换流量。发布自动化程度高，可以自动回滚	服务器资源丰富的公司。新老版本不兼容的情况下需要一次性升级到新版	服务器资源丰富的公司。新老版本不兼容的情况下需要一次性升级到新版

2.5 运维阶段

常见问题：

• 用户量增长引起流量洪峰（12306抢票）。
• 数据库表的数据增长导致查找速度变慢。
• 内存/进程泄漏导致服务资源不足。
• 光缆被挖断。

应对步骤：

1. 止损：采用能够阻止损失的手段。
2. 周知：另服务上下游感知到服务出现问题。
3. 定位：精确问题出现的位置。
4. 修复：修复解决问题。

3. 怎样执行流程

3.1 如何优化流程

• 随着技术的升级，质量与效率不再不能兼得。技术的发展带来质量与效率的同时提高。
• 将质量保障融入到流程，将流程自动化。
• 从需求到上线全流程自动化，同时提高质量和效率。

3.2 DevOps

开发（Dev）和运维（Ops）形成闭环。（计划 >>> 编码 >>> 编译 >>> 测试）> (发布 >>> 部署 >>> 运维 >>> 监控)。第一个括号属于开发，第二个括号属于运维，循环往复。

解决方案：

• 代码管理
• 自动化测试
• 持续集成
• 持续交付

效率竖井

• 流程中实际产生价值的部分很短
• 大量的时间用在等待和传递上
• 任何人之间的沟通很慢

3.3 全流程自动化

通过效能平台串联各个阶段

• 需求发起研发流程的自动化
• 写代码、测试环境部署的自动化
• 自动化测试触发和报告分析
• 发布过程可观测融入流程

减少无价值的等待

• 分析整个流程的耗时，计算真正产生价值的时间
• 不断优化流程，让有价值的流程时间占比上升

4. 后端开发的一周

周一：产品功能演示和反思会。针对上个迭代开发的功能进行演示，反思上个迭代的不足（如果没有特殊问题可以跳过）。这一天，PM和UED已经准备好了明天要规划的需求列表。

周二：Grooming会议。总结上一周backlog里积累的需求，在会以上，PO和PM阐述各个需求的价值。Scrum Master和架构师确认需求中包含的技术任务。最终，会议确定下个迭代要做的需求有哪些，并将部分分配给你。

周三：提交火车发布车票。之前开发的需求需要上线，提交一个发布车票。对其他人提交的上线工单进行Code Review。修复代码缺陷。

周四：发布。之前提交车票的部分功能要在今天发布。发布过程中监控出现异常，马上中止了发布，定位分析原因。发现是自己代码的问题，需要进行回滚和修复。

周五：Planning会议。发现下个迭代只能完成x个需求，按照优先级把不能完成的需求移除迭代。对x个需求的工作量进行评估，把x个需求各自的开发和上线时间进行排期。