自研告警平台最难的地方，不是第一版做出来。
第一版通常并不复杂：接几个 Webhook，写一套路由规则，发到飞书、钉钉或企业微信群，做一个告警列表，加一点去重和静默，再补几个统计报表。很多公司都能做。
真正难的是后面几年。监控系统越来越多，业务团队越来越多，值班机制越来越复杂，通知渠道越来越碎，审计和权限要求越来越细，管理者开始要 MTTA、MTTR、响应比例和人员负载。原来那个“够用”的自研告警平台，会慢慢变成一个没人敢动、又离不开的内部系统。
这时候问题不是“自研对不对”。自研当然可以对。真正的问题是：这个平台现在还在创造差异化价值，还是已经变成高成本的通用基础设施维护？
如果只是把告警接住、降噪、分派、升级、通知、分析、审计和复盘闭环做一遍，那它很可能已经不值得继续重投入自研。
先承认：自研平台一开始通常是合理的
很多自研告警平台不是拍脑袋做出来的。公司早期没有合适的商业工具，监控系统格式特殊，通知要接内部 IM、短信网关或工单系统，采购流程又慢，团队只能先自己解决问题。
这些原因都成立。并不是所有团队都应该放弃自研。如果告警平台承载了强业务语义，比如和交易风控、调度系统、自动化变更、容量决策或混沌演练深度绑定，它可能确实是核心能力。
但很多平台后来偏离了这个方向。它们一开始为了解决一个业务问题，最后把大量精力花在通用能力上：值班表怎么排，没人认领怎么升级，重复告警怎么聚合，维护窗口怎么静默，谁能看哪个团队的故障，操作审计怎么留，飞书、钉钉、企业微信接口变了怎么办。
这些事情重要，但不一定值得每家公司都自己造一遍。
自研告警平台的成本，通常被低估了
评估自研成本时，很多团队只算服务器和开发人力。这太少了。真正的成本至少有七类。
第一类是接入成本。Zabbix、Prometheus、Grafana、夜莺、云监控、Sentry、日志平台、自研监控、数据库监控、Kubernetes 事件，都会陆续进来。每多一个告警源，就要处理字段映射、状态转换、恢复逻辑、去重 key、严重级别、标签规范和异常重试。
第二类是通知成本。发一条群消息很简单，但生产 On-call 需要 App 推送、语音、短信、邮件、飞书、钉钉、企业微信、Slack、Teams，还要知道通知是否成功，失败后是否兜底，夜间 Critical 是否穿透勿扰。这些边界往往不会在白天测试时暴露，而是在凌晨故障时暴露。
第三类是排班成本。值班表不是一个日历。真实团队需要按天、周、月轮换，白班夜班分离，主备角色，临时调班，请假顶班，交接提醒，多值班表并存，不同服务走不同值班表。如果平台只支持“今天谁值班”，它很快会被 Excel 和群公告绕开。
第四类是升级成本。关键故障不能没人响应，所以系统要支持自动升级：主值班 5 分钟未认领，升级给备值班；15 分钟未关闭，升级给 Owner。这里不只是定时器，而是状态机：认领、暂缓、关闭、自动恢复、手动升级、重新分派和重复通知都要处理好。写错了，要么漏通知，要么通知轰炸。
第五类是降噪成本。去重不等于降噪。成熟的降噪要支持聚合、静默、抑制、抖动检测、风暴预警、延迟窗口和标签增强。做浅了没效果，做深了很耗人。
第六类是管理成本。平台负责人要补 RBAC、团队数据权限、SSO、审计日志、用量数据、分析看板、数据导出、API Key 和操作留痕。这些都是“做了没人夸，不做一定出事”的功能。
第七类是机会成本。维护告警平台的人，通常也是最懂公司稳定性、监控体系和基础设施的人。他们本可以去提升监控质量、改进发布系统、做自动化恢复、建设服务目录、推动 SLO。长期修通知适配、值班表边界和报表字段，公司损失的是稳定性能力建设的时间。
判断是否继续自研，先问三个问题
不要用情绪判断自研平台，也不要因为看到商业产品就立刻替换。先问三个问题。
第一个问题：这套平台有没有不可替代的业务语义？如果平台只是通用告警响应，价值主要是接收告警、通知、排班、升级和报表，它很容易被专业 On-call 平台替代。如果平台深度参与业务决策，比如根据交易风险调整熔断策略，和发布系统一起做智能回滚，基于 CMDB 和容量模型判断故障影响范围，它就有继续保留的理由。
第二个问题：当前维护投入是否还匹配收益？
年维护成本 = 研发人力 + 值班排障 + 通知通道维护 + 云资源 + 安全合规 + 需求沟通 + 历史包袱处理
如果每年投入大量人力，只是在追赶通用 On-call 能力，性价比通常很低。
第三个问题：平台风险是否已经高于迁移风险？很多团队不迁移，是因为怕影响告警链路。这个担心合理，但也要反过来问：旧平台是否已经偶尔丢告警，通知失败是否没人知道，权限是否过粗，审计是否不完整，值班表是否靠群公告兜底，故障没人认领是否只能靠人工催，报表是否无法回答 MTTA、MTTR 和中断次数。
如果这些问题已经存在，旧平台本身就是风险源。
自研平台最容易卡住的六个能力
很多平台不是完全不能用，而是卡在深水区。这些深水区很适合作为评估清单。
1. 告警模型：事件、告警、故障是否分清
自研平台常见的问题，是所有东西都叫“告警”。监控系统推来的原始消息是告警，同一个问题的多次触发也是告警，一组相关问题也是告警，需要人处理的事项还是告警。
概念混在一起，后面就很难做降噪和分析。更合理的模型应该区分：
事件 Event -> 告警 Alert -> 故障 Incident
事件是原始上报，告警是同一检查项或同一对象的状态变化，故障是需要人处理、可分派、可认领、可关闭、可复盘的对象。Flashduty On-call 采用的就是这类模型：接收监控系统上报的事件，自动触发告警，再由告警触发故障；相似活跃告警可以聚合到同一条故障里统一处理。
如果自研平台没有故障这一层，团队处理的永远是一堆离散消息。
2. 通知链路：能不能从“发出去”升级到“可确认”
很多自研平台只能证明消息已经调用了接口。但 On-call 需要的是：人是否真的被触达，并且是否完成响应动作。
通知链路至少要支持分渠道策略、交互式处理和结果入时间线。Info 可以进群，Warning 可以 App 或 IM，Critical 需要 App、短信、电话甚至多级升级。值班人应该能在 App、IM 卡片或语音电话里直接认领故障。通知什么时候发出，发给谁，通过什么渠道，是否成功，是否有人认领，也应该进入故障时间线。
否则复盘时只能翻群聊和网关日志。
3. 值班和升级：能不能自动承担责任分配
值班表必须能被分派策略调用。如果告警来了，系统还要让人去查今天谁值班，再手工 @，那这个值班表没有进入 On-call 链路。
成熟的值班能力要支持轮换规则、白班夜班、主备角色、临时调班、交接提醒、多人值班、公平轮换和团队管理。升级策略则要回答：当前环节通知谁，多久未认领或未关闭进入下一环节，是否重复通知，是否允许暂缓，是否允许手动升级和重新分派。
Flashduty 的分派策略把触发条件、通知对象、通知方式、延迟窗口、通知模板和升级规则放在一起。对自研平台来说，这些不是锦上添花，而是关键故障不漏单的基本保障。
4. 降噪：能不能减少无效打扰，而不是隐藏风险
自研平台很容易把降噪做成“少发点”，这很危险。真正的降噪不是把告警关掉，而是把多条相关告警收敛成可处理的故障，同时保留关键上下文。
同一服务同一资源的重复告警应该聚合，维护窗口内的已知告警应该静默，上游故障导致的下游派生告警应该抑制，短时间反复触发和恢复的告警应该识别抖动，大量告警合入同一故障时应该触发风暴预警。
更关键的是，降噪效果要能被衡量：故障数量是否下降，夜间中断是否下降，Critical 响应比例是否保持，告警 TOP 是否变化。否则“降噪”很容易变成“把问题藏起来”。
5. 权限、审计和合规：能不能进入企业级使用
很多自研平台早期只有管理员和普通用户，小团队还可以，多业务线共用后就不够了。平台需要回答：谁能创建协作空间，谁能修改分派策略，谁能管理值班表，谁能查看某个团队的故障，谁能创建 API Key，谁能看审计日志。
Flashduty 的权限设计把权限分成功能权限和数据权限。功能权限基于角色控制，比如 Admin、Responder、Viewer，也支持自定义角色；数据权限基于团队控制，用于限定协作空间、值班表、模板和集成等资源的管理范围。审计日志会记录写操作，包含时间、用户、事件名称、事件 ID 和来源 IP。
这些能力在事故发生前常常没人关心，事故发生后会变成必需品。
6. 数据分析：能不能回答管理问题
很多自研平台最后会补报表，但报表不是把告警数按天画出来。管理者真正关心的是：哪个团队故障最多，哪个服务 MTTA 变长，哪个人响应投入过高，夜间中断是否在下降，Critical 故障响应比例是否稳定，哪个检查项贡献了最多噪音。
Flashduty 分析看板支持按团队、协作空间、人员、严重程度、时间范围等维度查看数据，指标包括故障数量、MTTA、MTTR、响应比例、响应投入和中断次数，也支持告警检查项和告警对象 TOP。
这类能力不是管理装饰。它决定了团队能不能从“感觉最近告警很多”，走到“这个服务的夜间中断主要来自这三条规则，下周先治理它们”。
什么时候继续自研，什么时候收缩或替换
不是所有自研平台都应该替换。可以用下面这个矩阵快速判断。
建议继续自研的情况是：平台承载强业务语义，商业产品很难表达；平台和内部自动化修复、发布、容量系统深度绑定；团队有稳定的平台工程投入；当前平台已经具备完整 On-call 闭环；安全、网络或部署环境限制导致 SaaS 和私有化都无法满足。
建议收缩自研范围的情况是：监控和业务判断有价值，但通知、值班、升级、分析维护成本高。更现实的做法是保留内部告警规则和业务决策层，把通用的通知、值班、升级、协同和分析交给专业 On-call 平台。
建议评估替换的信号是：需求主要集中在飞书/钉钉/企微集成、电话短信、值班表、升级策略、静默、聚合、分析看板、审计、权限、复盘等通用能力；平台维护依赖少数人；业务团队开始绕开平台；管理者要的数据拿不到；故障响应仍然靠群里喊人。
一旦大家开始在 Prometheus Alertmanager 单独配机器人，在 Zabbix 里单独配短信，自己写脚本发群消息，用 Excel 管值班，说明统一平台已经跟不上真实工作流。
不要用“大迁移”开始
很多团队一想到替换自研平台，就担心大迁移。这个担心合理，告警链路不能随便动。更稳妥的方式，是从一个业务或一个告警源开始并行验证。
第 1 步：选一个核心但边界清晰的业务，比如支付、订单、核心数据库或 Kubernetes 集群。
第 2 步：保留原有监控系统，不改采集和规则，只把告警同步接入 Flashduty。
第 3 步：配置协作空间、标签映射、分派策略和值班表。
第 4 步：只对部分 Critical 告警开启真实通知，其他告警先观察。
第 5 步：跑 2 到 4 周，对比原平台和 Flashduty 的响应数据。
第 6 步：确认稳定后，再扩大到更多团队和告警源。
这个过程不要求一次性废掉自研平台。目标是先回答几个具体问题：Flashduty 能不能接住现有告警，标签和严重级别是否能保留，分派策略能不能覆盖真实值班机制，电话、短信、App、IM 是否能可靠触达，没人认领时是否能自动升级，故障时间线是否能支撑复盘，分析看板是否能替代人工报表。
如果这些问题都能回答，再谈替换。
和自研系统集成，不一定要二选一
自研平台和 Flashduty 不是只能选一个。迁移可以分层进行：
监控和检测继续保留。
业务特有决策继续保留。
通用 On-call 响应交给 Flashduty。
故障状态和结果再同步回内部系统。
如果有自研监控系统，可以通过标准告警事件把告警推送到 Flashduty，触发故障处理流程。如果希望把 Flashduty 里的故障变化同步回内部平台，可以使用故障 Webhook。Webhook 支持创建故障、分派、认领、暂缓、关闭、重新打开、合并、评论、更新标题、更新严重程度等事件类型，接收方需要根据事件 ID 做去重。
如果希望内部系统主动查询或管理数据，可以使用 Open API，通过 HTTPS 和 APP Key 查询、管理故障、协作空间、值班表等实体。内部自动化动作，比如重启服务、创建工单、触发脚本，也可以通过自定义操作和 Webhook 集成打通。
这个模式比“全部推倒重来”现实得多。
成本对比不要只看 License
很多团队比较商业产品和自研平台时，会说：自研平台不用买 License。这句话只对一半。
自研平台不用买软件 License，但会消耗内部工程 License。告警接入、通知通道、值班表、升级策略、权限审计、报表导出、数据存储、前端页面、移动端或 IM 交互、故障排查、安全修复，都是真成本。
Flashduty On-call 是 License 订阅制，只有需要查看和处理故障的成员才需要 License；仅被动接收通知的成员不需要 License。对很多大团队来说，这比“全员买席位”的模式更容易控制成本。
但价格不应该是唯一决策依据。更合理的是算总拥有成本：
自研总成本 = 平台研发维护人力 + 通知通道费用 + 基础设施 + 需求沟通 + 故障风险 + 机会成本
商业平台总成本 = License 费用 + 超额通知费用 + 接入迁移成本 + 内部适配成本
如果自研平台的差异化价值很高，继续投入可能值得。如果它主要在维护通用 On-call 能力，就应该认真考虑把这部分交出去。
最后：不要为了过去的投入继续投入
自研平台最容易陷入沉没成本：已经做了三年，已经接了几十个系统，已经写了很多规则，已经有不少团队在用，所以继续维护。
但过去投入过，不代表未来还应该继续投入。真正应该看的，是未来一年这个平台会消耗多少人力，会带来多少风险，会不会阻碍团队把精力放在更重要的稳定性建设上。
如果一个平台已经稳定承载业务特有能力，就继续把它做好。如果它只是承载通用 On-call 流程，却长期拖住平台团队，那就应该考虑把告警接入、降噪、分派、升级、协同、分析、审计和复盘交给 Flashduty 这样的专业平台。
不是因为自研不好，而是因为工程团队最宝贵的资源，不应该长期花在重复造通用基础设施上。
