开篇：一句话结论

云端服务中断一小时，贸易商停的不是「一个软件」，是三条线：报不出价、出不了库、对不了账。这三条线各停一小时，损失不在软件账单上，在客户那一边。

2026 年 10 月，日本云服务商 IDC Frontier 遭勒索攻击，约 7 分钟之内在「东日本区域 1」横向扩散，495 家客户组织失去对其虚拟服务器、网站与数据的访问（IDC Frontier 公告、Moxso、CMIT Solutions 等公开报道）。7 分钟，495 家——这个扩散速度说明一件事：中断不是慢慢发生的，是一下子全停。

本文给四类中断场景的影响表、一小时内的三个止损动作、降级预案的四步做法，以及断网可用性该怎么判断。

一、热点场景还原：周五上午十点，系统转圈了

先说明：下面是场景复述，不对应某一家具体公司。

周五上午十点，一家做存储和接口的贸易商正在赶一批当天要发的货。业务员在查库存，仓管在打单，会计在对账。

十点零几分，系统开始转圈。刷新，还是转圈。十点十五分，群里有人问「是不是只有我这边进不去」，三四个人同时回「我也进不去」。

接下来的一个小时是这样的：

业务员这边，客户在线上问价。查不到库存、查不到上次成交价，只能回一句「稍等」。两个客户等不及，去找了别家。

仓管这边，出库单打不出来。货在货架上，人也在，但不知道该拿哪一箱——库位信息在系统里。物流车按原定时间来了又走了。

会计这边，当天要付的一笔货款，付款申请在系统里走审批。批不了，款付不出去，供应商那边已经在催。

十一点多系统恢复。一小时的中断，造成的后果有：两单丢单、一批货延发一天、一笔付款逾期、以及全公司一小时的停滞。

老板后来算这笔账的时候说了一句话让我印象很深：这一小时里，我什么都做不了，只能等别人修好。

「只能等别人修好」——这就是依赖他人网络的本质。

本地部署这一层的完整口径，放在本地部署ERP的专题入口里。

二、核心方法：四类中断，三个动作

1. 四类中断场景的影响表

中断场景直接后果一小时的实际损失有没有降级办法
报价中断客户问价答不上丢单、客户转向别家有：本地留一份价格表副本
出库中断库位查不到、单打不出延发、物流空跑有：纸质出货单 + 库位图
对账中断应收应付查不到付款逾期、账期违约部分：本地留应收应付台账
审批中断付款/改价卡住供应链关系受损有：线下签字 + 事后补录

四类里，报价中断的单位损失最高，因为它直接面向客户，且客户转身成本极低。元器件贸易是比价充分的市场，一次答不上价，客户可能就再也不来了。

2. 一小时内的三个止损动作

动作一，五分钟内确认范围。 是全网中断还是自己这一端的问题？先查自己的网络、换一台机器试、问一个外部同事。确认范围只需要五分钟，不做这一步会让全公司瞎等。

动作二，十分钟内切到降级流程。 每个关键岗位都要有一份「没系统怎么干活」的纸面流程：报价用最新价格表副本、出库用纸质单 + 库位图、付款走线下签字。这份流程要贴在工位上，不能只在老板脑子里。

动作三，三十分钟内通知客户。 主动告知比被动解释好得多。客户问价答不上，最坏的处理是沉默；次坏的是说「系统坏了」；最好是「我在十分钟内给您报价，稍等」——前提是你能做到。

三个动作的前提是：降级流程在中断前就存在。 中断时才想，来不及。

3. 降级预案的四步做法

第一步，列出不可中断的三个动作。不要列全公司流程，只列三个：哪三个动作停一小时，损失最大？对多数贸易商，是报价、出库、付款。

第二步，给每个动作准备一份离线副本。报价需要最新价格表（导出成表格，每周更新一次）；出库需要库位图（打印贴在仓库）；付款需要应收应付台账（每周导出一次）。

第三步，指定降级流程的触发人和执行人。谁来判断「切到降级」、谁来拿纸质单。人不确定，流程就是纸。

第四步，每季度演练一次。挑一个下午，断网两小时，看各岗位能不能按降级流程走完。演练一次你会发现很多细节——比如库位图上个月就没更新。

4. 断网可用性该怎么判断

这一项在选型时就要问清楚，不要等中断时才知道。

