从 NL2SQL 到自动巡检:乐檬如何打造面向多租户 SaaS 的全链路可观测性体系?

作者:白玙、孙杰、三烽

背景

当数十万门店终端在营业高峰同时发起收银与支付请求,任何一次链路抖动,都会直接变成门店现场的排队与交易失败。对食品零售数字化服务商乐檬而言,运维不是后台支撑角色,而是直接决定门店体验与品牌口碑的业务一线动作------既要扛住海量门店的峰值冲击,又要在高频版本迭代中持续守住多租户 SaaS 的稳定性底线,这是乐檬必须回答的命题。

浙江乐檬信息技术有限公司(以下简称"乐檬")是一家专注食品零售行业数字化的软件与信息技术服务商。公司以"乐檬"品牌对外提供面向商超、连锁门店及商贸经销商的一体化零售数智化解决方案,产品矩阵覆盖门店经营的全链路环节:乐檬零售(单店版、连锁版、商超版、海外版)、连锁门店 ERP、乐檬商贸进销存、乐檬 WMS 仓储系统、乐檬资金账务系统(聚合支付与分账)、全渠道会员管理 CRM、微商城小程序新零售,以及生鲜配送、可视化陈列、AI 智能秤等延伸能力。行业方案覆盖商超、零食、水果、生鲜、熟食、炒货、烘焙、茶饮、餐饮、肉类、酒水、商贸流通等十二个垂直领域,累计服务门店超过 20 万家,覆盖全国 200 余个城市,获得 1.5 万余个零售品牌与 100 余家区域龙头企业选用,对外提供 7×24 小时人工服务。

业务挑战

乐檬的业务形态决定了其运维复杂度显著高于一般 SaaS 服务商:海量门店终端在营业高峰集中产生收银与支付请求,产品线横跨收银、ERP、WMS、支付分账、小程序等多个系统,观测数据分散在不同技术栈中。伴随业务线与门店规模持续扩张,运维复杂度被拉升到新的量级。

告警治理分散、风暴淹没真异常

收银 SaaS、连锁 ERP、WMS、支付账务等系统分别依赖日志服务、Prometheus 指标、应用监控 APM 与云产品监控,告警规则需要在不同控制台分别配置与维护。随着业务持续扩张,规则数量快速膨胀,既容易出现错配与漏配,也在大促、节庆等流量高峰期产生告警风暴,值班工程师难以从噪声中识别真正需要干预的问题。

观测数据难产出、业务侧难消费

面向内部研发、客户成功与区域运营团队的报表需求高度多样:系统侧的接口成功率、时延分布与资源负载,业务侧的门店在线率、收银单量、支付成功率与分账及时性,缺一不可。这类看板往往需要跨多种观测数据编写复杂查询才能产出,制作周期长且易出错;对业务人员而言,查询语法又是一道门槛,观测能力被锁在少数专家手里,需求响应速度难以匹配业务节奏。

事前靠人盯、事后靠人查

在事前防线一侧,承载多租户业务的容器集群与云服务资源主要依靠人工登录逐项查看,既缺少可复用的巡检 SOP,也无法在故障发生前系统性识别资源瓶颈与潜在风险;在事后定位一侧,一次门店收银失败可能源于门店网络、收银端、SaaS 应用、数据库、支付通道等任一环节,跨系统排障需要在多个平台间反复切换、人工关联,定位过程严重依赖资深工程师的经验,而支付链路的任何定位延长,都会直接影响门店经营体验与资金合规。

乐檬需要的不是再买一套监控工具,而是一套能统一告警入口、降低数据消费门槛、把防线前移、让 AI 完成跨系统定位的智能运维体系。

解决方案:在统一数据底座之上,构建四层智能运维能力

经过评估,乐檬选择以阿里云云监控 2.0 以及全域智能运维平台 STAROps 为核心完成这次升级。乐檬在阿里云可观测体系上已积累日志、指标、链路等多类观测数据,STAROps 通过 UModel 可观测模型将其统一建模为全链路数字孪生,再由告警治理、自动巡检、根因分析等能力消费;平台无需单独开通,在云监控 2.0(CMS 2.0)或日志服务(SLS)控制台进入 STAROps 入口即可默认启用,与乐檬既有的观测体系平滑衔接。围绕三大挑战,整体落地四层能力。

(一)统一告警治理:把多套系统的告警收敛进同一个入口

乐檬使用云监控 2.0 告警管理中心,将原先分散在日志服务、Prometheus 指标、应用监控与云产品监控中的告警规则收敛到同一平台统一管理,工程师无需再跳转多个系统分别配置。在此基础上引入 STAROps 内置的告警规则治理技能(Skill):对存量告警规则自动巡检并输出治理建议,识别重复规则、阈值不合理规则与长期未触发的失效规则;同时结合告警与事件分析能力,对高峰期告警进行收敛,显著降低告警风暴对值班效率的侵蚀。

(二)自然语言观测:一句话生成观测看板

依托 STAROps 的 NL2SQL(自然语言转查询语句)能力,乐檬的研发与运营人员可以直接用自然语言描述观测需求,由平台自动生成对应的查询与观测看板。典型使用方式包括:查询指定区域门店的收银接口成功率趋势、对比大促期间各支付通道的时延分布、统计分账任务的延迟分布与失败明细、按业务线维度汇总告警处理与接手完成情况。看板产出从"提需求、排期、写查询"的多环节流程压缩为一次对话,让观测数据既能快速产出,也能被业务角色直接消费。

(三)定时智能巡检:把重复性检查交给数字员工

