作者：白玙、鸣溯
福州塔斯汀餐饮管理有限公司创立于 2012 年，是一家专注于"手擀现烤"中国汉堡的连锁餐饮品牌。塔斯汀传承中华传统面点技艺，研制出口感极具辨识度的"手擀现烤"堡胚，开创了中国汉堡全新品类。多年来，塔斯汀凭借出色扎实的研发能力、高质稳定的产品品控、便捷贴心的服务体验，稳步成长为中国餐饮行业头部品牌。目前，塔斯汀已在全国布局超万家门店，覆盖 300 余座城市，深受广大消费者喜爱与认可。
万店规模的连锁餐饮企业，业务系统横跨门店 POS、供应链、会员营销、线上点餐等数十条服务链路。AI 时代，随着业务规模及业务迭代飞速增长，监控覆盖面越来越广，监控告警越配越多，但同时也带来了许多问题。企业告警来源复杂，包括云监控、ARMS、SLS、业务自定义告警、证书告警等，由于告警数据分散在不同系统，数据格式、通知方式和处理流程各不相同，导致告警配置、通知触达、响应排查、经验沉淀和闭环管理的成本不断增加。
业务挑战：告警之后，才是运维效率的分水岭
在云上多业务环境中，企业通常不缺监控工具，真正稀缺的是把告警转化为可协同、可追踪、可复用事件的能力。同一故障可能连续产生多条告警，重要信息被刷屏淹没，值班人员需要在多个平台之间切换，靠经验拼接上下文，AI 给出了诊断结论，却缺少人工反馈，无法判断哪些分析准确、哪些需要优化。
传统监控通常解决了"发现问题"，但告警管理及告警发出后的协同处置仍存在如下典型问题：
- 多源告警分散： 企业告警来源复杂，告警数据分散在 4-5 个不同系统；不同监控系统需要分别配置联系人、通知方式和触达策略，维护成本高且容易出现遗漏。同时，各系统的告警内容和状态表达不统一，值班人员难以快速判断告警状态并定位问题，也无法及时、准确地通知对应负责人。
- 重复噪声多： 配置告警规则时，一条规则通常会关联多个甚至数十个实例。当这些实例因同一故障同时触发告警时，短时间内便会产生大量重复的飞书消息和电话通知，形成"告警风暴"。重复告警不仅增加值班人员的判断和处理负担，还会淹没真正重要的信息，导致关键告警被忽略。
- 诊断依赖个人经验： 告警出现时，根因可能分散在监控指标、SLS 日志、应用链路和业务系统中。整个排查过程需要跨多个平台反复切换，人工关联监控、应用、容器和日志的上下文信息，不仅耗时，也高度依赖值班人员的个人经验。
- 沉淀闭环难： 告警恢复并不等于处置闭环，由于根因、解决方案缺少结构化沉淀，历史经验难以检索和复用，也无法持续反哺后续诊断。
我们认为，告警之后，才是运维效率的分水岭， 为解决这些问题，需要建设一套统一且智能的 AI 运维平台，对多源告警进行集中接入、标准化处理和智能编排，将告警准确触达对应运维人员，辅助快速定位并解决问题，降低故障影响，同时沉淀处置经验，形成持续优化的告警闭环。平台建设的重点不是"再增加一个告警入口"，而是让每一次告警都拥有完整生命周期。
解决方案：告警统一入口+AI 反馈闭环+数字员工矩阵
针对多源告警分散、重复噪声、根因定位慢和经验难沉淀等问题，塔斯汀基于阿里云云监控 2.0（CMS 2.0）和全域智能运维平台 STAROps，以阿里云云监控 2.0 统一告警中心为入口，在现有运维平台上引入低代码工作流作为告警编排层，并建立了一条完整闭环：
CMS 2.0 多源告警接入→ 低代码工作流编排 → 自动收敛 → 飞书协同 → STAROps AI 辅助分析 →补充根因信息 → 评价 AI → 经验沉淀。
云监控 2.0 统一告警管理 + 工作流编排：通过事件集成 + 订阅机制统一多套告警源入口
塔斯汀将 ARMS、CMS 1.0、SLS 告警、Prometheus 以及自定义告警等多个告警源通过 CMS 2.0 的事件集成能力统一接入事件中心。再通过工作流编排事件管理归一化规则：
Webhook 接入 → 来源识别 → 字段标准化 → 收敛判断 → 群路由与排班 → 卡片生成或更新 → 数据落库 → 分级加急与反馈。
工作流 根据告警来源选择解析分支，把标题、等级、资源、状态等信息转换成统一上下文；随后调用告警收敛和群路由能力，决定新发、更新还是恢复卡片，并按 P1、P2、P3 进入对应的通知与加急策略。飞书卡片产生的认领、状态更新和根因反馈，也通过同一编排链路继续向后流转，这样既保留了可视化编排的灵活性，也避免把长期状态、一致性和历史事实压在工作流中。新增告警来源时，通常只需增加解析分支并复用后续公共节点，不必重新开发整条处置链路。
飞书告警卡片 + AI 根因分析：一张卡片承载认领、追问、统计全流程
平台将实时状态、协同入口和历史事实分开管理：实时状态负责告警收敛与卡片更新，飞书负责现场协同，历史数据负责保存真实根因、反馈和处置记录。
值班人员可以直接在卡片中认领告警、查看状态，并引用卡片向 AI 追问原因。系统会自动带入当前告警上下文，减少重复描述和跨平台检索。
在飞书告警卡片上落地典型的场景：
- 问运维告警问题：自然语言描述：如今日告警量、未认领、Top 告警规则。
- 创建告警规则：自然语言创建云上告警，自定义告警规则。
- 引用告警卡片追问：引用告警卡片，不用复述，AI 自动带上下文。
- 告警一键根因分析：直接引用卡片追问 AI，AI 自动查询历史根因以及调用 STAROps 根因诊断能力，给出结论，诊断过程实时输出，过程透明。
- 人机协同：提供交互能力，高权限命令人工审核。
这种交互方式让告警卡片从"通知"变成"处置入口"：问题由谁处理、分析到了哪一步、最终根因是什么，都围绕同一个事件持续沉淀。
AI 反馈闭环：每一次诊断沉淀为（上下文，人工根因，评价）三元组
AI 根因分析的结论是否可靠，不能只靠产品侧感觉，必须有数据。塔斯汀在处置链路中嵌入了一个极简但完整的反馈机制：
Step 1 · AI 出诊断：值班人员引用告警卡片追问后，AI 基于注入的事件上下文 + 该服务历史根因库输出诊断结论。
Step 2 · 人工填写实际根因：事件恢复后（或处置过程中确认根因时），值班人员在卡片的"填写根因"入口录入实际根因描述------自由文本，要求写清"真正发生了什么"。
Step 3 · 评价 AI 准确度：填写根因后，系统弹出评价入口，只有两个选项------"AI 准"或"AI 不准"。如选"AI 不准"，可选填一行说明（如"AI 把根因归到下游，实际是上游流量问题"）。
这些记录积累后形成两个直接价值：
-
历史根因库：同一个服务再次出现类似告警时，AI 在 Step 1 的诊断中会优先读取该服务的历史根因记录，参考过往的真实根因而非纯粹依赖当前指标推理。这让 AI 的诊断结论越用越贴近该客户的实际业务特征。
-
诊断准确率统计与场景化改进 ：团队可以按
service + alert_type维度统计 AI 准确率,并针对性做场景化改进和优化。
STAROps 数字员工矩阵：Skill 封装 + Mission 编排 + 一键 RCA
在告警闭环之上，塔斯汀通过 STAROps 构建第二层能力：把资深 SRE 脑中的排障步骤编码为平台可调度的 Agent 能力。
Skill 封装------将排障 SOP 编排为可复用能力单元
每个 Skill 定义一个特定故障场景的完整排障路径，包括：触发条件（什么类型的告警/指标组合应该调用这个 Skill）、数据采集步骤（按顺序查哪些指标/日志/调用链）、判断逻辑（指标组合满足什么条件判定为什么根因）、输出格式（结构化诊断结论 + 建议操作）。
Mission 编排------多 Skill 并行调度形成巡检矩阵
单个 Skill 解决单场景诊断问题，但日常巡检需要数十个 Skill 按业务线和时段策略并行运行。塔斯汀通过 STAROps 的 Mission（长期任务）能力，将多个巡检 Skill 编排为持续运行的数字员工，每轮巡检执行后，Agent 输出结构化巡检报告：正常项折叠展示，异常项高亮并附带诊断结论和建议操作。SRE 的日常从"轮班盯监控大屏"变为"早上看一遍巡检报告，处理标红项"。
总体而言，塔斯汀的实践不是简单增加一个告警页面，而是把告警从消息升级成事件，把 AI 输出升级成可反馈的数据，把一次处置升级成能够持续复用的运维资产。
当每一次告警都能被正确归并、及时处理、完整复盘，并反哺下一次诊断，运维平台才真正从"通知工具"走向"持续学习的工程系统"。
方案成效：从工程闭环走向可量化收益
这套告警闭环上线后，最先感受到变化的是一线值班同学。同类告警不再反复刷屏，群里留下的是真正需要看的那几条；从收到告警到查完处理完，整个过程都在飞书里完成，不用再跨系统翻来翻去，排查的门槛和耗时都明显下降。
运维和 SRE 团队的变化在于处理方式。 借助 AI 做根因定位，原本要人工逐层排查的过程被压缩成一次点击；定位出的根因会沉淀下来，同类问题再出现时可以直接复用既有结论；告警的处置动作也支持按需编排，不同类型的告警走不同的处置路径。
在治理层面，告警从"感觉多"变成了可以被量化的数据。响应、处理、恢复等各环节的过程指标都能追踪，治理因此有了抓手------降低告警噪声、提升响应与处理效率、提升 AI 判断质量、沉淀运维知识，这四条线可以持续看到数据、持续往前推。