可以交付,但要把“上线”从外包方的任务里拆出来,改成由你方持权限的人执行、外包方提供可复核的操作包。前提是双方先确认一件事:外包方不需要登录生产环境,也能通过代码仓库、构建产物和部署脚本完成绝大部分工作。剩下的最后一步,用一份写明命令、顺序和回滚点的操作说明来交接,由你方人员在自己可控的窗口内执行。这样做的代价是每次发布多一道人工步骤,收益是生产凭据始终不出你方边界。
生产权限通常混着三件事:改代码、改配置、碰数据。企业拒绝给权限,往往只针对其中一类,却把三类一起卡住,导致外包方连能做的部分也停了。先做一次归类,判断依据是动作发生的位置,而不是动作的名称。
归类之后你会发现,真正被权限卡住的只是第二、三类中的执行环节,而不是开发本身。把这三类写进交付清单,外包方的责任边界就清楚了:交付物是“可执行的变更”,不是“已经生效的线上状态”。
操作包是这套安排的核心。它要能让一个不了解项目细节、但懂基本运维的你自己人,照着做完一次发布。判断它是否合格,不看篇幅,看四个部分是否齐全。
一个假设的例子:外包方要新增一个表单提交接口。操作包里写明先执行建表脚本,再替换应用目录下的两个文件,然后重启服务,最后用一条查询确认新表有记录。你方人员按顺序执行,若重启后接口报错,就按回滚步骤换回旧文件并删除新表。整个过程中外包方没有接触生产环境,但交付是可验证的。
没有生产权限,验收就不能等到上线后看效果,否则问题会拖到发布窗口才暴露。可行的做法是把验收拆成两层,前一层在发布前完成。
发布前验收:外包方在代码仓库打标签或提交合并请求,你方检查提交内容是否与变更清单一致,构建产物能否在测试环境跑通。这一层能拦住大部分代码和配置错误。
发布后验收:你方执行完操作包,按验证命令逐项确认,把结果反馈给外包方。如果验证不通过,先按回滚步骤恢复,再带着具体现象回到发布前那一层排查。
这两层的分工决定了下一步动作:发布前不通过,退回外包方改;发布后不通过且回滚成功,说明问题出在环境差异或执行顺序,需要补充操作包细节,而不是重新开发。
权限受限时,沟通频率比平时更重要,因为一次执行失败就要等下一个窗口。建议把发布窗口固定下来,比如每周固定时段,外包方提前一天提交操作包,你方指定一名执行人和一名复核人。执行人照做,复核人对照验证命令确认结果,两人都不需要理解全部代码。
记录方式也要改。不要只记录“已上线”,而是记录本次操作包的版本、执行时间、每步验证结果和是否触发回滚。这些记录是下一次发布判断风险的依据:如果某个步骤连续两次需要回滚,就该要求外包方把它拆得更细,或者改由测试环境提前验证。
需要说明的是,生产环境没有出现异常,并不能单独证明操作包没有问题。也可能是本次变更未触及关键路径,或者验证命令覆盖不到的地方恰好没被使用。因此验证命令要覆盖本次变更直接影响的入口,而不是只确认服务能启动。
如果外包方坚持必须直接登录生产才能完成工作,而你又不能开放权限,那要重新判断的是合作方式,而不是继续加验证步骤。常见的不成立条件有两个:一是变更本身依赖生产环境的实时状态,比如排查只在线上复现的故障;二是你方没有能执行命令的人员,也没有人愿意承担执行责任。
遇到第一种情况,可以让外包方在测试环境复现,或由你方人员代为采集日志和状态信息,把排查变成一次信息交接。遇到第二种情况,需要先落实执行人,否则再完整的操作包也只能停在文档里。权限安排能否落地,最终取决于你方是否有人接住最后一步,而不是文档写得多细。