大促前的临时扩容，最直接的对接人是你们的运维负责人，但真正决定你能不能扩到资源的人，是云厂商的客户经理或机房驻场运维主管，找对人只是第一步，关键是找对完整的审批链条。
很多人一到大促前就慌，CPU告警一响，立刻到处找人问“服务器临时扩容找谁”，结果要么是找了一圈人被踢皮球，要么是找到了人但流程走不完，资源到位时大促已经开始了，这篇文章把整个扩容链路拆开讲清楚，你照着做,能把踩坑概率降掉一大半。
大促前扩容找谁对接，先分清四种身份
你把“扩容”两个字丢到工作群里，响应你的人通常有四类：商务经理、技术架构师、运维执行人、财务审批人，这四类人职责完全不同，找错了人,进度就卡住了。
商务经理管钱，不管技术
如果你是云上架构，第一联系人应该是你们的客户经理，这个人的核心价值是帮你锁库存、谈折扣、加配额，大促前所有云厂商都会面临资源争抢，特别是热门可用区的计算实例，不是你点一下控制台就有货的，客户经理手里有预留池,可以帮你提前锁住机器。
业内专家指出，大促前一周才联系客户经理要资源，成功率会明显下降,因为头部厂商的热门规格早就被大客户预订完了。
解决方案架构师管方案，不管审批
客户经理把你转给解决方案架构师之后，你要跟这个人确认的是规格选型、容量规划、架构上限，比如你现在的负载均衡规格够不够、数据库连接数会不会打满、缓存集群要不要加分片，这个人是技术顾问，但他没有权限直接给你放资源,所有实际扩容动作都要走工单或运维系统。
运维执行人管交付，不管预算
如果是自建机房或托管IDC，你要找的是机房运维主管或基础设施负责人，这类人负责物理机的上下架、网络配调、带宽加量，他们不问你要多少钱，但会问你要多详细的需求说明书，包括IP段规划、防火墙策略、监控纳管方式。
行业共识认为，自建机房的扩容复杂度比云上高出一个量级,因为涉及硬件采购周期和物理上架的硬性时间成本。
财务审批人管签字，不管紧急
最后一道卡点是财务或采购负责人，很多临时扩容卡死在这里，技术和运维都搞定了，但预算审批没走完，采购单发不出去，你需要提前准备好报价单、对比方案、预估用量说明，让财务在半天内能签字,而不是等你补材料。
大促扩容流程是什么，从申请到上线踩准五个节点
搞清楚找谁之后，更要紧的是把整个大促扩容流程是什么捋顺，流程不对，人找得再准也是白搭，标准化流程包含五个节点,缺一个都会在关键时刻爆雷。
第一步：容量评估定需求
拉上业务方和技术负责人，把大促的预估峰值流量换算成机器数量，换算公式不复杂：峰值QPS除以单机承载力，再乘上1.5到2的冗余系数，注意不要只算应用服务器，数据库、缓存、消息队列、网关、带宽全部要纳入清单。
第二步：预算确认卡时间
把容量清单转成财务语言，标注好按时计费、包月计费、一次性采购三种模式的成本差异，这一步必须留出至少一个工作日的审批缓冲期，如果公司有预算冻结机制,你要提前确认本季度是否还有可用额度。
第三步：资源申请走工单
云上直接提工单，选择“大促扩容”专属通道，附上客户经理给的预留券或配额提升审批单，自建机房要发采购申请，注明到货时限，让采购走加急流程，这里有一个关键操作：每一种资源都要单独申请，不要混在一个工单里,否则某个资源缺货会拖累全部资源交付。
第四步：交付验收做标记
机器交付后，第一时间做三件事：确认配置和申请单一致、确认加入监控集群、确认写入DNS或负载均衡后端，很多团队死在这一步，机器交付了但漏加监控，大促时机器实际已经宕机,监控面板上还是一片绿。
第五步：压测回归兜底线
扩容完成后至少做一轮全链路压测，验证扩容后的系统能否承载预估流量，压测发现短板后，留出半天时间做参数调整，如果压测过程中出现连接数打满或磁盘IO飙升，说明容量预估偏低,要立刻回退到第二步追加预算。
临时扩容要提前多久，时间线按七天倒排
临时扩容要提前多久没有统一答案，但有一条硬性经验：云上至少提前七天，自建机房至少提前二十天，低于这个阈值，你只能靠客户经理刷脸抢资源,风险极大。
云上扩容的七天倒排表
- 第七天：完成容量预估,拉通客户经理确认目标可用区有货。
- 第五天：提交预算审批，拿到财务签字,提交工单。
- 第三天：资源交付完成，部署应用,接入监控。
- 第二天：全链路压测,处理性能瓶颈。
- 第一天：冻结变更，只保留紧急修复通道,全员待命。
自建机房的两个月倒排表
自建机房的核心瓶颈是硬件采购，如果你连采购流程都没启动，时间线要从下单开始算起，主流服务器厂商的交付周期通常在两周到一个月之间，加上上架、布线、系统安装、网络调试，整体需要四十天左右是常态，所以自建机房场景下，临时扩容基本不存在“临时”两个字，只存在“提前规划”和“临场加塞”两种状态，加塞的代价是插队费或加急费,成本可能翻倍。
混合架构的最短路径
很多公司是核心业务在云上，边缘业务在自建机房，这种架构下的临时扩容有个技巧：把非核心业务先缩容或降级，把资源腾给核心链路，这比新购机器快得多，操作得当半天就能完成，具体做法是关掉日志分析集群的非核心任务，或者降低推荐算法的算力分配,优先保障交易链路。
扩容预算怎么报，三个技巧让审批一次过
预算审批是临时扩容里最容易被低估的一环，技术人写预算容易写成一堆机器型号和带宽数值，财务根本看不懂，审批自然慢，要把预算说得让财务听得懂,有三个技巧。
按峰值用量报价，不按购买总量报价
财务关心的是“这笔钱花完东西还在不在”，你要解释清楚按时计费资源用完即释放，不会沉淀为固定资产，比如预期大促峰值持续六小时，你就报六小时的弹性资源费用，并说明峰值过后缩容到基线水位，这样财务会理解这是一次性活动支出,而不是持续成本。
对比自建和云上的成本差
直接在预算表里放一个对比，自建机房的硬件采购成本、运维人力成本、闲置折旧成本列一行，云上弹性扩容成本列一行。对比数字一亮，财务签字速度会快很多，因为所有财务都厌恶不确定性,但看得懂的对比能降低他们的决策门槛。
加一条风险回退预算
预算单里额外加一个“应急备用预算”条目，金额是主预算的两成左右，标注用途为“峰值超过预估时追加资源”，很多团队不敢报这条，怕被砍预算，实际经验是有回退预算的方案通过率反而更高，因为财务看到你有风险管理意识,而不是把宝全押在一个数字上。
大促前扩容找谁对接，常见问题速查
Q：大促前扩容找谁对接最有效率？
最有效率的是直接拉一个包含客户经理、解决方案架构师、运维负责人、财务审批人的四人群，在群里一次性同步需求和时间节点，不要私下逐个对接，否则信息同步成本极高，如果公司规模较小没有客户经理，找云厂商的工单客服申请“大促保障”标签,也能走加急通道。
Q：大促扩容流程是什么，哪些环节可以压缩？
标准流程五个节点中，预算确认和资源交付环节不可压缩，前者是制度红线，后者是物理限制，可以压缩的是容量评估和压测回归，分别能压到半天和四小时以内,前提是提前准备好历史流量数据模板和压测脚本。
Q：临时扩容要提前多久才能保证大促不崩？
云上架构最低标准是提前七十二小时完成所有扩容动作，预留四十八小时做压测和应急回滚，自建机房则要按三到六周规划，少于三周只能指望硬件供应商有现货库存,同时要接受较高的加急采购成本。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787046.html
