上线操作规范——基础版本
一 背景
最近团队成员的上线操作让人头疼。几个特别突出的问题:
1、上线准备不足,设计文档中没有体现、也没有考虑到可能的资源依赖,导致临操作了才想起来做资源申请;
2、暗箱操作... 一再要求上线时需要在群内周知,以便前后端、测试、产品共同配合完成,但依然不加理会,总是要主动询问才回复已操作;
3、发布完成就认为上线完成,有时甚至不做基本的校验...
二 关于上线的几个常识
(1)上线操作不只是发布代码!!!
(2)jenkins 点上线完成只是上线动作完成,不代表需求整体结束!!!
(3)上线操作完成且确认整个环节无问题,才算需求处理完成!!!
三 基础规范
0、上线准备
确保上线前依赖资源已经准备完成,包含但不仅限下列内容:
(1)域名、服务器、ci 流程、数据库、缓存等资源申请。 新服务上线需要向运维申请访问域名(内网 or 外网)
(2)刷数据,例如表结构变更、历史数据属性刷新等等类似需要上线前完成操作的数据,一定确保上线前完成处理!
1、上线步骤
技术设计文档中要体现,包括:
1-1 是否需要申请新资源、
1-2 是否需要先完成刷数据操作,
1-3 前后端上线的先后顺序;
1-4 后端上线时接口服务、脚本服务是否有上线顺序要求等;
1-5 新的接口权限申请(如果有接口权限配置管理,需要确保完成相应的权限申请)
2、上线操作
测试完成,上线操作时,需要在上线群同步上线消息:
1、发布即将上线操作预告,包括上线步骤及负责人;
2、上线操作完成后群内同步上线完成消息,如果还有后续步骤,@后续上线负责人完成下一步操作
3、负责上线内容的开发,上线完成后必须确认是否有明显问题! 例如上线后出现服务不可用、接口访问权限申请了但没生效等等
如果发现上线有问题,10 分钟内根据问题严重等级确认回滚 或 快速修复。评价标准:
(1)流程不可用且问题不能快速定位 => 回滚代码,并在上线群发部回滚操作通知;
(2)不影响配置核心流程,不能立即定位(10 分钟),上线群内先同步问题和进度,然后评估后续操作内容;
(3)非核心流程问题且能够在 10 分钟内定位问题原因并马上(30 分钟)修复 => 执行代码修复上线,修复完成并确认生效后后群内同步修复完成结果
评论