11 阿里面试高频题集（资深运维 / SRE）一、阿里面试流程与节奏 1.1 典型面试轮次（P6+/P7） 1.2 每轮

配套用法：其他 10 篇搭建知识体系，这篇是考场冲刺题集。场景题 + 原理题 + 架构设计题 + 行为面（含薪资谈判）。

一、阿里面试流程与节奏

1.1 典型面试轮次（P6+/P7）

1 轮：HR 初筛（背景、薪资、动机）
2 轮：技术一面（直属主管，考基础 + 项目）
3 轮：技术二面（跨团队，考深度 + 架构）
4 轮：交叉面（不同 BU，考软实力 + 通用能力）
5 轮：HR 三面（文化价值观、薪资、入职）
6 轮：大老板面（P8+ 才有，战略 + 思维）

1.2 每轮时长 + 重点

轮次	时长	重点	准备
HR 初筛	30 min	匹配度、动机	JD 对应经历
技术一面	60 min	Linux、K8s、DB 基础	本知识库 01-05
技术二面	60-90 min	SRE、架构、故障案例	06-07、10
交叉面	60 min	沟通、跨团队、复盘能力	行为面 + 故事
HR 三面	30-60 min	阿里价值观、薪资	本文末尾

1.3 阿里文化关键词（每轮都可能提及）

客户第一：一切决策的出发点
因为信任，所以简单：同事协作
拥抱变化：主动求变
诚信：不 cheat、不背锅甩锅
敬业：对结果负责
激情：热爱工作
此时此刻、非我莫属、舍我其谁：担当

二、技术基础高频题

2.1 Linux（详见 02）

Q1：一台服务器 CPU 飙到 100% 怎么排查？

答题模板（分 5 步）：

top 看哪个进程：us 高 or sy 高 or wa 高
定位线程：top -H -p <pid>，热点 TID
分类处理：
- Java → jstack <pid> 找 TID 转 16 进制匹配
- Native → perf top -p <pid>
生成火焰图确认热点函数：perf record -F 99 -p <pid> -g -- sleep 30
代码层优化 + 验证

Q2：内存占用高怎么判断是不是泄漏？

看 RSS 长期趋势（Prometheus 一周曲线）
持续上升不下降 = 泄漏
Java：heap dump + MAT 分析
Native：jemalloc 的 profiling

Q3：TIME_WAIT、CLOSE_WAIT 各代表什么？

TIME_WAIT：主动关闭方等 2MSL 确认对端收到 FIN（客户端偏多）
CLOSE_WAIT：被动关闭方收到 FIN 但应用没 close（应用 bug）
生产大量 CLOSE_WAIT → 代码没关 socket

Q4：怎么查磁盘 IO 瓶颈？

iostat -xz 1：%util、await、aqu-sz
SSD await > 10ms、HDD > 50ms 警戒
iotop -oP 找罪魁进程
进程级：cat /proc/<pid>/io

Q5：TCP 三次握手四次挥手 + 半连接/全连接队列

半连接队列：tcp_max_syn_backlog，SYN 收到后
全连接队列：min(somaxconn, listen backlog)，完成握手
队列满：半连接满 → SYN 丢 / 全连接满 → ACK 丢
netstat -s | grep -i listen 看 overflow

2.2 Kubernetes（详见 05）

Q6：Deployment 和 StatefulSet 区别？

Deployment：无状态，Pod 可互换
StatefulSet：有状态，Pod 名字稳定（pod-0, pod-1）、有序启停、每副本独立 PVC
场景：StatefulSet 用于 ZK/Kafka/MySQL 集群

Q7：Pod 调度流程？

Scheduler watch 到 Pending Pod
Filter 阶段：排除不符合的节点（资源、污点、亲和性、PodSpread）
Score 阶段：打分排序（资源均衡、亲和偏好）
Bind：写 Pod.spec.nodeName 到 apiserver
Kubelet 接收

Q8：Pod 生命周期 hooks？

PostStart：容器启动后立即执行（与容器主进程并行）
PreStop：容器被终止前（优雅下线关键）
常见误区：PostStart 执行失败会导致容器重启

Q9：kubectl exec 的原理？

kubectl exec → apiserver → kubelet → containerd/runc → 容器命名空间
走的是 SPDY/WebSocket 长连接，通过 apiserver 代理

相关安全：RBAC pods/exec 权限严管

Q10：kubernetes Service 的几种类型，各自适用场景？

ClusterIP：集群内访问
NodePort：节点端口暴露（不推荐生产）
LoadBalancer：云厂商 LB（生产主流）
ExternalName：DNS CNAME（外部服务别名）
Headless：无 VIP，返回 Pod IP 列表（StatefulSet）

