Loop Engineering 实战案例：一个电商平台的闭环演进

前面几篇讲了闭环的原理、反模式、LLM决策、跨服务设计。这篇换个角度——讲一个真实案例。数据做了脱敏，但演进过程是真实的。

背景

某电商平台，日活 50 万，大促日 PV 峰值 500 万。技术栈：Java 微服务 + Nginx + Redis + MySQL + Kafka。运维团队 5 人，7×12 值班。

痛点很典型：大促必出故障，出了故障靠人肉，修完了写个复盘文档，下次大促还是同样的问题。

阶段一：零闭环（2024 Q1）

这时候没有闭环，只有监控。Prometheus + Grafana 画了一堆面板，值班盯着看。出了问题靠经验判断——“这个报错上次是 Redis 连接池打满了””那个超时一般是数据库慢查询”。

典型故障处理流程：

1. 告警响了 → 值班看面板
2. 判断问题在哪 → SSH 上机器看日志
3. 手动执行修复（重启、扩容、限流）
4. 等指标恢复 → 确认问题解决

平均响应时间：15-30 分钟。大促期间告警风暴，响应时间更长。

这个阶段的问题不是没有监控，是从监控到动作之间的链条全靠人。人慢，人会误判，人在凌晨3点状态更差。

阶段二：第一个闭环——自动降级（2024 Q3）

第一个闭环选了最痛的点：支付服务超时。

支付服务是核心链路，一旦超时，用户付不了钱，直接损失 GMV。之前每次支付超时都是值班手动摘节点，慢且容易出错。

闭环设计：

感知：支付接口P99延迟 > 3秒（滑动窗口5分钟）
决策：连续2个窗口超阈值 → 降级
执行：从Nginx upstream摘除最慢的支付节点
验证：30秒后检查P99是否回落到1秒以下

就是这么简单。一个 Python 脚本，50 行代码，跑在一台独立机器上。

踩的坑： 上线第一周就误触发了。原因是凌晨流量低谷，一个正常请求导致P99毛刺。修法：加了最低采样数要求——窗口内至少 100 个请求才做判断。

效果： 支付故障的自动恢复时间从 15 分钟降到 45 秒。大促期间避免了 3 次支付中断。

阶段三：第二个闭环——库存服务自动扩容（2024 Q4）

库存服务在大促期间流量翻 20 倍，必须提前扩容。之前靠人估算——“双11大概需要 30 台机器”——估多了浪费，估少了崩。

闭环设计：

感知：Kafka消费lag > 5000 且持续5分钟
决策：lag增长率 > 1000/分钟 → 扩容
执行：调K8s HPA增加pod数量（每次+50%）
验证：5分钟后lag是否下降

这里有个关键设计：扩容幅度用百分比而不是固定数量。 流量翻 5 倍和翻 20 倍需要的扩容量不同，百分比增长自动适应。同时设了上限——最多扩到 50 个 pod，防止无限扩容吃光集群资源。

踩的坑： 扩容后的 pod 需要预热（JVM JIT、缓存加载），刚启动时性能差。修法：扩容后 2 分钟内不参与负载均衡，等预热完了再放进来。

效果： 2024 双11，库存服务零故障。之前双11必有 1-2 次卡顿。

阶段四：闭环冲突——支付降级和库存扩容打架（2025 Q1）

两个闭环各自跑得挺好，但有一次大促，两个闭环同时触发了——支付降级摘了节点，库存扩容加了节点。结果支付流量被集中到剩余节点，负载更高了；库存扩容又占用了集群资源，支付服务没资源回滚。

根本原因： 两个闭环不通信。支付降级不知道库存在扩容，库存扩容不知道支付在降级。

修法：引入全局资源预算。

CLUSTER_TOTAL_CPU = 400  # 集群总CPU核心数
RESERVED_FOR_PAYMENT = 150  # 支付服务保底资源

def can_scale(service: str, additional_cpu: int) -> bool:
    used = get_current_cpu_usage()
    if service == "payment":
        return True  # 支付服务不受限
    if used + additional_cpu > CLUSTER_TOTAL_CPU - RESERVED_FOR_PAYMENT:
        return False  # 其他服务扩容不能动支付保底资源
    return True

