很多企业到了某个阶段，都会遇到一个有点尴尬的问题：
几年前花了不少人力做起来的自研监控或可观测平台，现在还要不要继续维护？
这个问题不好回答。说继续维护，团队里已经没有当年那批核心开发了，需求还在不断往上堆；说停掉，又担心已有能力、历史规则、内部流程和团队习惯一下子断掉。更麻烦的是，自研平台往往不是一个单纯的技术项目，它背后还有组织协作、故障响应、权限边界、合规审计和历史包袱。
所以我不建议用“自研好”或者“商业平台好”来讨论这件事。
更合理的问题是：当年自研解决了什么问题？今天它还在解决同一个问题吗？继续维护的成本，是不是已经超过了它带来的控制感和定制收益？如果要收敛，哪些能力该保留，哪些能力该交给成熟平台或开源组件？
把这几个问题拆开，答案会清楚很多。
自研平台当年通常是合理的
很多自研可观测平台不是拍脑袋做出来的。它们出现时，往往有很现实的原因。
早期企业内部系统规模上来以后，单个开源工具很难直接满足全部需求。Prometheus 负责指标，Grafana 负责大盘，ELK 负责日志，SkyWalking 或 Jaeger 负责链路，Zabbix 还在管不少主机和网络设备。每个工具都能用，但账号、权限、标签、业务线、告警流转和展示入口都不统一。事故发生时，值班人要在多个系统之间切换，复制机器名、服务名、trace_id、时间范围，再去问不同团队谁负责哪个系统。
这时候做一个内部平台，把这些工具包起来，是合理的。
还有一些企业有很强的内部流程。CMDB、发布系统、工单系统、权限系统、值班系统、审计系统都已经存在，外部工具很难直接贴合内部组织结构。比如某个部门只能看自己业务线的数据，某个核心系统的变更必须进入审计，某类告警必须先发给一线值班，再升级到二线负责人。这些都不是简单装一个开源组件就能解决的。
自研平台在这个阶段的价值很明确：把分散工具统一起来，把内部流程接进来，把企业自己的资产模型和组织模型放到观测系统里。
这不是低水平重复建设。很多团队当年如果不自研，反而很难把监控体系真正推起来。尤其是在云原生和 OpenTelemetry 还没成熟、商业可观测产品也不够贴合本地化需求的时候，自研是一个务实选择。
问题在于，可观测平台不是做完一版就结束的系统。
成本不是从采集开始，也不会停在查询
自研平台最容易被低估的，是长期维护成本。
刚开始看，平台要解决的事情似乎不复杂：采指标、存指标、查指标、配告警、做大盘。很多团队第一版也确实能很快跑起来。接入 Prometheus 或自研采集器，时序数据写进 VictoriaMetrics、M3、Thanos 或其他存储，再加一个查询页面和大盘页面，基础监控就能工作。
但只要平台进入生产，它的边界会不断扩大。
第一层扩展是数据类型。光有指标不够，研发要查日志，性能问题要看 Trace，业务异常要看订单表或业务库，基础设施还要接云监控、Kubernetes Events、网络拨测、数据库慢日志、中间件状态、发布事件和配置变更。每多一种数据，就多一套接入、查询、索引、权限、成本和故障处理逻辑。
第二层扩展是平台能力。用户不只要查数据，还要收藏查询、保存大盘、导入模板、配置变量、做权限隔离、设置通知渠道、屏蔽维护窗口、管理告警升级、支持审计、支持多租户、支持数据源授权。很多功能单独看都不大，但长期堆起来就是一个完整产品团队的工作量。
第三层扩展是事故现场。真正的故障不是“CPU 高了”这么简单。一个支付成功率下降，可能要从北向业务指标开始看，再下钻到网关、订单服务、支付服务、Redis、Kafka、MySQL、最近发布、异常日志和慢 Trace。平台如果只提供查询框和值班大盘，值班人还是要靠经验把线索串起来。新人接班时，问题会更明显：工具都在，但路径不在。
第四层扩展是治理能力。告警会变多，规则会变旧，标签会漂移，服务名会不一致，日志字段会各打各的，仪表盘会没人维护。SRE 想做 SLO，发现业务指标口径不统一；平台团队想做 AI 分析，发现 AI 拿不到系统对象、健康状态、上下游关系和可用的下钻路径，只能生成一些泛泛建议。
第五层扩展是组织和合规。谁能看哪些业务的数据，谁能改告警规则，谁能操作采集配置，谁能下载日志，谁的查询会影响集群，哪些操作要进审计，哪些数据要脱敏，哪些系统要按部门隔离。这些事情在小团队里不显眼，在中大型企业里会变成硬要求。
到这里，自研平台已经不只是采集、存储和查询了。它变成了一个横跨指标、日志、链路、告警、权限、SLO、值班、审计、AI 和稳定性运营的系统。继续维护它，需要的不只是几个后端工程师，而是产品、前端、后端、数据、SRE、存储、AI、安全和运维一起长期投入。
如果公司愿意把它当战略平台养，这当然可以继续做。怕的是平台已经承担了战略级复杂度，但组织还把它当几个工程师的内部工具。
判断要不要继续维护，看四件事
讨论自研平台是否继续维护，不要从情绪出发，也不要只看采购价。可以从四个维度判断。
第一，看差异化是否真实存在。
如果自研平台的核心价值是和内部 CMDB、发布系统、工单系统、权限系统、审计系统、业务模型强绑定，而且这些绑定确实支撑了核心故障响应流程，那它仍然有保留价值。这样的能力外部平台很难完全替代，至少不应该一刀切废掉。
但如果平台主要是在 Prometheus、Grafana、ELK、Jaeger 外面包了一层入口，做了几个查询页面、权限页面和告警页面，那就要谨慎。因为这些能力已经进入成熟平台和开源组合的标准范围，继续自研的收益会越来越低。
第二，看团队是否有持续产品化能力。
可观测平台的难点不是某个功能能不能做，而是能不能长期把体验、性能、权限、稳定性和治理做扎实。比如日志查询慢了谁来优化？高基数指标把存储打爆了谁来处理？告警噪音太多谁来治理？新业务接入时谁来定义标签规范？AI 分析需要上下文时谁来补对象模型？
如果平台团队长期稳定，有明确负责人，有路线图，有用户反馈机制，有运维预算，自研可以继续走。反过来，如果维护已经靠少数人临时救火，需求排期常年排不上，核心模块没人敢改，那继续扩展只会让风险更大。
第三，看事故现场是否变快。
这是最重要的标准。可观测平台不是给大家看图用的，它最终要缩短发现、定位和处理故障的时间。
可以拿真实故障复盘来检验：业务异常出现时，平台能不能先告诉大家哪个业务受影响？能不能从业务指标跳到技术对象？能不能从异常对象继续看日志、Trace、仪表盘、事件和最近变更？能不能自动带上时间范围、服务名、实例名、pod、trace_id 这些上下文？新值班人是否不用问老同事，也能沿着平台给出的路径查下去？
如果答案大多是否定的，那平台虽然自研了很多年，但它可能只是工具入口，不是真正的故障处理入口。
第四，看总成本是否还说得过去。
自研平台没有采购费，但不是免费。研发人力、存储资源、查询性能优化、故障值守、合规改造、用户培训、需求沟通、人员流失风险，都是成本。更隐蔽的成本是事故现场的人力浪费：多个团队围在群里查半天，反复复制字段，重复打开大盘，却没有一条清晰路径。
如果自研平台每年消耗的隐性成本已经很高，而新增能力又跟不上业务复杂度，那就该考虑收敛。收敛不是承认过去错了，而是承认问题已经变了。
不是“自研或商业”二选一
很多讨论容易走向极端：要么继续全部自研，要么全部替换成商业平台。现实里更常见、也更稳的路线，是共存和分层。
底层数据不一定要重来。企业已经有 Prometheus、VictoriaMetrics、Elasticsearch、Doris、Loki、SLS、CLS、SkyWalking、Jaeger、ARMS、Zabbix、公有云监控，这些系统里都有存量数据、查询习惯和历史经验。直接推倒重建，风险很大，也不一定划算。
更好的做法，是先判断哪些系统适合继续作为数据底座，哪些系统适合退到历史或专用场景。成熟的时序、日志、链路系统可以继续保留，通过数据源集成接到上层平台。自研采集器如果仍然稳定，也可以先保留；如果和 OpenTelemetry、Prometheus 生态差距太大，再分批迁移。日志和链路尤其不要轻易重采全量，优先复用已有存储，再逐步治理字段、服务名、trace_id 和资源标签。
Flashcat 在这里的角色，不是要求企业否定所有内部能力。
它更适合放在已有系统之上，做几件自研平台最容易越做越重、但事故现场又离不开的事情：接入已有数据源，统一对象模型，建立从业务到技术对象的下钻路径，把北极星、灭火图、事件墙、SLO、告警和值班入口组织起来，再让 FlashAI 基于这些上下文做分析和巡检。
这和“再做一个查询入口”不是一回事。
查询入口解决的是数据能不能看到。对象模型和下钻路径解决的是事故发生时该从哪里开始、下一步看什么、哪些线索相关、哪些数据应该被自动带过去。北极星负责把业务核心指标变成故障发现入口，灭火图负责把接口、服务、组件、基础设施拆成可观测对象，并为每个对象配置健康状态和排查入口。FlashAI 的价值也建立在这些上下文之上，而不是靠一个聊天框凭空分析。
如果企业内部已经有很强的 CMDB、发布系统、工单系统和值班体系，也没必要简单废掉。更实际的做法是让它们继续承担自己擅长的部分：CMDB 负责资产和归属，发布系统负责变更事件，工单系统负责流程沉淀，值班系统负责通知升级。Flashcat 负责把观测数据、对象健康和排查路径组织到同一个事故现场里。
这样，自研能力不是被否定，而是回到更清晰的位置。
一条更稳的迁移路线
如果决定从自研平台收敛到商业平台、开源组合或二者组合，不要一上来就大替换。可观测系统本身承担生产保障，迁移它必须保守。
第一步，先盘点存量能力。
列清楚当前自研平台有哪些数据源、采集器、告警规则、通知渠道、权限模型、仪表盘、日志字段、Trace 系统、SLO 口径、值班流程、审计要求和内部系统集成。特别要标出哪些能力仍在真实事故中被频繁使用，哪些只是历史遗留，哪些已经没人敢动。
这一步不要只问平台团队，也要问一线值班、研发负责人和业务负责人。平台团队看到的是模块，值班人看到的是路径，业务负责人看到的是影响面。三者合起来，才能判断哪些东西必须保留。
第二步，并行接入，不急着下线。
先把已有 Prometheus、日志系统、链路系统、云监控、Zabbix 或自研数据源接入 Flashcat，在上层建立少量核心系统的北极星和灭火图。不要一开始追求覆盖全公司，先选一条真实核心链路，比如登录、下单、支付、投放、交易或调度系统。
这个阶段的目标不是“新平台功能完整”，而是证明它能让一个真实事故场景更快。比如业务指标异常后，值班人能从北极星进入关联的灭火图，再从异常服务下钻到指标、日志、Trace 和最近事件。如果这条路径跑通，后续迁移会顺很多。
第三步，治理标签和上下文。
很多迁移失败，不是工具问题，而是数据上下文太乱。service 名在指标里叫 A，在日志里叫 app-a，在 Trace 里叫 order-service；环境字段有 prod、production、prd 三种写法；pod、instance、host、namespace、cluster 缺一块；日志没有 trace_id。这样的数据接入任何平台都很难用。
所以要把服务名、环境、集群、业务线、系统、实例、pod、trace_id、span_id 这些字段逐步统一。短期可以通过映射和规则补齐，长期还是要在采集和应用输出侧治理。OpenTelemetry 和 Prometheus 生态不是银弹，但它们提供了更容易协作的公共语言。
第四步，分批迁移告警和大盘。
不要把所有告警规则一次性搬过去。先迁核心业务的关键告警，尤其是能和北极星、灭火图对象绑定的规则。基础资源类、历史脚本类、特殊设备类告警可以继续在老系统里跑一段时间，作为兜底。
仪表盘也一样。真正有用的大盘保留，没人看的大盘不要迁。迁移不是搬家比赛，目标是减少事故现场的噪音。与其复制一百个历史大盘，不如把十个核心对象的健康状态、关键指标和下钻路径做扎实。
第五步，把自研平台退到合适位置。
有些自研模块可以下线，有些可以只读保留，有些可以改成内部系统适配层，有些应该继续作为企业独有能力存在。比如内部 CMDB 适配、发布事件接入、特殊行业设备监控、合规审计报表，这些未必需要丢掉。关键是不要让自研平台继续承担它已经不适合承担的全套可观测产品职责。
最后一步，建立新的治理节奏。
平台迁移完成不是结束。要定期检查核心对象是否覆盖、下钻路径是否可用、告警是否噪音过高、SLO 口径是否准确、FlashAI 分析是否能拿到足够上下文、权限是否符合组织变化。可观测平台最怕“一次建设，长期失修”。自研平台会遇到这个问题，商业平台也一样。
结论：别维护一个越来越像产品公司的内部项目
自研可观测平台要不要继续维护，答案不是统一的。
如果它承载了企业独有的资产模型、稳定流程、行业场景和组织协作，并且公司愿意持续投入一个真正的平台团队，那它值得继续维护，甚至可以继续做深。
如果它只是把一堆开源组件包了一层，核心开发人员已经离开，需求积压严重，告警、权限、日志、链路、SLO、AI、值班和合规都在不断往里压，那就该认真考虑收敛。继续维护这样的系统，本质上是在内部养一个越来越像产品公司的项目，但没有产品公司的投入强度。
更务实的路线，是保留内部真正有价值的能力，把通用可观测平台能力交给成熟产品和成熟开源生态，把精力放回对象建模、排障路径、业务健康和稳定性治理上。
Flashcat 能参与的地方，也正是在这里：接入已有系统，不要求推倒重来；把指标、日志、链路、事件和业务指标组织到对象上；用北极星发现业务异常，用灭火图承接系统健康和下钻路径，用 FlashAI 基于真实上下文做分析、巡检和建设盘点。
如果你的自研平台也走到了这个十字路口，可以先不用急着问“换不换”。把一条核心业务链路拿出来，看看它今天从发现异常到定位原因要走多少系统、问多少人、复制多少字段。再用 Flashcat 接一次已有数据，建一版北极星和灭火图，跑一遍真实排障路径。结果通常会比选型表更诚实。
