2019 年，从可用率 95% 到 99% 的跨越

这一年发生了什么

2019 年，第一代代理产品正式上线。HTTP 和 SOCKS5 服务面向企业用户开放。产品从"能跑"变成了"有人用"。

用户开始用真金白银来投票。他们不会因为某个功能酷就买单，只会因为"好用"才续费。而"好用"的核心，就是稳定。

这一年，我们第一次把可用率作为正式指标对外承诺。从内部测试的 95% 到上线目标的 99%，这个 4% 的差距花了我们一整年。

产品上线的背景与准备

2019 年对我们来说是关键的一年。前两年我们一直在做技术验证和架构搭建，但产品和用户之间还隔着一层——用户通过定制化的方式接入，没有标准化的产品界面。

在正式上线之前，我们用了将近三个月做最后的准备工作。这些准备工作的核心就是确保上线后不会因为用户量增长而导致稳定性下降。

压力测试。 我们搭建了模拟真实用户行为的压力测试环境，覆盖了从注册、开通、配置到日常使用的全部流程。在压力测试中暴露了多个之前没有发现的问题：数据库连接池在并发超过 200 时出现性能瓶颈、某个 API 接口在高并发下返回超时、监控系统的写入性能在高流量时跟不上。

应急预案。 针对可能出现的故障场景，我们编写了详细的应急预案。每个预案包括故障表现、可能原因、处理步骤、负责人和预期恢复时间。这些预案在后来多次故障中被验证有效。

灰度发布。 我们没有直接面向所有用户发布正式产品，而是先邀请了一批长期合作的测试用户使用新系统。在灰度期间发现并修复了多个问题，避免了对全部用户造成影响。

灰度期间我们发现了一个典型问题：测试用户和正式用户的网络环境不同。测试用户大多在网络条件较好的环境下使用，而正式用户中有一部分在复杂的网络环境下——有的在企业内网使用、有的通过移动网络使用、有的在海外使用。这些特殊网络环境暴露出了之前没有覆盖到的协议兼容性问题。

另一个灰度期间的重要发现是：用户对产品操作流程的理解和我们预期的不同。我们设计的开通流程在内部看来很简单，但在灰度用户中有超过 30% 在某个步骤上遇到困惑。我们根据反馈优化了流程，最终版本的开通成功率提升到了 95% 以上。

这些预判问题在上线后基本都应验了。

产品上线后的意外发现

产品上线后的第一个月，我们遇到了一些在测试环境中完全没有预料到的问题。

用户的使用方式和我们预期的不一样。 在设计产品时，我们假设用户主要是做网页数据采集，所以 HTTP 代理是主要使用方式。但上线后发现，不少用户把代理用于 API 调用、广告验证、账号管理等非网页采集场景。这些场景对代理的稳定性要求不同——API 调用对失败率更敏感，账号管理对 IP 的固定性要求更高。

不同用户的流量模式差异很大。 有的用户集中在工作时间使用，有的用户 7x24 小时不间断运行，有的用户只在特定时段跑批量任务。这些不同的流量模式对系统的压力模式完全不同，需要我们调整资源分配策略。

用户对可用率的理解和我们定义的不一样。 我们认为 99% 可用率意味着系统运行时间达到 99%，但用户理解的是"我的每 100 次请求中有 99 次成功"。这两个定义之间的差距，导致了早期几个用户的投诉。

可用率 95% 到 99% 的实际差距

95% 和 99% 看起来只差 4 个百分点，但真实差距远大于这个数字。用一个简单的计算来说明：假设你的业务每天发送 10 万次请求。

95% 可用率对应每天 5000 次失败，99% 对应每天 1000 次失败。从 95% 到 99%，失败次数从 5000 降到了 1000。但用户体验的差异不只是数量上的，更重要的是质量上的：5000 次失败意味着业务流程频繁中断，运维人员需要频繁介入；1000 次失败意味着大部分业务流程可以自动完成，重试机制可以处理其中大部分。从 95% 到 99%，实际上是从"需要有人在旁边盯着"到"可以无人值守运行"的质变。

