14 天试用最怕的不是时间不够，而是试用方法错了。
很多团队注册一个 On-call 平台后，会先把页面都点一遍，看看支持哪些集成、有哪些通知渠道、能不能创建值班表。两周过去，大家感觉“功能挺多”，但还是回答不了最关键的问题：
这个工具能不能解决我们的真实告警响应问题？
如果试用没有接入真实告警，没有让值班人真正收到通知，没有跑过认领、升级、暂缓、关闭，没有看过 MTTA、MTTR 和通知中断数据，那试用结果就很容易变成主观印象。
Flashduty 新注册企业有 14 天专业版免费试用期。更好的用法不是“14 天内把所有功能都试一遍”，而是用真实场景验证一条完整链路：
告警能不能接进来。
重复告警能不能收敛。
关键故障能不能触达正确的人。
没人响应时能不能升级。
处理过程能不能留下时间线。
管理者能不能看到响应效率和噪音来源。
故障结束后能不能复盘。
这篇文章给一套可执行的 14 天试用路径。
试用前先定目标：不要从功能清单开始
试用前先回答一个问题：这 14 天要验证什么？
不同团队的目标不一样。
有的团队已经有 Prometheus、Zabbix 或夜莺，只是告警太多、通知太乱。它要验证的是统一接入、降噪和分派。
有的团队已经有值班机制，但排班靠表格，升级靠人工催。它要验证的是值班表、主备轮班、自动升级和通知触达。
有的团队是管理者推动选型，关心 MTTA、MTTR、响应比例、人员负载和告警噪音来源。它要验证的是分析看板和报表。
有的团队在比较 PagerDuty、Opsgenie、自研平台或云监控通知能力。它要验证的是完整 On-call 闭环，而不是单点通知。
建议把试用目标写成三句话：
我们选择哪个业务作为试点？
这 14 天要解决哪 3 个告警响应问题？
什么数据证明试用有效？
例如：
试点业务：支付系统。
问题：告警分散在 Prometheus 和云监控；Critical 告警夜间没人及时认领；告警恢复后没有复盘记录。
验证指标：Critical 告警 5 分钟内首次认领；重复告警聚合到同一故障；故障详情能还原触发、通知、认领、关闭时间线。
这比“看看产品好不好用”更容易判断。
第 1 天：只接一个真实告警源
第一天不要急着把所有监控系统都接进来。
更好的做法是选一个真实、重要、但范围可控的告警源。比如：
- 一个 Prometheus Alertmanager。
- 一个 Zabbix 告警媒介。
- 一个夜莺告警源。
- 一个云监控告警通道。
- 一个标准 Webhook 或自研告警接口。
Flashduty On-call 的核心流程是：告警通过集成进入协作空间，然后根据分派策略通知到具体的人。
这里有两个接入方式。
专属集成适合新手和单业务试点。你在某个协作空间内添加集成，系统生成 Webhook 地址，告警直接进入这个空间，不需要额外路由。
共享集成适合公司级统一接入。告警先进入集成中心，再通过路由规则按 service、team、env 等标签分发到不同协作空间。共享集成必须配置路由规则，否则告警会被丢弃。试用早期如果只是验证一个业务，先用专属集成更稳。
第一天要完成的不是“接入很多系统”，而是跑通第一条真实事件。
验证标准很简单：
监控系统触发一条测试告警
→ Flashduty 集成卡片出现最新事件时间
→ 协作空间内生成故障
→ 故障详情里能看到标题、严重程度、标签、关联告警和事件
如果第一天结束还没有真实告警进来，后面的试用基本都会失真。
第 2 天：把协作空间按业务建清楚
协作空间是 Flashduty On-call 中管理故障的最小单元。告警、集成、分派规则和权限都会围绕协作空间组织。
试用时最容易犯的错误，是建一个“测试空间”，把所有告警都扔进去。
这样很快会变乱。
更推荐按业务或团队创建空间，例如“支付中心”“订单系统”“DBA 团队”“基础设施”。如果只是试用，可以先建一个试点业务空间，但命名和归属要按真实业务来，不要按“测试”来。
创建空间时重点看三件事：
第一，所属团队是谁。所属团队拥有空间配置权限，后续集成、分派、降噪策略都由它管理。
第二，访问级别怎么设。公开空间账户内成员可见，私有空间只对所属团队、创建者和管理员可见。试用阶段如果需要跨团队评估，公开更方便；如果涉及敏感业务，私有更合适。
第三，故障关闭规则怎么定。默认情况下，故障关联的告警全部恢复后，故障可以自动关闭。也可以配置超时自动关闭，最长 30 天。这个设置会影响 MTTR 和后续复盘判断，试用时不要忽略。
第二天的目标，是让试点业务有一个干净的工作区。
如果一个空间里混了办公网络、核心交易、数据库和测试环境告警，后面无论是分派还是分析，都会很难判断。
第 3 天：补齐标签，不然后续都会乱
On-call 平台的很多能力都依赖标签。
路由要靠标签。
聚合要靠标签。
静默和抑制要靠标签。
分析看板也要靠标签。
如果告警只有一段标题和描述，试用时看起来也能通知，但很难验证真正的响应治理能力。
建议至少检查这些标签：
service：业务服务或应用。env：环境，例如 production、staging。severity：严重程度。team：负责团队。resource：主机、实例、Pod、数据库等告警对象。check：告警检查项，例如 CPU、磁盘、接口错误率。
Flashduty 会从原始告警系统上报的事件消息体中提取标签。对于 Prometheus 来源，通常会提取 Payload 中的 Labels 和 Annotations。需要补充或改写时，可以使用标签增强，通过正则提取、映射表或组合方式生成新标签。
试用阶段不需要一次性建立完美标签体系。
先做一件事：让试点业务的 Critical 告警至少能按 service、env、team 和 resource 被识别。
否则你后面会发现，分派策略只能写得很粗，降噪规则也很难判断是否准确。
第 4 天：配置第一条分派策略
告警接进来以后，真正要验证的是：它会通知谁？
Flashduty 的分派策略决定了故障发生时，在什么时间、通过什么渠道、通知给谁、超时如何升级。策略按从上到下顺序匹配，命中后停止继续匹配。
第一条分派策略不要设计得太复杂。
建议先覆盖试点业务的生产 Critical 告警：
触发条件：env=production 且 severity=Critical
通知对象：当前值班表或指定试点处理人
通知方式：App 推送 + IM 单聊；必要时加语音
群聊通知：同步到试点业务群
升级条件：10 分钟未认领升级给备值班或团队负责人
如果团队还没有值班表，可以先分派给个人或团队。但这只能用于第一轮验证。真正评估 On-call 机制时，应该尽快引入值班表，因为生产故障不应该长期绑定某个固定个人。
分派策略还可以设置延迟窗口。延迟窗口是在首次通知前等待一段时间，取值范围 0 到 3600 秒。如果故障在等待期内自动关闭，就不再通知。对于瞬时抖动、短暂网络超时，这个能力很适合减少无效打扰。
第 4 天的验证标准：
触发一条 Critical 测试告警
→ 命中正确分派策略
→ 正确人员收到通知
→ 群聊同步消息
→ 故障时间线记录分派和通知动作
如果时间线里看不到通知状态，后面排查“为什么没收到”会很困难。
第 5 天：让值班人真正认领一次
很多试用失败，是因为只验证了“能收到消息”，没有验证“能处理故障”。
收到通知只是第一步。值班人要能快速认领、暂缓、升级、关闭，系统才算进入响应闭环。
Flashduty 支持多种认领方式：
- 在控制台故障详情中认领。
- 在 IM 应用消息卡片中认领。
- 在语音电话播报结束后按键认领。
- 在 App 上查看和处理故障。
试用时一定要让真实值班人操作一次，而不是由管理员代点。
需要观察几个细节：
值班人是否知道从哪里打开故障详情？
IM 账号是否已经和 Flashduty 账号关联？
App 是否已绑定设备并开启通知权限？
电话或短信是否能送达？
认领后故障是否从待处理变为处理中？
MTTA 是否能被记录？
如果试用人员只在电脑前点控制台，结果会过于理想。真实 On-call 往往发生在手机、IM 和语音场景里。
第 5 天应该把这些路径都跑一遍。
第 6-7 天：建立第一张值班表和升级链路
第 1 周结束前，要把试用从“通知测试”推进到“值班机制测试”。
值班表是连接故障和人的桥梁。Flashduty 支持按小时、天、周、月轮换，支持白班/夜班、主备值班、临时调班、日期掩码和公平轮换等场景。
试用阶段不需要把全年排班都录进去。
先建一张最小可用值班表：
值班表：支付系统主备值班
人员：2-4 名试点成员
规则：每人轮换 1 天或 1 周
角色：主值班、备值班
通知：主值班先接收，备值班作为升级环节
然后把分派策略里的通知对象从固定个人改成值班表。
接下来要模拟两个场景。
第一个场景：主值班正常认领。系统应该通知当前主值班，主值班认领后故障进入处理中。
第二个场景：主值班不响应。系统应该在设定窗口后升级到备值班或负责人。
升级条件可以选择“未关闭”，也可以选择“未关闭且未认领”。试用时建议两个都理解清楚：
“未关闭且未认领”更适合验证是否有人响应。
“未关闭”更适合验证故障是否在规定时间内解决。
第 7 天结束时，你应该能回答：
当前谁在值班？
主备关系是否清楚？
没人认领时是否会自动升级？
值班人请假或替班时是否能临时调班？
通知是否符合个人偏好和分派策略？
如果这些问题回答不了，试用还没有进入真正的 On-call 场景。
第 8-9 天：验证告警降噪，而不是只看通知
第二周开始，要验证最影响值班体验的能力：降噪。
告警多不是通知问题，而是响应对象没有收敛。一个主机宕机触发 50 条告警，值班人不应该处理 50 次。一组接口超时反复触发恢复，也不应该每次都电话打断。
Flashduty 的降噪能力包括告警聚合、规则聚合、智能聚合、风暴预警、抖动检测、静默策略和抑制策略。其中静默策略所有版本可用；告警聚合、风暴预警、抑制策略需要标准版及以上；智能告警聚合属于专业版能力。
试用专业版时，建议重点验证三件事。
第一，重复告警是否能聚合到同一故障。
可以选择一个高频告警对象，比如同一服务、同一主机、同一检查项，观察多次触发是否合入同一个故障。
第二，低价值告警是否能被静默或过滤。
维护窗口、压测、测试环境、已知无害告警，不应该持续打扰值班人。
第三，风暴场景是否能被识别。
如果一个故障持续合入大量告警，系统可以记录风暴事件并触发预警通知。风暴预警最多支持配置 5 个阈值，每个阈值范围为 2 到 10,000。
这两天不要追求“把通知降到最低”。
试用阶段更应该看四个结果：
故障数量是否少于原始告警数量？
值班人是否更容易判断处理对象？
Critical 告警是否仍然能强触达？
静默和抑制是否留下可排查记录，而不是把重要信息直接吞掉？
降噪的目标不是安静，而是让真正该处理的故障更突出。
第 10 天：看分析看板，找出试用数据里的问题
跑了 7-9 天真实告警后，应该开始看数据。
Flashduty 分析看板支持按团队、协作空间、个人等维度统计故障数据，时间范围最多支持查询最近 1 年。指标包括故障数量、MTTA、MTTR、响应比例、响应投入和中断次数，还可以按工作时间、休息时间、睡眠时间拆分。
这一天不需要做复杂报表，先回答几个问题：
试点业务一共产生了多少故障？
Critical / Warning / Info 的比例是否合理？
哪些告警检查项最频繁？
哪些告警对象最频繁？
哪些故障没有认领？
MTTA 是否符合预期？
夜间中断次数是否过高？
哪些人承担了最多响应投入？
分析看板的价值，不是给管理者一个漂亮图表，而是帮助团队找到下一步治理方向。
如果 TOP 告警检查项集中在某几个规则，说明监控规则需要治理。
如果 MTTA 偏高，说明触达或值班机制有问题。
如果中断次数集中在睡眠时间，说明分派策略、延迟窗口和告警等级需要调整。
如果某个人响应投入明显过高，说明排班或责任分配不均衡。
试用到这里，已经不应该只讨论“产品好不好用”，而应该讨论“它能不能帮我们暴露真实问题”。
第 11 天：验证 IM、作战室和状态页
第 11 天适合验证协同能力。
如果你的团队主要用飞书、钉钉、企业微信、Slack 或 Microsoft Teams，不能只测试短信和电话。真实故障处理大多发生在 IM 里。
Flashduty 的 IM 应用集成属于专业版能力，支持交互式卡片和账号关联。成员可以在 IM 消息卡片上处理故障。机器人集成配置更简单，但交互能力弱，更多是基础通知。
如果试点业务涉及多人协同，可以创建一次作战室。作战室可以围绕活跃故障在飞书、钉钉、企业微信或 Slack 中创建专属沟通群组，处理人变更时同步成员，群内可接收故障状态更新，也可以进行认领、关闭、暂缓等操作。作战室相关操作会记录在故障时间线中。
这里要注意：Microsoft Teams 集成可以用于通知，但作战室目前不支持 Teams。
如果你的业务有对内或对外沟通需求，也可以验证状态页。
Flashduty 支持公开状态页和内部状态页。公开状态页对公网用户开放，支持邮件订阅；内部状态页面向组织内部成员，专业版支持最多 20 个内部状态页，并支持通过飞书、钉钉、企业微信、Slack 等 IM 集成接收事件推送。
试用时可以模拟一次状态页发布流程：
发布故障事件
→ 选择受影响组件
→ 设置影响状态
→ 添加时间线更新
→ 故障恢复后关闭事件
状态页当前需要手动发布事件。试用时不要把它当成自动告警机器人，而要把它当成统一沟通窗口。
第 12 天：从故障详情生成复盘
第 12 天要验证一件经常被忽略的事：故障结束后，能不能复盘。
Flashduty 的故障详情会记录触发、分派、通知、认领、暂缓、关闭、评论等时间线动作。处理过程中也可以添加 Markdown 评论、排查笔记、截图和沟通纪要。
复盘报告是专业版能力。故障关闭后，可以从故障详情页创建复盘报告。创建时选择模板，系统会提取严重程度、处理时间、响应人员等信息，生成草稿状态报告。报告支持在线协作编辑、自动保存、发布、重新编辑和删除。
AI 生成复盘报告可以基于模板结构、故障详情、处理时间线，以及具备权限的飞书或 Slack 作战室聊天记录生成初稿。AI 初稿不是最终结论，团队仍然需要补充根因、影响范围、改进措施和跟进事项。
试用时可以拿一条真实或演练故障做复盘。
重点不是报告写得多漂亮，而是检查素材是否完整：
故障什么时候触发？
通知到了谁？
谁第一次认领？
有没有升级？
有没有暂缓？
什么时候关闭？
处理过程中有哪些评论、截图、链接？
是否能写清影响范围、根因、解决方案和后续行动项？
如果复盘时还要回到群聊里翻半天记录，说明处理过程中的上下文沉淀还不够。
第 13 天：算清 License 和用量
第 13 天适合做成本和版本判断。
Flashduty On-call 采用 License 订阅制，按活跃用户数量计费。只有持有 License 的成员才能使用 On-call 的完整故障查看、处理和配置能力；无 License 成员不能查看和处理故障，但可以被动接收邮件、短信、电话、IM 通知，也可以被分派策略引用为通知对象。
这对试用结论很重要。
不要简单按公司技术团队总人数估算成本。应该按“真正需要查看和处理故障的人”估算 License。
建议列三类人：
核心处理人：SRE、运维、平台、业务研发值班人，需要 License。
配置和管理人：团队 Leader、平台负责人、On-call 管理员，需要 License。
被通知人：业务负责人、管理层、外部协作方，只接收通知，通常不需要 License。
同时也要看通知额度和使用量。
专业版每用户每月包含短信、电话、邮件免费额度，超出后按量计费；Webhook 不限。试用期间如果大量使用电话和短信演练，要留意它和真实生产场景是否一致。不要因为测试时频繁触发电话，误判日常成本。
这一天应该产出一张简单表：
预计需要 License 的人数
试点业务日均故障量
短信、电话、邮件预计月用量
是否需要 IM 集成、作战室、内部状态页、复盘、工单集成等专业版能力
是否需要私有化部署或企业支持
这会直接影响采购判断。
第 14 天：做一次验收，而不是再加功能
最后一天不要继续加新系统。
第 14 天应该做试用验收。
建议把验收分成五类：
接入：至少一个真实告警源已接入，告警能稳定进入正确协作空间。
触达：Critical 告警能通过 App、IM、语音或短信触达正确值班人。
响应：值班人能认领、暂缓、升级、关闭故障，时间线记录完整。
治理：重复告警有聚合策略，低价值告警有静默或过滤方案，TOP 噪音来源清楚。
管理：能看到 MTTA、MTTR、响应比例、中断次数和人员响应投入。
如果团队试用了作战室、状态页、工单集成和复盘，也把它们加入验收：
协同：重大故障能创建作战室，成员和状态同步正常。
沟通：需要对外或对内同步时，状态页发布流程清楚。
工单：Jira、ServiceNow 或 ServiceDesk Plus 同步边界明确。
复盘：故障关闭后能创建复盘报告，并形成跟进事项。
最后给出一个清晰结论：
是否建议进入正式采购或 POC？
如果进入，下一阶段需要接入哪些业务？
如果暂不进入，主要阻塞是什么？
如果继续试用，需要销售或技术支持协助哪些配置？
试用的目标不是“证明工具完美”，而是降低采购和落地的不确定性。
14 天里最重要的三个判断
如果只能看三个结果，我建议看这三个。
第一，真实告警是否接进来了。
没有真实告警，所有试用结论都只是演示结论。
第二，值班人是否真的用起来了。
只有管理员配置成功不算成功。真正要看一线值班人能不能收到、认领、升级和关闭。
第三，数据是否能推动改进。
如果试用后你知道哪些告警最吵、谁被打扰最多、哪些故障没人认领、MTTA 是否变好，那这个试用就是有效的。
Flashduty 的价值不是替换你的监控系统，而是先把现有监控产生的告警接住、降噪、分派、升级和闭环。
14 天足够验证这件事。
先选一个业务，接入一个真实告警源，跑完一次从告警触发到故障复盘的完整流程。
👉 现在注册试用
参考资料
- Flashduty 产品与文档：14 天专业版免费试用、入门指南、协作空间、集成数据、分派策略、值班管理、个人通知设置、告警降噪、分析看板、通知渠道、作战室、状态页、故障复盘、定价与 License 模式。
