关键型云负载稳跑：运行契约与工程化落地

把核心交易系统搬上云，和把官网搬上云，是两件完全不同的事。前者关心的是每一笔请求的响应时间能不能压住、一次可用区抖动会不会击穿 RTO、审计日志能不能对上监管口径。后者只要页面能打开就行。过去几年大量企业完成了”能跑”这一步，接下来要回答的是”跑得稳、跑得省、跑得久”。

关键型负载的清单不长：交易撮合、实时风控、核心账务库、工业控制链路、医疗影像推理。它们的共同点是容错窗口极窄。讨论它们上云，技术选型只是入场券，真正的分水岭在运行体系。

性能确定性从节点运行时开始

普通 Web 服务能接受偶发的延迟毛刺，交易系统不能。一笔支付从 50ms 抖到 500ms，风控规则可能直接拦截，用户侧就是失败。云上多租户、共享存储、网络转发路径都会引入不确定性，所以资源确定性必须从最底层做起。

一个常被忽略的版本差异：Kubernetes 1.24 起 dockershim 被移除，节点容器运行时切到 containerd 或 CRI-O。这个切换本身不影响业务，但如果你依赖 CPU Manager 的 static 策略给关键 Pod 绑核，就必须同时确认 kubelet 的 --cpu-manager-policy=static 与拓扑管理器策略（--topology-manager-policy=single-numa-node）协同生效，否则绑核结果和预期不一致，延迟毛刺照样出现。验证方式很直接：在关键 Pod 内跑 lscpu -e 看 CPU 列表是否与 cpuset 一致，再对比 /sys/fs/cgroup/cpuset/ 下的实际分配。

资源确定性还有一层：关键 Pod 要用 Guaranteed QoS（requests 等于 limits），配合节点亲和与优先级抢占，避免被普通业务挤占。这不是”越新越好”的问题，是”配置对不对”的问题。

现代化要有取舍，不是全盘照搬

云原生社区推的微服务、容器化、Serverless、服务网格，解决了很多通用问题，但套到关键型负载上要逐个过筛。

Serverless 的弹性对突发流量友好，可关键型负载往往需要常驻容量和可预测的冷启动。一个风控推理服务如果每次请求都吃冷启动，延迟波动足以造成误判。它的适用边界其实可以量化：只有在配置了预留并发或预置实例、且冷启动延迟被压到 SLO 容忍范围内时，才谈得上用于关键链路；纯按量、无预热的函数不适合承载交易主路径。这是场景判断，不是技术优劣。

服务网格同理。sidecar 带来的额外网络跳数和资源开销，对延迟敏感型业务可能是硬伤。关键链路的流量治理，用节点级或内核态方案往往比每 Pod 一个 sidecar 更可控。

落到路径上，三条原则值得坚持。稳态优先、敏态为辅——核心链路先保稳定和可预测，容器化可以做，但要用固定资源池和优先级调度兜底。可观测性先行——没有细粒度监控、日志、链路追踪，别谈关键负载上云，因为故障形态常常是”变慢”而非”挂掉”。混沌工程常态化——可靠性是演练出来的，不是设计出来的。

混沌演练要能判定成败

把混沌工程写进流程容易，做成可判定的事难。以 Kubernetes 环境为例，用 Chaos Mesh 注入网络延迟是常见手段：对目标命名空间下的关键服务施加 100ms 延迟、持续 5 分钟，同时盯住 SLO 面板。

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
 name: latency-check
spec:
 action: delay
 mode: one
 selector:
 namespaces:
 - core-pay
 delay:
 latency: "100ms"
 duration: "5m"

判定标准要事先写死：注入期间 P99 延迟不超过 SLO 阈值的 1.2 倍、错误率不突破预算、熔断与重试按预期触发且不引发雪崩。任何一项越界，说明冗余设计或流量调度有缺口，演练即失败，必须回补。没有判定标准的混沌演练，只是一次表演。