StablePay 监控与告警体系优化方案

1. 背景

1.1 现状简介

当前 StablePay 已具备基础监控与告警能力，生产环境已接入 SLS、APM、Trace、K8s 指标等观测能力，能够支撑日志查询、链路排查、指标加工和部分业务告警。

当前监控告警主链路以 SLS 日志 -> 数据加工 -> MetricStore -> SLS 告警 -> 通知对象 为主，已具备运行基础，但在指标覆盖、告警规则厚度和通知治理方面仍有完善空间。

1.2 本次优化目标

本次方案基于现有建设，对指标、告警规则、通知机制和云监控 2.0 告警归集进行补齐和优化。

2. 现状

2.1 指标现状

当前生产环境已存在业务日志转指标能力，并已落在 stablepay-log-prod/stablepay-log-metrics 中。结合现有查询结果，当前核心指标主要围绕业务结果、业务量和错误量展开，已明确看到的指标族包括：

unified_action_outcome
unified_biz_count
unified_error_count

在香港地域当前已确认的相关 SLS 项目包括：

stablepay-log-prod
stablepay
sls-alert-5789353176465649-cn-hongkong
cms-alert-center-5789353176465649-cn-hongkong

其中 stablepay-log-prod 下当前已确认存在以下 Logstore / MetricStore：

stablepay-log
stablepay-log-metrics
internal-alert-history
internal-etl-log

结合现网告警规则进一步复核后，可确认一条非常关键的事实：

当前生产 SLS 正式业务告警并不是简单“都直接查某一个 raw logstore”
主流模式是：
- 主判定基于 stablepay-log-metrics / metrics
- 部分规则再联查 stablepay-log 原始日志补 message、trace_id、error 等排障上下文

已确认的代表样本包括：

业务成功率下降（5m ）： stablepay-log-metrics.prom 指标查询 + stablepay-log 原始日志补样本
System 错误爆发（5m system 错误数 > 10）：直接基于 unified_error_count{error_class="system"} 的 metrics 聚合判定

因此，后续正式规则建设与云监控 2.0 收口时，应默认把 stablepay-log-metrics 视作业务结果类规则的主判定来源，而把 stablepay-log 视作可选的排障上下文补充来源。

其中 sls-alert-5789353176465649-cn-hongkong 下当前已确认存在统一告警历史仓：

internal-alert-center-log

从该历史仓抽样结果可以直接确认，当前历史事件中已经包含以下统一字段：

alert.alert_name
alert.project
alert.policy.action_policy_id
alert.policy.alert_policy_id
alert.status
alert.severity

这意味着后续补齐“规则历史分母”可以不只依赖飞书群消息，还可以直接结合告警中心历史仓进行交叉验证。

当前指标体系已有基础，但总体仍偏收敛，更多围绕统一业务结果类指标展开。后续重点是在现有日志格式之上抽取统一指标、配置监控和告警，不展开日志采集改造本身。

2.2 告警规则现状

当前业务告警主要配置在 SLS 侧。结合现有只读盘点结果，生产环境中当前可见规则总量不多，且规则内容主要集中在成功率、失败率、错误量、理由码异常、指标断流等方向。

当前规则中既有正式业务规则，也混有测试规则和基础系统规则，整体仍偏薄，规则边界仍需收口。

结合 2026-05-11 在 StablePay 生产环境告警群 中抽取的近期消息样本，当前已经可以确认至少有以下规则真实进入生产告警链路：

业务成功率下降（5m ）
Processing 占比异常（5m processing 比例 > 5%）
Deployment Available Replica Error_automode-cluster-stablepay-1

其中前两类告警样本能直接看到 stablepay-log-prod 和 stablepay-log-metrics 的查询链接与 stablepay生产通知策略，说明它们当前仍主要来自 SLS 业务指标规则；第三类告警样本来自 ACK / 云监控侧基础设施能力，通知策略为 ACK_ContactGroup_Default Contact Group (Empty)_IdV2_570301。

2.3 通知机制现状

当前告警通知链路已经存在，控制台中已可见 webhook 集成与对应通知对象，说明“规则触发后发出通知”的基础能力已经具备。

但目前更容易确认“有通知对象”，还难以确认完整的告警分级、处理人归属、升级路径和降噪机制。因此当前通知机制更接近“已接通链路”，后续仍需继续治理。

基于 2026-05-11 的群消息样本，还可以直接确认当前生产告警通知至少存在以下特征：

同一个生产告警群中同时存在 SLS 业务告警和 ACK / 云监控基础设施告警。
群内同时出现 默认告警通知、P1告警通知、告警恢复通知、未解决再次通知 等多种消息形态。
当前基础设施告警样本中已出现 stablepay-pre namespace 的 stablepay-notification Deployment 告警，说明非生产环境样本已经混入当前生产告警群。
当前通知链路已经具备“发出来”的能力，但尚未完成环境边界、重复提醒和恢复通知的一致性治理。

3. 主要问题

3.1 指标覆盖不足

当前核心指标数量和维度仍相对有限，部分核心服务和关键链路是否具备足够的可观测指标，仍需进一步盘点。

3.2 告警规则偏少且覆盖不均

当前正式业务告警规则数量仍然较少，覆盖方向相对集中，更多聚焦于成功率、失败率、错误量等少数维度，对不同服务、不同链路和不同问题类型的覆盖仍不均衡。

3.3 通知机制不够完善

当前通知链路已经存在，但尚未确认一套完整清晰的告警分级、处理人归属、升级路径和降噪策略。若缺少后续处理闭环，告警价值会明显受限。

3.4 云监控 2.0 告警归集能力尚未完成建设

当前监控与告警主链路仍以 SLS 为主，云监控 2.0 侧的统一告警归集能力尚未完成建设。后续不仅需要承接现有 SLS 告警，也需要逐步归集 ARMS、基础设施监控以及其他业务自定义告警，形成统一的告警管理入口。

4. 优化目标

4.1 指标与规则优化目标

先补齐一套可复用的基础指标与通用告警规则，优先提升核心服务在成功率、失败率、错误量、时延、断流等方向的可观测性与可告警性。

4.2 通知机制优化目标

建立与现有告警规则相匹配的通知治理机制，避免告警泛滥或无人响应。

4.3 云监控 2.0 告警归集目标

以云监控 2.0 作为统一告警归集入口，逐步承接现有 SLS 告警，并为后续归集 ARMS、基础设施监控及其他业务自定义告警预留统一管理能力。

5. 方案范围

5.1 本次包含内容

本次方案重点包含以下内容：

盘点并梳理当前指标、告警规则和通知机制现状
在现有基础上补齐和优化核心指标与告警规则
梳理并优化现有通知对象、通知策略和处理链路
明确告警归集到云监控 2.0 的建设目标、承接范围和推进路径

5.2 本次暂不包含内容

本次方案暂不包含以下内容：

