On-call 平台的 POC，不能只看演示。
演示环境里的告警都很干净，通知都能按预期送达，值班人也永远在线。真实生产环境不是这样。真实环境里有历史包袱：Prometheus、Zabbix、夜莺、云监控、自研系统同时存在；告警标签不统一；业务团队和平台团队权限边界复杂；凌晨告警要能电话触达；没人认领时要升级；故障处理完还要工单、复盘和报表。
所以，POC 的目标不是证明一个产品“功能很多”。
POC 的目标是回答一个采购问题：
这个平台能不能在我们的真实组织、真实告警、真实值班流程里稳定工作，并且带来可量化改善？
如果没有一套验收清单，POC 很容易变成三种结果：
功能都点过，但不知道是否解决问题。
试了几个测试告警，但没有验证真实故障链路。
大家觉得体验还行，但采购时说不清为什么值得买。
下面是一套适合企业采购前使用的 On-call POC 验收清单。它不只适用于 Flashduty，也适用于评估任何 PagerDuty-like 告警响应平台。但其中涉及 Flashduty 能力的部分，会按产品事实写清楚边界。
先定义 POC 范围：不要全公司一起试
一个有效的 POC，范围要小，但场景要真。
最合适的试点对象通常是一条生产业务线，而不是全公司所有告警源。比如支付系统、订单系统、核心数据库、基础设施团队或某个 Kubernetes 集群。
范围太大，配置会变成项目迁移；范围太小，又无法验证真实价值。
建议 POC 范围这样定义：
试点业务：1-2 个生产业务或平台团队
告警源：1-3 个真实告警源
人员范围：一线值班人、备值班、团队负责人、平台管理员
周期：至少覆盖一个完整值班轮换周期
验收目标：接入、降噪、触达、升级、协同、报表、权限和成本
POC 不建议从“全量接入所有监控系统”开始。先选一个业务，把从告警进入到故障复盘的完整链路跑通，再决定是否扩大范围。
验收项 1：告警能否稳定接入
第一项验收永远是接入。
如果告警进不来，后面所有能力都没有意义。
需要验证的问题：
现有监控系统是否能低成本接入？
接入后是否能保留关键字段和标签？
告警是否进入正确的协作空间？
共享集成是否有兜底路由，避免告警被丢弃？
接入频率是否满足生产峰值？
Flashduty On-call 本身不产生告警，而是作为统一告警中心接收来自 Zabbix、Prometheus、夜莺、云监控等监控系统的告警事件。接入方式包括专属集成和共享集成。
专属集成适合单一业务团队，告警直接进入当前协作空间。共享集成适合多业务共用监控平台，告警先进入集成中心，再通过路由规则分发到不同协作空间。共享集成必须配置至少一条路由规则，否则告警会被丢弃。
验收标准可以这样写：
P0-1：至少接入一个真实生产告警源。
P0-2：触发、恢复、更新事件能在 Flashduty 中形成正确的告警和故障。
P0-3：告警中的 service、env、team、resource、check 等关键标签可被识别。
P0-4：共享集成有兜底路由规则。
P0-5：测试峰值不超过单集成 100 次/秒、1000 次/分钟的频率限制；如可能超过，需要提前确认扩容方案。
验收证据：
集成卡片的最新事件时间
故障详情中的关联告警和原始事件
标签字段截图或导出记录
路由规则配置截图
压测或历史峰值估算
这里最常见的失败原因，不是平台不能接，而是上游告警字段太乱。POC 时要把标签质量单独列为验收项。
验收项 2：告警标签是否足够支撑治理
标签不是美化字段。
标签决定后续能不能路由、聚合、静默、抑制、统计和复盘。
POC 要验证的不只是“告警有没有标题”，而是“告警能不能被机器理解”。
建议至少验收这些标签：
service：业务服务或应用
env：生产、预发、测试等环境
team：负责团队
resource：主机、实例、Pod、数据库等资源对象
check：告警检查项
severity：严重程度
cluster / region：集群、机房或地域
Flashduty 会从原始告警系统上报的事件消息体中提取标签。需要补齐时，可以使用标签增强，通过正则提取、映射表或组合方式生成新标签。基础标签增强需要标准版及以上，高级标签增强，例如 API 映射，需要专业版及以上。
验收标准：
P1-1：试点业务的 Critical 告警具备 service、env、team、resource、check 标签。
P1-2：分派策略可以基于标签精确匹配。
P1-3：聚合策略可以基于标签定义相似告警边界。
P1-4：分析看板能按告警检查项和告警对象识别 TOP 噪音来源。
验收证据：
告警详情标签截图
标签增强规则配置
分派策略条件
告警 TOP 数据
如果 POC 阶段标签不稳定，先不要急着推进复杂降噪。否则规则会越写越多，维护成本会迅速上升。
验收项 3：告警是否能进入正确的人和团队
On-call 平台最基本的价值，是把故障送到正确的人手里。
这里要验证的不是“能不能发通知”，而是“能不能按组织责任分派”。
需要验证的问题：
不同业务线是否进入不同协作空间？
不同严重程度是否走不同分派策略？
生产和非生产环境是否区分？
工作时间和非工作时间是否可以使用不同策略？
无人值班时是否有兜底？
Flashduty 的分派策略决定故障发生时，在什么时间、通过什么渠道、通知给谁、超时如何升级。策略按从上到下顺序匹配，命中后停止继续匹配。触发条件可以按生效时间、服务日历、标题、级别、标签等匹配；通知对象可以是值班表、团队、个人，也可以组合使用。
验收标准：
P0-1：支付系统 Critical 告警进入支付协作空间，并通知支付主值班。
P0-2：Warning 告警只进入 IM 群或 App，不触发电话轰炸。
P0-3：测试环境告警不会进入生产值班链路。
P0-4：没有匹配到业务策略时，有默认兜底策略通知 SRE 或管理员。
P0-5：轮空值班表场景有处理方案，避免无人收到个人通知。
这里要特别注意：如果故障没有匹配到分派策略，系统不会分派给任何人，也不会有任何通知。因此 POC 必须验证“兜底策略”。
验收证据：
协作空间规划
分派策略列表和顺序
不同级别告警的实际通知记录
故障时间线中的分派和通知事件
验收项 4：通知是否真实可达
通知验收不能只看一条测试短信。
生产 On-call 要面对多种现实情况：值班人在手机上，IM 消息被刷掉，电话被系统拦截，邮件进垃圾箱，凌晨手机开了勿扰模式。
POC 要验证多渠道触达组合。
Flashduty 支持 App 推送、语音、短信、邮件、IM 应用集成和 IM 机器人。App 推送支持移动端处理；语音通知可用于重大故障升级和强触达；短信、邮件适合作为兜底；IM 应用集成支持交互式卡片，机器人更适合快速通知。
验收标准：
P0-1：Critical 故障至少通过两个独立渠道触达值班人。
P0-2：语音、短信、邮件至少各完成一次真实送达测试。
P0-3：App 能接收推送，值班人能在移动端查看、认领、关闭、升级故障。
P0-4：飞书、钉钉、企业微信、Slack 或 Teams 中的主协作工具完成集成验证。
P0-5：IM 应用卡片能完成认领、关闭或升级等关键操作；如果使用机器人，明确其主要是通知，不是完整交互。
验收证据：
故障时间线中的通知渠道和通知结果
值班人手机截图
IM 卡片操作记录
语音按键认领记录
个人通知偏好配置
通知验收还要看个人设置。只有故障直接分派到个人，或分派策略设置为“单聊 + 遵循个人偏好”时，个人偏好才会生效。如果 POC 中发现“我设置了通知偏好但没收到”，要检查分派策略是否真的使用个人偏好。
验收项 5：值班表和升级是否可持续
值班机制不是把一个人写死在通知对象里。
企业 POC 必须验证排班、主备、临时调班和升级链路。否则上线后很容易变成“某个管理员手工维护通知名单”。
Flashduty 的值班表支持按小时、天、周、月轮换，支持多层规则、白班/夜班、主备值班、临时调班、日期掩码、公平轮换等场景。分派策略可以把通知对象设置为值班表，并按环节配置升级条件。
验收标准：
P0-1：创建一张真实值班表，覆盖主值班和备值班。
P0-2：当前值班人可以在日历中准确显示。
P0-3：主值班 10 分钟未认领时升级给备值班。
P0-4：故障 30 分钟未关闭时升级给团队负责人或二线专家。
P0-5：临时调班不修改长期规则，窗口结束后自动恢复。
P0-6：换班通知可以提醒即将下班和即将接班人员。
验收证据：
值班表日历截图
临时调班记录
故障时间线中的升级动作
主备不同场景的通知记录
这里要区分两个升级条件：
“未关闭且未认领”适合防止无人响应。
“未关闭”适合确保故障在规定时间内解决。
POC 时建议两个都测试，避免上线后才发现策略含义和团队预期不一致。
验收项 6：告警降噪是否真的减少处理负担
降噪不是“把通知关掉”。
真正的降噪，是把大量告警收敛成少量可处理的故障，同时保留排查需要的上下文。
Flashduty 的降噪能力包括告警聚合、规则聚合、智能聚合、风暴预警、抖动检测、静默策略和抑制策略。静默策略所有版本可用；告警聚合、风暴预警和抑制策略需要标准版及以上；智能告警聚合属于专业版能力。
POC 要验证四类场景：
重复触发：同一告警反复触发，是否合入同一故障。
相似告警：同一资源或服务的多个告警，是否能聚合为一个处理对象。
维护窗口：计划维护、压测、发布期间，是否能静默低价值通知。
根因派生：Critical 根因存在时，是否能抑制同一检查项的 Warning / Info 派生告警。
验收标准：
P0-1：同一服务、同一资源、同一检查项的重复告警能合入同一故障。
P0-2：聚合后的故障详情中仍能查看关联告警和事件。
P0-3：静默策略能覆盖计划维护窗口，并能区分直接丢弃和保留标记。
P0-4：抖动检测能识别频繁触发和恢复的故障。
P0-5：告警风暴达到阈值时，时间线记录风暴事件并触发预警通知。
验收证据：
同一故障关联告警数量
聚合策略配置
静默和抑制规则配置
风暴预警时间线
POC 前后故障数量、通知中断次数和 TOP 告警变化
如果要衡量“压缩率”，不要只看平台上的一个数字。可以按 POC 前后自己计算：
告警收敛效果 = 原始告警事件数量 / 实际创建故障数量
但这个指标要和漏报风险一起看。通知少了不一定代表治理好了，关键故障仍然必须能触达。
验收项 7：故障处理是否形成闭环
On-call 平台不是把告警发出去就结束。
POC 必须验证故障从触发到关闭的生命周期。
Flashduty 的故障有待处理、处理中、已关闭等处理进度。任意人员认领故障后，处理进度会变为处理中；关闭故障后，处理进度变为已关闭；故障关联的告警全部恢复时，故障也可以自动关闭。故障详情页包含时间线，用于记录触发、分派、通知、认领、暂缓、关闭、评论等动作。
验收标准：
P0-1：值班人能在控制台、App 或 IM 中认领故障。
P0-2：认领后处理进度从待处理变为处理中。
P0-3：处理人可以暂缓故障，暂缓到期后未处理完成会重新进入待处理并发起分派。
P0-4：故障可手动关闭，也可随关联告警恢复自动关闭。
P0-5：误关闭后可以重新打开，并填写重开原因。
P0-6：处理过程中可以添加 Markdown 评论、截图和排查笔记。
验收证据：
故障时间线
关键时间节点：触发时间、首次认领时间、关闭时间
评论和截图记录
重新打开记录
POC 时要让真实值班人操作，而不是管理员代点。否则你验证的是管理员熟不熟悉系统，不是值班流程是否可用。
验收项 8：重大故障能否多人协同
单人可处理的告警，测试认领和关闭就够了。
重大故障不一样。它通常需要研发、SRE、DBA、网络、安全、客服、业务负责人一起协作。
这时要验证作战室、状态同步和沟通机制。
Flashduty 作战室是专业版及以上能力，支持在飞书、钉钉、企业微信和 Slack 中为活跃故障创建专属沟通群组。处理人变更时，相关人员可以自动同步到作战室；作战室内可以接收故障状态更新，也可以进行认领、关闭、暂缓等操作；相关操作会记录在故障时间线中。同一时间系统仅支持为一个 IM 集成开启作战室功能。Microsoft Teams 集成目前不支持作战室。
验收标准：
P1-1：在试点 IM 工具中创建作战室。
P1-2：故障处理人变更时，相关成员能加入作战室。
P1-3：作战室内能看到故障状态更新。
P1-4：作战室内的认领、暂缓、关闭操作能同步到 Flashduty。
P1-5：作战室相关操作记录进入故障时间线。
P1-6：故障关闭后可以解散作战室。
验收证据：
作战室群截图
故障时间线中的作战室操作
成员同步记录
IM 权限配置记录
如果团队主要使用 Microsoft Teams，要提前确认：Teams 可以用于通知集成，但作战室目前不支持 Teams。这个边界应该在 POC 阶段写入结论。
验收项 9：状态页能否支撑内外部沟通
故障期间，技术团队不应该一边修系统，一边重复回答“恢复了吗”“影响哪些服务”“什么时候好”。
状态页的价值，是给内部和外部受众一个统一的信息发布窗口。
Flashduty 状态页支持公开状态页和内部状态页。公开状态页对所有公网用户开放，无需登录即可访问，用户可通过邮件订阅事件更新。内部状态页仅限组织内部用户访问，需要 Flashduty 账号登录，专业版支持内部状态页，并可通过飞书、钉钉、企业微信、Slack 等 IM 集成接收实时推送。
状态页事件包括故障和维护。故障影响状态包括运行正常、性能下降、部分中断、完全中断；维护影响状态包括运行正常和维护中。
验收标准：
P1-1：创建一个公开状态页或内部状态页。
P1-2：按业务组件组织服务，并设置组件分组。
P1-3：发布一次故障事件，选择受影响组件和影响状态。
P1-4：添加至少两条时间线更新，模拟调查中、恢复中、已恢复。
P1-5：订阅者能收到邮件或 IM 通知。
P1-6：故障结束后，事件进入历史记录，并可用于可用性统计。
这里要注意一个边界：状态页当前主要通过状态页管理页面手动发布事件，也可以通过 Open API 创建和更新状态页事件。POC 时不要把它误解成监控探测工具，它的重点是正式沟通和信息同步。
验收证据：
状态页 URL
组件和分组配置
事件时间线
订阅通知记录
验收项 10：工单和自动化能否接入现有流程
企业采购前，一定会问：能不能和现有 ITSM、研发流程、自研平台打通？
这里要分三类能力验收。
第一类是工单同步。
Flashduty 支持 Jira、ServiceNow、ServiceDesk Plus 等同步集成，相关能力属于专业版及以上。Jira 同步目前是 Flashduty 到 Jira 的单向同步，Jira 中的信息不会同步回 Flashduty；已创建 Issue 的故障在严重程度、状态更新时可以同步到 Jira，评论也可以同步。ServiceNow 和 ServiceDesk Plus 支持按配置选择 To、From 或 Two-way 同步方向。
第二类是 Webhook。
告警 Webhook 可以在告警触发、更新、合并、关闭等事件发生时向外部地址推送。故障 Webhook 可以在创建故障、分派、添加处理人、暂缓、认领、关闭、重开、合并、评论、更新标题、更新严重程度等事件发生时推送。Webhook Endpoint 必须以 http:// 或 https:// 开头，默认启用 TLS 验证，也可以配置自定义 Headers。接收方返回 HTTP 200 视为成功。
第三类是 Open API。
Flashduty Open API 覆盖 On-call、Monitors、RUM 和平台模块。On-call 包含故障管理、协作空间、告警管理、集成中心、路由规则、值班排班、分析看板、状态页等接口。所有接口 Endpoint 为 https://api.flashcat.cloud，使用 APP Key 通过 query string 认证。
验收标准：
P1-1：至少选择一个现有系统完成联动验证，例如 Jira、ServiceNow、ServiceDesk Plus 或自研平台。
P1-2：明确同步方向，是单向、反向还是双向。
P1-3：严重程度、状态、评论、自定义字段映射符合团队流程。
P1-4：Webhook 接收方能处理重复事件和乱序事件。
P1-5：Webhook 调用历史可用于排查失败请求。
P1-6：需要 API 自动化的场景能通过 Open API 完成。
验收证据：
外部工单链接
字段映射配置
Webhook 调用历史
API 调用示例和返回结果
失败重试和去重方案
这里不要只测试“能创建一个工单”。真正要验证的是故障状态、优先级、评论、处理人和自定义字段是否符合现有流程。
验收项 11：分析看板能否支持管理决策
采购 On-call 平台时，管理者最关心的不是某个按钮，而是稳定性治理是否有数据。
POC 要验证分析看板是否能回答这些问题：
哪个团队故障最多？
哪个业务告警噪音最大？
哪些告警检查项最频繁？
哪些资源最容易触发告警？
MTTA 是否达标？
MTTR 是否改善？
响应比例是否足够高？
夜间中断次数是否过多？
人员响应投入是否不均衡？
Flashduty 分析看板需要标准版及以上。它支持按团队、协作空间、个人等维度查看，指标包括故障数量、MTTA、MTTR、响应比例、响应投入和中断次数。中断次数仅统计短信、语音、App 推送三种渠道的分派通知；一个响应人员多渠道同时推送仅算一次中断，如果距离上一次通知不超过 1 分钟，不算中断。
分析看板还支持按工作时间、休息时间、睡眠时间拆分；全局维度可以查看告警检查项和告警对象 TOP 20；数据可下载或导出。
验收标准：
P0-1：能按试点团队或协作空间查看故障数量、MTTA、MTTR。
P0-2：能识别 TOP 告警检查项和 TOP 告警对象。
P0-3：能看到工作时间、休息时间、睡眠时间的打扰分布。
P0-4：能导出 POC 数据，用于内部评审。
P0-5：能基于数据提出至少 3 个治理动作。
验收证据：
分析看板截图
导出的 CSV 或 PDF
POC 前后对比表
治理动作清单
分析看板的数据可能存在约一小时延迟，POC 验收时不要用它做秒级实时判断。
验收项 12：权限、SSO 和审计是否满足企业要求
如果 POC 面向企业采购，安全和权限不能最后才看。
需要验证三件事。
第一，权限模型。
Flashduty 使用功能权限和数据权限两类权限。功能权限基于 RBAC，决定 API 是否可调用、按钮是否可点击、页面和菜单是否可见；数据权限基于团队，决定用户能访问哪些团队、协作空间、值班表、集成、模板等资源。某些操作必须同时拥有功能权限和数据权限。
系统预置 Admin、Responder、Viewer 角色，也支持自定义角色。Admin 拥有所有权限；Responder 拥有除费用中心、成员管理、角色管理、单点登录管理外的大部分操作权限；Viewer 主要用于只读访问。
第二，SSO。
Flashduty 支持 SAML2.0、OIDC、CAS 单点登录；LDAP 单点登录仅私有化版本支持。SSO 支持登录即创建账号，也可以关闭后要求先邀请成员。通过 SSO 首次登录并自动创建的成员可标记为外部成员，并可开启禁止编辑外部成员，让成员信息由身份提供商统一管理。
第三，审计。
审计日志记录主体内所有成员通过控制台或 API 执行的写操作，包括创建、修改、删除资源，以及成员管理、权限变更等。审计日志可按时间范围、用户、事件、事件 ID 检索，记录包含时间、用户名、事件名称、事件 ID 和来源 IP。审计日志最多保留 30 天；控制台当前不支持直接导出审计日志。
验收标准：
P0-1：管理员、响应者、只读查看者三类角色能按预期访问。
P0-2：业务团队只能管理自己负责的协作空间、值班表和集成。
P0-3：SSO 能完成登录，并正确映射邮箱、用户名、手机号等字段。
P0-4：需要身份提供商统一管理时，外部成员不可在 Flashduty 中被随意修改。
P0-5：关键配置变更能在审计日志中查到。
P0-6：审计保留周期和导出方式满足合规要求；如果需要导出，提前确认技术支持方案。
验收证据：
角色配置截图
团队数据权限验证记录
SSO 登录测试记录
审计日志查询截图
合规差距清单
不要等到采购审批时才发现审计留存周期、SSO 协议或权限模型不满足企业要求。
验收项 13：成本模型是否和组织规模匹配
POC 最后一定要算成本。
Flashduty On-call 采用 License 订阅制，按活跃用户数量计费。只有持有 License 的成员才能使用 On-call 的全部功能；无 License 成员不能查看故障或处理故障，但可以被动接收邮件、短信、电话、IM 通知，也可以被分派策略引用为通知对象。
这意味着，成本不应该按“公司技术团队总人数”粗略估算，而应该按“需要登录平台查看和处理故障的人”估算。
POC 成本验收建议分三类人：
必须持有 License：值班工程师、SRE、运维、平台管理员、需要处理故障的研发负责人。
可能需要 License：团队 Leader、稳定性负责人、需要配置分派策略和值班表的人。
通常不需要 License：只被动接收通知的开发、业务负责人、管理层、外部协作方。
同时要看通知额度。
专业版每用户每月包含短信、电话、邮件免费额度，超出后按量计费；Webhook 不限。免费版每日最多接收 100 条告警，超出部分会被静默丢弃且不会返回错误，不适合用来做生产级 POC。
验收标准：
P0-1：列出正式上线阶段需要 License 的成员数量。
P0-2：估算每月短信、电话、邮件用量。
P0-3：确认是否需要专业版能力：IM 集成、作战室、故障复盘、AI 故障摘要、工单集成、内部状态页等。
P0-4：确认是否需要私有化部署、LDAP、企业支持或专属服务群。
P0-5：形成总拥有成本估算，并和现有方案或竞品方案对比。
验收证据：
License 人员清单
通知用量估算
版本能力对照表
成本测算表
如果一个团队有 100 名技术人员，但日常真正处理故障的人只有 10-20 人，License 模式会显著影响总拥有成本。POC 阶段要把这件事算清楚。
一张可直接使用的 POC 评分表
建议把 POC 评分做成 100 分。
不是为了形式化，而是为了让采购判断可讨论、可复核。
告警接入与标签质量：15 分
分派、通知和值班升级：20 分
告警降噪和故障收敛：15 分
故障处理闭环与时间线：10 分
协同、状态页和复盘：10 分
分析看板和数据导出：10 分
工单、Webhook 和 API 集成：8 分
权限、SSO 和审计：7 分
成本模型和版本匹配：5 分
评分时建议用三档：
通过：满足生产要求，可以进入采购或扩大试点。
有条件通过：核心链路可用，但需要补齐配置、权限、集成或成本确认。
不通过：关键能力缺失，或无法在真实流程中稳定运行。
不要给所有项目平均权重。
如果你的核心问题是夜间没人响应，分派、通知和值班升级权重就应该最高。
如果你的核心问题是告警风暴，降噪和故障收敛权重就应该最高。
如果你的核心问题是企业合规，权限、SSO 和审计就不能只占很小比例。
POC 的评分表要服务你的真实问题。
最后的采购判断：值得买的标准是什么
一个 On-call 平台值得买，不是因为它能接很多告警源，也不是因为界面看起来完整。
它至少应该在 POC 中证明四件事。
第一，它能接住真实告警。
不是演示告警，而是来自现有 Prometheus、Zabbix、夜莺、云监控或自研系统的真实生产告警。
第二，它能把告警送到正确的人。
分派、值班、升级、通知渠道和个人偏好都要经得起真实场景验证。
第三，它能减少无效打扰，同时不漏掉关键故障。
聚合、静默、抑制、抖动检测和风暴预警要共同服务一个目标：让值班人处理故障，而不是处理噪音。
第四，它能留下数据和证据。
时间线、处理记录、分析看板、审计日志、工单同步和复盘报告，都是采购后持续治理的基础。
如果 POC 结束后，团队能清楚回答：
我们接入了哪些真实告警？
哪些故障被正确分派和升级？
通知有没有按预期触达？
告警噪音有没有下降？
MTTA、MTTR、响应比例和中断次数是什么？
哪些能力还需要配置或采购确认？
正式上线需要多少 License？
那这次 POC 就有采购价值。
如果回答不了这些问题，即使产品功能很多，也不应该急着买。
Flashduty 的合适切入点，是先不替换监控系统，而是把现有告警统一接入，经过降噪、分派、升级、协同、分析和复盘，验证一条完整 On-call 闭环。
POC 要做的，就是把这条闭环用真实数据跑出来。
👉 预约 POC
参考资料
- Flashduty 产品与文档：集成数据、协作空间、标签增强、分派策略、通知渠道、个人通知偏好、值班管理、告警降噪、故障生命周期、故障详情与时间线、作战室、状态页、故障复盘、分析看板、Webhook、Jira / ServiceNow / ServiceDesk Plus 同步、Open API、权限设计、SSO、审计日志、定价与 License 模式。
