05. 可观测性、稳定性工程与云原生基础（深挖版）¶
这一章很容易在面试里被答成“新概念集合”：
- 有监控
- 有日志
- 上了 K8s
- 可以自动扩容
但真正的面试官通常更关心：
- 你是否知道为什么系统明明有监控，还是会出事故
- 你是否理解指标、日志、链路追踪三者不是替代关系
- 你是否知道 SLO、尾延迟、容量评估这些词背后的工程意义
- 你是否理解容器和 Kubernetes 解决了什么，又没解决什么
这一章的目标，就是把“可观测性 + 稳定性工程 + 云原生基础”这三条线连成一个后端工程体系视角。
先把这一章的知识骨架搭起来¶
可观测性和稳定性工程，本质上是在回答：系统出问题时我们怎么看见、怎么定位、怎么恢复，以及怎样让它以后少出问题。日志、指标、链路追踪是“看见问题”的三根主柱；告警、容量规划、灰度发布、SLO/SLA、应急预案则是在保证系统长期稳定。
云原生部分不要只记成“Docker + K8s”，更要理解它为什么出现：标准化交付、环境一致性、弹性扩缩容、资源隔离和自动化运维。容器和编排只是手段，目标是让系统更易部署、更易治理、更易恢复。
所以这一章要始终把工具放回工程目标里理解。
进入问答前，先把最小前置知识补齐¶
可观测性和云原生经常被答成工具名集合，但更重要的是先知道工程目标是什么：系统出了问题要看得见，发布变更要可控，资源波动时要能自动调整，故障发生后要能快速恢复。
因此日志、指标、链路追踪并不是最终目的，容器和 K8s 也不是目的，它们只是让“看见问题、管理变更、自动恢复”变得更系统化的手段。
1. 什么是可观测性？它和“有监控”是一回事吗？¶
标准回答¶
可观测性是指系统在运行时，是否能通过外部输出的信息快速判断内部状态、定位问题和解释异常行为的能力。
为什么“有监控”不等于可观测性？¶
因为很多系统虽然有监控图表，但真正出问题时仍然回答不了：
- 到底是哪一层出问题？
- 是哪个依赖变慢？
- 是流量变了，还是代码变了？
- 是局部问题还是全局问题？
这说明“采了一些指标”不等于“系统真的可观测”。
一句总结¶
可观测性的核心不是“把数据采上来”，而是让你在系统出问题时，能靠这些数据解释系统为什么变成现在这样。
2. 可观测性的三件套是什么？¶
1）Metrics（指标）¶
用于快速观察系统整体趋势，例如：
- QPS
- RT
- 错误率
- CPU / 内存 / 磁盘 / 网络
- 队列长度
- 线程池活跃度
2）Logs（日志）¶
用于还原事件细节，例如：
- 具体错误上下文
- 请求参数
- 异常堆栈
- 状态变化记录
3）Tracing（链路追踪）¶
用于看跨服务调用链路，例如：
- 某一跳慢在哪
- 哪个下游超时
- 重试发生在哪里
为什么三者不能互相替代？¶
- 指标擅长发现趋势和异常
- 日志擅长还原细节
- 链路擅长定位分布式路径中的具体慢点
高分点¶
三件套是互补关系：指标帮你发现“有问题”，日志帮你看到“出了什么事”，链路帮你定位“问题发生在调用链的哪一段”。
3. 为什么只看平均值不够？¶
标准回答¶
因为平均值会掩盖尾延迟问题，无法反映少数请求异常慢但对用户体验和系统稳定性影响极大的情况。
一个典型例子¶
如果 100 个请求里：
- 99 个请求都是 10ms
- 1 个请求是 3000ms
平均值可能还看起来不算太差，但那个极慢请求：
- 会影响用户体验
- 会占用线程 / 连接
- 会触发重试和级联超时
所以要看什么？¶
- P95
- P99
- P999
高分点¶
很多线上事故不是“整体都慢了”，而是“尾部请求开始异常变慢”，所以只看平均 RT 会严重低估系统风险。
4. 什么是 SLI、SLO、SLA？¶
SLI（Service Level Indicator）¶
服务水平指标，是可量化的观测值，例如：
- 成功率
- 延迟
- 可用性
SLO（Service Level Objective）¶
服务水平目标，是你给自己设定的内部目标，例如：
- 99.9% 请求成功
- P99 延迟低于 100ms
SLA（Service Level Agreement）¶
服务水平协议，是你对外承诺给客户的服务保障。
为什么这三个概念重要？¶
因为它们把“系统要稳定”这件事，从空泛目标变成可量化的工程目标。
一句总结¶
SLI 是你量什么，SLO 是你希望做到什么，SLA 是你对外承诺什么。
5. 告警为什么不能只靠简单阈值？¶
标准回答¶
因为单一阈值容易误报，也容易漏报，无法适应不同业务周期、流量波动和复杂故障场景。
为什么会误报？¶
例如：
- 晚高峰流量天然高
- 某些批处理任务天然会拉高指标
如果只写死一个阈值，就可能不停告警。
为什么会漏报？¶
如果阈值设太宽，真正的异常又可能被掩盖。
更成熟的做法¶
- 阈值 + 趋势
- 环比 / 同比
- 多指标联合
- 业务指标和系统指标联动
高分点¶
告警系统真正的问题从来不是“有没有消息发出来”，而是“能不能在真正有问题时及时发现，并且不被无意义告警淹没”。
6. 什么是稳定性工程？¶
标准回答¶
稳定性工程是围绕系统可用性、性能、容量和故障恢复能力，建立监控、预警、限流、降级、演练、复盘等一整套工程方法。
它和排障有什么区别？¶
排障更像“出了问题怎么查”； 稳定性工程更像“平时怎么把系统建设成不容易出大问题、出了问题也能快速止损”。
常见组成¶
- 可观测性
- 限流 / 熔断 / 降级 / 隔离
- 容量评估
- 压测
- 灰度发布
- 故障演练
- 事故复盘
一句总结¶
稳定性工程不是救火技巧，而是让系统少起火、起火后也能更快扑灭的体系建设。
7. 线上故障处理的标准思路是什么？¶
一个稳的回答框架¶
- 先止血
- 回滚
- 限流
- 降级
-
切流量
-
再定位
- 看监控
- 看日志
- 看链路
-
看最近发布和配置变更
-
再修复
- 修代码
- 修配置
-
调整容量 / 路由 / 依赖
-
最后复盘
- 根因
- 为什么没提前发现
- 监控 / 预案 / 流程哪里需要补
为什么这个顺序重要？¶
因为线上事故里：
- 用户影响扩大是第一风险
- 技术上是不是“查得漂亮”反而是第二位
高分点¶
线上故障处理最重要的不是上来就猜根因，而是先把影响范围控制住，再做有证据的定位和修复。
8. 事故复盘应该复什么？¶
标准回答¶
事故复盘应覆盖：
- 根因
- 触发条件
- 影响范围
- 发现与响应过程
- 为什么现有监控 / 预案没拦住
- 后续改进项
为什么“以后注意”不是复盘？¶
因为复盘不是写态度，而是补系统能力。 真正有效的复盘应该让未来系统具备：
- 更早发现问题
- 更小影响范围
- 更快恢复能力
一句总结¶
复盘的价值不在于追责，而在于把一次事故转化成系统能力和流程能力的提升。
9. 什么是容量评估？为什么重要？¶
标准回答¶
容量评估是根据流量规模、资源使用、单实例能力和冗余目标，估算系统需要多少容量以及在什么阈值下需要扩容的过程。
为什么不能“流量上来了再扩”？¶
因为很多系统在高峰时扩容已经太晚：
- 实例启动有时间
- 缓存预热有时间
- 数据迁移有时间
- 链路抖动会先出现
常见评估维度¶
- 峰值 QPS
- 单实例吞吐
- CPU / 内存 / 磁盘 / 网络余量
- 依赖系统瓶颈
- 冗余水位
高分点¶
容量评估不是算平均流量，而是算峰值、留冗余，并且把扩容动作放在风险真正发生之前。
10. 压测为什么重要？¶
标准回答¶
压测是验证系统在高负载、极端场景和容量边界下表现的关键手段。
它主要解决什么问题？¶
- 理论容量和真实容量是否一致
- 哪一层先成为瓶颈
- 尾延迟怎么变化
- 故障保护机制是否有效
为什么很多系统“平时没问题，一到大促就挂”？¶
因为没有真正验证过：
- 流量峰值
- 热点模式
- 下游协同能力
- 降级链路是否真的生效
一句总结¶
压测的价值不是证明系统很强，而是提前暴露容量边界和脆弱点。
11. 容器和虚拟机有什么区别？¶
标准回答¶
虚拟机通常包含完整 Guest OS，隔离更强；容器共享宿主机内核，更轻量、启动更快、资源利用率更高。
为什么容器会更轻？¶
因为它不需要每个实例都带一套完整操作系统，而是通过：
- Namespace
- Cgroups
- 分层镜像文件系统
来实现隔离和资源控制。
容器适合什么？¶
- 服务标准化部署
- 快速启动
- 弹性扩缩容
- 环境一致性
高分点¶
容器最大的工程价值，不只是更轻，而是把“应用和运行环境”打包成更标准、更可调度的部署单元。
12. Namespace 和 Cgroups 分别解决什么问题？¶
Namespace¶
用于资源隔离，例如：
- 进程视图
- 网络视图
- 挂载点
- 主机名
Cgroups¶
用于资源控制和统计，例如：
- CPU
- 内存
- IO
一句总结¶
Namespace 解决“看见什么”，Cgroups 解决“能用多少”。
13. Kubernetes 最核心的几个对象是什么？¶
Pod¶
K8s 的最小调度单元。
Deployment¶
管理无状态应用的副本数、滚动升级和回滚。
Service¶
为一组 Pod 提供稳定访问入口和服务发现能力。
ConfigMap / Secret¶
管理配置与敏感信息。
Ingress¶
HTTP / HTTPS 流量入口。
高分点¶
Pod 是调度单元，Deployment 是应用副本与发布管理单元，Service 是稳定访问抽象，这三者是 K8s 最核心的主线。
14. readiness 和 liveness 有什么区别？¶
readiness probe¶
判断实例是否已经准备好接流量。
liveness probe¶
判断实例是否还活着，是否需要重启。
为什么这两个不能混？¶
因为一个实例可能：
- 还活着
- 但还没准备好提供服务
如果把这两者混了，平台可能会：
- 过早接流量
- 或者错误重启正常但暂时未 ready 的实例
一句总结¶
readiness 解决“能不能接请求”，liveness 解决“要不要重启它”。
15. 为什么上了 K8s 不等于系统天然高可用？¶
标准回答¶
因为 Kubernetes 主要解决的是部署、调度和自愈层面的问题，而业务级高可用仍然取决于：
- 架构设计
- 数据复制
- 依赖治理
- 流量控制
- 一致性与故障恢复策略
常见误区¶
很多人会以为：
- 有多 Pod
- 有自动重启
- 有自动扩缩容
就意味着高可用已经解决。
但实际上，K8s 并不能自动解决：
- 数据库主从切换正确性
- 下游依赖雪崩
- 配置错误
- 业务逻辑缺陷
- 跨地域容灾
高分点¶
K8s 提供的是平台层编排能力，不会替你自动完成业务层高可用设计。
16. 为什么云原生强调“配置和镜像分离”？¶
标准回答¶
因为镜像应尽量保持稳定和环境无关，配置则应按环境动态注入，以支持同一份构建在不同环境下复用。
为什么不能把配置写死进镜像？¶
如果写死：
- 测试、预发、生产要重复构建
- 配置变更成本高
- 环境切换不灵活
- 敏感信息更容易泄露
一句总结¶
镜像是代码和运行环境快照，配置是部署环境变量，两者职责应该分开。
17. 什么是 Sidecar 思想？¶
标准回答¶
Sidecar 是把日志收集、代理、监控、安全等通用能力，从业务进程旁路拆出来，作为伴生容器或独立辅助组件运行的一种模式。
为什么有价值？¶
因为它能把一些横切能力从业务代码里抽离：
- 日志采集
- 流量代理
- 安全控制
- 配置下发
这样业务代码可以更聚焦业务逻辑。
高分点¶
Sidecar 的价值本质上是“把通用基础能力从业务进程里解耦”，而不是单纯多起一个容器。
18. 一组典型追问链¶
- 可观测性和“有监控”为什么不是一回事？
- Metrics、Logs、Tracing 三者分别解决什么问题？
- 为什么只看平均 RT 很危险？
- SLI / SLO / SLA 各自代表什么？
- 告警为什么不能只设阈值？
- 稳定性工程和排障有什么区别？
- 线上故障处理为什么先止血再定位？
- 事故复盘为什么不是写“以后注意”？
- 容量评估和压测为什么是稳定性建设的一部分？
- 容器为什么比虚拟机更适合服务部署？
- Namespace 和 Cgroups 在做什么？
- Pod、Deployment、Service 三者关系是什么？
- readiness 和 liveness 为什么不能混？
- 为什么上了 K8s 不等于天然高可用？
- Sidecar 的本质价值是什么？
19. 一份更像面试现场的总结回答¶
可观测性、稳定性工程和云原生，本质上都在回答同一个问题：系统上线后，怎么长期稳定地运行和演进。可观测性解决的是“出问题时看不看得清”，稳定性工程解决的是“平时能不能把风险控制在可承受范围内”，云原生解决的是“服务能不能以标准化、可调度、可扩展的方式交付和运行”。真正成熟的回答，不是说用了监控、用了 Docker、用了 K8s 就结束，而是能说明这些能力分别解决什么问题、没解决什么问题，以及它们怎样组合起来支撑一个真实在线系统。
20. 复习建议¶
至少做到：
- 能说清指标、日志、链路追踪三者的分工
- 能解释为什么要看 P99，而不是只看平均值
- 能理解 SLO、告警、容量评估和压测的工程意义
- 能说清容器和虚拟机的区别
- 能讲明白 Pod / Deployment / Service / probe 这些云原生基础对象
- 能明确指出 K8s 不替代业务层高可用设计
做到这里，这一章已经足够覆盖大多数后端岗位在可观测性、稳定性和云原生方向的基础追问。