面试故障回答案例
# 接口超时或者延迟
在一次生产发布后，发现接口响应时间明显变慢，从200ms上升到3秒以上，并出现部分超时情况。
初步判断可能是数据库或应用性能问题，于是按照排查流程进行分析：
首先检查服务器资源（CPU、内存、磁盘IO）均正常；
接着查看应用日志，没有明显报错；
然后重点排查数据库，通过慢查询日志发现某条SQL执行时间较长；
使用EXPLAIN分析后发现该SQL未命中索引，导致全表扫描。
确认问题后，短期通过添加索引快速恢复系统性能；
长期对SQL进行优化，并引入缓存机制减少数据库压力。
事后也进行了复盘，增加了慢SQL监控和发布前SQL审核流程，避免类似问题再次发生。
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
# MySQL 慢查询 / 性能下降
在一次业务高峰期，系统接口响应时间从200ms上升到2-3秒，出现明显卡顿。
影响了大约40%的用户请求，核心查询接口延迟严重，部分请求超时。
我首先从系统层排查，CPU、内存、磁盘IO都正常；然后查看应用日志，没有明显报错；
接着重点排查数据库，通过慢查询日志发现某条SQL执行时间较长。
使用 EXPLAIN 分析执行计划后，发现该SQL未命中索引，导致全表扫描。
确认根因后，短期通过增加组合索引，使查询时间从秒级下降到毫秒级；
长期对SQL进行重构，并引入Redis缓存，减少数据库压力。
事后复盘中，我们增加了慢SQL监控，并在上线流程中加入SQL审核机制，避免类似问题再次发生。
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
# CPU 100% / 负载过高
在一次生产环境中，监控告警显示服务器CPU持续100%，系统响应明显变慢。
影响了多个业务接口，部分请求出现超时，服务可用性下降。
我首先通过 top 定位高CPU进程，然后结合 pidstat 分析线程使用情况；
发现某Java进程CPU占用异常，于是通过 jstack 导出线程堆栈。
最终定位到某个业务线程存在死循环问题，导致CPU被打满。
短期通过重启服务快速恢复；同时修复代码中的死循环逻辑；
长期增加线程监控和CPU告警，并在发布前进行代码review。
通过这次问题，我们也完善了应用性能监控体系，提升了问题发现能力。
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
# Redis 缓存雪崩 / 穿透
在一次大促活动期间，系统QPS激增，同时数据库压力突然升高。
导致接口响应时间明显变慢，部分请求超时，影响核心业务。
排查过程中发现Redis命中率明显下降，大量请求直接打到数据库；
进一步分析发现是缓存集中失效，导致缓存雪崩。
短期通过设置不同的过期时间（加随机值）缓解雪崩问题；
同时开启限流，保护数据库。
长期方案是引入多级缓存（本地缓存+Redis），并对热点数据做永不过期处理；
同时增加缓存预热机制。
复盘后，我们也增加了缓存命中率监控，并优化了缓存策略。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
# Kafka 消息积压
在一次日志处理系统中，发现Kafka消费延迟不断增加，消息出现积压。
导致下游数据处理延迟，影响数据分析的实时性。
排查过程中，通过Kafka监控发现消费者消费速率明显低于生产速率；
进一步分析发现消费者处理逻辑较慢，并且分区分配不均。
短期通过增加消费者实例，提高消费能力；
同时临时扩容分区数。
长期对消费逻辑进行优化，并引入批量消费机制，提高吞吐量；
同时优化分区策略，保证负载均衡。
事后增加了Kafka消费延迟监控和报警机制。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
# 服务不可用
在一次生产发布后，部分服务出现无法访问的情况。
影响了约20%的用户请求，部分接口返回5xx错误。
排查时首先检查服务状态，发现部分实例未正常启动；
查看日志后发现是配置文件错误导致启动失败。
短期通过回滚版本快速恢复服务；
同时修复配置问题并重新发布。
长期优化发布流程，引入灰度发布和健康检查机制；
并增加配置校验，避免低级错误。
复盘后完善了CI/CD流程，提升发布稳定性。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
# 不停机更新
生产环境中，为了保障不停机更新，我一般会采用 Kubernetes RollingUpdate 或灰度发布，结合 readinessProbe、多副本、优雅退出等机制，确保新版本正常后再替换旧实例，整个过程用户无感知。
数据库迁移方面，我会优先采用向前兼容的方式，比如先新增字段，再让新旧程序同时兼容，后台分批迁移数据，最后再清理旧字段。对于大表变更，会使用 gh-ost 或 pt-online-schema-change 做在线迁移，避免锁表。
同时我会提前准备回滚方案，应用可以通过 rollout undo 回滚，数据库则尽量避免破坏性变更，保障旧版本也能兼容运行。
1
2
3
4
5
2
3
4
5
# 你在整个系统部署中做了哪些优化？
# 1）部署流程优化（CI/CD）
之前是人工或半自动部署，存在发布慢、容易出错的问题。
我推动基于 GitLab CI + Docker + Kubernetes 的自动化流水线：
- 镜像自动构建与版本管理（commit SHA 标记）
- 分环境（dev/test/prod）部署隔离
- 引入 Helm / Kustomize 做模板化部署
- 支持一键回滚
👉 效果：发布时间从几十分钟降低到几分钟，人工错误率明显下降
# 2）资源与性能优化（K8s层面）
在 Kubernetes 部署中：
- 统一设置 requests / limits，避免资源争抢
- 引入 HPA 自动扩缩容
- 对高负载服务做节点亲和性 + 污点容忍优化调度
- 调整 Pod 分布，避免单节点热点
👉 效果：高峰期延迟下降，Pod OOM 问题减少
# 3）高可用与容灾优化
- 多副本 + PDB（PodDisruptionBudget）
- 滚动更新策略优化（maxUnavailable / maxSurge）
- 核心服务跨节点分布
- 数据库/缓存分离部署
👉 效果：节点故障时业务无感或秒级恢复
# 4）可观测性优化
- Prometheus + Grafana 监控体系完善
- Loki/ELK 日志集中化
- Alertmanager 分级告警（P1/P2/P3）
# 在整个架构升级中你做了哪些操作？
# 1）从单体到微服务/容器化迁移
- 将传统部署方式迁移到 Docker 容器化
- 引入 Kubernetes 统一调度
- 拆分应用模块，按服务独立部署
👉 带来好处：解耦、独立扩缩容、发布更灵活
# 2）流量入口架构升级
- 从 Nginx 单入口 → Ingress Controller / Gateway API（如果你用过可以说）
- 增加灰度发布能力（按 header / 权重）
- 支持蓝绿发布
👉 效果：发布风险降低，可控性增强
# 3）服务治理能力建设
- 引入服务发现（CoreDNS / kube-dns）
- 配置限流、熔断、重试机制（如在网关层）
- 对高频接口做缓存优化（Redis）
# 4）存储与数据架构优化
- MySQL 主从 + 读写分离
- Redis 缓存分层（热点数据缓存）
- 日志与监控数据分离存储（ELK / VictoriaMetrics）
# 5）稳定性与安全架构增强
- TLS 加密（Ingress / API Server）
- RBAC 权限控制
- Namespace 级隔离
- 镜像安全扫描（CI阶段）
# 你在整个系统部署中遇到那些难点
在整个系统部署过程中，遇到过几个比较典型的难点，包括应用容器化改造、Kubernetes资源调优、数据库迁移以及发布稳定性保障等问题。
# 案例1：应用启动慢导致发布失败（推荐回答）
# 场景
在Kubernetes部署Java应用时：
Deployment升级
↓
Pod启动
↓
Readiness Probe检查失败
↓
滚动更新卡住
↓
发布失败
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
# 现象
发布时发现：
kubectl rollout status deployment app
1
一直卡住。
查看Pod：
kubectl describe pod
1
发现：
Readiness probe failed
1
# 原因
进一步排查发现：
应用启动需要加载大量配置
连接数据库
加载缓存
初始化线程池
1
2
3
4
2
3
4
实际启动需要：
90秒
1
而探针：
initialDelaySeconds: 10
1
导致探针提前检测。
# 解决方案
调整：
readinessProbe:
initialDelaySeconds: 120
1
2
2
增加：
startupProbe:
1
启动探针。
# 优化结果
发布成功率明显提升。
上次更新: 2026/06/15, 01:53:28
|