一次性重构全部监控与告警体系
在未完成现有规则收口前，直接推动整套监控链路迁移到云监控 2.0
对每一个服务立即给出最终阈值和最终规则清单

6. 总体方案

6.1 总体链路

本次优化仍以现有链路为基础展开，整体链路如下：

业务系统日志 -> SLS 日志存储 -> 日志加工/指标沉淀 -> MetricStore -> 告警规则判断 -> 通知对象 -> 告警接入云监控 2.0

其中，现阶段重点放在日志加工、指标沉淀、告警规则、通知治理和告警归集四个环节，云监控 2.0 在本方案中的定位是统一告警归集与管理入口。

6.2 各环节职责

各环节职责初步定义如下：

指标加工层：基于业务日志和现有加工能力，沉淀可用于监控和告警的统一指标。
告警规则层：围绕核心指标配置合理规则、阈值和触发条件，提升问题发现能力。
通知分发层：将告警按合理方式分发至对应通知对象，支撑告警分级、处理和升级。
平台承接层：以云监控 2.0 为统一告警归集入口，逐步承接 SLS、ARMS、基础设施监控及其他业务告警的统一管理能力。

7. 指标与告警规则优化

7.1 指标盘点方式

指标盘点建议按三层开展，并优先靠近当前已沉淀的指标与规则方向：

分层	定位	主要内容	当前阶段要求
基础通用告警指标	面向所有核心服务统一补齐	请求量、成功率、失败率、错误量、时延、断流	第一优先级
系统稳定性告警指标	面向运行稳定性与基础设施异常	Pod 重启、Ready 异常、CPU / 内存压力、OOM / 异常退出	第一优先级
核心业务通用告警指标	面向 StablePay 核心交易与资金链路共性问题	BizCode / ReasonCode、上游 / 下游错误、processing 占比、状态推进异常	当前先定范式，后续逐步扩展

当前阶段不建议直接定义单业务专属告警指标，而是先沉淀一套跨核心业务链路可复用的告警指标范式。

7.1.1 当前可用指标来源

结合当前阿里云 Observability 与 SLS 盘点，StablePay 当前已确认可直接用于监控与告警的指标来源如下：

来源类型	当前位置 / 数据集	已确认内容	更适合承接的指标方向
SLS 业务日志转指标	`stablepay-log-prod/stablepay-log-metrics`	`unified_action_outcome`、`unified_biz_count`、`unified_error_count`	通用业务结果类指标、核心业务通用告警指标
ARMS / APM 应用黄金指标	`apm.metric.apm.service`	`request_count`、`error_count`、`slow_count`、`avg_request_latency_seconds`、`error_rate`	基础通用告警指标
ARMS / APM 异常指标	`apm.metric.exception`	异常请求数、异常错误数、异常耗时类指标	错误爆发、异常请求类通用规则
Kubernetes 基础设施指标	`k8s.metric.high_level_metric_pod`、`k8s.metric.kube_state_metrics_pod`	CPU、内存、重启、Ready、终止原因等	系统稳定性告警指标
Kubernetes 事件	`k8s.event.events`	`level`、`clusterName`、`pod_name`、`eventId` 等	事件类告警、异常排查辅助
Trace 与日志字段	当前业务日志与链路字段	`trace_id`、`span_id`、`biz_code`、`error`、`caller`、`__topic__`	后续继续沉淀业务语义指标的原始来源

7.1.2 第一版指标清单

第一版指标建设不追求铺满全部系统，而是优先围绕当前已经有数据来源、也更容易形成正式规则的方向推进。

基础通用告警指标

告警指标	建议分级	当前采集来源	当前状态	备注
近 5 分钟成功率下降	P1	SLS MetricStore、业务结果日志	已有沉淀	当前已有“业务成功率下降”方向
近 5 分钟失败率升高	P1	SLS MetricStore、业务结果日志	已有沉淀	当前已有“失败率升高”方向
近 5 分钟错误量升高	P1	SLS MetricStore、ARMS APM	已有沉淀	当前已有 system / upstream 错误爆发方向
近 5 分钟平均时延升高	P2	ARMS / APM 黄金指标	部分沉淀	规则未见明显沉淀
近 5 分钟 P95 时延升高	P1	ARMS / APM	待补齐	建议后续补充
近 10 分钟指标断流	P1	SLS MetricStore	已有沉淀	当前已有“指标断流”方向
近 5 分钟请求量异常下跌	P1	ARMS / APM、SLS 日志聚合	待补齐	适合和成功率一起看

系统稳定性告警指标

告警指标	建议分级	当前采集来源	当前状态	备注
近 5 分钟 Pod 重启次数异常	P2	K8s Pod 指标	待补齐	适合形成统一基础设施规则
Pod Ready 状态异常	P1	K8s Pod 指标	部分沉淀	已看到类似告警结果
Pod CrashLoop / 异常退出	P1	K8s Pod 指标、K8s 事件	部分沉淀	已看到类似告警结果
近 5 分钟 CPU 使用率过高	P2	K8s Pod 指标	待补齐	建议补齐
近 5 分钟内存 Working Set 过高	P2	K8s Pod 指标	待补齐	建议补齐
近 5 分钟 OOM 风险升高	P1	K8s Pod 指标、K8s 事件	待补齐	建议补齐
副本可用数异常	P1	云监控 2.0 / K8s 相关能力	部分沉淀	当前已有类似告警结果

核心业务通用告警指标

告警指标	建议分级	当前采集来源	当前状态	备注
近 5 分钟非 0000 BizCode / ReasonCode 异常升高	P1	SLS MetricStore、业务日志	已有沉淀	当前已有“非0000 reason 总量升高”方向
近 5 分钟 Upstream 错误量升高	P1	SLS MetricStore、业务日志	已有沉淀	当前已有“Upstream 错误爆发”方向
近 5 分钟 System 错误量升高	P1	SLS MetricStore、业务日志	已有沉淀	当前已有“System 错误爆发”方向
近 5 分钟 processing 占比异常	P2	SLS MetricStore、业务日志	已有沉淀	当前已有“Processing 占比异常”方向
近 5 分钟长时间 pending / 未终态占比异常	P2	SLS 业务日志、业务结果日志	待补齐	适合核心链路观察
近 5 分钟状态推进异常量升高	P1	BizCode / 业务日志 / MetricStore	待补齐	需结合业务动作范式推进
近 5 分钟上游 / 下游依赖失败率升高	P1	业务日志、ARMS、MetricStore	部分沉淀	适合 payment、payout、channel、callback 等链路
近 5 分钟对账 / 核对异常量升高	P0 / P1	业务日志、核对任务结果	待补齐	高价值，后续补业务语义

7.1.3 指标建设原则

