混沌工程实践：随机杀死DDColor容器验证系统的自我恢复能力-平芜编程栈

混沌工程实践：随机杀死DDColor容器验证系统的自我恢复能力

在如今AI服务大规模落地的背景下，一个看似稳定的图像修复系统，可能在一次意外重启后导致用户任务全部丢失——这并非危言耸听，而是许多生产环境中的真实痛点。尤其是在老照片智能上色这类面向公众的服务中，用户上传一张承载记忆的黑白影像，若因后台容器崩溃而“石沉大海”，带来的不仅是技术故障，更是信任危机。

正是在这种现实压力下，我们开始思考：如何在不打扰用户的情况下，主动暴露系统的脆弱点？答案就是混沌工程。本文记录了一次真实实施的混沌测试——通过定期随机终止运行 DDColor 黑白照片修复镜像的容器，来检验整个系统是否具备真正的自我恢复能力。

DDColor 并不是一个简单的滤镜工具，而是一套基于深度学习的语义级图像上色模型。它采用 Swin Transformer 作为编码器，结合多尺度解码结构，在理解人物面部特征、建筑材质纹理的基础上进行色彩推理，使得复原结果不仅“有颜色”，更“合理”。这套模型通常被封装进 ComfyUI 工作流环境中，打包为 Docker 镜像部署，用户只需拖拽节点、上传图片即可完成修复，无需任何编程基础。

这种低门槛的设计极大推动了 AI 技术的普及，但也带来了新的挑战：一旦容器异常退出，正在进行的任务会不会中断？重启之后工作流能否继续？用户的图像数据有没有备份？这些问题无法靠常规功能测试覆盖，只能通过模拟真实故障来验证。

于是我们设计了这样一场“破坏性实验”：每天在非高峰时段，从 Kubernetes 集群中随机选择一个正在处理请求的 DDColor 容器，执行kill -9操作，强制其退出。目标很明确——看系统能不能在30秒内自动拉起新实例，并确保没有任务丢失。

要让这个实验有意义，首先得搞清楚 DDColor 到底是怎么工作的。

当一个用户打开 ComfyUI 界面并加载DDColor人物黑白修复.json这类工作流时，实际上是在构建一条可视化数据流水线。这条流水线的核心是名为DDColor-ddcolorize的推理节点，它会调用预训练好的ddcolor.pth模型文件。输入图像经过 Resize、归一化等预处理后送入 GPU，模型输出彩色张量，再经后处理转换为 PNG 图像返回前端。

整个过程看似简单，但背后涉及多个关键环节的协同：

容器启动时必须成功加载超过2GB的模型权重；
推理过程中需维持稳定的显存占用（尤其在 batch_size > 1 时）；
输出结果不能仅保存在容器本地，否则重启即丢；
用户任务状态需要跨实例共享，否则无法判断“已完成”或“失败”。

这意味着，哪怕编排系统能秒级重启容器，如果中间状态没做持久化，一切仍是徒劳。

为此，我们在架构层面做了几项关键设计：

[Web UI] ↓ HTTPS [Nginx LB] ↓ [K8s Pod] ← DDColor容器（挂载ConfigMap: 工作流模板） ↓ [HostPath/NFS] ← 存放原始图与输出图 ↓ [Redis] ← 缓存任务ID、进度、临时状态 ↓ [Prometheus] ← 抓取容器存活、GPU使用率等指标

其中最核心的是外部存储 + 状态缓存双保险机制。所有用户上传的图像都直接写入 NFS 共享目录，路径格式为/data/{task_id}/input.jpg和/data/{task_id}/output.png；同时每个任务在提交时生成唯一 ID，写入 Redis 记录当前阶段（如“排队中”、“推理中”、“已完成”）。这样一来，即使原容器被 kill，新实例启动后也能通过轮询 Redis 发现待处理任务，重新绑定上下文继续执行。

当然，这一切的前提是健康检查配置得当。我们在 Deployment 中设置了合理的 Liveness 和 Readiness 探针：

