课程 6.4 - 审计记录与责任归属¶
Scenario｜故事¶
“每个人都以为别人负责”¶
一个配置变更通过口头批准，一次 报价源 Incident 在聊天中讨论，Exposure 监控则“有人在看”。第二天，没有人能确认谁做了变更、验证了什么、后续是否完成。
运营治理的作用，就是防止这种模糊状态。
Learning Objectives｜学习目标¶
- 理解为什么审计记录和责任归属重要。
- 为 Incident、变更和复核定义责任人。
- 使用支持跟进和审计的简单记录。
- 区分责任与授权。
Governance Cycle｜治理循环¶
Incident / Change / Risk Signal
→
Assign Shift Leader / 当班负责人
ShiftLead
→
Approved Action
Action
→
Record Evidence
Evidence
→
Verify Result
Verify
→
Close or Escalate
Close
→
Periodic Review
Minimum Audit Trail｜最低审计记录¶
| 项目 | Minimum Record |
|---|---|
| Incident | Timeline, impact, Shift Leader / 当班负责人, actions, closure evidence |
| Change | Request, approval, configuration, test, verification, rollback plan |
| Risk review | Scope, data, conclusion, Shift Leader / 当班负责人, next action |
| Handover | Open items, priorities, named Shift Leader / 当班负责人 |
| Escalation | Message, recipient, timestamp, follow-up |
Responsibility vs Authority｜责任与授权¶
| Concept | Meaning |
|---|---|
| 项目 | Who performs or follows up the task |
| Accountability | Who is answerable for the outcome |
| Authority | Who is permitted to approve or execute action |
| Consultation | Who provides technical/risk input |
| Information | Who must be updated |
Dealer 可能负责记录和升级风险，但不一定有权修改生产参数。
Case Study｜案例¶
待处理变更缺少Shift Leader / 当班负责人¶
实战训练¶
真实场景
一个配置变更出现问题，但没有人能说明谁批准、谁执行、谁验证。
Dealer 应该看的证据
审批记录、变更时间、执行人、验证截图、影响范围、回滚计划。
错误示范
只在聊天里说“已经改了”，没有审计轨迹。
正确处理
记录 request、approval、change、verification、Shift Leader / 当班负责人 和 closure，让之后能复盘。
Summary｜总结¶
完成 6 Module A
完成标准¶
- 能说明本课的核心风险或操作目的
- 能指出需要查看的系统、数据或证据
- 能说明正确的升级或处理方式
- 已完成 Shift Leader / 当班负责人抽查或实操确认