优先靠近当前已沉淀指标与规则，不从零设计一整套全新体系。
先定义通用指标，再逐步扩展单业务专属指标。
先保证基础通用与系统稳定性，再逐步补厚核心业务通用告警指标。
第一版指标建设目标不是做大盘美化，而是尽快支撑正式规则建设与云监控 2.0 收口。

7.2 规则补齐思路

当前规则优化建议分两步推进：

先围绕当前已有沉淀方向补齐统一规则，如成功率下降、失败率升高、错误爆发、指标断流、理由码异常、upstream 错误、processing 占比异常等。
在统一规则逐步收口后，再结合核心业务链路沉淀一套业务通用告警规则范式，后续由业务 owner 逐步扩展更细的业务告警。

规则补齐的目标是让基础规则与业务规则形成清晰分层，便于后续分级、通知和云监控 2.0 归集。

7.2.1 规则组织方式：统一模板 + 系统级 Override

当前阶段不建议直接走“所有系统完全共用一套规则”或“每个系统完整复制一套规则”这两个极端方案。

原因如下：

若所有系统完全共用一套规则，当少数核心系统需要更严格阈值或更短触发窗口时，调整会牵一发动全身。
若每个系统都复制一整套正式规则，短期虽灵活，但很容易造成规则数量膨胀、维护成本上升和收口困难。

因此，本方案建议采用“统一规则模板 + 少量系统级 override”的组织方式：

先定义一组跨系统复用的正式规则模板，例如成功率下降、失败率升高、System 错误爆发、processing 占比异常、Deployment Replica 异常、Pod 不健康等。
每条规则模板先维护一套默认阈值、持续时间、重复提醒间隔和默认分级，作为第一阶段基线。
只有当某个系统在业务重要性、流量规模、噪音特征或处理要求上明显不同，才为该系统追加 override。
override 只覆盖必要字段，例如阈值、持续时间、最小样本量门槛、分级或通知动作，不复制整条规则定义。

建议按如下抽象管理：

rule_template：规则模板定义，负责表达“监控什么问题”。
system_rule_override：系统级差异化配置，负责表达“某个系统需要比默认模板更严格、更宽松或不同分级”。

这样做的目标是：

保持规则总量可控，避免“每个系统一整套”带来的快速膨胀。
允许核心系统在必要时独立提高阈值敏感度，不被全局统一阈值限制。
便于后续在云监控 2.0 中建立统一模板后，按系统补差异，而不是重复建大量近似规则。

7.3 阈值评审方式

阈值不建议在当前阶段一次性拍死，而应结合历史数据、当前流量规模、误报情况和服务重要性分批评审：

基础通用规则先形成一版默认阈值，作为第一阶段统一基线。
高优先级规则优先按 P0/P1/P2/P3 进行区分，不同等级使用不同阈值和持续时间。
对用户影响与资金影响更直接的指标，优先采用更严格的阈值。
对资源、稳定性和趋势类指标，可采用相对宽松阈值，避免过早制造告警疲劳。
规则正式上线后，需要根据历史噪音和真实事件持续调整。

7.4 告警收敛原则

规则补齐的目标不是单纯增加规则数量，而是在保证发现问题能力的前提下，尽量减少重复告警、无效告警和低价值告警。收敛时建议遵循以下原则：

同一问题优先保留最能反映结果影响的规则，避免多个规则重复轰炸。
测试规则、历史噪音规则、长期无动作价值规则应优先清理或停用。
规则命名、指标语义与阈值表达应保持一致，降低理解和维护成本。
告警分级应与通知动作绑定，没有明确动作的规则不应长期保留为正式规则。

8. 通知机制优化

8.1 通知对象梳理

在现有 webhook、群组和通知对象基础上，先完成通知对象与规则范围的梳理，明确以下内容：

哪些正式告警当前已有明确接收对象
哪些告警已有通知链路但接收范围不清晰
哪些规则仍未绑定有效通知对象
哪些通知对象只是测试或临时使用，需从正式体系中剥离

通知对象梳理的目标不是罗列地址本，而是建立“规则 -> 分级 -> 通知对象 -> 处理人”的可追踪关系。

当前阶段可先不把 owner / 备用 owner 盘点完成作为前置阻塞项。第一阶段先完成规则分级、通知模板和规则归属范围梳理；在正式切主通知前，再为进入正式体系的规则补齐处理责任人。

8.2 告警分级

通知机制优化的核心不在于增加通知渠道，而在于建立一套清晰、可执行的告警分级规则。

StablePay 内部仍保留 P0/P1/P2/P3 这套语义，但当前落地到阿里云云监控 2.0 时，严重度先与阿里云原生四档直接对齐：

阿里云严重度	StablePay 内部语义	当前建议动作
紧急	`P0 / P1`	立即群通知，值班与 owner 优先介入
错误	`P2`	群通知 + 白天处理 / 工单
警告	`P3`	低优先级处理与复盘
普通	观察项 / `P4` 风格低优先级项	观察、看板、低频通知

当前原则：

不在阿里云控制台里强行区分 P0 和 P1
若后续内部需要区分 P0 与 P1，通过规则命名、标签或处理流程表达
第一批正式规则优先使用 紧急 / 错误 / 警告
普通 主要留给观察项、低优先级提示项和灰度告警

8.3 处理人与升级路径

在告警分级基础上，需要同步明确处理责任和升级路径，至少应保证核心告警能够落到明确的处理对象，避免出现告警发出后无人跟进的情况。建议按以下方式设计：

紧急 对应的高优先级规则必须明确值班处理人和升级路径。
错误 至少应明确默认 owner 群组或责任团队。
警告 可不强制即时处理，但需纳入定期复盘或巡检。
对跨团队告警，应明确一线处理团队和后续协同对象，避免多方旁观。

需要说明的是，责任归属可以分阶段补齐：

第一阶段先允许规则以团队或群组维度承接，保证规则本身先落地。
在规则灰度通过、准备切主通知前，再补齐明确的主处理人与升级路径。
未补齐责任归属的规则，不应直接进入最终正式主通知体系。

8.3.1 统一告警群与双轨通知

当前阶段不建议为每个系统拆独立告警群，而建议将正式告警统一收敛到一个 StablePay 主告警群中。

但经过当前 PoC，通知路径需要收口为“双轨通知”：

轨道 1：阿里云原生飞书机器人发送标准告警卡片
轨道 2：轻量 webhook 路由层补发一条短消息，动态 @ 对应 owner

这样做是因为当前已经明确：

阿里云原生飞书卡片可以稳定送达
原生卡片保留 告警规则 / 告警历史 / 认领问题 / 关闭问题 / 屏蔽通知 等 ChatOps 能力
仅依赖“飞书机器人 + 联系人 / 联系人组”并未在当前场景下稳定实现群内自动 @ 联系人

因此，正式通知的推荐形态不是“单轨原生自动 @”，而是：

原生卡片负责完整告警内容与后续处理入口
轻量补充消息负责精准通知到人

