机场故障多久恢复才算稳定？恢复时间、采样误差与未恢复事件这样记

机场一次故障多久恢复，必须先说清从哪里开始计时、怎样认定恢复，以及观察在哪个时点结束。 只公布“平均恢复几分钟”，却不披露故障次数、未恢复事件与采样间隔，难以评价用户真正承受的中断。

本文给出个人能够执行的事件记录方法。它不提供商家稳定性排名，也不声称存在所有机场通用的“几分钟内恢复才合格”。工作会议、偶尔浏览和连续下载的可接受中断不同，记录首先服务于自己的使用需求。

一、故障次数、可用率与恢复时间回答不同问题

一周出现一次长中断，和出现很多次短中断，可能形成相近的累计不可用时间，但对登录、会议和下载的影响不同。可用率概括观察窗口内的成功或可用比例；故障次数描述事件频率；恢复时间则描述一次中断持续到何时。

它们应当放在一起看。不能用“故障很少”掩盖一次尚未恢复的长故障，也不能只用“每次恢复很快”忽略反复断开的体验。关于固定样本计算可用率的基础方法，可先看机场稳定性的固定采样记录。

指标或记录	主要回答什么	单独使用的缺口
故障事件数	发生了多少次可定义的中断	不知道每次持续多久
累计观察到的不可用时间	窗口内承受多少中断	不知道是否集中在关键任务
已完成事件恢复耗时	已确认恢复的事件有多长	未恢复事件可能被漏掉
最长已完成事件	观察到的严重事件边界之一	不代表未来最长只会如此
未关闭事件及观察跨度	截止目前仍有什么悬而未决	不能当作已结束事件算均值

二、把“任务失败”与“机场根因”分开

先选一个能代表需求的普通任务，并规定成功条件。收到页面外壳、节点探测在线或ping通，不一定满足原任务。Google SRE强调观察用户可见行为，并区分症状与原因；外部失败记录可以说明体验异常，但未必能定位根因。Google SRE：监测分布式系统

例如，你可以记录“本机家庭Wi-Fi通过节点A读取指定页面失败”，不能只凭这一点写“服务商全网中断”。同时保留一个受允许的对照任务或另一网络，有助于说明影响范围，但不需要对陌生系统进行高频探测。

测试目标本身也可能出故障，客户端或本地网络也可能异常。记录中设置“归因未知”是必要选项。若每次失败都立即换设备、换网络和换节点，就很难判断原路径何时恢复。

三、最有用的不是一个时间，而是四个时间点

周期采样无法连续观察全部瞬间。把最后一次成功、第一次失败、最后一次失败和第一次成功分别记下来，才能说明中断大概落在哪个范围。时间统一带时区，并保留实际采样时间，不用计划时间代替。

时间点	意义	需要注意
最后成功时间	此前最近一次通过任务验收	不是故障开始的精确时刻
首次失败时间	第一次观察到不满足条件	故障可能已经发生一段时间
最后失败时间	恢复前最近一次明确失败	之后可能仍有未观察空隙
首次恢复时间	故障后第一次重新满足条件	不自动等于稳定恢复

“首次恢复时间减首次失败时间”可以作为一项可观测耗时，但应明确它使用采样时刻，不是后台实际维修耗时。个人无法看到服务商开始排障、替换设备或回滚配置的真实时间，就不要把外部观察直接命名成工程修复时长。

四、一个虚构算例：每五分钟测一次会带来什么误差

假设09:00任务成功，09:05首次失败，09:15仍失败，09:20首次成功；并假定中间是一次连续中断，没有漏掉短暂恢复或再次故障。实际开始可能在09:00至09:05之间，实际结束可能在09:15至09:20之间。

在这个简化假设下，真实持续时间约落在10至20分钟的范围；按首次失败到首次成功记录的可观测耗时是15分钟。这个15不能被包装成精确的后台恢复时间，测量间隔已经限制了精度。

NIST的可靠性数据说明介绍了无法知道精确发生时刻、只知道所在区间的情况。本文借用“区间观察”的概念解释采样误差，算例和记录方式是为网络任务自行整理，不是NIST给机场规定的测试标准。NIST：Censoring与区间数据

虚构采样	任务结果	当时能知道什么
09:00	成功	这一时点任务可完成
09:05	失败	故障开始不晚于此时
09:15	失败	此时尚未观察到恢复
09:20	成功	此时任务重新可完成

如果09:10没有采样，不能把它填写成失败；如果期间换过节点，也不能继续把后续成功当作原节点恢复。缺测、切换和条件变化应直接标注，它们影响的不是表格美观，而是结论是否成立。

五、一次成功与稳定恢复之间，需要一条预先约定的规则

为避免偶然成功马上被写成恢复，可以事先规定恢复确认条件。例如，连续三次按固定间隔完成同一任务，才将事件标为“已确认恢复”；首次成功时间和确认时间分别保存。这是一个自拟规则示例，不是所有用户都应采用三次。