2.3 数据库（详见 04）

Q11：MySQL 事务隔离级别 + 各自问题？

级别	脏读	不可重复读	幻读
读未提交	✅	✅	✅
读已提交（RC）	❌	✅	✅
可重复读（RR，默认）	❌	❌	❌（间隙锁）
串行化	❌	❌	❌

Q12：InnoDB 为什么用 B+ 树？

树高低（3-4 层撑百亿数据）→ IO 次数少
叶子节点双向链表 → 范围查询高效
非叶节点只存 key → 节点扇出大

Q13：MVCC 怎么实现的？

每行隐藏字段：DB_TRX_ID（最后修改事务 ID）+ DB_ROLL_PTR（回滚指针）
undo log 链存历史版本
ReadView：当前活跃事务列表，判断版本可见性
RC 每次 SELECT 创 ReadView，RR 事务开始创一次

Q14：索引失效的常见原因？

函数包裹列：WHERE DATE(col) = x
隐式类型转换：WHERE varchar_col = 123
LIKE '%xxx'（左模糊）
OR 条件一边无索引
不满足最左前缀（组合索引）
索引列参与计算
负向查询（!=, NOT IN）选择率太低走全表

Q15：Redis 持久化对比？

RDB：内存快照，fork 子进程，bgsave，恢复快，丢数据风险（两次快照间隔）
AOF：追加日志，everysec 最多丢 1 秒
混合（4.0+）：RDB 做基线 + AOF 增量，推荐
阿里云 Redis 自动做 RDB + AOF 备份

Q16：Redis Cluster 16384 个槽位怎么来的？为什么不是更多？

心跳包要带所有槽位状态，16384 bitmap = 2KB，可接受
65536 个 = 8KB 太大
16384 / 1000 节点 = 每节点 16 个槽，足够均衡

2.4 网络（详见 03）

Q17：HTTPS 握手过程？

TCP 三次握手
ClientHello（支持的 TLS 版本 + 密码套件 + 随机数）
ServerHello + 证书 + ServerKeyExchange
客户端验证证书（CA 链 + 有效期 + 域名）
客户端生成 pre-master secret，用服务端公钥加密传输
双方基于三个随机数派生会话密钥
ChangeCipherSpec + Finished
TLS 1.3 进一步压缩为 1-RTT（甚至 0-RTT）

Q18：HTTP/1.1 vs HTTP/2 vs HTTP/3？

1.1：持久连接、管道化（实际不用）、文本协议、队头阻塞
2：二进制、多路复用（解决 HTTP 队头阻塞）、Header 压缩、Server Push
3：基于 QUIC（UDP），解决 TCP 队头阻塞 + 更快握手

Q19：DNS 解析完整过程？

浏览器缓存 → 系统 hosts → 系统 DNS 缓存
  → 本地 DNS 服务器（运营商/公共如 8.8.8.8）
  → 根 DNS（.）→ 顶级域（.com）→ 权威域（example.com）
  → 返回 A 记录

Q20：CDN 工作原理？

用户请求 → DNS 智能解析 → 最近 CDN 边缘节点
边缘节点命中缓存直接返回
不命中 → 回源（或二级缓存）→ 缓存后返回
关键：缓存键设计（URL + Query + Header）、缓存时间、预热、刷新

三、架构设计题

3.1 设计题答题框架

1. 澄清需求（规模、SLA、预算、合规）
2. 容量估算（QPS、数据量、存储、带宽）
3. 核心架构图（组件 + 流量）
4. 关键决策点（技术选型权衡）
5. 高可用 & 容灾
6. 可观测性
7. 成本优化
8. 扩展性（下阶段演进）

3.2 经典场景题

设计题 1：百万 DAU 电商秒杀系统的运维架构

要点：

流量预估：峰值 100 万 QPS，是平时 100 倍
入口层：DDoS 高防 + WAF + CDN（静态资源）+ 高性能 NLB
应用层：ACK 多节点池 + HPA + 虚节点兜底，按库存 SKU 分桶限流
中间件：
- Redis 集群（Tair 性能型）做库存 + 热点 key 本地缓存
- MQ（RocketMQ）削峰填谷，下单异步化
DB 层：PolarDB 主 + 多读 + 分库分表，订单表按用户 ID 哈希
预案：
- 限流降级：超过阈值排队 + 兜底页
- 熔断：DB 出问题只读不写
- 灰度：活动先对 VIP 开放
压测：全链路压测覆盖至峰值 1.5 倍
降级策略：详情页静态化、商品列表用旧缓存、非核心功能关停