支付服务有资源保底，其他服务扩容不能占用。这个简单约束避免了 90% 的冲突。

阶段五：第三个闭环——大促自动预案（2025 Q2）

前两个闭环是被动响应式的。到了阶段五，团队开始做主动式闭环——在问题出现之前就动作。

思路： 大促的流量模式是可预测的（预热→爬坡→峰值→回落），没必要等 lag 报警了才扩容。

闭环设计：

感知：大促倒计时 + 实时流量 vs 预测流量
决策：流量超过预测的80% → 提前扩容；低于预测50% → 提前缩容
执行：批量调整多个服务的pod数量
验证：各服务指标是否在安全区间

class PromotionOrchestrator:
    """大促预案闭环"""
    
    PHASE_CONFIG = {
        "warmup": {    # 预热期（大促前2小时）
            "payment_replicas": 10,
            "inventory_replicas": 15,
            "order_replicas": 8,
        },
        "peak": {      # 峰值期
            "payment_replicas": 20,
            "inventory_replicas": 30,
            "order_replicas": 15,
        },
        "cooldown": {  # 回落期
            "payment_replicas": 5,
            "inventory_replicas": 8,
            "order_replicas": 4,
        },
    }
    
    def execute_phase(self, phase: str):
        config = self.PHASE_CONFIG[phase]
        for service, replicas in config.items():
            scale_service(service, replicas)
        
        # 等待1分钟后验证
        time.sleep(60)
        self.verify_all_healthy()

这个闭环的本质是把人的经验编码成自动化。以前值班在大促前手动做的那些操作，现在自动执行。

效果： 2025 618，全程零人工干预。5 人运维团队第一次在大促期间正常下班。

阶段六：LLM 辅助决策（2025 Q3，进行中）

5 个闭环跑稳了，规则能覆盖的场景基本覆盖了。但还有 10-15% 的故障是规则没见过的——新的错误模式、跨服务的异常联动、大促和故障同时出现。

这些场景目前在用 LLM 辅助判断：

1. 规则引擎 escalate 时，把上下文丢给 LLM
2. LLM 给出建议动作 + 置信度
3. 安全校验层验证 LLM 的建议是否安全
4. 置信度 > 0.8 自动执行，< 0.8 人工确认

还在灰度中，目前 LLM 辅助决策的准确率大约 72%。不够高，还不能大面积放开。

数据总结

指标	阶段一(零闭环)	阶段五(5个闭环)
平均故障恢复时间	15-30分钟	30-90秒
大促故障次数	2-3次/大促	0次
值班人力	7×12	7×8（大促时自动）
误操作率	~5%（人肉操作）	~2%（自动+校验）
月度运维成本	约15万	约8万（省了人力）

演进中的几条经验

1. 一个闭环一个闭环地上。 不要一次上三个。每个闭环需要观察期、调参期、信任建立期。上太快，出了问题你不知道是哪个闭环的锅。

2. 先跑观察模式。 新闭环至少跑一周”只告警不动作”，确认阈值合理后再开自动。这个耐心必须有。

3. 闭环之间的协调比闭环本身难。 单个闭环的技术实现不难，难的是多个闭环同时运行时不冲突。资源预算、优先级、冷却期——这些协调机制必须提前设计。

4. 大促预案是最值得投入的闭环。 被动响应的闭环只能缩短故障时间，主动预案的闭环能避免故障发生。ROI 最高。

5. 人的经验要逐步编码进闭环。 闭环不是一步到位的，是随着团队对系统理解的加深逐步完善的。每次复盘后的行动项，应该变成闭环的一个规则，而不是只留在文档里。

下一步

这个案例的闭环演进还在继续。团队在尝试两件事：一是把闭环配置化，让非运维人员也能调整规则；二是用 LLM 做更深层的根因分析，缩短从”发现问题”到”定位原因”的时间。

闭环不是终点，是持续演化的过程。你的系统在变，你的闭环也得跟着变。

---

相关阅读：

• Google SRE Book - Chapter 6 (Handling Overload) & Chapter 7 (SLO)
  -《SRE：Google运维解密》- 闭环思想的源头
• Netflix Chaos Engineering - 用故障注入验证闭环有效性