SLA：4小时内恢复服务，靠的是体系而非个人拼搏

下面这种情形，我见过很多次。

客户签订了 SLA（服务级别协议），其中约定：“关键故障恢复时限为4小时。” 故障发生后，工程师开始查看基础设施，才发现自己并不了解它。 没有文档，没有拓扑图，不清楚设备部署在哪里，没有备件，也没有访问相关设备的权限。

结果，这4小时没有用来恢复服务，而是用来熟悉环境。

对我们而言，在条件具备的情况下，4小时并不是一个难以企及的恢复目标。 关键在于准备是否充分。而准备工作早在第一次故障之前，甚至在合同签订之前，就应当开始。 这里讨论的是约定范围和条件下的服务恢复，不是对任何设备、任何故障作出统一承诺。

先做好运维接管

流程的起点不是写下 SLA，而是接管需要维护的基础设施。 在承诺维修之前，首先要弄清楚，自己究竟接手了什么。

第一步是快速审查：了解现场，评估整体状态，梳理现场设备与连接关系， 并检查基础信息安全措施，包括备份、恶意软件防护和访问权限。

第二步是全面盘点设备、软件和配置。 不是“大致知道”，而是准确掌握。 不了解客户部署了什么，就很难在故障发生时迅速定位处理对象。 关于这些文档如何在后续维护中持续更新，可参阅 《服务器预防性维护：为什么比故障抢修更经济》（俄文原文）。

风险清单与切实可行的改进计划

根据审查结果，形成风险清单：

• 瓶颈在哪里，哪些环节最可能先出问题；
• 哪些问题影响关键业务，哪些可以稍后处理；
• 哪些设备已经停产，后续备件供应存在困难；
• 哪些环节缺少必要的冗余，例如磁盘阵列未达到预期的冗余状态。

之后，再制定分阶段消除瓶颈的计划。 不是承诺“明天把所有问题都解决”， 而是明确“第一个月处理这三处，第二个月处理另外五处”。 多年形成的基础设施问题，通常无法在一周内全部解决。 与客户共同制定现实的计划，比给出漂亮的承诺更有价值。

监控：在客户发现之前识别问题

如果总是等客户先打来电话，服务团队往往已经失去了提前处置的机会。

监控系统可以部署在客户侧，由客户自己的团队负责跟踪； 也可以由服务商集中运行。 无论采用哪种方式，目标都是在性能或状态劣化演变为故障之前发现它。

磁盘使用率达到95%，不一定已经造成服务中断，但应当触发告警。 机房温度升高，未必意味着设备已经失效，却已经值得联系相关人员核实。

告警还必须送达工程师真正会注意到的渠道。 不能只发到一天才查看一次的邮箱， 而应结合即时通信、工单系统和电话等渠道进行通知。

备件：全天候可取用

即使监控、升级处理机制和工程师能力都很完善， 如果凌晨三点电源模块损坏，却没有备件， 4小时的恢复目标也可能变成“等商店上午十点开门再去采购”。

因此，需要在客户现场或服务商自己的场所建立应急备件储备， 覆盖风险评估中识别出的关键更换需求。 对于支持热插拔的设备，可以按设备要求实施热更换； 其他设备则应遵循相应的停机与更换流程。

关键是全天候可取用。 工程师应当能够在需要时取到对应备件，而不是等待仓库人员第二天上班。

备件清单应由风险评估决定。 如果基础设施中存在已经停产、市场上难以获得零件的设备， 就应优先考虑其备件保障。 否则，一旦发生故障，可能面临无件可换的局面。

升级处理：落实到电话，而不只是文件

很多公司的问题，就出在这里。

升级处理矩阵写得很清楚： “工程师在15分钟内未接手故障，就转交上一级负责人。” 但实际执行时，却没有人转交。 理由可能是“他还在线”“他平时回复很快”，或者“不想为这点事打扰别人”。 结果，关键故障被搁置了一个小时，因为大家都以为别人会处理。

真正有效的做法不同。 关键故障分派给工程师后，应通过电话确认通知。 不是一条可能被略过的即时消息，也不是一封可能被忽视的邮件。 关键故障意味着立即开始处理，而不是等忙完其他事情再看。

如果工程师在预先约定的 N 分钟内仍未接手， 就电话联系团队负责人，并按既定链路继续升级，必要时直至部门负责人。 这听起来严格，但如果工程师正在休息，而团队又没有确认通知是否送达， 恢复时限就很难得到保障。

值班：覆盖夜间、周末与节假日

关键故障不会按照工作日程出现。 它可能发生在周六晚上、新年假期，或者所有人都已离开现场之后。