从工程角度说，这个跨越涉及三个层面的系统性改进：

资源冗余：从够用到有富余。 在 95% 阶段，资源规划满足当前需求即可。但实际运营中发现当某个上游资源出现问题时，没有富余容量来承接切换过来的流量。到 99% 阶段，每个资源节点都预留了至少 30% 的富余容量。

故障感知：从等用户报到自动发现。 之前监控主要关注服务是否在线。之后增加了更多维度：连接建立时间是否异常增长、失败率是否在某个时间段突然上升、资源池响应时间是否在劣化。这些亚健康状态的检测，让很多问题在升级为事故之前就被处理了。

自动切换：从人工处理到系统自愈。 在 95% 阶段，故障切换还需要运维人员手动操作，每次切换平均需要 5-15 分钟。到了 99% 阶段，自动切换机制可以在 30 秒内完成故障识别和流量迁移。

SLA 的构成因素

在追逐 99% 可用率的过程中，我们逐渐意识到代理服务的可用率不是单一指标，而是由多个环节的可靠性共同决定的。从用户发出请求到收到响应，每个环节的稳定性都会影响最终的可用率数据。

网络链路。 从用户本地网络到运营商骨干网，再到代理服务器和目标网站，每一段链路都可能出问题。2019 年的统计显示，约 40% 的失败请求与网络链路问题直接相关——用户本地宽带波动、运营商互联拥堵、国际出口带宽满载，都是常见的网络层故障来源。

服务器稳定性和资源池。 硬件故障、系统 OOM、应用程序崩溃都属服务器端故障，此外上游资源池的 IP 耗尽或接口限流也会导致服务不可用。2019 年约 30% 的故障归因于服务器或资源池层面。

DNS 解析。 DNS 如果解析失败或返回错误 IP，请求甚至无法到达服务器。我们遇到过上游 DNS 服务波动导致代理异常的案例——表面看是节点问题，根因却在 DNS。这些因素叠加决定了最终的可用率水平，每个环节做到 99.9%，整体才有可能达到 99%。

故障处理的标准化流程

2019 年，我们建立了一套标准化的故障处理流程，这个流程后来成为整个服务体系的基础：

故障发现。 通过多维度监控自动发现异常。如果一个节点的失败率超过阈值、响应时间劣化超过 50%、或者连续多次探测失败，系统自动生成告警。

故障确认。 告警触发后，值班人员确认故障是否真实。去掉误报后进入真正的故障处理流程。

故障定位。 确定故障的根因。是代理节点本身的问题、上游资源的问题、还是网络链路的问题？不同根因的处理方式完全不同。

故障处理。 根据故障类型执行预定方案。节点故障自动切换，上游故障切换到备用资源，网络故障调整路由策略。

故障复盘。 每次故障处理后，由负责团队编写故障报告，内容包括故障时间、影响范围、根因分析、处理过程和改进措施。

一次典型的故障处理案例

2019 年 8 月的一次故障是我们从"发现问题-修复问题"到"系统性改进"的转折点。

那天下午两点左右，监控告警突然响起：某组节点的失败率从正常的 1% 以下飙升到了 15% 以上。值班人员确认告警后，发现这批节点都来自同一个上游资源池。进一步排查发现，该上游的 API 接口在半小时前开始返回超时，导致依赖该资源的代理节点大量失效。

按照预定的故障处理流程，团队首先将流量切换到备用的上游资源池——切换过程花了大约 3 分钟，失败率随即回落到正常水平。但关键问题在于：为什么过了整整半小时才发现？回溯监控数据发现，该上游的可用率其实在一点半左右就开始劣化——从 99% 降到了 95%，然后逐步加速。但我们的告警阈值只关注"完全不可用"的状态，没有捕捉到这种渐进式劣化。

这次故障的实际影响范围不大——约 5% 的用户受到了影响，持续了约 30 分钟。但它暴露了两个关键问题：一是缺乏对上游资源健康状态的渐进检测机制，二是告警阈值设置过于粗放。

