服务SLA——99.9%可用性怎么做到的
99.9%的可用性，翻译成经营者能听懂的语言是：一年之中，你的AI助手不能用的时间不超过8小时46分钟。
对于一家依赖AI来做日常经营判断的企业来说，这8小时46分钟的"不可用"不是不方便——它可能意味着：一个该被发现的应收款风险错过了、一个该被提醒的库存短缺没有被及时上报、一个关键的经营决策因为缺少AI的分析而推迟了一天。
因此，99.9%的SLA不是一句营销口号。它是一个由技术架构、运维流程、监控体系和故障响应机制共同支撑的承诺。本文将从这四个维度拆解这个承诺是如何兑现的。
SLA的严格定义：不是什么"差不多99.9%"
可用的定义
很多公司说"我们的系统99.9%可用"时，他们可能只计算了服务器在线的时间——如果服务器没宕机就算"可用"。但EIOS对"可用"的定义严格得多：
EIOS的"可用"定义：一个已认证的企业用户，通过标准API或Web界面，向任一Agent发送一条业务查询，能在15秒内收到一个格式正确、基于实时数据（而非缓存数据）的完整回复。
如果上述条件中的任何一个不满足——服务器在线但Agent返回了超时、返回了错误、返回了基于过期缓存的数据——都计为"不可用"。
这种严格的定义意味着：99.9%的可用性比听起来更难达成。它不只是"服务器不宕机"，它是"端到端的用户体验不中断"。
测量方式
EIOS的可用性测量通过三层探针实现：
第一层：基础设施探针（每30秒）。监测服务器、数据库、缓存、消息队列的基础健康状态——CPU、内存、磁盘、网络。
第二层：服务探针（每60秒）。向每个核心服务发送一个合成请求，验证服务是否正常响应——不仅是"还活着"，而是"能正确干活"。例如向财务分析Agent发送一个标准查询"本月收入总计"，验证返回的数据结构和数值范围是否正常。
第三层：端到端探针（每5分钟）。模拟一个真实用户从登录→选择Agent→提问→收到回复的完整流程。这是最严格的测试——因为如果任何一个环节出错，整条链路就算中断。
可用性的计算方式：可用时间 / （可用时间 + 不可用时间），按月、按季度、按年分别统计。2026年度，EIOS的三层可用性分别为：基础设施层99.99%、服务层99.95%、端到端层99.92%。综合SLA按端到端层计算——99.91%（四舍五入对外承诺99.9%）。
技术架构：高可用不是靠"一台更强的服务器"
消除单点故障
高可用的第一原则是：没有任何一个组件是"唯一的"。任何一个组件挂掉，必须有另一个在它挂掉的瞬间无缝接替。
EIOS的架构中，以下关键组件都实现了冗余：
应用服务器冗余（PM2集群模式）：NestJS应用以PM2的集群模式运行，同时启动多个进程实例。如果一个进程崩溃，PM2自动重启并在重启期间由其他进程承接流量。单个进程的崩溃对用户来说是不可感知的。
数据库冗余（MySQL 8.4主从复制）：主数据库负责写入，从数据库负责读取。如果主库出现故障，从库可以在几分钟内提升为主库。同时有每日自动备份，确保在最坏情况下（双库同时故障）可以在1小时内从备份恢复。
缓存冗余（Redis Sentinel）：Redis使用Sentinel模式，主Redis负责读写，至少一台从Redis实时同步。主Redis故障时Sentinel自动将从库提升为主库，切换时间通常在10秒以内。
Nginx反向代理冗余：在生产服务器上，Nginx作为所有流量的入口。如果Nginx进程异常，PM2会自动重启它，重启期间的短暂中断（通常1-2秒）通过客户端的自动重试机制来消化。
外部AI服务冗余（多模型并行）：EIOS依赖外部大语言模型API。我们不依赖单一模型提供商。当主模型（如DeepSeek）出现延迟或不可用时，系统会自动降级到备用模型（如通义千问或GLM），确保Agent的推理能力不中断。
计算资源的"弹性而非奢侈"策略
有人可能会问：为什么不做更彻底的冗余（如多机房、多活）来追求99.99%甚至更高的可用性？
答案是：在99.9%和99.99%之间，成本增加约3-5倍，而给客户带来的实际可用性改善是每年多大约7小时。对于EIOS的目标客户群体——中型和成长型企业——这不是一个合理的投入产出比。
我们选择在99.9%这个合理目标上做到极致，而不是为了一个更高的数字去过度投资。
监控体系：在客户发现之前就知道出问题了
"客户告诉我系统坏了"是不可接受的
EIOS运维团队有一条铁律：系统问题必须被监控发现，而不是被客户报告。如果客户比我们的监控先发现了问题，这不只是一个技术故障——这是对监控体系的设计失败。
四层监控金字塔
第一层：基础设施监控（Prometheus + Grafana）。CPU使用率、内存使用率、磁盘空间、网络流量。阈值告警：CPU持续超过80%超过10分钟、磁盘使用率超过85%、内存使用率超过90%。这层监控是"防止服务器物理资源耗尽"。
第二层：应用性能监控（自定义APM）。每个API端点的响应时间、错误率、吞吐量。阈值告警：P95响应时间超过15秒、错误率超过1%、某端点连续5次返回非200状态码。这层监控是"防止某个功能变慢或变坏"。
第三层：业务健康监控（Agent质量探针）。每个Agent的响应准确率、响应完整度、幻觉率。这层监控是EIOS独有的——不仅监控"系统有没有在运行"，还监控"Agent的回答质量有没有下降"。如果一个Agent的幻觉率突然从2%上升到8%，即使API返回值是200，也会触发告警。
第四层：用户体验监控（端到端合成事务）。模拟真实用户场景：登录→选择Agent→提问→验证回答。这层监控回答的问题是："如果我是一个真实的用户，我现在能用这个系统吗？"
告警的"信号-噪音比"管理
一个常见的运维陷阱是"告警疲劳"——太多低优先级的告警导致团队对真正的关键告警失去敏感性。EIOS的告警体系有三个设计原则：
原则一：只有影响用户的问题才触发即时告警。一个Agent进程的CPU使用率短暂升高到90%但不是持续的——不告警。一个端到端探针连续两次失败——立即告警。
原则二：告警有明确的响应级别。P0（关键）：影响所有客户的核心功能中断，15分钟内必须响应。P1（高）：影响部分客户或非核心功能，30分钟内响应。P2（中）：性能下降但功能可用，2小时内响应。P3（低）：潜在风险信号，下一个工作日处理。
原则三：每次告警之后都有复盘。不论是P0还是P3，每一次告警和响应之后都有一份简短的复盘记录：什么触发了告警、我们怎么响应的、我们如何防止同类问题再次发生。
故障响应：8小时46分的年度"不可用预算"怎么花
2026年度故障回顾
在2026年度，EIOS经历了总额约7.5小时的端到端不可用时间（在99.91%的可用性下）。以下是这些"不可用分钟"的来源：
2月18日：数据库连接池耗尽（1小时12分钟）
根因：一个批处理Agent在执行大规模历史数据导入时，异常地占用了所有数据库连接，导致其他正常请求无法获取连接。修复：限制单个Agent的最大数据库连接数到总连接池的30%，剩余70%保留给其他请求。
5月3日：外部LLM服务大面积延迟（2小时35分钟）
根因：DeepSeek API出现全球性服务降级，响应时间从正常的2-5秒延长到30-60秒。修复：改善了模型切换策略——当主模型P95响应时间超过10秒持续5分钟时，自动将50%流量切换到备用模型。同时增加了第三个备用模型作为额外保险。
9月22日：一次失败的部署（28分钟）
根因：一个新版本在部署后5分钟被端到端探针检测到Agent响应格式异常。立即回滚到上一个稳定版本。修复：部署流程中增加了"金丝雀检查"——新版本先部署到单进程，接受端到端探针的15分钟验证，验证通过后才推送到所有进程。
11月8日：Redis主节点内存溢出（45分钟）
根因：缓存未设置TTL的某个Agent会话状态在长时间运行后占满了Redis内存。修复：所有缓存键强制设置最大TTL（24小时），并增加了Redis内存使用的阈值告警。
其他碎片化中断（累计约2.5小时）
包括Nginx的短暂重启、SSL证书自动续期期间的服务闪断、以及若干次短暂的网络波动。这些碎片化中断每次持续时间在30秒到5分钟之间，单独来看影响有限，但累计起来是"不可用预算"的稳定消耗源。
每次故障都是一次"免疫接种"
值得强调的是：在这7.5小时的不可用时间里，没有一次故障的根因重复出现过。每一次故障之后，团队都找到了根因并实施了永久的预防措施。这不是"运气好没有重复故障"——这是系统的、纪律性的故障复盘文化的结果。
运维领域有一个广为人知但很少被认真执行的准则："不要浪费任何一次危机。(Never waste a good crisis.)"每一次故障都是系统的"免疫接种"——它暴露了架构中的一个薄弱点，修复它之后，系统对这个特定故障模式产生了"抗体"。
数据安全与灾备：当所有预防都失效时
防御纵深：不是"不会丢数据"，而是"丢了也能找回来"
SLA不只是"服务不中断"。它也包括"在最坏的情况下，客户的数据不会丢失"。
第一层：实时主从复制。所有数据写入主库的同时，同步写入从库（异步复制，延迟通常小于1秒）。
第二层：每日自动全量备份。每天凌晨自动执行数据库全量备份，备份文件异地存储（不同于生产服务器的独立存储）。保留最近30天的每日备份。
第三层：增量日志备份（binlog）。数据库的binlog以小时为单位进行增量备份，存储在独立于全量备份的另一个位置。在最坏的情况下（主库和从库同时损坏），可以通过"最近的全量备份+后续的所有增量日志"恢复到故障前最后1小时的状态。
第四层：客户自主数据导出。作为一个额外的保障，任何客户都可以在任何时候一键导出自己的全部数据（JSON格式）。这不是为了灾备——这是为了让客户知道"你的数据永远在你的控制下"。
恢复时间目标（RTO）和恢复点目标（RPO）
RTO（恢复时间目标）：从灾难发生到服务恢复的目标时间——小于1小时。这包括数据库恢复、应用重启、以及全面的功能验证。
RPO（恢复点目标）：允许丢失的最大数据量——小于1小时的数据。这意味着在最坏的情况下，最多丢失最近一个小时的增量数据。
这两种指标在2026年度从未被实战检验过——因为主从复制的机制使得主库故障从未同时导致从库故障，我们从未需要真正从备份中恢复。但恢复演练每季度进行一次，确保在需要的时候，整个流程可以被可靠地执行。
SLA的哲学：承诺的本质是给自己施加纪律
SLA常被误解为"对客户的承诺"。但它实际上首先是"对团队的纪律"。公开承诺99.9%的可用性，意味着你的团队知道——有一个公开的、可被衡量的、必须被兑现的数字在上面。这个数字驱动着无数的日常决策：
要不要在周五下午部署一个新版本？——如果你知道周五下午的部署如果出问题，可能会吃掉你整个季度的"不可用预算"，你会等到周一早上。
要不要给数据库加一个索引？——如果你知道在生产高峰期加索引可能导致锁表，你会安排在凌晨的低峰期执行。
要不要临时关掉一个监控探针？——如果你知道它存在是有原因的（上一次就是因为关了它才没及时发现故障），你不会关。
SLA的本质不是对客户的承诺。它是团队对自己日常行为的约束。而正是这些约束——日复一日地被遵守——最终兑现了对客户的承诺。
下一篇：安全认证与合规——SOC2+等保三级意味什么。