因此，服务商内部需要明确夜间、周末和节假日的值班安排。 不能依赖临时自愿帮忙，而要有清晰的排班： 今天谁值班，谁是后备人员，如何联系。

值班工程师应当清楚：收到关键故障工单后，需要立即按优先级接手。 这是当班职责。 没有这样的安排，“4小时”就可能只在工作日朝九晚六有效， 其他时间则无法稳定兑现。

有效的规程，与流于形式的规程

Andrey Gromov 最近在 《大公司为何走向衰落》中， 把失去约束的官僚主义列为原因之一。 乍看之下，前面提到的审查、风险清单、升级矩阵和值班表， 似乎也会增加繁文缛节。

区别在于：文件究竟为谁服务。

流于形式的规程，是为了出事之后能找到归责对象。 写好一次，放进文件夹，直到事故发生后才被想起。 真正有用的规程，则是为了让凌晨三点的工程师不必从头摸索， 而能按明确步骤行动。 流程中的每个角色，都应当知道异常发生时自己要做什么。

一个简单的检验办法是： 经历真实故障之后，团队有没有复盘规程是否仍然适用，并在需要时更新？ 如果规程从不接受现场经验的检验，它就很容易沦为纸面文件。

Uptime Institute 在2025年的年度故障分析中指出： 在与人为错误有关的重大故障中， 85%涉及人员未遵循程序，或程序本身存在缺陷。 这一比例并不是指全部故障。 参见 Uptime Institute，2025年（英文）。 问题不只是规程多还是少，而在于规程是否有效、是否持续更新。

俄罗斯采用的 IT 服务管理国家标准 ГОСТ Р ИСО/МЭК 20000-1-2021（俄文） 也强调服务管理体系的建立、实施、保持和持续改进。 规程应当是工作工具，而不是写好后就不再改变的文件。 这里引用的是管理思路，并不表示 ATRIMUT 获得了该标准的认证。

哪些因素拖慢响应

即使 SLA 写着“15分钟响应”，实际等待也可能长达三小时。 常见障碍有以下几类。

人为因素。工程师看到了告警，却想着“先吃完饭再处理”； 或者没有意识到故障的重要性； 也可能同时面对多个紧急任务，无法判断优先级。 依赖个人临场判断，会给响应链路带来不确定性。

工程师与管理者之间的信息脱节。 管理者看到的是“我们有98%的 SLA 达标率”； 工程师想到的却是“昨天那个故障，如果一开始就给我权限， 本来一小时能解决，结果用了三小时”。 双方关注的指标不同。 如果不能坐下来讨论真实瓶颈，问题就不会自动消失。

告警噪声。 监控一夜发来200条通知，其中190条并不紧急， 工程师逐渐不再关注它们， 于是可能错过第201条真正重要的告警。

缺少反馈。 工单关闭之后，没有人分析为什么耗时这么久， 没有人更新操作手册，也没有人调整告警。 一个月后，同样的问题再次发生， 团队又一次忙于紧急抢修，而不是减少重复故障。

这套机制为何有效

把这些环节连起来，就能看到完整的工作链路。

监控在客户发现之前识别异常，告警送达工程师。 如果属于关键故障，就通过电话通知。 工程师在约定的短时间内接手。 他了解基础设施，因为审查和文档已经提前完成； 他有操作手册，因为处理流程已经梳理； 他能拿到备件，因为潜在故障已经纳入储备计划。 如果超出他的处理能力，升级机制就按条件触发， 而不是等某个人偶然想起来。

这样，4小时就不再只是一句承诺， 而是有资源、流程和工程判断支撑的恢复目标。

在我们的实践中， 基础设施审查、风险清单、监控、全天候备件保障、 电话升级通知和值班安排相互配合， 使我们能够在绝大多数情况下按约定时限恢复服务。 这不是因为工程师拥有超常能力， 而是因为体系提前消除了许多可能造成延误的障碍。

结语

要在4小时内恢复服务，关键不只是故障发生后的反应速度， 更在于故障发生之前做了什么。

如果背后有基础设施审查、准确的文档、风险评估、监控、 全天候备件保障、电话升级通知和值班机制， 这个目标才有可靠的实现基础。

如果背后只有合同中的一句话， 以及对工程师“到时候总能想出办法”的期待， 那么即使给出更长时间，也未必能够恢复服务。

对中国同行与合作伙伴而言， 这篇文章介绍的是我们在俄罗斯开展 IT 运维与技术支持时的工作思路， 可作为技术交流和讨论俄罗斯项目合作的参考。