影刀RPA拼多多/TEMU店群自动化SLA体系与可用性度量实战店群系统跑久了总会被问一个灵魂问题“系统可用性是多少”这个问题很难回答因为没人定义过什么是“可用”。是调度器不崩是任务成功率是店铺登录不失效是API不超时我们以前也是模糊的。直到一次大促后复盘老板问“这次稳定性怎么样”我们只能说“还行”“大部分正常”。老板不满意。店群矩阵自动化突破运营极限后来我们花了几周时间建立了一套完整的SLA服务级别协议体系把“稳定性”变成了可量化的指标、可追踪的目标、可告警的阈值。这篇文章不讲脚本也不讲架构。专门聊聊店群自动化系统的服务可用性如何定义、如何计算、如何保障、如何对外承诺。适用场景需要对外提供SLA承诺的SaaS店群平台或内部需要量化稳定性目标。技术栈SLI定义、SLO计算、错误预算、燃尽图、可用性看板。temu店群自动化报活动案例一、SLA不是一句话是一套体系先厘清几个概念。SLAService Level Agreement对外承诺的可用性目标比如“月度可用性≥99.9%”。达不到要赔钱或扣绩效。SLOService Level Objective内部设定的目标通常比SLA更严格比如“月度可用性≥99.95%”。留出缓冲。SLIService Level Indicator具体衡量的指标比如“任务成功率”“任务延迟”“登录成功率”。店群自动化系统的SLA不能只写“系统可用”因为用户关心的不是系统是否在运行而是他们的任务是否按时按质完成。所以我们定义了三类SLI对应不同角色关心的维度| SLI类别 | 指标示例 | 目标值(SLO) | 谁关心 ||---------|----------|-------------|--------|| 任务成功率 | 用户提交的任务最终成功的比例 | ≥99.5% | 运营 || 任务延迟 | P95任务从提交到完成的时间 | 订单发货5分钟上架30分钟 | 运营 || 系统可用性 | 核心API和调度器的请求成功率 | ≥99.9% | 运维、开发 |每一类下面还有细分按店铺、按平台、按任务类型。二、SLI的具体定义与计算方式SLI 1任务成功率公式成功任务数 / 总任务提交数注意- “成功”指任务最终完成可能经过重试不是首次尝试成功。- - 用户主动取消的任务不计入分母和分子。- - 由于平台自身问题如店铺被风控导致的任务失败也应计入失败因为用户感知是系统没搞定。实现调度器在任务最终结束时成功或最终失败记录一条SLI日志。defrecord_sli(task_id,final_status):sli_log{task_id:task_id,shop_id:task.shop_id,platform:task.platform,task_type:task.type,final_status:final_status,# success or final_failedattempts:task.retry_count,timestamp:time.time()}kafka.send(sli_tasks,sli_log) 离线聚合每5分钟 sql SELECT platform,task_type,count(*)astotal,sum(casewhen final_statussuccessthen1else0end)assuccess,success/totalassuccess_rate FROM sli_tasks WHERE timestampnow()-interval5minute GROUP BY platform,task_type **SLI2任务延迟**公式任务完成时间-任务提交时间不包括排队等待调度的时间要明确 我们区分两种延迟-**调度延迟**从提交到被调度器分配给执行节点的时间。反映调度器压力。--**执行延迟**从开始执行到执行完成的时间。反映脚本效率和平台响应。--**端到端延迟**提交到完成的总时间。用户最关心。 计算P95和P99按任务类型分开看。订单发货的P95目标5分钟报表生成的P95目标1小时。**SLI3系统可用性**定义核心服务的请求成功率。 核心服务包括-任务提交APIPOST/api/tasks--查询任务状态API--调度器健康检查--配置中心读取 每个服务实例暴露/metrics端点Prometheus采集请求总数和错误数。可用性1-(错误请求数/总请求数)。 注意客户端超时或网络问题不计入服务端错误否则会低估可用性。只统计服务端返回5xx或超时由服务端定义的超时。---## 三、SLO设定与错误预算SLO不能拍脑袋。我们根据历史数据过去3个月的实际表现来设定。 例如过去3个月任务成功率的周平均值在99.2%-99.7%之间波动我们把SLO设为99.5%比历史中位数稍高有挑战但可实现。 每个SLO对应一个**错误预算**(1-SLO)*时间窗口内的总请求量。 例如月度SLO99.5%→ 错误预算0.5%*月度总任务数。假设月度100万任务错误预算5000次失败。 错误预算是一种“容错额度”。超出预算后团队需要停止新功能发布专注于稳定性修复。 我们实现了错误预算看板实时显示每个SLO的燃烧率 python# error_budget.pydeferror_budget_remaining(slo,total_requests,errors_so_far,window_days30):allowed_errors(1-slo)*total_requests remainingallowed_errors-errors_so_far burn_rateerrors_so_far/(allowed_errors/window_days*days_passed)returnremaining,burn_rate 当燃烧率1.0即错误消耗速度超过预期触发告警。燃烧率1.5时自动暂停低优先级的发布流水线。---## 四、可用性看板与周报我们把所有SLO指标集中在Grafana看板上按平台、任务类型、店铺层级下钻。 看板包含-**当前SLO状态**绿/黄/红显示距离预算耗尽还有多少--**历史趋势**过去30天的成功率曲线叠加上下限告警线--**错误分布**按错误类型超时、元素未找到、API限流的饼图--**店铺排行**成功率最低的10个店铺需重点关注 每周一自动生成SLO周报发送给技术团队和运营负责人。周报包含-上周各SLO达成情况是否在预算内--偏离SLO的主要原因如“TEMU上架脚本因页面改版失败率上升”--本周改进计划--错误预算消耗预测 有了这个周报团队可以清晰地看到稳定性的“健康体检报告”而不是凭感觉。---## 五、SLA对外承诺与赔偿条款如果系统对外提供SaaS服务需要给客户SLA承诺。我们制定了三个等级的SLA-**免费版**无SLA承诺尽力而为--**专业版**月度任务成功率≥99%否则赔偿10%月费--**企业版**月度任务成功率≥99.5%任务P95延迟≤30秒订单类≤5分钟否则赔偿20%月费 赔偿不是目的而是约束自己。我们在合同中明确-SLA的计算方式以调度器日志为准客户可审计--排除项平台故障、客户店铺被风控、客户主动取消任务、计划内维护提前通知--赔偿上限月度服务费的50%为了支撑SLA对外承诺我们的内部SLO必须比SLA更严格如99.7%留出缓冲。 我们每季度发布一份SLA达成报告供客户下载。报告包含可用性数据、故障事件摘要、改进措施。这是建立信任的重要方式。---## 六、故障事件管理SLA的达成离不开规范的故障处理流程。 我们对故障分级|级别|定义|响应时间|处理时间||------|------|----------|----------||P0|全部用户无法提交任务|5分钟|30分钟内恢复||P1|单个平台全部任务失败|15分钟|2小时||P2|单店铺持续失败|1小时|4小时||P3|任务延迟升高成功率下降|2小时|8小时|每个故障必须产出**RCA根因分析报告**包含-故障时间线--根因--影响范围受影响的店铺数、任务数--改进措施含负责人和截止日期 RCA需要经过技术负责人评审并录入知识库。相同根因的故障重复发生会触发问责。 我们每月汇总故障数据计算**MTBF平均无故障时间**和**MTTR平均修复时间**。这两个指标反映了系统的本质稳定性。---## 七、可用性提升的实战案例分享一个真实案例我们曾有一个季度TEMU订单发货任务的SLO99.5%连续两个月未达成实际约98.8%。 分析发现85%的失败来自“物流单号获取超时”原因是第三方物流API不稳定。 解决方案分三步1.**增加重试与降级**物流API失败时先重试3次指数退避仍失败则降级到另一家物流服务商。2.2.**异步化**将物流单号获取从同步改为异步先标记订单为“物流处理中”后台重试直到成功最后通知发货。用户感知延迟但成功率提升。3.3.**缓存**对常用物流公司的路由信息做本地缓存减少API调用。 上线后发货任务成功率从98.8%提升到99.7%超过了SLO。同时我们把这个改进经验推广到其他依赖外部API的任务。 如果没有SLO量化我们可能不会把这个“低成功率”当回事。有了数据优先级就明确了。---## 八、容量与可用性的关系可用性不仅仅是“不出错”也包括“在负载下不出错”。 我们每年做两次容量规划根据业务增长预测店铺数、任务量增长率提前扩容。 容量模型 所需节点数(任务峰值QPS*单任务平均耗时秒数)/(单节点并发槽位) 例如峰值QPS10平均任务耗时30秒则并发任务数300。单节点支持10并发需要30个节点。再加20%冗余 →36个节点。 当实际节点数与理论需求差距超过30%时自动触发扩容预警。 可用性还包括**依赖服务的可用性**。我们的店群系统依赖Redis、PostgreSQL、Kafka。这些中间件的可用性SLO必须高于我们的SLO如99.99%。如果依赖服务达不到我们需要设计降级或冗余如双写两个消息队列。---## 九、真实踩坑与经验**坑1SLO定义不一致导致争议**任务成功率中用户重试成功的算成功还是失败我们内部定义时没明确。后来客户投诉“系统成功率只有95%”我们算出来是98%。差异在于客户认为用户手动重试不算系统能力。 解决定义明确“最终成功”包括系统自动重试不包括用户手动重试。并在SLA文档中写明。**坑2监控数据丢失导致SLO无法计算**某次Kafka积压SLI日志丢失了一部分导致月度成功率虚高。审计时发现数据缺口。 解决在SLI日志发送端增加本地持久化和重试同时定时比对“任务表”与“SLI表”的数量是否一致不一致则触发数据修复任务。**坑3过度追求SLO导致业务决策变形**团队为了提高任务成功率把大量超时任务的重试次数从3次改成10次导致队列积压新任务等待时间变长。成功率高了但延迟恶化了。 解决引入多维度SLO不能只看成功率同时监控延迟。两个SLO都达标才算可用。**坑4忽略SLA排除项客户索赔**一次平台官方故障导致大量失败客户根据SLA索赔。但我们SLA中排除了“平台自身问题”客户不认可认为“系统应该能识别并绕过”。 解决在SLA条款中明确“平台已知故障”的判定标准以平台状态页为准并增加“故障检测与自动切换”能力如切换到备用API。---## 十、总结从“感觉稳定”到“量化稳定”店群自动化系统的稳定性不能停留在“今天好像没崩”的模糊感知。 SLA体系把稳定性变成可衡量、可追踪、可改进的目标。它迫使你-定义什么是“成功”--监控每个环节的表现--为失败留出预算但控制燃烧率--对外承诺对内兜底 建立SLA体系的建议4.从最重要的1-2个SLI开始如任务成功率、订单延迟5.2.先设置宽松的SLO如99%跑通采集和计算流程6.3.逐步收紧SLO并配套告警和复盘机制7.4.对外SLA需要法务审核对内SLO可以激进一些 我们现在的店群系统每个月的SLO达成情况都是透明的。管理层在月度OKR review时会直接看这个数字。团队也对“稳定性”有了共同的、可量化的理解。 毕竟不能测量的东西就无法改进。---作者林焱