面向DORA运营弹性的外部合成监控

操作弹性 · 信息与通信技术风险管理 · 金融服务

《数字运营弹性法案》（DORA），欧盟法规 (EU) 2022/2554，自2025年1月17日起适用于欧盟金融实体。其核心目标之一是要求企业及时检测信息与通信技术（ICT）事件，并保持支持关键或重要功能的服务可用性。

实现该目标需要监控能够反映面向客户服务的实际可用性，而不仅仅是其背后系统的内部健康状况。内部可观测性工具从企业网络内部报告基础设施状态，但无法确认服务是否从外部用户的视角可达且功能正常。外部合成监控通过在定义的时间表上，从网络之外的地点对生产服务执行脚本交易来解决这一问题。

本文识别了与持续监控和检测相关的具体DORA义务，并阐述了外部合成监控，尤其是Dotcom-Monitor平台如何满足这些义务。

DORA的检测与可用性义务

DORA基于结果而非规定工具。它不强制特定监控产品或检查频率。它确立了检测、可用性和监管义务，而监控则是履行多项义务的操作控制。以下四条规定最为相关。

第9条（保护与预防）要求金融实体持续监控和控制ICT系统和工具的安全性及运行功能。此义务为持续性质，排除了周期性或手动检查本身作为充分控制。

第10条（检测）要求建立机制，及时检测异常活动，包括ICT网络性能问题和ICT相关事件，并识别潜在的关键单点故障。第10条第2款进一步要求检测机制应支持多层控制，定义预警阈值，并向负责事件响应的人员发送自动预警。

“金融实体应建立机制，及时检测异常活动，包括ICT网络性能问题和ICT相关事件。”
DORA，第10条（检测）

第17条和第19条（事件管理与报告）要求制定ICT相关事件管理的文件化流程，对于被归类为重大事件的，应在监管机构规定的以小时计的截止时间内通知主管部门。通知速度直接依赖于检测速度。

第28条（ICT第三方风险）要求实体管理并监督ICT第三方服务提供商带来的风险。若供应商支持关键或重要功能，其可用性纳入实体的监控范围。

根据上述规定，需具备五项监控能力：持续监控、及时事件检测、可用性验证、第三方ICT监督以及服务降级预警。以下各部分依次详述。

外部验证的作用

内部工具，包括应用性能管理（APM）、服务器指标和日志分析，从网络内部监测系统。它们准确报告基础设施状态，但无法检测发生在用户与服务器之间的某些故障，具体包括：

• 针对特定地区或网络用户解析错误的DNS变更。
• 客户端拒绝的已过期或配置错误的TLS证书。
• 数据中心入口路径上的CDN或ISP路由故障。
• 第三方脚本或API阻塞，导致页面无法完成加载。
• 负载均衡器对健康检查返回有效响应，但无法完成完整用户交易。

在上述各类状况中，内部监控报告正常，然而服务对用户不可用。外部合成监控从网络外执行用户交易，因此能在影响用户的地点登记故障。

外部验证还具备合规的证据价值。当可用性测量来源于被测系统之外时，向审查者展示的记录更具可信度。独立且带时间戳的可用性数据支持伴随DORA检测要求的审计和报告义务。

DORA要求与Dotcom-Monitor能力映射

以下小节列出各项要求及对应的满足能力。Dotcom-Monitor是一款从网络外执行检查的合成监控平台，与上述检测与可用性义务相契合。

持续监控（第9条）

要求。持续监控和控制支持面向客户服务的ICT系统运行功能。

满足方法。按定义间隔（最短可达一分钟）运行的定时合成检查，提供连续覆盖受监控服务。网页应用监控在真实浏览器中加载服务，测量渲染结果，非仅确认服务器响应，从而持续记录服务对用户的实际功能表现。

异常活动的及时检测（第10条）

要求。及时检测异常活动，包括ICT网络性能问题及事件，识别关键单点故障。

满足方法。合成交易失败或超出响应时间限制，独立于用户报告即能检测异常。使用EveryStep录制工具脚本化完整流程，将检测范围扩展至多步骤流程（如认证、支付、开户），其中任一步失败即构成事件。

预警阈值和自动告警（第10条第2款）

要求。定义预警阈值，向负责事件响应的人员提供自动告警。

满足方法。可配置告警，基于预定义条件（如响应时间超限、错误响应或交易步骤失败）触发。告警自动发送至邮箱、短信或集成事件管理工具，通知指定响应人员而非共享队列。基于降级（非完全故障）的阈值告警满足第10条第2款对多层控制的要求。

