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

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

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 证书有效期
  • 域名有效期
  • 分析日志情况，如果有反复出现的错误日志需要分析原因
• 节假日期间，外出需要带电脑，并保障通讯畅通