如何保障服务稳定性？｜阿里巴巴后端开发面经解析

60 秒回答模板

我会先定义核心链路和 SLO，例如可用性、延迟、错误率、容量水位；再做稳定性治理：上线前靠容量评估、压测、灰度和回滚降低变更风险，运行时靠超时、重试预算、限流、熔断、隔离和降级防止故障扩散，发现问题靠指标、日志、链路追踪和告警定位，事后靠预案演练、故障复盘和改进项闭环提升系统韧性。

考点 核心机制与工程取舍

难度 中高频面试题

回答目标 按定义、机制、场景讲清楚

稳定性不是泛泛的“不挂”，而是核心链路在明确流量和故障假设下满足 SLO。要说明哪些接口是关键路径，错误率、p95/p99 延迟、容量水位、恢复时间和数据正确性分别怎么衡量。

大多数事故来自变更和容量误判。上线前要有容量模型、压测、热点预估、依赖梳理、配置校验、灰度发布和快速回滚；高风险改动还要准备开关和降级预案。

入口限流保护自身，依赖熔断避免把下游故障拖成全链路故障；超时必须短于调用方预算，重试要有退避和次数限制。线程池、连接池、缓存、队列和隔离舱要防止局部故障耗尽全局资源。

稳定性要能被发现和解释。核心指标包括 QPS、错误率、延迟分位、饱和度、队列长度、依赖耗时、慢查询、GC、CPU/load、磁盘和网络；链路追踪用于定位哪一跳拉长或失败。

故障处理中先止血再定位，优先降级、扩容、回滚或切流。恢复后要复盘触发条件、检测缺口、预案有效性和长期修复项，并把改进落到监控、容量、代码和流程里。

限流控制进入系统的流量，熔断在依赖异常时快速失败，降级是在能力不足或依赖失败时保留核心功能、牺牲非核心体验。

失败请求会额外放大流量，如果没有超时、退避、幂等和重试预算，调用方会把下游压得更重，还可能造成重复写入。

看它是否覆盖事前预防、事中发现与止损、事后恢复与复盘，并且每个动作都有指标、阈值、责任人和演练验证。

告警应围绕用户影响和核心 SLO，使用分级、聚合、抑制和恢复通知，低价值机器指标只做诊断，不直接打扰值班。