可用性验证与审计证据

要求。证明支持关键或重要功能的服务保持可用，并提供适用于审计和事后审查的记录。

满足方法。正常运行时间和服务水平报告记录带时间戳的服务可用性历史。因测量起点位于网络外，该记录构成独立的可用性证据及任何中断的时间和持续性证据，支持内部审查和监管审查。相关可用性目标详见平台正常运行监测资源。

ICT第三方监督（第28条）

要求。监控支持关键或重要功能的ICT第三方供应商的可用性和性能。

满足方法。API监控检查应用依赖的REST、SOAP及GraphQL端点，包括第三方提供的。在运营中使用的托管应用，SaaS监控直接跟踪供应商可用性，使实体拥有独立的依赖可视性，而非依赖供应商的状态报告。

早期预警和事件报告（第10、17、19条）

要求。提前预警服务降级，及时检测重大事件以满足报告时限。

满足方法。由于持续从网络外运行检查，降级和故障能接近事件发点被发现，缩短事件发生到被察觉的时间。这一点对第17、19条尤为重要，重大事件的通知截止时间以小时计。更早检测增加对事件进行分类、响应和上报的时间。该能力支持早期故障检测，且在金融服务的合成监控讨论中进一步剖析。

内部系统覆盖

要求。在监控公共服务之外，还需监控支持关键或重要功能的内部应用。

满足方法。公共服务由全球监控网络检查；防火墙后内部应用由部署在实体环境内的私有代理检查，利用单一平台对内外系统执行相同检查。

需求与能力总结

下表整合了上述映射关系。

示例检测盲点

两类故障阐明为何需外部验证，内部监控无法独立检测。

区域性DNS配置错误。DNS变更导致某单一ISP解析错误。服务器端指标保持正常，因为受影响的请求未抵达基础设施。来自受影响区域的外部检查在其下一周期记录故障并发出预警，指示受影响位置。

第三方认证延迟。外部身份提供商可用但响应缓慢，认证额外延迟数秒，无内部错误提示。完整登录的合成交易测量到响应时间异常，超过配置阈值，并将依赖关系识别为问题源头。这即是第28条要求的第三方供应商可视性。

推荐监控配置

以下配置建立了与上述检测和可用性义务对齐的监控基线，优先考虑关键路径而非穷尽覆盖。

步骤1：识别关键或重要功能。列举面向客户的服务，若失败需报告事件，例如认证、支付、转账、开户和账单访问，作为监控优先级。

步骤2：脚本化完整用户流程。对每项功能，使用EveryStep录制器录制全用户流程，结束于证明服务功能完成的步骤（如转账成功或账户视图加载）。仅检查首页无法检测后续步骤的失败。

步骤3：选择相关地点监控。选择对应实体客户地理位置的监控点，利用全球监控网络，以检测区域性故障。

步骤4：监控第三方依赖。为关键功能依赖的第三方API和托管应用配置独立检查，以便识别故障归属实体或供应商。

步骤5：定义阈值与告警路由。设定响应时间和错误条件的告警阈值，将告警送达指定响应人员及事件管理系统。对降级与完全故障均配置告警。

步骤6：保存可用性记录。从一开始启用正常运行时间和SLA报告，使可用性历史自动积累，便于审计和事后检视。

步骤7：扩展至内部系统。为支持关键功能的内部应用部署私有代理，确保这些系统获得同等的持续检查。

范围与限制

外部合成监控是DORA计划中的一项控制措施，非单独满足全部法规要求。它提供可用性验证和及时检测，但不包含ICT风险治理、事件分类与报告流程、威胁驱动渗透测试、备份与恢复，亦不涵盖DORA对第三方供应商合同安排的要求。这些义务由实体弹性计划内的其他控制措施履行。

合成监控仅验证已脚本化的交易。未配置的用户流程不在监控范围内，故监控覆盖需随服务变更持续维护。在此定义范围内，外部合成监控提供其他控制很难产生的检测和可用性证据。

结论

DORA要求金融实体及时检测ICT事件，并维持及证明支持关键或重要功能的服务可用性。内部监控报告基础设施状态，无法检测发生于用户与服务器间的故障。外部合成监控持续从网络外及相关区域验证完整用户交易，包括第三方依赖，保留带时间戳的结果记录。

这些能力直接对应第9条的持续监控义务、第10条的检测与告警义务、第17和19条的时效要求及第28条的第三方监督。外部合成监控本身非DORA合规的全部，但为满足其检测和可用性要求提供直接且有据的手段。

常见问题解答