系统上线后出了故障，谁来修、多久能修好？

先说结论：故障当天能不能快，技术强弱只占一半，另一半在上线前有没有把三件事写清楚——什么情况算故障、链路上每一段归谁负责、承诺的是"多久有人接"还是"多久恢复可用"。这三件事落到纸面，出问题时就不用开会争论谁先动手；没写清楚，再强的团队也会先花两小时对齐认知。

这份判断也带条件：如果系统只是内部十几个人在用、可以容忍半天打不开，那不值得配重型监控和 7×24 值班，按需响应更划算；但只要它面对外部客户、涉及收款、或者承载必须留存的业务数据，"谁先动手、多久给答复"就必须在上线前定下来。

下面按我们做定制软件、小程序 / App 和后台系统的实际交付顺序讲：先分清这是哪一类故障，再定位它落在链路的哪一段，最后才谈响应时效、责任边界和上线前该准备什么。

一、为什么"上线后出问题"最容易变成扯皮

故障现场和合同文本之间，通常有三处落差。

第一处：合同里写的是"系统"，出问题时坏的是"链路"。 用户点一次下单，要经过手机系统、微信或支付平台的接口、你的域名解析与证书、云服务器、数据库、我们的代码、还有贵司同事在后台配的活动规则。任何一段出问题，用户看到的都是同一句"系统坏了"。而每一段的负责人可能不是同一家公司。

第二处："负责维护"这四个字没有信息量。 它没说明响应时间、没说明值班时段、没说明修不好的时候有没有临时方案。真出事时，双方对同一句话的理解可以差出一天。

第三处：没有观测能力，讨论就只能靠猜。 日志没留、监控没配，团队到了现场只能先复现、再排查，时间全花在"确认现象"上，而不是修复。

这三处落差不解决，会出现一个反直觉的结果：故障本身可能只影响二十分钟，但定责和沟通花了两天。所以真正的运维能力，不是"修得多快"，而是"多快能定位到自己还是别人"。

二、第一步：这不是一种故障，是四种

用户嘴里的"系统崩了"，至少要分成四类。类型不同，处理顺序完全不同——尤其是第一件事该不该回滚。

故障类型	典型现象	判断依据	第一步通常做什么
可用性中断	页面打不开、接口全部超时、小程序白屏	错误率突增、健康检查失败、证书或域名异常	先止损：切换、限流或回滚上一版本
数据错误	金额不对、订单状态不动、库存和实物对不上	单量正常但结果错、可按订单号复现	先冻结涉事数据写入，再定修数方案
性能退化	平时 1 秒、现在 8 秒，高峰排队	响应时间曲线抬升、数据库慢查询、队列积压	先定位瓶颈在应用还是数据库
外部依赖与规则变化	支付回调不到、短信收不到、平台接口升级报错、应用被下架	只有某一外部环节全量失败	先核对方公告与凭证有效期

这四类里，最容易被误判的是数据错误。它的"系统"其实是能打开的，用户能登录、能点按钮，所以团队一开始往往不觉得严重；但它造成的损失是持续的——错的数据会被继续引用、被导出、被拿去对账。我们的处理习惯是：只要确认存在错误的写入，先把相关写入口冻结，宁可停十分钟业务，也不让错误数据多长一千条。

另一个容易被漏掉的是外部规则变化。短信签名审核被驳回、支付证书到期、平台接口版本下线、类目资质到期被要求整改，这些在系统内部一切正常，代码一行没改，但业务停了。它们没法靠测试发现，只能靠"到期提醒"和"对方公告"来防。

三、第二步：故障落在链路的哪一段

定位不靠表态，靠证据。上线前如果没约定要采集哪些信息，出事时连"是不是我们"都判断不了。我们认为至少要能回答五个问题：什么时候开始、影响哪些用户和功能、错误码是什么、最近一次变更是什么、请求能不能按单号追到日志。

有了这五个答案，责任通常能归到下面五段之一。

一、贵司侧的配置与账号。 域名解析、HTTPS 证书续期、企业主体账号、支付商户号状态、短信签名、内部网络白名单、后台配置的活动规则。这一段出问题的比例比很多人想象的高，而且往往发生在"什么都没改"的时候——证书到期、账号欠费、同事调了配置都是无声的。

二、我们交付的代码与部署。 新版本缺陷、配置项写错、数据库变更脚本执行异常、依赖包版本冲突。判断这类问题的关键证据是"最近一次变更"：如果故障时间点和发版、改配置、跑脚本的时间高度重合，就先按这个方向查，而不是从网络层开始。

三、云与基础设施。 云厂商的可用区异常、带宽打满、磁盘写满、被刷接口或被攻击。这类情况在监控上通常表现为"整体"指标异常，而不是某一条业务链路单独出问题。