故障复盘后，我们做了两项改进：增加了上游资源的渐进式健康评分机制（不仅看是否在线，还看响应时间和成功率的变化趋势）；调整了告警策略，对渐进式劣化设置更敏感的阈值。这两项改进在后来的运维中多次发挥作用。

用户教育的重要性

2019 年我们还意识到一个关键问题：用户对代理稳定性的理解参差不齐。有些用户以为代理应该像水电一样 100% 稳定，有些用户则觉得"偶尔断一下正常"。

我们开始在产品站和文档中加入关于"什么是合理的可用率预期"的内容。不是所有用户都需要 99.9% 的可用率，但用户需要知道自己买的产品的可用率是多少，以及这个可用率对他们来说是否够用。

怎么判断代理稳不稳（三）：可用率是怎么测的

2019 年我们在运营中还发现了一个重要现象：可用率在不同地区差异很大。一个代理节点在北京的可用率可能是 99.5%，但相同节点在乌鲁木齐的可用率可能只有 95%。造成这种差异的原因包括运营商互联问题、地区网络基础设施差异和本地网络质量。2019 年我们根据这些发现优化了节点分布策略，确保不同地区的用户都能获得相对一致的体验。

可用率与价格的关系

在 2019 年的运营中，我们注意到一个值得讨论的现象：可用率和价格之间存在明确的关联。要实现 99% 的可用率，需要投入的资源远高于 95%。资源冗余意味着要维护更多的节点，自动切换需要更复杂的监控和调度系统，快速故障响应需要 7x24 小时的值班安排。但很多用户在选择代理服务时只比较了价格，没有比较可用率。一个价格便宜但只有 95% 可用率的服务，和一个价格稍高但有 99% 可用率的服务，对业务的实际成本影响可能非常大——因为代理失败导致业务中断的损失，远高于代理服务本身的费用差距。

团队成长

2019 年随着产品上线，团队规模也在扩大。运维人员带来了大规模系统运营的经验，产品经理带来了用户视角的需求分析，测试人员带来了更系统的质量保障方法。团队的专业化分工让我们能够同时处理多个方向的改进：一部分人负责核心系统的稳定性优化，一部分人负责监控和告警体系的完善，一部分人负责用户支持和问题跟踪。这种分工在 2019 年下半年体现出明显的效果——故障处理速度更快了，问题复盘的深度更深了。

可用率数据的可信度评估

很多服务商公布的可用率是实验室数据，在理想网络环境下测得的最优值。但实际使用场景千差万别。你需要问清楚三个问题：

• 测试频率是每分钟测一次，还是每小时测一次？频率越高数据越可信。
• 测试节点是从一个机房测，还是从多个地理位置同时测？单点测试只反映局部状况。
• 统计口径是连接失败就算故障，还是连续多次失败才算故障？不同口径的数字差异巨大。

同样的 99%，不同的测量方式，用户实际体验可能完全不同。

历年产品数据

2019 年产品上线后的可用率变化：

产品上线后的运营经验

2019 年的运营让我们积累了一些经验，对运维代理服务很有参考价值：

不要把监控告警的阈值设得太敏感。 最初我们设了非常严格的规则，只要一次连接失败就告警。结果告警频率太高，团队产生了告警疲劳。后来我们把规则调整为连续多次失败或失败率在某个时间段内超过一定比例才告警。

故障恢复后不要马上切换回来。 早期我们有个习惯：主节点恢复后立即把流量切换回来。但发现有些故障是间歇性的，切换回来后又出问题，导致反复切换。后来我们加了观察期，恢复后再观察一段时间才切换回来。

用户通知要及时。 早期我们出了故障后只顾着修，忘记通知用户。结果用户发现服务异常后以为是我们跑路了。后来我们建立了故障通知机制，即使还没修好，也要告知用户"我们知道了，正在处理"。

关于请求维度可用率

除了传统的时间维度可用率，2019 年我们开始推广请求维度可用率的概念。请求可用率的计算方式：成功处理的请求数除以总请求数再乘以 100%。这个指标的优点在于它直接反映了用户的实际体验。如果系统 7x24 小时都在运行但每 100 个请求中有 5 个失败，用户的感受就是这个代理经常出问题。