乐檬通过 STAROps 的长期任务(Mission)机制,让数字员工(Agent)按定时或事件驱动的方式自主执行巡检、分析与变更操作,将过去依赖人工的重复性检查转化为可靠的自动流程。落地的巡检场景包括容器集群健康巡检、应用健康度巡检、云服务资源健康巡检,以及支付与分账数据管道的质量检查。巡检结果以结构化报告形式沉淀,并可与历史巡检结果做差异对比,使资源瓶颈与配置漂移能够在演变为故障之前被发现。对于扩缩容、配置变更等高风险动作,Mission 内置的人工干预(HIL)机制会主动发起人工确认请求,在提升自动化程度的同时守住变更安全底线。这一层把事前防线从人工逐项查看升级为自动化守护。

(四)专属运维数字员工:跨系统范围快速收敛根因

乐檬通过默认规则、技能(Skill)与 MCP 工具的组合配置,将通用数字员工定制为贴合自身业务的专属 SRE 智能体,并按自身的系统边界配置其职责、权限与可调用工具。当收银或支付链路发生告警时,数字员工可基于告警上下文或工程师的自然语言提问,触发快速根因分析:借助 UModel 构建的运维数字孪生,统一关联应用、服务、资源、拓扑、告警与变更信息,配合指标异常检测、日志聚类、链路分析与变更回溯等 AI 分析算子,在跨系统范围内完成因果推理------把原本依赖资深工程师经验的排障过程,转化为可复用的自动化分析,直接回应故障定位链条长的挑战。

实现价值:从"被动救火"到"主动自治"的三重升级

(一)告警治理:从分散手工作业到统一标准动作

过去,四类观测系统的告警各有各的入口,规则配置依赖个人经验,错配漏配难以察觉,高峰期告警刷屏,值班工程师要在噪声里翻找真正的异常。

现在,统一告警管理中心加上规则治理技能,让规则的新增、审查与优化从依赖个人经验的手工作业,转变为有工具支撑的标准动作,高峰期告警按需收敛,值班判断不再被风暴干扰。告警收敛 70%。

(二)数据获取:从提需求排期到一次对话出看板

过去,一张业务观测看板要经过提需求、排期、编写复杂查询多个环节,制作周期长且易出错,不懂查询语法的业务人员只能等待专家答复。

现在,借助 NL2SQL 与问答取数能力,研发、客户成功与运营人员无需掌握查询语法,即可用自然语言快速获取应用观测核心指标与门店经营视角数据,观测能力从少数专家扩散到更广泛的业务角色,需求响应周期大幅缩短到分钟级。

(三)运维姿态:从事后响应到事前防护,AI 伴随排障

过去,资源巡检靠人工逐项查看,覆盖度与一致性难以保证;故障定位靠跨平台切换与人工关联,MTTR 难以稳定压缩。

现在,在两周一个版本的高频迭代节奏下,Mission 定时巡检持续输出结构化报告与历史差异对比,配置漂移得以及早识别,自动化巡检为发布质量提供了稳定的兜底保障;故障发生时,专属数字员工基于告警或问答直接触发快速根因分析,结合数字孪生拓扑与 AI 分析算子在跨系统范围内收敛排查范围,减少工程师在多个控制台间反复切换与人工关联的时间开销,收银与支付链路的平均恢复时间稳步压缩到分钟级。

未来展望:把"主动自治"的边界继续扩大

统一告警治理、自然语言观测、自动化巡检与智能根因分析四层能力已在核心链路跑通,接下来,乐檬将与阿里云沿三个方向继续深化。

(一)从"核心链路试点"走向"全业务线覆盖"

将数字员工的职责边界从收银与支付链路,逐步扩展到连锁 ERP、WMS、小程序新零售等更多系统,把已验证的告警治理、巡检与根因分析能力复用为各产品线的标准配置,让智能运维能力成为全业务线的标配。

(二)从"技术指标观测"走向"业务连续性度量"

基于 NL2SQL 的跨数据源查询能力,进一步把接口成功率、时延等技术指标,与门店在线率、收银单量、分账及时性等业务指标打通,建立业务连续性视角的度量体系,让运维价值直接用业务语言可衡量。

(三)从"人机协作"走向"更高程度的自主运维"

在人工干预机制的安全框架下,逐步扩大数字员工自主闭环的场景范围,并把巡检、定位、变更中沉淀的经验持续转化为可复用的技能资产,让运维经验从个人能力演进为组织资产。

相关推荐
阿里云云原生1 小时前
Agent 观测与优化开发者摸底报告
云原生·agent
探索云原生3 小时前
Kueue + HAMi vGPU 实战:显存与算力配额管理
docker·ai·云原生·kubernetes·gpu
玉&心5 小时前
通过helm在k8s上面一键部署前端和后端代码
云原生·容器·kubernetes·helm
容器魔方7 小时前
议程一览 | 华为云亮相 KubeCon + CloudNativeCon China 2026
人工智能·云原生·容器·开源·华为云·云计算
瀛川8 小时前
Agent 换了 Pod,身份怎么办?拆解 Substrate 的 Actor Identity
人工智能·云原生
yanwumuxi8 小时前
Milvus使用和改进
云原生·eureka·milvus
分布式存储与RustFS9 小时前
RustFS 1.0.0-rc.5 发布:GA 前的最后一次大版本打磨
云原生·开源·对象存储·分布式存储·s3·rustfs·性能基准
ZzzZZzzzZZZzzzz…10 小时前
K8s---网络:从 Pod 网络模型到 Calico 三种模式
运维·网络·云原生·容器·kubernetes·calico·pod网络模型
DLYSB_18 小时前
混合云与工业边缘场景下“云原生告警与物理现场声光”的集成架构实践
云原生·架构·报警灯