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

一、写在前面

流程在我们日常工作生活中是必不可少的，那关于流程方面我们将展开说说，希望看完的你有所收获

二、为什么要有流程

2.1、团队规模和流程的关系

为什么要有流程？

• 个人开发者是不需要流程的
• 超过一个人的团队就需要协作
• 随着团队规模上升，会出现全新的问题

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

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

2.2、传统的瀑布摸型

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

2.3、敏捷开发

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

2.4、名词解释

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

2.5、会议解释

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

三、有哪些流程

3.1、需求阶段

• 不要浪费时间讨论不应该存在的问题
• MVP(minimum viable product，最小化可行产品)思想
• 站在用户的角度思考
• 收集用户反馈，快速迭代
• 四大法则
  • 重要且紧急(20%~25%)
  • 重要但不紧急(60%~80%)
  • 不重要不紧急(15%)
  • 紧急但不重要(<1%)

3.2、开发阶段

• 从部署
  • 传统虚拟机
    • 在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
    • 运维人员负责维护和交付虚拟机
    • 每个虚拟机中都要安装相应的依赖环境
  • 容器化
    • 容器是在操作系统中虚拟出来的
    • 通过cgroup,namespace和Jnion Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
    • 应用和其依赖作为一个整体，打包成镜像交付
• 从架构
  • 单体架构
    • 多个模块共同组成一个服务，服务体量较大
    • 模块之间直接调用，不需要RPC通信服务整体扩缩容量
    • 多人开发一个代码仓库，需要充分集成测试
  • 微服务架构
    • 各个功能在不同的服务中
    • 不同模块需要进行RPC通信
    • 不同摸块可以独立扩缩容
    • 每个服务的代码仓库仅由少部分人维护
• 团队的分支策略
  • 多个团队成员之间各自用什么分支开发？
  • 修改之间有冲突怎样解决？
  • 出了问题的代码如何回退到之前版本？
• 代码规范、自测和文档
  • 代码规范
    • 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
    • 不要有魔法数字，魔法字符串
    • 重复的逻辑抽象成公共的方法，不要copy代码
    • 正确使用IDE的重构功能，防止修改错误
  • 自测
    • 单元测试
    • 功能环境测试
    • 测试数据构造
  • 文档
    • 大型改造需要有技术设计文档，方案评审
    • 好的接口文档能更方便的和前端进行沟通

3.3、测试阶段

• 功能环境
  • 需要一个能模拟线上的环境进行开发和测试
  • 环境和环境之间能够隔离，不影响其他功能的开发和测试
• 集成环境
  • 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
  • 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
• 回归环境
  • 确保新的功能不对老的功能产生影响
  • 回归测试一般会借助自动化测试脚本

3.4、发布阶段

3.4.1、发布过程中要做的事

• 发布负责人
  • 负责按照计划执行发布
  • 需要通知各个相关人员发布进展
  • 观察各个服务的发布状态，及时处理异常
• 变更服务的相关RD
  • 按照上线checklist检查服务的日志，监控，响应上线过程中的告警
  • 对于自己负责的改动，在小流量或者是预览环境进行功能验证
  • 执行发布计划中的其他操作（如线上配置，数据处理等）
• 值班同学
  • 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起
  • 如果有变更引起的告警或者用户反馈，需要及时中止发布

3.4.2、各种发布模式

蛮力发布 - 简单粗暴，直接用新版本覆盖老版本

优点
    简单
    成本低
缺点
    发布过程中服务会中断
    出了问题会影响全部用户
适用
    测试环境部署
    小公司或者非核心的业务服务

金丝雀发布 - 由于金丝雀对瓦斯极其敏感，因此以前矿工开矿下矿洞前，先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名

优点
    相对简单
    能够用少量用户验证新版本功能
缺点
    发布过程中服务会中断
    发现不了随用户量增大才会暴露的问题
适用
    测试环境部署
    小公司或者非核心的业务服务

滚动发布 - 每个实例都通过金丝雀的方式逐步放大流量，对用户影响小，体验平滑

优点
    发布过程中用户体验不会中断
    可以充分验证服务功能
缺点
    流程较复杂，对发布系统有比较高的要求
    发布速度较慢
    新老版本不兼容的情况不能使用
适用
    发布系统能力较强，可以平滑切换流量
    发布自动化程度高，可以自动滚动

蓝绿发布 - 把服务分成蓝绿两组，先把蓝组流量摘掉然后升级，只用绿组提供服务，之后切换全部流量，只用蓝组提供服务，然后升级绿组服务，最终两组全部升级

优点
    发布速度快
    流程相对简单
缺点
    需要有一半机器承担所有流量的能力
    出问题会影响全部用户
适用
    服务器资源丰富
    新老版本不能兼容的情况，需要一次性升级到新版

红黑发布 - 和蓝绿发布类似，但是发布时会动态扩容出一组新的服务，而不需要常备两组服务

优点
    发布速度快
    流程相对简单
缺点
    对机器数量仍然有要求，需要能扩容一倍
    出问题会影响全部用户
适用
    服务器资源丰富
    新老版本不能兼容的情况，需要一次性升级到新版

3.5、运维阶段

公司在发展过程中，逐渐形成了十分复杂的超大规模微服务体系。为了实现对这些复杂微服务的监控，我们往往会在微服务中添加埋点采集Metrics、Logging、分布式Trace等多种数据

四、流程怎样优化

在重视质量的团队，效率往往比较低
在重视效率的团队，事故往往比较多
技术的发展会带来质量和效率的同时提高
将质量保障融入到流程，将流程自动化
从需求到上线全流程自动化，同时提高质量和效率

DevOps解决方案

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

效率竖井

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

全流程自动化

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