当前落地基线进一步收口为：

按告警类型拆通知策略
一个飞书机器人，负责原生告警卡片
一个自定义 Webhook，负责进入飞书自动化补发轻量 @ owner
业务结果类已配置独立通知模板
当前不配置行动集成
当前不配置升级策略

8.3.2 路由方式建议

云监控 2.0 当前更适合作为统一告警入口和规则治理平台，不建议要求其原生承担“按系统动态 @ 飞书成员”的全部能力。

当前建议的实现链路如下：

云监控 2.0 / SLS / ARMS / ACK 告警 -> 飞书原生告警卡片

并行补一条：

云监控 2.0 / SLS / ARMS / ACK 告警 -> 轻量 webhook 路由层 -> 查询 owner 映射 -> 同一告警群发短消息并 @ 对应 owner

这里需要明确：

对 StablePay 正式告警体系而言，“精准通知到对应 owner”仍然是硬需求
但这个需求当前不再强行压在阿里云原生联系人组自动 @ 能力上
告警平台能力与责任人触达能力应拆开处理

当前推荐分工如下：

阿里云原生卡片：标准告警、ChatOps、告警链接、告警历史
轻量路由层：读取 system / service、查 owner 映射、补一条短提醒消息

8.3.2.1 轻量路由层边界

当前补充的 webhook 路由层只做最小职责：

接收告警 webhook
读取 system / service
查询 owner 映射表
向固定正式告警群补发一条短消息并 @ owner

不在这一层重复承接：

完整告警卡片渲染
规则判断
复杂去重引擎
多群分发系统
完整状态机与告警平台能力

建议短消息保持很轻，只负责提醒，不复制整张原生卡片内容。

8.3.2.2 私聊与反馈能力的阶段边界

当前阶段只做最小闭环能力：

所有正式告警统一进入同一个飞书群
群内保留阿里云原生告警卡片
webhook 路由层补发一条短消息，动态 @ 对应 owner
owner 未命中时走兜底文案，不阻断消息送达

第二阶段再评估是否补齐增强能力：

私聊提醒
私聊中的反馈按钮
个人反馈结果自动同步回群
告警认领、误报标记、处理中状态回写等交互能力

当前阶段的默认原则是：优先把“原生卡片 + 轻量 @ owner 提醒”稳定打通；按钮反馈、回写同步等交互能力不作为第一阶段上线阻塞项。

8.3.3 Owner 映射表要求

无论最终采用飞书集成平台还是自建中转层，按系统自动 @ owner 都依赖一张稳定的 owner 映射表。

建议映射表最少包含以下字段：

字段	说明
`system`	系统标识；当前也允许直接承载业务结果类规则中的 `service` 值
`service_scope`	可选，服务范围或更细粒度对象
`owner_name`	主 owner 姓名
`owner_open_id`	主 owner 飞书 open_id
`backup_owner_name`	备用 owner 姓名
`backup_owner_open_id`	备用 owner 飞书 open_id
`team`	所属团队
`status`	是否启用

当前阶段不要求一次性把所有系统 owner 全量补齐，但进入正式主通知体系的规则，必须能够稳定映射到对应 owner 或明确兜底对象。

8.3.4 前置条件与 PoC 验证项

该能力要真正上线，当前至少需要满足以下前置条件：

正式告警消息中必须稳定带出可路由字段，至少包括 system 或可反推 system 的 service / resource 标识。
owner 映射表必须可维护、可查询，并支持后续人员变更。
轻量 webhook 路由层需要经过最小 PoC 验证，确认在同一群内可以稳定补发 @ 目标成员的短消息。

建议 PoC 的验收项包括：

能否从告警消息中稳定解析系统标识。
能否根据映射表查到正确 owner。
能否在同一个飞书群中成功补发 @ 对应 owner 的短消息。
owner 缺失时能否稳定走兜底逻辑。
消息模板是否足够承载规则名、等级、系统、链接和排查信息。

8.3.5 当前落地进度

截至 2026-05-19，通知链路已从“PoC 试通”进入“按类型逐步落正式”的阶段。当前已经明确落地的内容如下：

项目	当前状态	说明
飞书机器人	已完成	`StablePay 生产告警` 已承接原生告警卡片
自定义 Webhook	已完成	`StablePay生产告警路由` 已用于补发轻量 `@ owner`
业务结果类通知模板	已完成	已用于业务结果类规则，当前仍在优化展示细节
业务结果类通知策略	已完成	当前首条正式规则已切到该策略
首条正式业务结果类规则	已完成	`[生产][基础通用][默认] 成功率下降 P1`
系统稳定性类通知模板	待创建	下一步建设
系统稳定性类通知策略	待创建	下一步建设
核心业务类通知模板	待创建	下一步建设
核心业务类通知策略	待创建	下一步建设

8.4 降噪与抑制

对于频繁重复、无明确动作价值或长期无效触发的告警，需要建立降噪与抑制机制：

同类告警在短时间窗口内合并发送，避免刷屏。
告警恢复信息按需开启，避免大量恢复通知干扰判断。
对长期无动作价值的低优先级规则，优先转为看板观察项。
对 P0 / P1 规则应保证“宁可少而精”，避免高优先级滥发。

8.5 告警反馈与持续降噪机制

第一版规则上线后，噪音和误报几乎不可避免，因此需要同步建立告警反馈与持续降噪机制。

建议按以下方式推进：

为正式告警建立统一反馈入口，至少能够区分“有效告警”“误报”“重复告警”“信息不足”“该系统不适用”等情况。
为正式规则维护调优台账，记录规则名、适用系统、分级、触发次数、误报情况、当前问题与后续调整动作。
在规则上线初期按周复盘，重点查看高频触发规则、长期无人处理规则和低价值噪音规则。
允许按系统做差异化收敛，例如对低流量系统增加最小样本量门槛、对边缘系统降低规则等级、对部分系统直接豁免某类规则。
对不适合立即转成正式告警的指标，可先转为观察项或大盘项，避免过早接入正式通知链路。

9. 告警归集到云监控 2.0

9.1 当前定位

当前阶段接入云监控 2.0 不是可选调研项，而是明确要推进的建设方向。目标不是替换现有全部监控数据链路，而是将多来源告警逐步归集到统一入口中。

9.2 承接边界

在本阶段，云监控 2.0 重点承接的是告警而不是所有采集链路。现有 SLS 日志、日志加工、MetricStore 和基础规则能力仍然保留并继续使用，后续重点推进的是告警归集和统一管理能力。

从承接范围上看，云监控 2.0 后续不应只覆盖现有 SLS 告警，也应逐步覆盖 ARMS 告警、基础设施监控告警以及其他业务自定义告警。

需要特别说明的是：当前云监控 2.0 侧虽然已可看到部分默认或通用告警能力，但告警中心与通知链路尚未真正投入正式使用，因此不应视为当前现网的主告警承接入口。

