本文目录导读：
晚上八点,店铺刚发出促销通知，客服群里突然弹出一句：“老板，顾客说付款页面一直转圈。”
你赶紧打开手机,首页加载了半天，商品图片一张也刷不出来，换个网络再试，还是一样，后台登录不上，订单状态看不到，广告却还在继续扣费。
做过线上生意的人,大概都能理解这种心情：店明明还开着，顾客也已经走到门口，可门就是推不开。
如果排查后发现,服务器正在遭受大流量攻击，那接下来要面对的，就不只是一个技术故障了，它会迅速变成订单问题、客服问题，甚至是信任问题。
大流量攻击，就像有人故意把店门口堵死
先用一个生活中的场景解释。
你在小区门口开了一家早餐店,平时一小时接待几十位顾客，煎饼、豆浆都能正常供应，突然有一天，门口来了上千个人，反复排队、询价、占位置，却不真正买东西，真正想吃早餐的人挤不进来，店员忙得团团转，生意反而做不下去。
服务器遭遇拒绝服务攻击时,情况有点类似：攻击者通过大量流量或请求，消耗网络带宽、连接数、计算资源，让正常用户无法使用服务，如果攻击流量来自大量分散设备，通常就属于分布式拒绝服务攻击，也就是常说的 DDoS。
这里有个容易被忽略的区别：并不是只有流量特别大，网站才会被打垮。
有些攻击主要挤占带宽,好比把通往早餐店的整条路堵住，有些攻击则专门盯着搜索、登录、查询等比较消耗资源的接口，好比不断提出复杂要求，让店员忙于应付，后一种情况，即使带宽看起来没有跑满，应用和数据库也可能先撑不住。
遇到网站卡顿,不能只盯着一个流量数字，更不能看到访问量暴涨就立即断定是攻击，活动引流、程序错误、爬虫集中访问，都可能造成相似现象。
一个小店的促销夜，为什么会变成“救火现场”？
不妨设想一个具体的经营场景。
一家卖手工饼干的小店,平时通过公众号和独立网站接单，店主花了几千元准备节日促销，提前联系达人推广，还让两位客服晚上加班。
活动开始后,最初十分钟订单增长正常，随后网站突然变慢，技术人员查看监控，发现请求数量明显偏离日常水平，大量请求持续访问少数几个接口，错误率和响应时间一起上升。
这时候,损失会从几个方向同时出现。
顾客已经付款,却因为查询页面打不开，以为订单没成功，有人重复下单，有人在评论区质疑商家跑路，客服无法确认订单，只能一遍遍解释，店主一边催技术处理，一边犹豫广告到底要不要暂停。
即使网站两小时后恢复,也不代表事情结束，重复付款需要核对，投诉需要回复，订单需要补查，还有一些顾客已经转身去了别家。
这个例子虽然是假设,但它说明了一个很现实的问题：服务器的可用性，往往直接连着普通人的收入和信誉。
用户并不一定在意故障背后的技术原因,他们最关心的是：我的钱安全吗？订单还算数吗？什么时候能正常使用？
真遇到攻击，第一件事不是反复重启
人在着急的时候,很容易做出一个动作：重启试试。
偶尔重启确实能缓解某些故障,但如果攻击流量还在持续，服务启动后可能很快再次被压垮，反复重启，还可能增加排查难度。
更合理的处理方式,是先确认瓶颈，再选择措施。
确认到底哪里出了问题。
查看带宽、请求量、连接数、处理器占用、数据库负载和错误日志，分清是网络链路被占满，还是应用处理不过来，同时对照活动时间和历史访问情况，避免把正常用户误拦下来。
尽快联系云服务商或网络服务商。
如果攻击已经打满了上游带宽,仅靠服务器本机设置防火墙，通常不足以恢复正常访问，因为恶意流量在到达本机之前，就已经占用了网络通道，这种情况下，需要服务商协助，在更上游进行防护、过滤或流量清洗。
根据业务情况启用针对性的防护。
对异常频率的访问进行限制,对高消耗接口增加保护，合理使用缓存，必要时暂时关闭非核心功能，内容分发网络、网页应用防火墙和抗 DDoS 服务各有作用，但没有哪一个产品可以不看配置、不看架构，就保证解决所有问题。
这里尤其要注意：防护措施也可能误伤正常顾客，促销时大量用户共用公司网络，或同一地区的移动网络出口，简单粗暴地封禁某个地址段，可能把真正的买家一起挡在外面。
技术在抢修，沟通也不能停
我认为,很多团队在故障处理时最容易漏掉的，不是某条配置，而是对外沟通。
网站打不开,客服又不回复，用户就会自己寻找解释，解释往往越传越离谱：有人说商家倒闭，有人猜测账户被盗，还有人直接发帖提醒别人不要付款。
与其让猜测扩散,不如通过仍然可用的渠道发布简短说明：
“目前部分用户访问异常，我们正在处理，已付款用户请勿重复支付，可通过客服提供订单信息进行核对，后续进展将在本渠道更新。”
这段话不需要堆技术术语,也不必在原因未核实前断言“遭到黑客攻击”，把已知情况、用户该怎么做、下一次从哪里看消息说清楚，比一句“正在紧急修复”更有帮助。
支付成功和订单保存是否正常,应当分别核实，不要为了安抚用户，在没有确认前承诺“所有订单都绝对没问题”。
我更在意的，是恢复之后有没有改变
我的观点很明确：安全投入不一定要一步到位，但不能永远等到出事后才开始。
一家日常订单不多的小店,未必需要购买昂贵的整套防护，可至少应该知道，出了问题联系谁，哪些业务必须优先保住，订单数据如何备份，用户应该从哪里获知消息。
这些准备看起来不起眼,却往往比临时加钱买服务器更管用。
提前为流量、错误率和费用设置告警，可以更早发现异常，把图片等静态内容与下单业务合理分离，可以减少相互影响，针对搜索、验证码、登录等接口设置合适的访问限制，可以降低滥用风险，准备一个独立的通知渠道，则能避免主站不可用时，连解释的地方都没有。
恢复之后,还要留存监控、日志、处理时间线和服务商工单，如果涉及勒索或明显违法行为，应保存相关证据，并根据情况报警，不要轻信所谓“付款就停攻击”的承诺，更不要因为气愤去尝试反击。
也别把所有责任都简单归结为“技术不行”，攻击是攻击者的责任，经营者和技术团队要做的，是在现实预算内提高韧性，而不是幻想任何系统都能永远不出故障。
服务器被大流量攻击,表面上看，是流量与资源之间的较量，落到生活里，却是店主熬夜核对订单，是客服反复解释，是顾客担心一笔付款有没有着落。
真正值得追求的,不是宣传里那句“绝对打不垮”，而是发生问题时能够及时发现、有效止损、诚实沟通，并且在恢复之后，让同样的损失更难再次发生。