关于DORA

DORA 详解

DORA 在不同领域有不同含义，我来介绍两个最常见的：

---

一、DORA (Digital Operational Resilience Act) - 数字运营韧性法案

1. 定义

DORA (数字运营韧性法案) 是欧盟针对金融行业的法规，旨在确保金融机构能够抵御、应对和恢复各类 ICT（信息通信技术）相关的干扰和威胁。

1 2	DORA = 欧盟金融行业的数字运营韧性监管框架 生效时间: 2025年1月17日

2. 适用范围

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

DORA 适用实体: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 金融实体 (约 22,000 家) │ │ ├── 银行和信贷机构 │ │ ├── 支付机构 │ │ ├── 电子货币机构 │ │ ├── 投资公司 │ │ ├── 保险公司 │ │ ├── 资产管理公司 │ │ ├── 养老基金 │ │ ├── 信用评级机构 │ │ ├── 加密资产服务提供商 │ │ └── 众筹平台 │ │ │ │ 关键 ICT 第三方服务提供商 │ │ ├── 云服务提供商 (AWS, Azure, GCP) │ │ ├── 数据中心 │ │ ├── 软件供应商 │ │ └── 数据分析服务商 │ │ │ └─────────────────────────────────────────────────────────────┘

3. 五大核心支柱

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

DORA 五大支柱: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 支柱1: ICT 风险管理 (ICT Risk Management) │ │ ├── 建立完善的 ICT 风险管理框架 │ │ ├── 识别、分类和记录 ICT 资产 │ │ ├── 持续风险评估和监控 │ │ ├── 保护和预防措施 │ │ ├── 检测异常活动 │ │ └── 业务连续性和灾难恢复计划 │ │ │ │ 支柱2: ICT 事件报告 (ICT Incident Reporting) │ │ ├── 建立事件分类和报告流程 │ │ ├── 重大 ICT 事件须向监管机构报告 │ │ ├── 初始报告: 事件发生后 4 小时内 │ │ ├── 中期报告: 1 周内 │ │ └── 最终报告: 1 个月内 │ │ │ │ 支柱3: 数字运营韧性测试 (Digital Resilience Testing) │ │ ├── 定期进行韧性测试 │ │ ├── 漏洞扫描和评估 │ │ ├── 渗透测试 │ │ ├── 威胁导向渗透测试 (TLPT) - 关键实体每 3 年一次 │ │ └── 场景化测试和演练 │ │ │ │ 支柱4: ICT 第三方风险管理 (ICT Third-Party Risk) │ │ ├── 第三方服务商风险评估 │ │ ├── 合同条款要求（审计权、退出策略等） │ │ ├── 集中度风险管理 │ │ └── 关键 ICT 服务商登记 │ │ │ │ 支柱5: 信息共享 (Information Sharing) │ │ ├── 鼓励金融实体间共享威胁情报 │ │ ├── 网络威胁信息交换 │ │ └── 最佳实践分享 │ │ │ └─────────────────────────────────────────────────────────────┘

4. 关键要求详解

4.1 ICT 风险管理框架

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

ICT 风险管理要求: ├── 治理架构 │ ├── 管理层责任和问责 │ ├── ICT 风险管理策略 │ └── 独立的 ICT 风险控制职能 │ ├── 资产管理 │ ├── ICT 资产清单 │ ├── 资产分类和重要性评级 │ └── 配置管理 │ ├── 保护措施 │ ├── 网络安全 │ ├── 访问控制 │ ├── 数据加密 │ └── 物理安全 │ ├── 检测能力 │ ├── 持续监控 │ ├── 异常检测 │ └── 威胁情报 │ └── 恢复能力 ├── 业务连续性计划 (BCP) ├── 灾难恢复计划 (DRP) ├── 备份策略 └── 恢复测试

4.2 第三方风险管理

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