9.3 后续推进方式

云监控 2.0 接入需要和现有规则治理并行推进，当前建议直接按以下四个动作开工：

拉齐现有正式生产告警分母，确认当前真实来源是 SLS、ARMS、ACK / 基础设施、云监控 2.0 已有项 中的哪些规则。
产出第一批正式规则范围，优先选择高价值、低歧义、动作明确的通用规则，不追求一次性覆盖全部规则。
在云监控 2.0 中建立统一规则模板，包括命名、分级、标签、通知模板和状态字段。
按“新建替代规则 -> 灰度验证 -> 切主通知 -> 下旧规则”的顺序逐条完成收口。

在上述动作之外，本阶段还需要同步推进一条通知治理主线：

建立“统一告警群 + 原生告警卡片 + 轻量 @ owner 提醒”的通知能力，并作为正式规则切主通知前的必要条件之一。

目标是在不影响现网告警可用性的前提下，逐步形成统一告警入口，并把第一批正式规则真正迁入可治理状态。

10. 云监控 2.0 告警收口行动指南

10.1 行动目标

本节的目标不是简单“把原有规则搬到云监控 2.0”，而是围绕正式告警做一次收口治理，形成以下结果：

明确当前 StablePay 生产告警的真实来源分母，包括 SLS、ARMS、基础设施告警和云监控 2.0 现有告警项。
为每一条需要保留的正式告警，在云监控 2.0 中建立对应的替代规则或承接规则。
在新规则完成验证后，下线原有重复规则，避免新旧两套规则长期并存。
对测试规则、长期高噪音规则、无明确动作价值规则直接清理或降级为观察项。
治理当前云监控 2.0 中命名、分级、通知链路和分组维度较乱的已有告警项，避免“旧问题换个平台继续存在”。

10.2 行动原则

云监控 2.0 收口建议遵循以下原则：

只收正式告警，不收临时测试规则。
先有替代，再下原规则，避免切换窗口出现告警空档。
同一问题只保留一个正式主告警，避免 SLS、ARMS 和云监控 2.0 多头重复通知。
规则迁移不是原样复制，而是借迁移机会统一命名、分级、阈值表达和通知对象。
低价值高噪音规则不做迁移，直接在方案中说明下线理由。
云监控 2.0 的价值是统一入口和统一治理，不要求当前阶段替换所有底层数据来源。
第一阶段只优先处理“当前真正进入生产通知链路、正在被使用的正式告警”，不把所有历史配置项、未接 webhook 的规则、长期未通知的闲置规则一并拖入同一轮治理。

10.3 现状分母与第一阶段边界

当前阶段已经可以确认：

正式生产告警链路同时存在 SLS 业务告警和 ACK / 云监控 基础设施告警。
生产告警群中已经出现非生产环境样本，说明环境边界和通知治理仍未收口。
第一阶段不需要处理全部历史规则，只处理“当前真正进入生产通知链路、正在被使用的正式告警”。

第一阶段治理分母建议收敛为两类：

业务结果类：成功率下降、失败率升高、System 错误爆发等 SLS 正式规则。
稳定性类：Deployment / Pod 健康相关的 ACK / 云监控规则。

盘点时统一维护一张治理台账，最少包含以下字段：

字段	说明
当前规则名	原规则展示名
来源平台	SLS / ARMS / ACK / 云监控 2.0
监控对象	服务、链路或基础设施对象
指标口径	成功率、失败率、错误量、时延、Pod 状态等
当前状态	启用 / 停用 / 测试 / 观察项
当前通知对象	webhook、群组或通知策略
处理建议	保留迁移 / 替代后下线 / 直接下线 / 转观察项
云监控 2.0 对应规则	新规则名或待补齐项

10.4 第一阶段治理样本

当前已确认、且适合进入第一阶段治理的典型规则如下：

当前规则名	来源平台	当前判断	当前处理建议
`业务成功率下降（5m ）`	SLS	已真实进入生产链路	第一批重建候选
`失败率升高（5m，支付）`	SLS	已真实进入生产链路	第一批重建候选
`失败率升高（5m，chaincore,channelcore）`	SLS	已真实进入生产链路，但重复提醒偏密	第一批重建候选，优先降噪
`System 错误爆发（5m system 错误数 > 10）`	SLS	与业务结果类同源，适合一起收口	第一批重建候选
`Deployment Available Replica Error_automode-cluster-stablepay-1`	ACK / 云监控	正式链路在用，但混入 `stablepay-pre` 样本	先治理环境边界，再承接
`Pod Not Healthy_automode-cluster-stablepay-1`	ACK / 云监控	正式链路在用，但混入 `stablepay-pre` 样本	先治理环境边界，再承接

10.5 规则处理原则

规则只分三类处理：

保留迁移：方向正确、动作明确，适合在云监控 2.0 中重建。
替代后下线：方向对，但表达、口径、分组或通知方式需要重建。
直接下线 / 转观察项：测试规则、长期无效规则、天然高噪音规则或更适合作为看板项的规则。

当前可直接归入“清理或观察项”的典型规则包括：

codex-sls-test-20260403-1
测试告警
Processing 占比异常（5m processing 比例 > 5%）
非0000 reason 总量升高（5m）
指标断流（10m 内 action_outcome 全为 0）
Upstream 错误爆发（5m upstream 错误数 > 50）

10.6 云监控 2.0 中的替代与下线顺序

建议严格按“新建替代规则 -> 灰度验证 -> 切通知 -> 下旧规则”的顺序执行。

推荐步骤如下：

在云监控 2.0 中为第一批正式规则建立统一规则模板，包括命名、分级、标签、通知策略和责任归属。
按统一模板重建第一批核心规则，优先覆盖成功率、失败率、错误爆发、断流、Pod Ready、Pod CrashLoop / OOM。
新规则先灰度运行 3 到 7 天，观察是否能覆盖原有告警场景，是否产生新的明显误报。
灰度期间原规则继续保留，但应在台账中标明对应替代关系，避免后续一对多或多对一无法回溯。
当新规则连续通过至少一个观察周期后，将生产通知切到云监控 2.0 对应规则。
通知切换完成后，下线原 SLS / ARMS / 其他来源中的对应旧规则，保证同一问题只保留一个正式主告警。
下线完成后，再复核生产告警群消息，确认没有双发、漏发和错误归属。

10.7 云监控 2.0 已有乱项的治理方式

如果当前云监控 2.0 中已经有部分告警项较乱，不建议边用边堆，而应先收口治理。治理重点包括：

命名治理：统一按“环境 + 系统范围 + 指标语义 + 分级”命名，移除历史试配命名和临时缩写。
分级治理：统一映射到 StablePay 内部 P0/P1/P2/P3，避免不同来源各自使用不同严重度表达。
标签治理：至少统一 env、service、system、alert_class、owner_team 等标签，便于路由和归集。
通知治理：统一通知动作，不允许同一类正式规则在多个平台各自维护独立通知链路。
分组治理：对成功率、失败率、错误量等规则统一按服务或链路分组，避免全局聚合后难以定位。
生命周期治理：规则必须明确状态，区分正式、灰度、观察项、停用，防止历史遗留规则长期悬挂。