连续确认会增加等待时间，因此报告需要同时披露采样间隔和确认规则。不同记录者使用“第一次成功”“连续成功”或“关键任务完成”作为终点，结果不适合直接排名。

出现成功与失败交替时，也需要定义事件合并规则。可以把未达到恢复确认前的波动保留在同一事件中，或者按明确规则拆分；重要的是先规定并一贯使用。不要为了减少故障次数而把整月所有波动合并，也不要把每个失败请求都当成一次独立事故。

六、未恢复事件不能删掉，也不能填成零分钟

假设已经结束的三次事件可观测耗时分别为5、10、15分钟，平均值为10分钟。另一次事件从首次失败后，直到120分钟后的最后一次采样仍失败。报告若只写“平均10分钟恢复”，会让读者看不到更严重的进行中事件。

更准确的写法是：“3次已确认恢复事件的可观测耗时均值10分钟；另1次截至最后一次失败采样仍未满足恢复条件，按预先约定的采样与事件合并规则，该未关闭事件的观察跨度已达120分钟。”由于第四次还没结束，不能把它当作最终120分钟混入完整事件均值，也不能填成零。

这里的120分钟描述记录系统中未关闭事件的观察跨度，不是经过连续监测证明的真实连续故障时长下界。离散采样可能漏掉短暂恢复；只有补充连续性假设或更完整证据，才能进一步解释实际中断持续了多久。对外引用时，这个限定需要与数字一并保留。

观察窗口开始时就已失败的事件，同样缺少起点。应标记“窗口开始前已存在，开始时间未知”，而不是默认从开始记录那一刻才发生。若最后一次采样以后已经停止观察，也不能继续自动累加成新的已验证故障时长。

这类未完整观察的数据需要单列。小规模个人记录不必强行套复杂生存分析模型；把窗口、已完成数、未完成数与未关闭观察跨度写清楚，通常比输出一个看似精确的综合均值更实用。

七、原节点恢复与自己借备用恢复，要分成两条时间线

你的任务可以通过备用节点恢复，而原节点仍然异常。前者体现个人恢复使用的能力，后者才是原路径的恢复观察。若把两者混为一谈，就可能把自己主动切换后的成功算成服务商已经修复原节点。

建议分别记录“用户任务恢复时间”和“原路径复测结果”。需要不中断工作时，优先使用已经验证过的备用方案，同时保留之后对原路径的低频复测。备用的选择与成本可参考主备切换的实际核对方法。

也要区分接入网络变化。切到手机热点后正常，只能说明新的组合可用；它可能改变运营商、地址和路由。切网后出现旧连接不恢复，可使用网络、客户端与应用的三层恢复步骤处理，随后标明条件已经变化。

八、把客服答复、公告与自己的观察放在同一时间线上

公告发布时间、客服确认时间、首次成功时间和稳定确认时间可能不一样。保留它们有助于解释变化，但公告“恢复”不能替代自己的原任务验收；自己一次失败也不等于公告对所有用户都错误。

Google的事件响应实践建议在调试和缓解过程中保留工作记录，便于协调与复盘。个人用户可用一个简短事件表实施这项思路，无需借用大型组织的完整流程。Google SRE Workbook：Incident Response

一条记录至少包含：事件编号、受影响任务、设备和网络、节点、上述四个采样时间、确认规则、切换动作、公告或客服时间、归因状态与是否关闭事件。不同任务的故障范围也应分开，不能把一次下载失败直接扩展成全部应用不可用。

九、怎样把记录用于续费判断

先看故障是否集中在自己真正需要的时段，是否影响关键任务，再看恢复是否及时、备用是否有效、客服是否提供可执行的信息。恢复次数多不一定说明服务更好，也可能说明故障发生得更多。

比较不同服务时，统一任务、时段、采样频率、确认规则和观察期限。只记录工作日白天的甲服务，与全天记录的乙服务，不具备同样暴露时间。给出样本范围，比把结果换成一个未经解释的星级更重要。

对于是否长期订阅，可以把事件记录与价格、续费和稳定性的长期选择条件一起判断。个人观察能够帮助减少不合适的预付决策，但不能保证未来不会发生更长中断。

常见问题

没发生故障，是不是MTTR等于零？

不是。没有可供计算的已完成故障样本，应写“本观察窗口未记录符合定义的事件，恢复耗时不适用”，而不是零分钟修复。

MTTR到底从哪一刻开始算？

不同资料可能用恢复、修复或解决等不同含义。引用任何MTTR数字前，都要读它的计时起点、终点与排除项。本文使用明确命名的可观测耗时，避免只写缩写。

能把每次失败的错误码直接当根因吗？

不能。错误码通常说明某一层观察到的结果，原因还需对照与服务端证据。保留“未知”，有助于避免错误归因。

怎样形成可供别人引用的结论？

写明观察起止、任务、采样间隔、故障定义、已完成与未完成事件数，再给出带范围的耗时。将“原路径恢复”和“备用后恢复使用”分开，别人就能理解数字究竟代表什么。