四、第三方平台与通道。 支付、短信、地图、电子发票、物流、微信 / 支付宝的接口调整、应用商店的审核策略。这类故障的特点是全量失败且和你自己的版本无关，最有效的动作是查对方状态页和公告，同时准备好对用户的话术。

五、平台审核与合规。 应用被下架、类目被要求补充资质、隐私政策与实际收集不一致被要求整改。这一类不算技术故障，但用户看到的结果一样是"用不了"，而且处理周期以天计。

责任分清楚的意义不是分对错，而是决定谁先动手。同一条链路上，只有一个人或一方在动手，其他人在提供证据，故障才修得快。多方同时改、同时重启、同时猜，是最常见的"越修越乱"。

四、第三步：响应时效和恢复时效，是两件事

很多服务承诺写得含糊，问题就出在把这两件事混成一句"及时处理"。

• 响应时效：从报障到有人受理、给出初步判断的时间。它承诺的是"有人在管"。
• 恢复时效：从报障到业务能继续被使用的时间。它承诺的是"业务回来"。
• 修复时效：从根因定位到彻底修好的时间。它承诺的是"不再复发"。

这三者的差别很实际：一次线上故障完全可能做到 15 分钟响应、40 分钟用回滚恢复业务、三天后彻底修好根因。如果合同里只写"24 小时内解决"，那回滚这种最快的手段反而没人敢用——因为回滚不等于"解决"。

分级是让承诺可执行的前提。下面是我们在方案里和客户一起定的分级方式，具体数字属于双方的约定，不是行业统一标准：

级别	判定	需要的动作
一级	核心业务不可用，或数据在持续出错	立即介入，先止损，同步节奏按小时计
二级	主流程可用但有明显功能受阻或明显变慢	当日介入，给出临时方案
三级	局部功能异常、单个用户受影响	排入最近一次版本
四级	体验与优化类问题	收集，评估后决定是否做

真正让 SLA 可用的，是下面这几个要素写不写：

1. 可用性的统计口径：按什么指标算（接口成功率还是核心功能可用）、按什么周期统计、以谁的监控为准。
2. 排除项：客户侧变更、第三方平台故障、不可抗力不计入考核——但排除不等于不协助，建议同时写明"仍协助排查，只是不计入时效考核"。
3. 值班方式与联系入口：电话还是工单，几点到几点，节假日怎么办，谁有权报障。
4. 升级路径：超过约定时间没解决的，多久由谁介入。这一条比响应时间更能反映真实的服务能力。
5. 临时方案：降级、限流、切换备用通道、人工兜底，这些往往比"彻底修复"更早让业务恢复。
6. 复盘：什么级别的故障必须出复盘，复盘包含哪些内容（时间线、根因、影响面、改进项与负责人）。

一份只写"7×24 待命"的承诺，实际价值接近于零：它没说怎么找到人，也没说找到人之后多久有结论。

五、上线前该准备的六件事

故障当天的从容，基本都是提前准备出来的。这六件事按投入产出排序，前四件即使预算有限也建议做。

1. 关键指标的监控与告警。 不需要一上来就做全链路可观测，先盯住四类：核心接口的错误率、核心业务成功率（下单成功、支付回调成功、消息送达）、响应时间、队列积压与任务失败数。告警必须指定接收人和接收方式——告警发到一个没人看的群，等于没有。

2. 可追溯的日志。 每条请求带唯一请求 ID，能从用户报的订单号或手机号追到具体调用链。日志保留周期要和业务对账周期匹配，涉及个人信息的字段做最小化处理，不要为了"方便排查"把敏感信息全量落盘。

3. 值班表与联系人清单。 双方各指定至少两名联系人，写清时段和升级顺序。单点联系人一旦休假、离职或换号，故障当天的第一小时就浪费在找人上。

4. 回滚预案。 上一版本必须处于可回滚状态：镜像和配置保留、数据库变更要么可回退、要么向前兼容。小程序要留意审核发布后的版本状态与回退方式，App 要保留旧版本的接口兼容，避免"服务端一改，老版本用户全挂"。

5. 备份与恢复演练。 备份存在不等于能恢复，定时任务成功也不等于数据可用。建议上线前完整演练一次，记录实际恢复耗时——这个数字才是你面对故障时的底气。

6. 账号与权限交接。 云账号、域名与证书、商户号、短信签名、应用商店开发者账号、第三方平台的子账号，都应该由贵司持有主体所有权，我们按需获得操作权限。交付时给一份账号清单，标注归属、续费节点和责任人。这件事同时也是降低供应商依赖的关键：账号在你手里，任何服务商更换都不至于让业务停摆。

六、故障发生后的第一小时，按这个顺序做