请求级别与连接级别可用率的区别

在推进请求维度可用率的过程中，我们进一步区分了两个概念：连接级别可用率和请求级别可用率。

连接级别可用率测量的是代理服务器的连通性——TCP 连接能否建立、SSL 握手是否成功。一台服务器如果 TCP 连接建立成功率为 99%，它的连接级别可用率就是 99%。但这个指标并不反映连接建立后的实际使用情况。

请求级别可用率统计的是在已建立的连接上，实际 HTTP 请求的成功率。连接建立成功了，但请求可能因为超时、响应错误、数据不完整等原因失败。这意味着连接级别可用率通常高于请求级别可用率——差值从 1% 到 5% 不等，取决于网络环境和服务器负载。

举例来说，某个节点连接级别可用率为 99.5%，但请求级别可用率可能只有 97%。两者之间的 2.5% 差距，就是"能连上但不一定能用"的隐形损失。我们在 2019 年下半年开始在内部同时追踪这两个指标，以更全面地评估服务质量。

给用户的一句话建议

不要只看服务商公布的可用率数字，要问清楚可用率是怎么测出来的。同样的 99%，不同的测量方式，实际体验可能差一个数量级。如果可能，要求服务商提供多节点、高频率的实时监控数据，而不是一个包装过的月度平均值。另外，要区分系统可用率和请求成功率——前者是服务商角度的指标，后者才反映你的真实体验。

故障分类与优先级

2019 年我们还建立了故障分类体系，按严重程度定义了三个级别：

P0 级故障：核心服务不可用，影响大量用户。 比如全部代理节点同时掉线、用户登录和 API 完全不可用。这类故障需要在 10 分钟内响应，30 分钟内恢复。

P1 级故障：部分节点不可用，影响部分用户。 比如某个资源池故障、某个区域的代理节点离线。这类故障需要在 30 分钟内响应，2 小时内恢复。

P2 级故障：非核心功能异常，影响较小。 比如控制面板某个功能异常、某个非核心 API 返回错误。这类故障在下一个工作日处理。

这个分类体系帮助我们合理分配了运维精力。之前所有故障都是同等紧急的，团队既要处理 P0 也要处理 P2，精力分散。有了分类后，P0 和 P1 优先处理，P2 有序安排，整体效率大幅提升。

内部指标与用户感知的差异

2019 年我们认识到一个关键问题：内部系统监控的可用率和用户实际感知的可用率是两回事。内部监控关注的是系统的运行状态——服务器有没有宕机、关键进程是不是在跑。用户感知关注的是每一次请求的成功与否。在系统运行正常但个别请求失败的情况下，内部监控显示 100% 可用，而用户的感受可能只有 98%。

我们做的一个重要改进是把用户感知的可用率作为核心指标。不是看系统有没有宕机，而是看用户的每一次请求有没有成功。这个指标切换让我们发现了许多之前被忽略的问题。

请求维度可用率

除了传统的时间维度可用率，我们开始推广请求维度可用率的概念：请求可用率等于成功处理的请求数除以总请求数再乘以 100%。这个指标的优点在于它直接反映了用户的实际体验。如果系统一直在运行但每 100 个请求中有 5 个失败，用户的感受就是这个代理经常出问题。我们建议用户在选择代理服务时，问"我的请求成功率是多少"，而不是"你们的服务在线率是多少"。

可用率测试方法

2019 年我们教用户关注的第三个问题是可用率的测量方式。很多服务商公布的可用率是在理想网络环境下测得的最优值。你需要问清楚三个问题：测试频率是每分钟还是每小时测一次？测试节点是一个机房还是多个地理位置同时测？统计口径是一次失败就算故障还是连续多次才算？同样的 99%，不同的测量方式，实际体验可能完全不同。

产品上线后的运营数据