如果某条云监控 2.0 已有规则无法判断是否还在使用，建议先做两步：

查看最近 7 天或 14 天是否有真实通知记录或历史事件。
若长期无通知、无 owner、无明确业务语义，则优先降为待确认项，不直接纳入正式分母。

10.8 第一批建议在云监控 2.0 承接的正式规则

第一批不追求多，优先按两组推进：

规则组	建议先做的规则	原因
业务结果类	成功率下降、失败率升高（支付）、失败率升高（chaincore / channelcore）、System 错误爆发	当前都已在 SLS 历史中确认持续运行，且已有较完整规则线索，最适合作为第一批迁移样板
稳定性类	`Deployment Available Replica Error`、`Pod Not Healthy`	当前都已从群样本和 `cms-alert-center` 历史中确认持续运行，适合作为第一批稳定性规则样板，但需先做环境边界治理

当前第一批正式规则候选清单（v0.1）如下：

规则组	当前规则	当前动作	备注
业务结果类	`业务成功率下降（5m ）`	第一批重建候选	当前历史量最高，且已确认真实进入生产链路
业务结果类	`失败率升高（5m，支付）`	第一批重建候选	重点覆盖 `cashier-prod/payplatform-prod`
业务结果类	`失败率升高（5m，chaincore,channelcore）`	第一批重建候选	当前重复提醒偏密，重建时优先降噪
业务结果类	`System 错误爆发（5m system 错误数 > 10）`	第一批重建候选	当前仍存在正式触发历史，适合一起收口
稳定性类	`Deployment Available Replica Error_automode-cluster-stablepay-1`	第一批治理候选	先治理环境边界，再决定正式承接方式
稳定性类	`Pod Not Healthy_automode-cluster-stablepay-1`	第一批治理候选	先治理环境边界，再决定正式承接方式

当前这版 v0.1 已足够支撑后续在云监控 2.0 中先建立统一模板和替代关系。

10.8.1 模板进度

当前模板建设按三类推进，优先保证每一类都有可用模板，再逐步优化展示细节。

模板类别	当前状态	进度	当前结论	下一步
业务结果类	已创建并使用	`1/3`	已能展示标题、时间、环境、来源、领域、明细，并保留原生 ChatOps 入口	继续优化系统/服务展示与详情链接体验
系统稳定性类	未创建	`0/3`	还未从业务结果类模板中拆出	按集群 / namespace / workload 视角单独设计
核心业务类	未创建	`0/3`	还未建立独立模板	按业务链路关键字段单独设计

10.8.2 生产业务结果类规则查询字段要求

当前业务结果类规则已经证明：查询语句返回的字段，会进入告警 payload 的 current_value / data，直接影响模板展示与 owner 路由。因此后续这类规则的查询语句，建议统一至少返回以下字段：

字段	是否必需	用途	当前建议
`service`	必需	当前最稳定的路由键，也是群里最重要的展示字段	必须 `SELECT` 出来
主指标值	必需	告诉看到的人到底是“成功率/失败率/错误量/processing 占比”中的哪个数值触发	按规则语义返回，如 `fail_rate`、`success_rate`、`error_count`
异常样本量	必需	帮助判断影响面与噪音程度	如 `fail_count`、`error_count`
总样本量	强烈建议	便于解释比例类告警是否可信，也便于后续加最小样本量门槛	如 `total_count`
`sys_code`	建议	帮助快速识别系统侧细分来源	业务结果类尽量统一返回
`biz`	建议	帮助定位业务域	业务结果类尽量统一返回
`reason_code`	建议	帮助快速判断失败原因类型	业务结果类尽量统一返回

补充原则：

env / source_platform / alert_domain / lifecycle 优先走规则标签，不强依赖查询语句返回。
业务结果类后续尽量统一使用 service 作为主路由键，不再要求每条规则单独设计不同路由字段。
若某条规则需要最小样本量门槛，查询语句应优先把“分子 + 分母”一起返回，而不是只返回比例。

补充说明：

这批第一阶段 SLS 正式规则不应再按“raw logstore 规则”去理解。
当前已确认：
- System 错误爆发 这类规则可直接基于 metrics 聚合判定
- 业务成功率下降、失败率升高 这类规则常见模式是 stablepay-log-metrics 主判定，再按需联查 stablepay-log
因此第一批正式规则的建设顺序应是：
- 先确保主判定口径、分组和阈值在 stablepay-log-metrics 侧成立
- 再决定是否需要额外补一段 stablepay-log 查询，作为通知或排障上下文

10.8.3 第一批规则在云监控 2.0 中的统一模板

为了避免只是“把旧规则抄一遍”，第一批规则在云监控 2.0 中建议统一按同一套命名、分级、标签和生命周期模板创建。

10.8.3.1 规则命名规范

云监控 2.0 中的新规则不再沿用旧规则的零散命名方式，统一采用中文、结构化、便于列表扫描与后续治理的命名规范。

建议格式：

[环境][分类][作用范围] 规则语义分级

各部分含义如下：

组成部分	说明	示例
`环境`	当前规则所属环境	`生产`
`分类`	与当前三层指标分层保持一致	`基础通用`、`系统稳定性`、`核心业务`
`作用范围`	默认规则或特定系统 / 链路 / 集群范围	`默认`、`支付链路`、`chaincore-channelcore`、`StablePay集群`
`规则语义`	这条规则到底在监控什么	`成功率下降`、`失败率升高`、`System 错误爆发`、`Pod 不健康`
`分级`	当前规则分级	`P1`、`P2`、`P3`

命名原则：

规则名优先服务于人，强调一眼可读、一眼可筛、一眼可分组。
规则名使用中文主表达，避免只有创建者自己能看懂的英文缩写堆砌。
默认规则和 override 规则通过“作用范围”区分，而不是额外增加 override 关键字。
阈值、时间窗口、生命周期、迁移批次等治理信息不放在规则标题里，而通过标签和治理台账维护。

推荐示例：

[生产][基础通用][默认] 成功率下降 P1
[生产][基础通用][支付链路] 失败率升高 P1
[生产][核心业务][默认] System 错误爆发 P1
[生产][系统稳定性][StablePay集群] Pod 不健康 P2

建议模板如下：

