Go上手笔记（五） 业务流程——从需求到运维｜ 青训营笔记

36Kr
192 阅读8分钟

这是我参与「第三届青训营-后端场」笔记创作活动的的第5篇笔记，如有错误还请指正。   【有船启航】

一. 流程意义

1. 团队规模和流程关系

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

2. 传统瀑布模型

image.png

敏捷开发

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

The Scaled Agile Framework (SAFe管理框架)简介

  • 精益产品开发
  • 敏捷软件开发
  • 系统思考
  • 现代的Scrum：
    • 敏捷教练Scrum Master
    • 产品负责人Product Owner
    • 敏捷团队Scrum Team
    • 敏捷发布火车 Agile Release Train
  • 人员&名词解释：
    • RD:研发
    • PM:产品经理
    • PRD:需求文档
    • UED:用户体验设计
    • QA:测试
    • Scrum1:敏捷团队1
    • P0/P1:优先级0/优先级1
    • Backlog:规划列表
  • 会议解释：
    • 待办事项整理会议(Backlog Grooming Meeting)：产品负责人描述下个迭代希望实现的用户故事，PM提出需求列表
    • 迭代计划会议(Sprint Planning Meeting)：选择迭代的任务和估算工作量
    • 每日站会(Standup Meeting)：昨天你做了什么？今天你将要做什么？你有需要帮助的地方吗？
    • 评审会(Review Meeting)：小组向产品负责人展示迭代工作结果
    • 反思会(Retrospective Meeting)：在每个迭代后召开简短的反思会，总结哪些事情做得好，哪些事情做得不好

二. 流程分类

1. 需求阶段（不要浪费时间讨论不应该存在的问题）

MVP (minimum viable product，最小化可行产品)思想要点

  • 核心功能
  • 站在用户的角度思考
  • 收集用户反馈，快速迭代

2. 开发阶段（云原生的时代）

部署形式发生了变化：

  • 传统虚拟机
    • 在物理主机中虚拟出多个虚拟机。每个虚拟机拥有自己的操作系统
    • 运维人员负责维护和交付虚拟机
    • 每个虚拟机中都要安装相应的依赖环境
  • 容器化
    • 容器是在操作系统中虚拟出来的
    • 通过cgroup，namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
    • 应用和其依赖作为一个整体，打包成镜像交付 架构发生了变化：
  • 单体架构
    • 多个模块共同组成一个服务，服务体量较大
    • 模块之间直接调用,不需要RPC通信
    • 服务整体扩缩容量
    • 多人开发一个代码仓库，需要充分集成测试
  • 微服务架构
    • 各个功能在不同的服务中
    • 不同模块需要进行RPC通信
    • 不同模块可以独立扩缩容
    • 每个服务的代码仓库仅由少部分人维护 团队的分支策略： 多个团队成员之间各自用什么分支开发?修改之间有冲突怎样解决?出了问题的代码如何回退到之前版本?

代码规范、自测和文档：

  • 代码规范
    • 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
    • 不要有魔法数字，魔法字符串
    • 重复的逻辑抽象成公共的方法，不要copy代码
    • 正确使用IDE的重构功能,防止修改错误
  • 自测
    • 单元测试
    • 功能环境测试
    • 数据构造
  • 文档
    • 大型改造需要有技术设计文档,方案评审
    • 好的接口文档能更方便的和前端进行沟通

3. 测试阶段

底层单元测试、集成测试、系统测试、UI测试

模型一：

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

4. 发布阶段

1. 发布要做的事情

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

2. 发布模式：

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

5. 运维阶段

问题：

  • 用户量增加引起流量洪峰(12306抢票)
  • 内存/进程泄漏导致服务资源不足
  • 光缆被挖断 关键动作：止损——上下游周知——定位问题——修复问题（止损最优先）

三. 流程执行

  1. 如何优化 传统中，在重视质量的团队，效率往往比较低，在重视效率的团队，事故往往比较多。 但！大人，时代变了。技术的发展会带来质量和效率的同时提高，将质量保障融入到流程,将流程自动化，从需求到上线全流程自动化，同时提高质量和效率。

  2. DevOps

    image.png

    从开发到运维的闭环（需求-编码-编译-测试-发布-部署-运维-监控）

image.png

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

  1. 全流程 自动化

如 价值流模型

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

总结

  1. 需求是要实现的一组设计目标，也是管理人员评估成本和项目时间的一种方式，但做之前一定要plan。

  2. 需要使用工具来适当地管理需求，特别是在项目规模大且许多人都在使用它的情况下。

  3. 花时间做需求计划可能要比实际实现需求更困难，但在待办事项整理会议上花费的每一秒，都会为以后实现需求省下大量时间。

在开发前，先把所有细致末梢整理好，可以避免以后反复修改，这可以为整个项目节省大量时间和支出。

avatar
文章
阅读
粉丝