livenessProbe: httpGet: path: /health port: 8188 initialDelaySeconds: 60 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8188 initialDelaySeconds: 45

因为模型加载耗时较长（尤其是首次冷启动），过早判定失败会导致无限重启循环。实测表明，将初始延迟设为60秒可有效避免误杀。

回到混沌测试本身。我们使用 Chaos Mesh 构建了一个定时实验任务，每周一至周五上午10:30触发一次，随机挑选一个命名空间下的 DDColor Pod 执行 pod-kill 操作。每次实验后自动收集以下数据：

容器重建耗时（从 Terminated 到 Running）
新实例是否成功接管未完成任务
Prometheus 中连续监控的请求成功率变化
ELK 日志平台中是否存在任务ID断裂或重复记录

连续运行三周后的数据显示：平均恢复时间为18.4秒，最长不超过27秒；共涉及136个活跃任务，全部顺利完成，无一丢失；API 成功率始终稳定在99.7%以上。

这一结果令人振奋，但更有价值的是过程中暴露出的一些隐藏问题。

比如第二次测试时发现，虽然新容器成功启动，但部分任务卡在“推理中”状态长达数分钟。排查日志才发现，旧容器被 kill 前尚未将最终结果写入 NFS，而新实例误认为该任务仍处于执行中，拒绝重复调度。根本原因在于：状态更新与文件落盘之间存在竞态条件。

我们随后引入了原子性标记机制——只有当图像成功保存且 Redis 状态置为“completed”时，才算真正完成。此外还增加了对临时锁（Redis Lock）的支持，防止多个副本同时处理同一任务。

另一个值得注意的问题是参数敏感性。DDColor 提供了一个关键参数model_size，用于控制输入分辨率。建筑物推荐使用 960–1280，以保留细节；人物则建议 460–680，避免显存溢出。但在实际使用中，不少用户会上传高清人像并设置 size=1024，极易引发 OOMKilled。

因此我们在入口层增加了动态校验逻辑：根据节点 GPU 显存容量自动限制最大允许尺寸。例如在 8GB 显存设备上，强制size ≤ 512，并通过前端提示引导用户调整预期。

参数	含义	推荐值	说明
`model_size`（输入尺寸）	控制输入图像缩放后的长边像素数	建筑物：960–1280；人物：460–680	尺寸越大细节越丰富，但显存消耗增加，推理时间延长
`colorization_model`	使用的具体模型版本	默认为最新版DDColor	可根据需求切换轻量或增强版模型
`output_format`	输出图像格式	PNG（推荐）	保留透明通道和高质量色彩信息

这些细节看似微小，却是保障系统鲁棒性的关键拼图。

值得一提的是，尽管 DDColor 官方并未提供标准 API 接口，但我们仍可通过底层代码理解其运行逻辑。以下是一个简化版的推理脚本，常用于性能压测或批处理场景：

import torch from models.ddcolor import DDColor from PIL import Image from torchvision import transforms # 加载模型 model = DDColor( encoder_name='swin', decoder_name='multi-scale' ) model.load_state_dict(torch.load('ddcolor.pth')) model.eval().cuda() # 图像预处理 input_image = Image.open("old_photo.jpg").convert("RGB") transform = transforms.Compose([ transforms.Resize((680, 680)), # 人物推荐尺寸 transforms.ToTensor(), ]) x = transform(input_image).unsqueeze(0).cuda() # 推理 with torch.no_grad(): output = model(x) # 后处理并保存 result = transforms.ToPILImage()(output.squeeze().cpu()) result.save("colorized_photo.png")

这段代码虽然不会直接出现在容器里（毕竟 ComfyUI 是图形化驱动），但它帮助我们定位了内存瓶颈所在——特别是在高分辨率输入下，Transformer 中间的注意力图会急剧膨胀。这也促使我们在部署时启用 PyTorch 的torch.cuda.empty_cache()主动清理策略，并限制并发请求数。

从工程角度看，这次混沌测试的成功不仅仅体现在“容器能重启”这一表象，更重要的是推动我们建立起一套完整的容错体系：