设计题 2：跨 3 地多活架构

要点：

单元化：用户按 ID hash 路由到单元
全局服务（GZone）：商品、配置中心
单元服务（RZone）：订单、支付等交易
数据同步：DTS 异步双向同步，冲突域设计
流量调度：GTM + 接入层 + 全局加速 GA
切流能力：秒级切流，配套 Runbook + 演练
挑战：单元间数据强一致场景（用户在 A 单元但商家在 B 单元）需要专设跨单元服务 + 分布式事务
切流演练：月度至少一次

设计题 3：日志平台选型 + 架构

要点：

规模：500 TB/日，查询秒级，保留 90 天
选型对比：
- ELK：自建可控、运维重、性能瓶颈大规模难扩
- SLS：托管、秒级入库查询、成本低、与阿里云深度集成
- Loki：省钱，但查询能力弱
推荐：SLS 为主 + Grafana 可视化
架构：
- Logtail 采集 → SLS LogHub → LogSearch 索引
- 冷热分层：7 天热 + 30 天温 + 长期投递 OSS
- 脱敏：Data Transform 实时 ETL 脱 PII
成本：采样 + 索引字段精简，预估月 10 万元

设计题 4：老系统上云迁移方案

要点：

评估：资产清单（应用、DB、中间件、依赖）、合规要求、预算
分批：
- 批 1：非核心（CMS、内部工具）→ 练手
- 批 2：支撑系统（用户、订单）
- 批 3：核心（交易、支付）
策略：
- Lift-and-Shift：VM → ECS（快，但没发挥云能力）
- Replatform：换阿里云托管产品（RDS、ACK）
- Refactor：架构改造上 Serverless / 微服务
数据迁移：DTS 全量 + 增量，小时级切换窗口
双写演练：写老 + 写新对比，保证数据一致
回滚：保留老环境 30 天

四、SRE 场景题

Q21：线上接口 P99 从 100ms 飙到 5s，怎么定位？

结构化排查：

现象确认：大盘看是全链路慢还是单服务慢，按用户/机房/版本分
链路追踪：ARMS 定位慢在哪一段（应用自身 / DB / Redis / 下游）
资源：看该服务 CPU、内存、GC、线程池
变更关联：最近是否有发布/配置变更
依赖方：下游是否异常
流量：是否突增（拖垮 DB / 缓存击穿）
假设验证：逐一排除，最可能的先处理

Q22：SLO 定得过高会怎样？

研发一直疲于救火，不敢发新功能
过度工程（为了 0.001% 的可用性花 10x 成本）
真正故障时错误预算没剩，组织层面失信
建议：基于历史数据定合理 SLO，业务价值导向

Q23：值班期间同时收到 5 个告警，怎么处理？

分级：先 P0 → P1 → P2
分工：如果有多人值班，并行处理
观察：是否存在根因告警（抑制下游派生告警）
记录：所有操作进作战群，便于复盘
求助：单人无法应付立即升级

Q24：变更后指标没问题但用户在投诉怎么办？

信用户反馈（真实世界最准）
立即回滚，事后分析
可能原因：
- 监控盲区（没覆盖的链路）
- 指标粒度太粗（平均值掩盖长尾）
- 用户特定场景（某运营商、某设备型号）
改进：完善监控覆盖 + 按用户维度分析

Q25：一套新系统上线，你会怎么建设稳定性？

路线图：

M1：基础监控（ECS/DB/K8s 基础指标）+ 基础告警
M2：应用指标（APM）+ SLO 初版 + 日志规范
M3：全链路压测 + 容量基线
M4：发布规范（灰度 + 回滚）+ 变更审批
M5：应急预案 + 演练
M6：混沌工程 + 稳定性文化

五、行为面（阿里特色）

5.1 必问题目

Q1：你做过最有成就感的事？

讲一个从 0 到 1 建设/根本性改变的项目
结构：起因 + 难点 + 你的创新 + 结果 + 延续影响
避免陷阱：不要讲"别人安排我做什么做得好"

Q2：讲一次失败的经历？

真实 + 反思 + 成长
避免：讲假的失败（"我太追求完美"）
推荐：一次故障 / 一次判断错误 / 一次沟通失败
重点：你学到了什么，下次怎么做

Q3：和同事意见不一致怎么办？

阿里看重"透明"和"因为信任，所以简单"
答题：
1. 先理解对方（倾听）
2. 用数据说话（不拍脑袋）
3. 如果无法统一，拉上级裁决（不内耗）
4. 一旦决定，全力执行（不阴阳）

