去年深秋跑河西某生鲜SaaS客户那边，对方技术总监一上来就吐槽，说之前跟风上了Serverless，大促的时候直接崩了，钱花了不少，运维的活一点没少干。
说起来也搞笑，他们当时是做社区团购的，流量波动大到离谱，平时早高峰晚高峰挤破头，半夜闲的服务器都在打哈欠。之前用ECS的时候，为了扛峰值得提前把4台机器扩到20台，算下来一年光服务器成本就小20万。当时云厂商销售上门吹，说Serverless按调用量付费，闲的时候几乎不花钱，连服务器都不用管，他们就信了。
当初拍脑袋踩的那些离谱坑
他们当时干脆把最核心的下单、库存同步接口全迁到Serverless上了，觉得这下可以躺平。结果第一次618大促，早高峰刚开10分钟，库存接口直接超时。翻日志才发现，默认的并发实例上限被平台卡了——销售当初根本没提这个要单独申请配额，临时提配额还要走工单，等平台审批通过，早高峰都过去快一半了。
更糟的是冷启动问题。他们把库存同步的Java函数包打了120M，里面塞了一堆根本用不上的日志框架、工具类，实例被平台回收后，第一个调用的用户要等两秒多的冷启动时间，直接触发503错误，当天上午的客诉堆了快两百条。当时他们的运维小哥蹲在客户机房的走廊上改代码，冷风吹的鼻涕都流下来，还在跟平台客服掰扯为什么冷启动时间这么长。
哪些场景用了真的能省钱省力气
踩完坑他们也学乖了，不再把所有链路都往Serverless上塞，而是挑着适合的用。现在回头看，波动幅度超过10倍的非核心链路，才是Serverless真正的甜区。
比如他们的身份证OCR识别接口，平时一天只有几百次调用，大促的时候要涨到几十万次。之前专门开了一台2核4G的ECS跑这个服务，一年光机器成本就8000多。现在迁到Serverless上，平时一天成本才几毛钱，大促的时候自动扩容，也不用怕卡配额——毕竟他们提前跟平台申请了专门的配额，还把函数包精简到了15M，冷启动时间压到了200毫秒以内，完全不影响用户体验。算下来一年的成本才1200多，连之前的零头都不到。
还有那个每天凌晨要同步前一天订单到财务系统的定时任务，之前也要专门开一台小服务器跑crontab，一年成本小3000。现在直接用Serverless的定时触发器，一年跑下来成本不到5块钱，说起来都好笑。当然，核心的下单链路他们早就迁回了ECS，毕竟那个要求毫秒级的稳定性，不能赌冷启动，也不能赌平台的配额会不会临时出问题。
落地前必须盯死的几个细节
别信销售说的”零运维”，真的。你自己得盯着函数的监控日志，哪个函数超时了，哪个函数内存用超了，哪个函数冷启动时间太长，这些都要自己搭告警。平台给的告警是最基础的，很多细的阈值要自己调。他们之前有个发优惠券的函数，平时内存只用128M，就配了128M的内存上限，结果有次活动要一次性给10万用户发券，函数跑的时候直接内存溢出，报错跑了一半，优惠券只发了一半，折腾了半天才补完。后来他们给这个函数配了弹性内存，还加了失败重试的队列，才没再出这种幺蛾子。
函数包的大小直接决定冷启动速度，别把所有依赖全打进去。能用共享层的就用层，能精简的就精简，比如Java项目别把整个SpringBoot的包扔上去，用GraalVM编译成原生镜像，冷启动能压到几十毫秒。别嫌麻烦，真到用户因为冷启动等的不耐烦退出去，你再改就晚了。
还有配额的问题，别等大促的时候才想起要提配额。提前一个月跟平台那边报备，把你预估的峰值QPS报给人家，让人家给你留好资源，别临时抱佛脚。真等流量冲上来了再提工单，黄花菜都凉了。
上个月再跟那个客户的技术总监吃饭，在新街口那家开了十几年的老鸭汤店里，他说现在Serverless的成本已经占他们整体云成本的15%，但带来的运维工作量减少了快40%。不是什么万能的银弹，但用对了地方真的香。
我啃着鸭腿吐槽他当初拍脑袋全迁核心链路的蠢事，他笑的汤都溅到桌子上，说当时被销售吹的脑子发昏，哪能想到这么多弯弯绕。