AI提效实战：用Gemini和Windsurf重构资源调度系统
去年双11前夜，我坐在家里书房的电竞椅上（远程办公的“福利”就是不用穿裤子写代码），盯着屏幕上疯狂滚动的告警日志，心里默默问候了产品经理全家。我们基础架构组负责的内部资源调度平台，又在流量高峰时崩了。原因？老系统完全没法预测突发流量，资源分配还是靠人工拍脑袋——这都2024年了，我们还在玩“人肉调度”？
作为字节跳动干了五年后端的老兵，我其实早看这套系统不顺眼了。但以前总觉得“能跑就行”，毕竟线上没出大事故，领导也不催。直到CTO在全员会上喊出“AI提效，人人有责”，我才意识到：再不搞点真东西，年终述职怕是要凉。
为什么我们要重做资源调度？
先说说背景。我们内部有个叫 Windsurf 的平台，名字很酷，功能却很原始——它负责为所有微服务分配计算资源（CPU、内存、GPU等）。早期设计时，团队为了赶上线，直接用了静态配额：每个服务申请多少资源，就固定给多少。结果呢？有的服务常年吃不满，资源闲置；有的突发流量一来，立刻OOM，拖垮整个集群。
更离谱的是，运维同事每天要手动调整几百个服务的配额，堪称“当代数字农夫”。测试同学每次压测都要提前一周申请资源，产品经理还总在需求评审时说“这个功能很简单，加个按钮就行”，完全不知道背后资源调度有多复杂。
说实话，当时我真的想砸电脑。但冷静下来一想：这不正是个用AI提效的绝佳场景吗？
技术选型：为什么是Gemini？
一开始，我们调研了几个方案：
- 自研模型：训练成本高，维护复杂，团队没人是ML专家
- 开源LLM微调：数据隐私是个大问题，内部资源使用数据不能随便喂给外部模型
- 云厂商API：延迟高，费用贵，而且不符合公司“技术自主可控”的战略
就在我们纠结的时候，Google发布了 Gemini。虽然它主要是多模态大模型，但它的推理能力、上下文理解深度，以及对结构化数据的处理能力，让我们眼前一亮。
最关键的是，Gemini支持私有化部署！我们可以在内部K8s集群上跑一个轻量版，既保证数据不出内网，又能利用其强大的推理能力。
“用大模型做资源调度？你是不是疯了？” —— 我们组新来的实习生听完方案后一脸懵。
但事实证明，这个“疯”想法还真行得通。
实战：把Gemini嵌入Windsurf
第一步：数据准备
Windsurf本身就有海量历史数据：每个服务过去30天的CPU使用率、内存占用、请求QPS、错误率……这些全都是结构化时序数据。我们把这些数据整理成JSON格式，每条记录包含：
{
"service_name": "feed-service",
"timestamp": "2024-05-01T12:00:00Z",
"cpu_usage": 0.45,
"memory_usage": 2.1,
"qps": 12000,
"error_rate": 0.001,
"current_quota": { "cpu": 4, "memory": 8 }
}
然后，我们用这些数据构造Prompt，让Gemini学习“什么样的负载需要多少资源”。
第二步：Prompt工程
这里踩了个大坑。最初我们直接问：“这个服务需要多少资源？” Gemini经常瞎猜，甚至给出负数。
后来我们改用结构化指令 + 示例学习（Few-shot Learning）：
你是一个资深SRE，请根据以下服务的历史负载数据，推荐合理的CPU和内存配额。要求：
- CPU配额必须是0.5的整数倍
- 内存配额必须是1GB的整数倍
- 要预留20%缓冲应对突发流量
示例输入： { "cpu_usage": 0.6, "memory_usage": 3.2, "qps": 8000 } 示例输出： { "cpu": 2, "memory": 4 }
现在请处理以下输入： { "cpu_usage": 0.85, "memory_usage": 5.7, "qps": 15000 }
效果立竿见影！Gemini的输出开始符合工程约束了。
第三步：集成到Windsurf
我们在Windsurf的调度引擎里加了一个新模块 ai-recommender，每天凌晨2点自动跑批处理：
- 拉取过去24小时各服务的监控数据
- 构造Prompt，调用本地Gemini API
- 获取推荐配额，写入数据库
- 运维同学可在控制台看到“AI建议”，一键采纳或手动调整
为了防止AI乱来，我们还加了安全熔断机制：如果推荐值比当前配额变动超过50%，就自动转人工审核。
效果对比：省下的不只是钱
上线三个月后，我们拉了份数据，结果让人惊喜：
| 指标 | 旧系统 | 新系统（Gemini+Windsurf） | 提升 |
|---|---|---|---|
| 资源利用率（CPU） | 32% | 68% | +112% |
| OOM事件/月 | 47次 | 3次 | -94% |
| 运维人工干预时长/周 | 15小时 | 2小时 | -87% |
| 新服务上线资源申请时间 | 3天 | 2小时 | -97% |
最爽的是，双11那天，系统自动扩容了Feed流服务的资源，扛住了峰值流量，而我们组全员在家睡觉——这才是AI提效该有的样子！
踩过的坑与教训
当然，过程没那么顺利。分享几个血泪教训：
1. 别迷信AI，要加护栏
有一次Gemini建议把某个核心服务的CPU从8核降到1核，理由是“过去一周平均使用率只有0.2”。但它忽略了这个服务每天凌晨3点有个批处理任务，会瞬间打满CPU。幸好我们的熔断机制拦住了，否则第二天早上就得背锅。
教训：AI可以辅助决策，但关键路径必须有人工兜底。
2. Prompt不是一劳永逸
业务变化很快。比如最近短视频上传功能火了，上传服务的I/O模式变了，Gemini的推荐开始不准。我们不得不每周review一次Prompt模板，加入新的业务特征（比如“是否涉及大文件上传”）。
3. 资源≠性能，别本末倒置
一开始我们只优化资源利用率，结果有些服务虽然资源省了，但P99延迟上升了。后来我们在Prompt里加入了SLA约束：“确保P99 < 200ms”，才平衡了成本与体验。
为什么这算“最佳实践”？
很多人觉得AI提效就是调个API，但实际上，真正的提效在于系统性思维：
- 数据闭环：Windsurf本身就有完善的数据采集，这是AI落地的基础
- 渐进式改造：我们没推翻重来，而是在现有系统上加AI模块，风险可控
- 人机协同：AI出建议，人做决策，既提效又不失控
- 度量驱动：所有改动都有数据验证，避免“为了AI而AI”
在字节，我们常说“Context, not Control”（给上下文，而不是控制）。Gemini在这里的角色，就是一个超级聪明的“上下文提供者”，帮工程师做出更快、更准的决策。
写在最后
现在，我已经在团队内部做了三次技术分享，主题都是“如何用AI重构传统系统”。每次都有新人问：“是不是以后SRE都要会调大模型了？”
我的回答是：工具在变，但工程本质不变。AI再强，也替代不了你对业务的理解、对系统的敬畏、对稳定性的执着。
不过嘛，如果你还在手动调资源配额……建议赶紧学点AI提效技巧，不然下次团建，你就只能坐后排听别人吹牛了。
对了，上周五晚上，我又在家撸代码到凌晨。但这次不是救火，而是在给Gemini加多目标优化功能——让它同时考虑成本、延迟、碳排放。毕竟，咱们字节人，卷完效率还得卷环保，你说是不是？
（完）
评论 0