模板项	建议值	说明
规则命名	`[环境][分类][作用范围] 规则语义分级`	统一到可读、可检索、可分组的格式
生命周期	`gray / formal / observe / off`	灰度、正式、观察项、停用四种状态明确区分
阿里云严重度	`紧急 / 错误 / 警告 / 普通`	直接与阿里云原生四档对齐
标签 `env`	`prod / staging`	必填，用于先解决环境混发问题
标签 `alert_domain`	`business_result / stability`	用于区分业务结果类和稳定性类
标签 `source_platform`	`sls / ack-prometheus / arms`	保留来源信息，便于回溯
标签 `service_scope`	如 `cashier-payplatform`、`chaincore-channelcore`、`cluster-automode-stablepay-1`	用于分组和路由
标签 `migration_batch`	`batch1`	用于区分本轮迁移范围
标签 `lifecycle`	`gray / formal / observe / off`	便于看板和治理台账联动
通知动作	`紧急` 立即通知，`错误` 群通知，`警告/普通` 低优先级通知或观察	分级和通知动作必须绑定

建议命名示例如下：

当前规则	云监控 2.0 建议命名
`业务成功率下降（5m ）`	`[生产][基础通用][默认] 成功率下降 P1`
`失败率升高（5m，支付）`	`[生产][基础通用][支付链路] 失败率升高 P1`
`失败率升高（5m，chaincore,channelcore）`	`[生产][核心业务][chaincore-channelcore] 失败率升高 P1`
`System 错误爆发（5m system 错误数 > 10）`	`[生产][核心业务][默认] System 错误爆发 P1`
`Deployment Available Replica Error_automode-cluster-stablepay-1`	`[生产][系统稳定性][StablePay集群] Deployment 副本异常 P2`
`Pod Not Healthy_automode-cluster-stablepay-1`	`[生产][系统稳定性][StablePay集群] Pod 不健康 P2`

分级建议先采用一版保守基线：

规则类型	当前建议分级	通知建议
成功率下降、失败率升高、System 错误爆发	`紧急`	生产正式告警群 + 值班处理链路
Deployment / Pod 健康类稳定性告警	`错误`	先群通知；确认只覆盖生产对象后再决定是否提到 `紧急`
观察项、口径未校准规则	`警告 / 普通 / observe`	不进入正式主通知或仅低频通知

10.8.4 第一批规则配置草案字段

在真正进入云监控 2.0 控制台创建规则前，建议先把每条规则最少需要补齐的配置字段定义好，避免现场边配边想。

字段	说明	当前阶段要求
新规则名	云监控 2.0 中的最终名称	必填，按统一命名模板
来源旧规则	旧 SLS / ACK 规则名	必填，用于替代关系回溯
数据来源	`sls / ack-prometheus / arms`	必填
监控对象范围	服务组、链路组或集群范围	必填
指标口径 / PromQL / 查询语句	新规则的核心计算表达式	必填
严重度	`紧急 / 错误 / 警告 / 普通`	必填，直接按阿里云原生四档配置
生命周期	`gray / formal / observe`	必填
最小样本量门槛	低流量防误报所需门槛	业务结果类建议补齐
持续时间	例如 `3m / 5m / 10m`	必填
重复提醒间隔	用于抑制刷屏	必填
标签集	`env / alert_domain / source_platform / service_scope / migration_batch / lifecycle`	必填
通知动作	群通知、值班、观察项	必填
灰度观察周期	新规则观察多长时间再切主通知	建议填 `3-7d`
旧规则下线条件	什么条件下可以关掉旧规则	必填

第一批 6 条候选规则可以先按同一张配置草案表来准备，配置前至少补齐以下最小信息：

当前规则	新规则名	数据来源	监控对象范围	分级	生命周期	当前最关键的待补字段
`业务成功率下降（5m ）`	`prod-business-all-success-rate-drop-p1`	`sls`	核心生产服务	`紧急`	`gray`	最小样本量门槛
`失败率升高（5m，支付）`	`prod-business-cashier-payplatform-fail-rate-rise-p1`	`sls`	`cashier-prod / payplatform-prod`	`紧急`	`gray`	样本量门槛、失败率阈值
`失败率升高（5m，chaincore,channelcore）`	`prod-business-chaincore-channelcore-fail-rate-rise-p1`	`sls`	`chaincore-prod / channelcore-prod`	`紧急`	`gray`	重复提醒间隔、服务边界
`System 错误爆发（5m system 错误数 > 10）`	`prod-business-all-system-error-burst-p1`	`sls`	核心生产服务	`紧急`	`gray`	服务分组、样本量门槛
`Deployment Available Replica Error_automode-cluster-stablepay-1`	`prod-stability-cluster-deployment-replica-mismatch-p2`	`ack-prometheus`	`automode-cluster-stablepay-1`	`错误`	`observe`	`env / namespace` 边界治理
`Pod Not Healthy_automode-cluster-stablepay-1`	`prod-stability-cluster-pod-not-healthy-p2`	`ack-prometheus`	`automode-cluster-stablepay-1`	`错误`	`observe`	`env / namespace` 边界治理

10.8.5 规则开发进度

当前规则开发不再只停留在“候选”，而是已经进入首条正式规则验证阶段。后续按“先业务结果类，再系统稳定性类，再核心业务类”的顺序推进。

规则类别	规则名	当前状态	已完成内容	下一步
业务结果类	`[生产][基础通用][默认] 成功率下降 P1`	已创建	老规则与新规则均已确认进入 `StablePay 生产环境告警群`；已建规则、已触发、已走业务结果类模板与策略	优化展示字段，补总样本量门槛，完成旧规则替代验证
业务结果类	`[生产][基础通用][支付链路] 失败率升高 P1`	已创建	已按原 SLS 5 分钟口径建规则，已挂业务结果类模板与策略，标签已补齐；新规则已确认进入 `StablePay 生产环境告警群`；老规则已确认出现在 `支付退款告警群`	观察自然触发情况，后续再补样本量门槛
业务结果类	`[生产][核心业务][默认] System 错误爆发 P1`	已创建	已建规则并挂业务结果类模板与策略；已确认老规则在 `StablePay 生产环境告警群` 真实发出	等待新规则自然触发，验证新链路消息形态
系统稳定性类	`[生产][系统稳定性][StablePay集群] Deployment 副本异常 P2`	待开发	方向已确定	先补独立模板与策略，再建规则
系统稳定性类	`[生产][系统稳定性][StablePay集群] Pod 不健康 P2`	待开发	方向已确定	先补独立模板与策略，再建规则

10.8.6 首条规则旧新对照

旧规则	新规则	结论	通知面说明
`业务成功率下降（5m ）`	`[生产][基础通用][默认] 成功率下降 P1`	可覆盖	老规则与新规则均已确认进入 `StablePay 生产环境告警群`；5 分钟窗口和主语义保持一致，新规则额外返回 `service / sys_code / biz / reason_code`，用于模板展示和 owner 路由。
`失败率升高（5m，支付）`	`[生产][基础通用][支付链路] 失败率升高 P1`	可覆盖	老规则已确认出现在 `支付退款告警群`，未确认进入 `StablePay 生产环境告警群`；新规则已确认进入 `StablePay 生产环境告警群`。
`System 错误爆发（5m system 错误数 > 10）`	`[生产][核心业务][默认] System 错误爆发 P1`	可覆盖	老规则已确认在 `StablePay 生产环境告警群` 真实发出；新规则沿用 5 分钟窗口与 `value > 10` 口径，但仍待自然触发验证新链路消息。