ICT 第三方服务商管理: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 服务商评估 │ │ ├── 尽职调查 │ │ ├── 风险评估 │ │ ├── 财务稳定性 │ │ └── 安全能力评估 │ │ │ │ 合同要求 │ │ ├── 服务级别协议 (SLA) │ │ ├── 安全要求 │ │ ├── 数据保护条款 │ │ ├── 审计权 │ │ ├── 分包商管理 │ │ ├── 终止和退出策略 │ │ └── 数据可移植性 │ │ │ │ 持续监控 │ │ ├── 服务质量监控 │ │ ├── 安全状况监控 │ │ └── 定期审查和评估 │ │ │ │ 集中度风险 │ │ ├── 避免过度依赖单一供应商 │ │ └── 制定替代方案 │ │ │ └─────────────────────────────────────────────────────────────┘

5. DORA 与其他法规的关系

法规	关系
GDPR	DORA 补充 GDPR，专注于运营韧性
NIS2	网络安全指令，DORA 是金融行业特别规定
PSD2	支付服务指令，DORA 加强其安全要求
MiCA	加密资产法规，DORA 提供运营韧性框架

6. 处罚机制

1 2 3 4 5 6 7

DORA 处罚: ├── 金融实体 │ └── 由各成员国监管机构确定，可包括罚款、吊销许可等 │ └── 关键 ICT 第三方服务商 ├── 最高 €5,000,000 或全球年营收 1% └── 每日罚款最高 €500,000 (持续违规)

7. 对支付机构的影响

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

支付机构 DORA 合规重点: ├── 支付系统韧性 │ ├── 核心支付系统高可用 │ ├── 实时监控和告警 │ └── 快速恢复能力 │ ├── 云服务商管理 │ ├── 主要云服务商合同审查 │ ├── 多云策略考虑 │ └── 退出计划准备 │ ├── 事件响应 │ ├── 重大事件 4 小时内报告 │ ├── 事件分类标准 │ └── 根因分析流程 │ └── 测试要求 ├── 定期渗透测试 ├── 业务连续性演练 └── 灾难恢复测试

---

二、DORA (DevOps Research and Assessment) - DevOps 研究与评估

1. 定义

DORA 也指 Google Cloud 的 DevOps 研究团队，以及他们提出的衡量软件交付效能的四个关键指标。

1	DORA Metrics = 衡量 DevOps 效能的"黄金指标"

2. DORA 四大指标

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

DORA 四大指标: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 1. 部署频率 (Deployment Frequency) │ │ └── 组织成功部署到生产环境的频率 │ │ │ │ 2. 变更前置时间 (Lead Time for Changes) │ │ └── 从代码提交到成功部署到生产的时间 │ │ │ │ 3. 变更失败率 (Change Failure Rate) │ │ └── 导致生产故障需要修复的部署百分比 │ │ │ │ 4. 服务恢复时间 (Time to Restore Service / MTTR) │ │ └── 从生产故障到恢复服务的时间 │ │ │ └─────────────────────────────────────────────────────────────┘ 前两个指标衡量"速度"，后两个指标衡量"稳定性"

3. 效能等级划分

等级	部署频率	变更前置时间	变更失败率	恢复时间
Elite	按需（一天多次）	< 1 小时	0-15%	< 1 小时
High	每天到每周	1 天 - 1 周	16-30%	< 1 天
Medium	每周到每月	1 周 - 1 月	16-30%	< 1 天
Low	每月到每半年	1 月 - 6 月	16-30%	> 1 周

4. 指标详解

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