问法一，断网时还能不能开单。 云端产品在断网时通常完全不可用；本地部署产品在断网时仍可开单、查库存，只是外网同步（如有）会暂停。

问法二，数据存在哪里。 存在你本机的数据，断网不影响访问；存在远端的数据，断网就是全停。

问法三，恢复靠谁。 云端中断要靠服务商修复，你能做的是等；本地部署的故障在你自己的环境里，你能做的是换机器、恢复备份——主动权在自己手里。

据 CISA 与 FBI 联合发布的 StopRansomware 指南，建议采用离线加密备份并定期做恢复演练（公开安全指南）。这条建议的背景就是：恢复能力要掌握在自己手里。

软件到底该不该上云，边界在哪，这篇拆过：软件即服务的边界：ERP该上云吗。

三、落到经营：把「不依赖他人网络」当成一种能力来买

前面的四步降级预案，不管用哪种部署方式都该做——本地部署的机器也会坏，也会断电。差别在于：故障的边界在哪里，以及修复的主动权在谁手里。

云端部署下，故障边界在你无法控制的网络和服务商基础设施里。你能做的是降级和等待。IDC Frontier 那次事件里，服务商在事发次日告知客户受影响区域数据恢复困难，并建议客户「在独立环境重建并恢复自己的备份」——连服务商自己都把兜底交回给客户。

本地部署下，故障边界在你自己的办公室里。网线、交换机、硬盘、电源——这些你都能自己换。太帅ERP 属于这一类：Windows 桌面应用、本地部署、内置数据库，免安装环境、免配服务器。断网时仍能开单、查库存、查历史报价，不受外网状态影响。

断网可用到底意味着什么，这篇单独讲过：离线可用：断网也能开单查库存意味着什么。

诚实说本地部署这一侧的代价：你要自己保证机器不坏、电不断、备份有做。硬盘会坏，办公室会停电，这些风险不会因为部署在本地就消失——但它们是可控的、可预防的、可自己修的。云端中断给你的是「等别人修」，本地故障给你的是「自己动手」，两种处境的差别不在故障率，在处置权。

四、常见误区

  • 宕机是小概率，不用准备。错在把概率当影响。正确的是：用「7 分钟扩散、495 家客户组织」这个真实速度衡量——中断发生得很快，准备要提前。
  • 有备份就等于不停工。错在混淆两件事。正确的是：备份解决数据丢不丢，降级预案解决业务停不停，两个都要有。
  • 降级流程等中断时再想。错在来不及。正确的是：贴在工位上，每季度演练一次。
  • 只问服务商的可用性承诺。错在把承诺当能力。正确的是：问断网时的实际表现，并自己断网演练一次。

FAQ

一小时真的有那么严重吗？

看发生的时间点。批货当天、客户在线等报价、供应商催付款——这三个时点撞上中断，一小时的损失远超一小时的软件费。所以要按「最坏时点」估损失，不是按平均。

降级流程要准备到什么程度？

覆盖三个动作就够：报价、出库、付款。每个动作一份离线副本、一个执行人、一张贴在工位上的说明。不要铺开到全公司流程，铺开了没人执行。

本地部署也会宕机吧？

会。机器会坏、电会断、系统会崩。区别在于故障边界和处置权：本地故障你能自己修、自己换、自己恢复备份；云端故障你只能等。

SLA 里的可用性承诺有用吗？

有用，但它通常是服务信用补偿，不覆盖你的业务损失。看 SLA 时要分清「赔你多少服务费」和「赔你多少丢单」——后者通常不在里面。

演练一次要多久？

两小时。挑一个业务不忙的下午，断网，走一遍降级流程。演练一次暴露的问题，比写十页预案有用。

写在最后

中断一小时，停的是报价、出库、对账三条线。损失不在软件账单上，在客户那一边，而客户转身的成本极低。

三个止损动作、四步降级预案、断网可用性的三个问法——这三件工具先用上，再看部署方式。最后要问的那句话是：出事的时候，我在等别人修，还是自己动手。

完整口径写在了配套的《订阅软件的数据导出限制》里——数据能不能完整拿回来，是中断之外的第二层保险。

主 CTA：完整口径写在了配套的《订阅软件的数据导出限制》里 次 CTA：继续读：本地部署ERP和SaaS云ERP的区别：9个维度对比表 → 本地部署ERP和SaaS云ERP的区别：9个维度对比表