2019 年产品上线后的可用率变化：上线前测试约 95%，平均恢复时间约 30 分钟；上线后第 1 个月约 97%，恢复时间约 15 分钟；第 3 个月约 98%，恢复时间约 8 分钟；第 6 个月约 99%，恢复时间约 3 分钟；第 12 个月约 99.2%，恢复时间约 2 分钟。数据说明可用率的提升不是线性的，它是在一次次故障处理和系统改进中逐步积累的。

一年的跨越

从 95% 到 99% 花了我们整整一年时间。这一年里，我们经历了很多次故障、很多次深夜紧急处理、很多次"为什么又出问题了"的反思。但每次故障之后，系统都比之前更稳定了一点。

2019 年结束时的最大收获是：可用率不是靠一次架构升级就能达到的，而是需要持续投入、长期积累的。它不是在办公室里设计出来的，而是在每一次故障处理和每一次系统改进中打磨出来的。没有捷径可走，每一百分点的提升都是团队加班加点、反复排查根因、一步步优化出来的。

2019 年代理行业的变化

2019 年不仅是我们的产品年，也是代理行业加速变化的一年。几个趋势对当年代理服务产生了直接影响。

更多服务商开始承诺 SLA。 2019 年之前，大多数代理服务商公布可用率时用"约 99%"这样的模糊表述，且很少在合同中明确承诺。2019 年开始，头部的几家服务商开始在官网上明确标注 SLA 承诺，并以月度或季度为单位公布实际的可用率数据。这种透明化的趋势把可用率从营销概念变成了可验证的指标，倒逼整个行业提升服务质量。

企业用户对代理服务的专业度要求提高。 随着大数据和 AI 行业在 2019 年的快速增长，企业对代理的需求从"能上网"升级到了"高质量数据通道"。企业用户开始要求专门的客户经理、定制的 IP 资源池、详细的流量报表。这意味着代理服务商不能只做资源转售，必须建立专业化的服务团队。

IPv4 资源紧缺加剧。 2019 年全球 IPv4 地址池持续紧缩，代理服务商获取新 IP 资源的成本上升。这对可用率产生了间接影响——资源减少意味着节点密度下降，部分地区的用户可能因为缺乏就近节点而体验劣化。我们 2019 年下半年开始加大海外 IP 资源的储备，以应对资源紧缺带来的挑战。

服务的核心价值

回顾 2019 年，最重要的不是产品代码本身，而是围绕建立起来的一套服务体系和团队成员对"让用户满意"这件事的重视。技术可以靠钱和时间堆出来，但服务意识需要团队在一次次用户反馈中逐步建立的。我们在这一年里逐渐明白了代理行业的本质：它不是 IP 资源的生意，而是信任的生意。用户花钱买的不是 IP 地址，而是"出了问题有人管"的安心感。这个认知影响了我们后来所有的产品决策和服务流程设计。

展望 2020

2019 年的经验积累让我们对 2020 年有了更清晰的方向。产品化完成之后，下一步的重点是系统的高可用改造。我们需要让系统在面对单点故障时能自动恢复，而不是依赖运维人员手动处理。

我们也在 2019 年底对服务稳定性做了全面评估，确定了 2020 年要解决的核心问题：消除单点故障、缩短故障恢复时间、提升架构的自动化水平。这些目标将在下一年逐一实现。

地区差异与可用率

2019 年我们发现可用率在不同地区差异很大。一个代理节点在北京的可用率可能是 99.5%，但在乌鲁木齐可能只有 95%。原因包括运营商互联问题（电信、联通、移动之间的互联带宽有限）、地区网络基础设施差异和本地网络质量。我们根据这些发现优化了节点分布策略，同时建议用户在选择代理服务时，要求服务商提供在本地所在地区的测试数据。

可用率与价格

可用率和价格之间存在明确的关联。实现 99% 的可用率需要投入的资源远高于 95%。资源冗余意味着要维护更多节点，自动切换需要更复杂的监控系统，快速响应需要 7x24 值班。但我们发现很多用户只比较价格不比较可用率。一个便宜但 95% 可用率的服务和一个稍贵但 99% 可用率的服务，对业务的实际成本影响可能非常大——代理失败导致业务中断的损失远高于代理服务本身的费用。