部署频率 (Deployment Frequency): ┌─────────────────────────────────────────────────────────────┐ │ 问题: 你的团队多久部署一次代码到生产环境？ │ │ │ │ Elite: 按需（一天多次） │ │ High: 每天到每周 │ │ Medium: 每周到每月 │ │ Low: 每月到每半年 │ │ │ │ 提升方法: │ │ ├── 自动化 CI/CD 流水线 │ │ ├── 小批量、频繁发布 │ │ ├── 特性开关 (Feature Flags) │ │ └── 主干开发 (Trunk-based Development) │ └─────────────────────────────────────────────────────────────┘ 变更前置时间 (Lead Time for Changes): ┌─────────────────────────────────────────────────────────────┐ │ 问题: 从代码提交到成功运行在生产环境需要多长时间？ │ │ │ │ Elite: < 1 小时 │ │ High: 1 天 - 1 周 │ │ Medium: 1 周 - 1 月 │ │ Low: 1 月 - 6 月 │ │ │ │ 提升方法: │ │ ├── 自动化测试 │ │ ├── 自动化部署 │ │ ├── 减少审批环节 │ │ └── 小批量变更 │ └─────────────────────────────────────────────────────────────┘ 变更失败率 (Change Failure Rate): ┌─────────────────────────────────────────────────────────────┐ │ 问题: 部署后导致故障需要回滚或修复的比例是多少？ │ │ │ │ Elite/High/Medium: 0-15% │ │ Low: 46-60% │ │ │ │ 降低方法: │ │ ├── 充分的自动化测试 │ │ ├── 代码评审 │ │ ├── 金丝雀发布 │ │ ├── 蓝绿部署 │ │ └── 监控和快速回滚 │ └─────────────────────────────────────────────────────────────┘ 服务恢复时间 (Time to Restore Service): ┌─────────────────────────────────────────────────────────────┐ │ 问题: 从生产故障发生到服务恢复需要多长时间？ │ │ │ │ Elite: < 1 小时 │ │ High: < 1 天 │ │ Medium: < 1 天 │ │ Low: 1 周 - 1 月 │ │ │ │ 缩短方法: │ │ ├── 完善的监控告警 │ │ ├── 快速回滚机制 │ │ ├── 故障演练 (Chaos Engineering) │ │ ├── 事件响应流程 │ │ └── On-call 机制 │ └─────────────────────────────────────────────────────────────┘

5. 2023 年新增指标

1 2 3 4 5 6 7 8 9 10 11 12

可靠性 (Reliability): ┌─────────────────────────────────────────────────────────────┐ │ 2023 年 DORA 报告新增第五个指标 │ │ │ │ 定义: 团队是否达到或超过其可靠性目标 │ │ │ │ 衡量方式: │ │ ├── SLO 达成率 │ │ ├── 可用性百分比 │ │ └── 用户体验指标 │ │ │ └─────────────────────────────────────────────────────────────┘

6. 如何实施 DORA 指标

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

DORA 指标实施步骤: ┌─────────────────────────────────────────────────────────────┐ │ │ │ 1. 数据收集 │ │ ├── CI/CD 系统 (Jenkins, GitLab CI, GitHub Actions) │ │ ├── 版本控制 (Git commit 时间) │ │ ├── 部署系统 (部署时间、频率) │ │ ├── 事件管理 (PagerDuty, OpsGenie) │ │ └── 监控系统 (故障检测时间) │ │ │ │ 2. 指标计算 │ │ ├── 自动化数据采集 │ │ ├── 定期计算和汇总 │ │ └── 可视化展示 │ │ │ │ 3. 分析改进 │ │ ├── 识别瓶颈 │ │ ├── 制定改进计划 │ │ └── 持续跟踪效果 │ │ │ └─────────────────────────────────────────────────────────────┘

7. 常用工具

工具	用途
Sleuth	专门的 DORA 指标追踪
LinearB	工程效能分析
Jellyfish	工程管理平台
Faros AI	工程数据平台
GitLab	内置 DORA 指标
Grafana	自建 Dashboard

---

两种 DORA 的对比

维度	DORA (欧盟法规)	DORA (DevOps 指标)
全称	Digital Operational Resilience Act	DevOps Research and Assessment
领域	金融监管合规	软件工程效能
发布方	欧盟	Google Cloud
性质	法律强制要求	最佳实践指标
适用对象	金融机构	所有软件团队
目标	运营韧性	交付效能

---

总结

如果你是金融/支付行业：

• 关注 DORA 法案，确保 2025 年 1 月前合规
• 重点：ICT 风险管理、事件报告、第三方管理、韧性测试

如果你是软件研发团队：

• 关注 DORA 指标，衡量和提升交付效能
• 重点：部署频率、前置时间、变更失败率、恢复时间

需要我进一步展开某个方面吗？比如 DORA 法案的合规检查清单，或者 DORA 指标的具体实施方案？