线上出问题时，最先发生的对话常常是"这不是我们的问题"。责任划分不清，会直接拉长故障时间——而且在复盘时同样会重演一次。
一、先把职责写成一张表
| 事项 | 开发 | 运维 |
|---|---|---|
| 代码缺陷 | 定位与修复 | 提供日志、环境与现场信息 |
| 环境与网络 | 提出需求与验证 | 负责配置与调整 |
| 性能优化 | 代码与SQL优化 | 资源、监控与容量评估 |
| 上线发布 | 提供发布说明与回滚方案 | 执行发布、监控与值守 |
| 数据问题 | 业务逻辑判断与修复脚本 | 执行、备份与核对 |
| 安全加固 | 修复代码层漏洞 | 基线、补丁与网络策略 |
表格不是万能的，但它能让"先找谁"这件事在十秒内解决。
二、交接环节最容易出事
- 开发交付必须包含：部署文档、配置项说明、依赖清单、回滚方式
- 运维验收必须确认：能独立部署、能看懂日志、能执行回滚
- 关键系统安排交接期共同值守
"能部署一次"才算交接完成
判断交接是否到位有个简单标准：运维独立部署一次，全程不找开发帮忙。做不到，说明文档还有缺口。
三、故障时的协作规则
- 先止损、后定位：谁在现场谁先动手，不等责任划分
- 指定一人统一指挥，避免多头操作
- 信息同步用统一渠道，避免信息碎片化
- 复盘对事不对人，关注流程改进而非追责
四、边界不是用来推责任的
划清边界的目的是"减少沟通成本"，不是"划清后互不相干"。真正的边界应当满足：常规问题各司其职，紧急情况下互相补位，事后按流程复盘。
五、定期一起过一遍线上问题
建议每季度由开发与运维共同回顾线上问题：哪些源于代码、哪些源于环境、哪些源于流程。共识就这样一次次对齐出来。边界写下来只是起点，一起复盘才让它活起来。
#职责边界#协作机制#交接流程#软件事业部
