一些开发团队没有专门的运维人员,研发运维都是团队自己来完成。

上线、生产环境的问题修复、紧急问题的响应,这些琐碎的事情会让消耗团队大量的精力和时间,如果不安排好工作方式和负责人,会造成大家凭积极性一拥而上,然后一哄而散的局面。

1. 概念

release。版本发布,一般都是一个迭代一次,也就是两周一次。会伴随着着功能的更新和缺陷的修复,小米公司的 MIUI 做到了数年的每个迭代的发布,备受好评。按迭代发布的好处是,团队获得了一种节奏感,不紧不慢的可持续发展。一般会使用代码分支测试、发布,并创建 tag 来管理版本。

hotfix。如果遇到生产环境的问题,需要立即处理并机动的发布,这种行为就是 hotfix。hotfix 需要在 release 的分支中修复、测试、发布,并且记得合并回 master 分支,否则下次 release 会丢失更改。

oncall。发布后,可能会有一些问题,需要有人值守处理反馈。负责 oncall 的人员需要分析问题,并找到合适的人来处理,尤其是节假日,oncall 的工作变得非常重要。

2. 人员安排

如果是一个敏捷团队,建议 release、hotfix 和 oncall 使用同一班人马,这些人员在团队内轮流参与:

  • 一位 deveops 人员:负责发布的变更执行,比如操作数据库备份、配置的变更、执行数据迁移脚本、流水线的触发等工作。
  • 一位值守的开发人员:负责处理发布后再遇到的问题,能快速修复的问题,尝试快速修复。如果是前后端分离的开发模式,需要前后端的开发人员一起参与。
  • 一位测试人员:负责预发环境的测试,和发布后的测试。
  • 一位产品经理(或 PO):负责和测试人员一起的验收测试,一起在发布时对出现的问题严重程度定级。如果过于严重,决定是否需要停止发布。

发布后的一个迭代内,这些人员需要继续负责 hotfix、oncall,直到下一次发布截止。这样计划的好处是,这些人有同样的上下文,也不不必为这些活动分开计划人员。

3. release 注意事项

  • 建立完善的流程,比如分支策略,发布手册等,可以在之前的文章中找到相关内容
  • 发布当天时间最好不要太晚,预留时间给测试验收
  • 测试人员对发布时出现的问题及时记录,不好马上关注在修复问题上,产品经理负责评估:
    • P0 必须及时修复,如果不能修复,回滚版本
    • P1 在第二天内修复,使用 hotfix 修复
    • P2 在迭代内修复,随下次上线发布给用户

4. hotfix 注意事项

  • hotfix 使用 release 的 git 分支,必须使用 pull request 的方式提交到分支。同时cherrypick 到 master,负责审核的 pull request 需要检查,相同的 commit 是否在 master 已经存在。
  • hotfix 必须先通过预发环境测试验证
  • hotfix 依然要遵守 release 流程,比如让测试人员验收合格

5. oncall 注意事项

  • 每日早上检查线上环境基本健康情况、线上告警
  • 每周做一次反馈检查,邮件组、问题反馈分类,和测试人员进行对接,如果有问题需要报告生产缺陷
  • 每周检查基础设施资源、有效期、错误日志分析
    • 资源包(CPU、内存、磁盘空间、出口带宽)
    • https 证书有效期
    • 域名有效期
    • 分析日志情况,如果有反复出现的错误日志需要分析原因
  • 节假日期间,外出需要带电脑,并保障通讯畅通
Last Updated:
Contributors: lin