3、多团队协作模型：DevSecOps中的角色划分与RACI矩阵
在云原生安全运行基线核验场景中，安全不再是单一团队的“守门员”职责，而是嵌入到开发、运维、SRE 的日常协作中。多团队协作模型的核心在于：明确每个角色在安全基线核验流程中的职责、权限与交付物，避免“安全推给运维、运维推给开发、开发说没时间”的恶性循环。
3.1 四大核心角色与职责边界
DevSecOps 将传统安全左移，同时要求右脑（运行时）持续验证。以下四个角色构成基线核验的协作闭环：
| 角色 | 核心职责 | 基线核验中的关键动作 | 常见误区 |
|---|---|---|---|
| 安全团队 (Security) | 定义基线标准、威胁建模、策略审计 | 制定容器/集群安全基线策略；审核合规报告；裁定例外豁免 | 只写文档不参与自动化，成为“纸上安全” |
| 运维团队 (Ops) | 环境稳定性、基础设施配置、变更管理 | 维护节点安全加固；管理网络策略与 RBAC 配置；执行基线扫描工具部署 | 被动执行安全策略，缺乏对基线漂移的主动感知 |
| 开发团队 (Dev) | 应用安全、依赖管理、镜像构建 | 在 CI 管道中集成镜像漏洞扫描；修复高危 CVE；确保 Dockerfile 符合安全基线 | 认为安全是“上线前的事”，忽略运行时基线 |
| SRE 团队 | 服务可靠性、可观测性、自动化运维 | 将基线核验指标接入监控告警；设计自愈策略（如自动隔离不合规 Pod） | 过度关注可用性而放宽安全基线阈值 |
协作要点： 安全团队负责“定标”，开发团队负责“达标”，运维团队负责“守标”，SRE 团队负责“验标”。四个角色缺一不可，且必须通过自动化工具链串联，而非人工邮件传递。
3.2 RACI 矩阵：责任到人，避免推诿
RACI 矩阵（Responsible 执行者、Accountable 决策者、Consulted 咨询者、Informed 知情者）是基线核验流程中消除职责盲区的有效工具。以下为云原生安全基线核验关键活动的 RACI 分配示例：
| 基线核验活动 | 安全 | 运维 | 开发 | SRE |
|---|---|---|---|---|
| 定义容器运行时安全基线 | A | C | C | I |
| CI 管道集成镜像漏洞扫描 | C | I | R | A |
| 集群节点安全加固与合规扫描 | C | R | I | A |
| 运行时基线漂移告警处理 | I | R | I | A |
| 安全例外申请与审批 | A | C | R | I |
| 基线核验指标面板设计与维护 | C | I | I | R |
RACI 使用原则：
- 每个活动有且仅有一个 A（决策者），避免多头领导导致基线策略冲突。
- R（执行者）可以多人，但需明确主执行人，例如“开发团队负责镜像扫描，SRE 负责扫描工具平台稳定性”。
- C（咨询者）和 I（知情者） 必须通过自动化通知（如 Webhook、IM 机器人）触达，不能依赖口头传达。
3.3 协作流程中的责任边界 SVG 图
下图展示了从基线定义到运行时核验的完整协作链路，以及各角色在关键节点的责任边界：
3.4 责任边界冲突处理原则
在实际协作中，角色边界模糊是常态。以下原则可帮助团队快速对齐：
- “谁定义谁解释”原则： 安全团队定义的基线策略，必须附带明确的判定标准和例外条件，避免运维团队在核验时自行“猜标准”。
- “谁执行谁升级”原则： 开发团队在 CI 中扫描到高危漏洞但无法修复时，应主动升级给安全团队（A）决策，而非搁置。
- “谁告警谁闭环”原则： SRE 团队发出的基线漂移告警，必须跟踪到运维团队（R）的修复确认，或安全团队（A）的例外批准，不能告警后无人跟进。
常见协作陷阱： 当安全团队同时担任 A（决策者）和 R（执行者）时，容易形成“安全团队既当裁判又当运动员”的局面，导致基线策略缺乏制衡。建议安全团队聚焦 A 和 C 角色，将 R 角色交给开发、运维或 SRE。
3.5 协作指标面板中的角色映射
在后续章节的指标面板设计中，每个指标都必须标注其对应的 RACI 角色，以便团队快速定位责任方。以下为示例映射：
| 指标名称 | 安全 | 运维 | 开发 | SRE |
|---|---|---|---|---|
| 镜像漏洞修复时长 (MTTR) | I | I | R | A |
| 节点合规率 | C | R | I | A |
| 运行时基线漂移次数 | I | R | I | A |
| 例外申请审批时长 | A | I | R | I |
通过将 RACI 矩阵与指标面板绑定，每个团队都能在面板上看到自己负责的指标状态，以及需要通知或咨询的相关方，从而实现“指标驱动协作”而非“会议驱动协作”。