Q4：为什么离开现公司？为什么选阿里？

不要贬低前东家
强调正面动机：发展空间、业务规模、技术挑战、团队
阿里吸引点：技术广度、双 11 级场景、云业务增长、业界影响力

Q5：你对阿里的价值观怎么理解？

不要死背，结合自己故事
推荐：举 1-2 个工作中体现客户第一 / 拥抱变化的例子

Q6：3-5 年职业规划？

体现野心 + 现实
资深 → 专家 → 技术主管
或者资深 → 架构师方向
结合阿里的能力体系讲（P 级晋升路径）

5.2 行为面答题 STAR + L

S（Situation）+ T（Task）+ A（Action）+ R（Result）+ L（Lesson learned）

L 是阿里特色，展现自我反思。

六、薪资谈判

6.1 阿里薪资结构

部分	说明
基本月薪 × 12	固定
年终奖	平均 3-6 个月，与 KPI 挂钩
股票 RSU	按四年 vesting，每年 25%
签字费	一次性，补偿上家未到手
五险一金	按当地最高基数
补贴	餐补、交通、健康体检

6.2 不同职级参考（2026 年市场行情，仅供参考）

级别	现金 package（月薪 × 月数）	RSU（年化）
P6	3-6 万 × 16	5-15 万
P7	5-9 万 × 16	20-50 万
P7 高	7-12 万 × 16	40-100 万
P8	起 20 万 × 16	80-200 万

实际以谈判能力、业务需求、市场环境变动为准。

6.3 谈判策略

掌握信息差：问清楚每一项（月薪、月数、股票、签字费）
锚定高值：初期报价略高于期望，留谈判空间
用竞争 Offer：有其他 Offer 时委婉提（不要威胁）
不只谈钱：级别、团队、汇报关系也重要
不要轻易接受 lowball：接受后几年内难再调
签字费谈判点：现在年终奖没拿 / 股票没 vest 部分，要求补偿

6.4 避坑

不要透露现在具体数字（只讲期望）
不要在一面就谈薪资（证明自己再说）
HR 让你"给个范围"，给偏上的
Offer 发了仍可协商，不会收回
对比总包（cash + stock），不对比单点

七、反向提问（面试结尾必有）

好的反问展示深度：

业务层："这个岗位最核心解决什么问题？成功标准是什么？"
团队层："团队现在的规模、结构、技术栈、近期重点是什么？"
技术层："团队当前最大的技术挑战是什么？"
成长层："我如果加入，前三个月主要做什么？我能获得什么成长？"
文化层："团队是怎么开复盘会的 / 怎么处理意见分歧的？"

避免：

问 HR 技术细节
问加班（暗示不愿干）
问晋升考核（显得功利）
问薪资（留到谈薪时）

八、考前一周冲刺清单

通读本知识库 11 篇，能口述每章大纲
准备 5-8 个个人故事（故障、项目、架构、协作、失败）
把简历上每个项目 "Why / What / How / Impact" 写清
刷阿里云产品文档（重点：ECS、ACK、SLS、ARMS、RDS、PolarDB）
熟悉阿里技术术语（飞天、Sigma、EagleEye、TDDL 等）
准备 5 个反问题
模拟面试 1-2 次（朋友/AI）
检查简历无虚假信息（背调会扎实查）
提前了解 JD 所在部门业务（阿里云 vs 淘天 vs 本地生活差异大）

九、阿里 BU 速览（对齐岗位）

BU	业务	运维关键词
阿里云智能	公共云 + 专有云	SRE、大规模集群、客户支持
淘天集团	淘宝 + 天猫	双 11、大促、全链路压测
本地生活	饿了么、高德	海量配送调度、LBS
菜鸟	物流	订单履约、仓储 WMS
国际数字商业	Lazada、速卖通	跨境、海外合规、多 Region
大文娱	优酷、UC	音视频高并发
阿里妈妈	广告	实时竞价、超大流量
达摩院 / 通义	AI	GPU 集群、分布式训练、推理

不同 BU 技术栈和运维重点有差异，面试前锁定目标 BU。

十、临场心态

不会的题直说："这个我没做过，但我的思路是……"
思考 5 秒再回答，比抢答更稳
把面试官当同事，不是裁判（你在和他讨论问题）
讲解时画图 / 举例，比纯说好 10 倍
承认局限：没人全知道，资深反而在于"知道自己不知道"
紧张是正常的，深呼吸，专注题目本身

祝你拿下 Offer！

准备充分不如心态从容，心态从容不如积累深厚。本知识库是你的弹药库，但最终打胜仗靠的是你这些年沉淀的能力。加油。