目录
- 这些报告时限到底要求什么
- 为什么报告时限本质上是「叫醒」问题
- 周末能多给你一点时间吗？
- 如何在报告流程前面放上一通响铃的电话
- 第 1 步 —— 建一个只给可上报事件用的 Calling 频道
- 第 2 步 —— 把检测链路指向这个 webhook
- 第 3 步 —— 用条件筛选，只让真正的候选事件响铃
- 第 4 步 —— 接住那些只会发邮件的系统
- 第 5 步 —— 让扛时限的人也订阅同一个频道
- 第 6 步 —— 开着勿扰模式做一次实测
- Echobell 不做什么
- 常见问题
- 用了 Echobell 就算符合 DORA 或 NIS2 了吗？
- DORA 的 4 小时到底从什么时候开始算？
- NIS2 的早期预警需要写全部细节吗？
- 我们的监控已经会给值班工程师发邮件，这还不够吗？
- 合规和工程能收到同一条告警吗？
- 电话真的能穿透勿扰模式吗？
- 这只适用于 iOS 吗？
- webhook 载荷里应该放什么数据？
- 相关内容
欧盟所有事件报告时限，都是从机器察觉到的那一刻开始计时的，而且你的团队睡着时它也照走不误。如果启动倒计时的那条告警，是周日凌晨 2:40 的一条静音推送，那么在第一个人看到它之前，你已经烧掉了 DORA 报告窗口的四分之一。本文讲清如何用 Echobell 在报告流程前面放上一通真正响铃的电话——让倒计时和你的响应几乎同时开始。
这件事的规模现在有了实测数据。2026 年 6 月 3 日，欧盟三大监管局（ESAs）发布了 DORA 下重大 ICT 相关事件的首份全欧概览：2025 年共报告 3,383 起重大事件，平均每家适用 DORA 的金融实体 0.18 起，其中约三分之一具有跨境影响（EBA、ESMA）。真正应该影响你告警设计的细节是：只有 10% 与网络安全有关，系统故障和外部事件才是主要成因。
换句话说，启动监管倒计时的事件，绝大多数都是最平淡无奇的那类——一次失败的发布、一个挂掉的依赖、一次供应商中断。也就是你的监控系统本来就会在凌晨三点抓到、然后推送到一台开着「勿扰模式」的手机上的那些东西。
这些报告时限到底要求什么
**三套制度、三个不同的起算点——而且全都按真实时间走。**下面是现行文本的规定。
| 制度 | 第一道时限 | 其次 | 最后 |
|---|---|---|---|
| DORA（欧盟金融实体） | 在将事件定级为重大后 4 小时内提交初始通知，且不得晚于知悉该事件后 24 小时 | 初始通知后最迟 72 小时提交中间报告 | 最后一次中间报告后不晚于 一个月 提交最终报告 |
| NIS2（欧盟关键与重要实体） | 在知悉重大事件后不得无故拖延，且无论如何须在 24 小时内提交早期预警 | 知悉后 72 小时内提交事件通知 | 事件通知后不晚于 一个月 提交最终报告 |
| SEC 第 1.05 项（美国上市公司） | 在认定事件具有重大性后，一般须在 4 个工作日内提交 8-K 表格 | — | — |
DORA 的时限来自《委员会授权条例 (EU) 2025/301》——关于事件报告内容与时限的监管技术标准，2025 年 2 月 20 日公布，用以补充《条例 (EU) 2022/2554》（欧盟委员会、第 5 条原文）。DORA 本身自 2025 年 1 月 17 日起适用（ESMA）。
NIS2 的时限见《指令 (EU) 2022/2555》第 23 条第 4 款；成员国须在 2024 年 10 月 17 日前完成转化（欧盟委员会）。SEC 的时限来自 2023 年 7 月 26 日通过的网络安全披露规则（SEC）。
为什么报告时限本质上是「叫醒」问题
因为这些时钟没有一个是按你的工作时间锚定的。 DORA 从定级和实体知悉起算，NIS2 从实体知悉起算，SEC 从重大性认定起算。某一时刻是否构成「知悉」，是你的合规部门要做的法律判断——但这些文本里没有任何一条，会因为第一个看到告警的人当时在睡觉而重新计时。
把 DORA 最紧的那条路径倒推一遍。从事件被定级为重大起你只有 4 小时，而定级不可能发生在有人看它之前。假设检测发生在 2:40，直到 8:00 才有人确认，再花 90 分钟调查完成定级，那么初始通知大约在 11:00 提交——仍在 24 小时上限之内，但 24 小时的额度里有八个多小时纯粹花在了睡觉上。把确认延迟压缩掉，后面每一步都能喘口气。
这不是在鼓吹对更多事情发告警。恰恰相反：只有一类范围很窄的告警——那些有可能演变成需上报事件的——应当在物理上无法被睡过去，其余的都该保持安静。（如果你的团队已经被告警淹没，先看修复告警疲劳，再考虑加一个更吵的通道。）
周末能多给你一点时间吗？
在 DORA 下能一点点——而且很可能轮不到你。《授权条例 (EU) 2025/301》允许：若时限落在该实体所在成员国的周末或法定假日，可在下一个工作日中午前提交。但同一条款明确把这项延展排除在信贷机构、中央对手方、交易场所运营者，以及 NIS2 下的关键或重要实体之外；主管当局还可对其他具系统重要性的实体取消该延展（第 5 条、Advisera 摘要）。
也就是说，最可能在周日夜里出事的那些机构，恰恰是完全享受不到周末缓冲的。NIS2 第 23 条本身根本没有周末延展。请按「周六和周二一样走」来规划，把你恰好符合条件的延展当成意外之喜，而不是可依赖的余量。
如何在报告流程前面放上一通响铃的电话
Echobell 只做一件事：把 webhook 或邮件变成一通电话——一通真正响铃、震动、像家人来电那样冲破 iOS 专注模式与勿扰模式的电话（参见绕过 iOS 专注模式接收关键告警）。它站在「检测到事件的系统」和「必须启动倒计时的人」之间。
第 1 步 —— 建一个只给可上报事件用的 Calling 频道
在 Echobell 中新建频道，把通知类型设为 Calling。这正是让手机响铃、而不是收到一条静音推送的关键（通知类型）。给它一个不会被误解的名字——「可上报事件 · 立即叫醒」——并且只用于这一件事。从频道详情复制 webhook URL，形如 https://hook.echobell.one/t/<channel-token>，请当作密钥保管。
第 2 步 —— 把检测链路指向这个 webhook
无论是什么系统发现了事件，都向该频道 URL 发一个 HTTP 请求。Echobell 提供了 Grafana、Prometheus Alertmanager、Uptime Kuma 和 UptimeRobot 的直接指南；其他任何能 POST JSON 的东西都可参照 webhook 指南。一个好的载荷，应该让人不用打开电脑就能做出初步定级判断：
{
"title": "可上报候选：{{service}}",
"message": "{{service}} 自 {{started_at}} 起中断 —— 是否影响客户：{{client_impact}}",
"externalLink": "https://status.internal.example/incident/{{id}}"
}externalLink 变量会在通知记录中变成可点击链接，接起电话的人可以直接跳到事件页面。
第 3 步 —— 用条件筛选，只让真正的候选事件响铃
一个见到告警就响的电话，很快就不再是电话，而是背景噪音。 Echobell 的条件支持按变量值配合 AND/OR 逻辑过滤，你可以要求同时满足 severity == "critical" 且 client_impact == true 才拨号。低于这条线的一律走另一个 Time Sensitive 或 Normal 频道。你的「可上报事件」频道一年响几次就够了，不该每周都响。
第 4 步 —— 接住那些只会发邮件的系统
不少供应商状态订阅、反欺诈工具和第三方服务商只用邮件通知——这在 DORA 下尤其要紧，因为供应商侧故障明确在适用范围内。Echobell 每个频道都可以有自己的邮箱地址，一条转发规则就能把这些邮件变成电话（邮件触发、邮件转电话设置）。
第 5 步 —— 让扛时限的人也订阅同一个频道
工程团队发现事件，合规、值班负责人或 DPO 才是扛时限的人。把频道共享出去，每位订阅者自选紧急程度：值班工程师收到电话，第二响应人收到时效性通知。同时开启 Retry Failed Call，让被专注模式拦下的来电自动重试。
第 6 步 —— 开着勿扰模式做一次实测
在每一台要紧的手机上打开勿扰模式，发一条测试 webhook，至少每季度做一次。没测过的升级路径只是一个假设，而事后复盘正是由假设堆成的。
Echobell 不做什么
在受监管的流程里，把这一点说清楚比在任何地方都重要。
**Echobell 会做的：**把 webhook 或邮件变成响铃电话、时效性通知或普通推送；让 Calling 类告警冲破 iOS 专注模式与勿扰模式；用条件与模板做过滤；把同一条告警发给共享的团队频道。
Echobell 不会做的：
- **给事件定级。**它无从判断某件事在 DORA 下是否「重大」、在 NIS2 下是否「显著」、在 SEC 规则下是否「重大」。这些都是你的人依据相关文本的标准做出的判断。
- **替你向任何机构提交。**它不会向主管当局、CSIRT 或 SEC 提交任何东西，它只负责把人带到能提交的那一步。
- **充当你的记录留存或 GRC 系统。**这些制度要求文档、登记册和证据，告警应用并不产出这些。Echobell 特意只把通知内容与历史存在你的设备上，服务器上只保留账户、频道和订阅信息（隐私模型）——这对数据最小化是好事，但作为审计留痕毫无用处。
- **附带合规证明。**它没有任何认证、审计报告或合同 SLA。如果你要把它引入受监管的流程，请像对待其他工具一样纳入你自己的 ICT 第三方风险流程，并保留一条不依赖它的通道。
- **保证送达。**一通电话依赖推送基础设施、网络和有电的手机。请把它当作大幅缩短确认时间的一层，而不是审计时可以指着说的控制措施。
诚实的说法是：无论哪个应用让你的手机响，你的监管义务都不会改变。电话改变的，是从机器察觉到有人做出判断之间的小时数——而在一个 4 小时的时钟下，这些小时就是预算的绝大部分。
常见问题
用了 Echobell 就算符合 DORA 或 NIS2 了吗？
不算。合规取决于你的治理、定级流程、文档，以及向主管当局或 CSIRT 的实际提交。Echobell 只缩短检测到人工确认之间的间隔。它是流程的一个输入，不是流程本身。
DORA 的 4 小时到底从什么时候开始算？
从定级开始。依《授权条例 (EU) 2025/301》，初始通知须在事件被定级为重大后 4 小时内提交，且无论如何不得晚于实体知悉该事件后 24 小时。这是两个独立约束，必须同时满足——这也是为什么「快速定级」和「快速告警」同样重要。
NIS2 的早期预警需要写全部细节吗？
不需要。《指令 (EU) 2022/2555》第 23 条第 4 款把 24 小时的早期预警设计成刻意暂定的：说明事件是否被怀疑由非法或恶意行为造成，以及是否可能产生跨境影响。更完整的情况在 72 小时通知中给出，根因分析则在一个月后的最终报告中。
我们的监控已经会给值班工程师发邮件，这还不够吗？
在有人醒着盯着的时候够了。邮件和普通推送会被专注模式、勿扰模式和睡眠计划静音——而这恰恰是夜里和周末、时钟最不留情的那段时间。缺口不在检测，而在确认。
合规和工程能收到同一条告警吗？
可以。共享频道后，所有订阅者都会收到触发，各自选择通知类型。常见做法是：值班工程师订阅为 Calling，值班合规负责人对「可上报事件」频道用 Calling、其余用 Time Sensitive。
电话真的能穿透勿扰模式吗？
Echobell 的 Calling 通知类型就是为冲破 iOS 专注模式与勿扰模式设计的，Retry Failed Call 设置还会对被专注模式拦下的来电重试。请在每位响应人实际使用的设备上验证后再依赖它——系统设置与版本各不相同。
这只适用于 iOS 吗？
不是。Echobell 同时提供 iOS 版和 Google Play 上的 Android 版（见 Android 版发布公告）。来电式告警在不同平台上的表现有差异，请在响应人真正携带的设备上测试。
webhook 载荷里应该放什么数据？
越少越好。发标识符和链接，而不是客户信息或事件细节——用 externalLink 变量指向你的事件记录，那才是为承载这些内容而建的系统。告警的任务是把人叫醒，不是把人讲明白。