顺序错了，技术再强也会拖时间。

1. 先确认影响面：哪些用户、哪些功能、有没有替代路径（比如小程序坏了 App 能不能用）。这一步决定要不要立即对外发声。
2. 止损优先于找根因：回滚、降级、限流、切备用通道、人工兜底。用户关心的是"能不能用"，不是"为什么"。
3. 只留一个对外同步人：客户方一个、服务方一个，固定节奏（比如每 30 分钟一次）同步进展，避免信息在多个群里互相矛盾。
4. 保留现场：日志、错误截图、请求样本、当时的配置和版本号先留存，再重启和清理。很多故障的根因就是被"重启一下"擦掉的。
5. 记录时间线：几点几分发现、谁做了什么、几点恢复。事后复盘和分清责任全靠这份记录，不要依赖记忆。
6. 当天给结论，三天内给复盘：当天说清影响面和临时处理，复盘再说根因和改进项，改进项要有负责人和时间。

七、不同团队，选择应该不一样

同一套方法，落到不同公司要调整。

没有技术人员、也没打算招的团队。 建议把运维一并委托，但要把值班时段、响应口径和月度巡检写进合同，并要求每个月有一份能看懂的报告：可用性数字、故障次数、处理时长、待办改进项。你不需要懂技术，但你需要能判断"这个月服务有没有做到"。

有自己的 IT 团队的团队。 最大的浪费是职责重叠：两边都觉得对方在管，或者两边同时动手。建议做一张链路责任表，逐段写清"谁负责日常、谁负责变更、谁在故障时先动手"，上线前联合演练一次。演练一次的成本，远低于第一次真故障的手忙脚乱。

多供应商拼装的系统（前端一家、后端一家、实施一家）。 这是最容易扯皮的结构。要么指定一个总协调方对整体负责，要么至少有一份链路责任表和统一的报障入口。没有这个，故障当天你会先在群里看三家互相举证。

正在评估要不要新建系统的团队。 建议在需求阶段就问清对方三个问题：上线后谁值班、故障分级怎么定、有没有可核验的复盘样例。答案比宣传页更能说明交付水平。

八、滚水科技在这件事上的做法与边界

我们的做法是把它写进交付物，而不是写在承诺里：

• 方案阶段就与客户确认故障分级、响应与恢复口径、双方联系人与升级路径，作为合同附件；
• 上线前出一份上线清单，含监控项、告警接收人、回滚预案、备份与恢复演练记录、账号归属清单；
• 交付时把源码、部署文档、账号清单一起交接，客户持有主体账号，我们保留必要操作权限；
• 上线后由专人对接，报障走统一入口，一级故障当天同步影响面与临时处理，事后提交复盘与改进项。

需要说清的边界：第三方平台的接口能力、审核结果、规则调整不由我们决定，我们能做的是提前预警、给出替代方案并协助沟通；贵司主体资质、账号、支付商户号与内部网络由贵司持有和授权，我们协助排查，但不能代替持有和授权；不在约定范围内的新需求属于变更，走变更评估，不混在故障处理里。

反过来，我们也会建议一些客户不要买重运维：如果系统只服务内部少数岗位、中断半天不影响对外的业务与资金，那么按次响应加季度巡检就够了，把预算放在功能迭代上更值。

九、补充问答

服务商说"7×24 小时待命"，够不够？
不够。要追问三件事：怎么找到人（电话还是工单，是否有值班表）、多久给初步判断、超过多久由谁升级介入。没有这三项，7×24 只是一个形容词。

故障是微信或支付平台那边引起的，算谁的责任？
通常不属于服务商的服务时效考核范围，但协助排查、切换备用通道、给用户准备话术仍应在服务范围内。建议合同里把"排除考核"和"仍然协助"分开写，避免出事时用"不是我们的问题"结束对话。

我们没人懂技术，怎么验收运维做得好不好？
看三样东西：可用性数据与故障记录是否按月给出、每次一级故障是否有复盘、复盘里的改进项有没有真的做完。这三样都能核，不需要技术背景。

上线后想加功能，能算在故障处理里吗？
不建议混在一起。故障是"已承诺的功能没按预期工作"，新需求是"范围变化"，两者的排期、计价和验收方式都不同。分开走流程，双方都不容易积累情绪。

来源说明

本文的判断来自我们在定制软件、小程序 / App 与后台系统项目中的交付、上线和运维实践，以及通用工程实践中的故障分级与可用性统计方法。文中分级方式、时效要素与准备清单属于我们的建议方案，具体数字需由双方按业务影响约定，不作为行业统一标准；平台接口能力、审核规则与资质要求请以各平台官方文档当日说明为准，本文未引用具体厂商条款中的数字。