10.9 实施过程中的验收标准

云监控 2.0 收口是否成功，不应只看“规则是否建好了”，而应至少满足以下验收标准：

第一批正式告警在云监控 2.0 中有清晰规则分母和统一视图。
每条正式规则都能明确对应服务范围、分级和通知对象；切主通知前补齐处理责任人。
原 SLS / ARMS 中对应旧规则已完成替代或明确下线理由，不存在长期双发。
测试规则、无效规则和高噪音规则已从正式分母中剥离。
生产告警群中同类问题不再来自多个来源重复轰炸。
团队能够明确回答“当前 StablePay 正式生产告警以云监控 2.0 为统一入口”。

10.10 建议的开工节奏

如果团队准备直接开工，建议按以下节奏推进：

第一阶段先完成分母与治理准备：

拉出生产告警群最近 7 天消息样本，按来源、规则名、环境、通知策略做分类。
导出现有 SLS 正式规则和云监控 2.0 / ACK 已有规则，合并成统一治理台账。
在台账中先明确三类规则：保留迁移、替代后下线、直接下线。
先清理测试规则、明显无效规则和不应进入生产群的非生产环境告警。

第二阶段开始第一批规则承接：

在云监控 2.0 中建立统一命名、分级、标签和通知模板。
重建第一批正式规则，并与原 SLS / ACK 规则建立一对一替代关系。
先灰度不切主通知，观察 3 到 7 天是否覆盖原告警场景。

第三阶段开始切换与收口：

对灰度通过的规则切换主通知到云监控 2.0。
下线原来源中的对应旧规则，避免双发。
复盘生产群消息，确认仍然高频但无动作价值的规则是否继续降级为观察项。

并行需要启动一条单独的通知路由实施线：

明确正式告警统一群的 chat_id 与正式接入方式。
确认告警消息最小必带字段，至少包含 env / system / service / severity / rule_name / source_platform / status。
建立第一版 owner 映射表，并先补齐第一批正式系统。
完成轻量 webhook 路由层 PoC，验证“原生告警卡片 + 补充短消息 @ owner”是否稳定可行。
若 PoC 不通过，再决定是否补最小自建服务，而不是继续在原生联系人组自动 @ 上反复试错。

整个过程中建议固定每周至少做一次规则治理复盘，重点看：

哪些规则仍在重复通知
哪些规则仍带有非生产环境样本
哪些规则虽触发频繁但没有处理动作
哪些规则已可确认应直接下线而不必迁移

10.11 当前执行勾选清单

以下清单用于跟踪当前方案的实际推进状态，后续每完成一步就直接在文档中勾选更新。

第一阶段：分母与治理准备

说明：当前已完成首批 SLS 正式业务告警与 ACK 基础设施告警样本的规则反查与台账合并；后续仍需继续补 ARMS 业务类告警、云监控 2.0 已有项与闲置规则归档，因此“跨来源全量反查”暂不勾选。

第二阶段：确定第一批正式规则

明确第一批业务结果类规则范围
明确第一批稳定性类规则范围
确认哪些规则进入 保留迁移
确认哪些规则进入 替代后下线
确认哪些规则进入 直接下线 或 转观察项
输出第一批正式规则候选清单 v0.1

第三阶段：云监控 2.0 中重建与灰度

在云监控 2.0 中建立统一命名模板
在云监控 2.0 中建立统一分级与标签模板
在云监控 2.0 中重建第一批业务结果类规则
在云监控 2.0 中重建第一批稳定性类规则
建立新旧规则一对一替代关系
完成第一批规则灰度观察

第四阶段：切换与下线

切换第一批规则主通知到云监控 2.0
下线原 SLS / ACK / 其他来源中的对应旧规则
复核生产告警群是否仍存在双发
复核生产告警群是否仍存在非生产环境样本
完成第一轮降噪复盘

第五阶段：通知路由与 Owner `@` 能力落地

明确正式告警统一群 chat_id 与目标接入方式
明确正式告警消息最小路由字段集
建立第一版 owner 映射表
补齐第一批正式系统 owner / backup owner
完成轻量 webhook 路由层 PoC：原生卡片外补一条短消息动态 @ owner
验证 owner 未命中时的兜底逻辑
若低代码方案不稳定，切换到最小自建 webhook 中转
正式接入主告警链路并完成一次端到端演练

11. 风险与待确认事项

11.1 指标口径

部分指标当前虽有基础数据来源，但计算口径、时间窗口和是否适合作为正式告警指标，仍需结合历史数据进一步确认。

11.2 服务接入差异

不同服务当前在指标完备度、日志语义和运行方式上仍可能存在差异，这会影响第一版统一规则的覆盖效果。

11.3 通知归属

当前通知对象与处理人关系尚未完全清晰，但这不应阻塞第一阶段规则治理与云监控 2.0 规则重建。需要控制的边界是：未补齐责任归属的规则可以先灰度，但不应直接切入最终正式主通知。

11.4 云监控 2.0 承接边界

云监控 2.0 后续承接哪些来源、何时切换通知链路、是否同步启用事件中心等，仍需在实施前进一步明确。

11.5 飞书低代码能力边界

当前方案不再默认依赖飞书低代码承接完整主通知链路，而是将其定位为可选辅助编排能力；正式职责到人以轻量 webhook 路由层为准。

需要重点确认的边界包括：

是否能稳定按告警中的 system 查询 owner 映射表。
是否能在同一个群中基于动态 open_id 成功补发短消息并 @ 目标成员。
是否能满足后续最基本的失败兜底与可观测性要求。

若上述任一关键项不成立，则不应继续强行坚持无自建方案，而应切换到最小自建 webhook 中转。

12. 预期产出

12.1 指标清单

输出第一版告警指标清单，明确指标分层、分级、口径和当前来源。

12.2 告警规则清单

输出第一版正式规则候选清单，区分已有规则、待补齐规则和待清理规则。

12.3 通知机制方案

输出通知对象、告警分级、处理人与升级路径的设计方案。

12.3.1 通知路由方案

输出“统一群 + 原生告警卡片 + 轻量 @ owner 提醒”的正式通知路由方案，包括：

最小路由字段集
owner 映射表结构
轻量 webhook 路由流程或最小自建 webhook 方案
fallback 与端到端验证方案

12.4 告警归集到云监控 2.0 方案

输出云监控 2.0 第一阶段告警归集范围、推进路径和后续扩展建议。

2026-05-20-稳定支付监控与告警体系优化方案