简介面向准备互联网大厂技术面试的求职者与在校生这份文档以对话形式复现了阿里巴巴技术面试的真实场景对Java方向候选人尤具参考价值。作者从自我介绍、论文项目讲解、简历项目复盘等环节切入详细记录了一面技术面的完整问答过程并穿插面试官的提问思路与阶段总结内容涉及JVM运行时数据区、类加载机制与双亲委派模型、GC内存分配与分代回收、HashMap/Hashtable、ArrayList/LinkedList、JUC并发包等高频考点。压缩包内共1个docx文档约21KB体积轻巧下载后可直接阅读。目前已有1159人学习下载。读者可借此了解阿里面试的真实节奏、回答组织方式与追问方向对照自身知识盲区查漏补缺也可作为模拟面试与面试复盘的自学素材适合有一定基础、目标Java开发或运维岗位的中高级求职者。1. 阿里运维工程师面试真正筛的是故障推进路径很多人把「阿里运维工程师面试.docx」理解成一份题库把两百道题背熟面试时把关键词吐出来就行。真正被刷掉的往往不是知识量而是故障推进路径。面试官问「ECS 上的服务突然 502」他想听的是你从 SLB 后端健康检查、安全组规则、ECS 内网带宽一路收敛到应用进程和连接数的过程而不是你从头背一遍 Nginx 配置项。运维工程师这个岗位在面试里的分水岭是能不能把「现象」翻译成一组可执行的验证动作再用命令逐条排除。这份 .docx 里如果只记结论面试时一追问「你怎么确认的」就露底如果记的是命令加判读标准追问反而变成加分项。下面的内容按 Linux 基本功、阿里云 ECS 与网络链路、容器与 K8s 场景题三条主线展开每个点都落到能当场敲出来的命令和能当场报出来的阈值上。2. 阿里运维工程师面试的 Linux 与软件源基本功2.1 负载、内存、磁盘这三组数为什么总被先问初级运维工程师面试题里出现频率最高的组合就是uptime、free、df、top。面试官不是想看你记得几个命令而是想确认你对「正常」有没有量化概念。负载要看的是它和 CPU 核数的比值8 核机器上 15 分钟均值 4 属于健康堆到 20 就要查是谁在跑满。内存要看的不是free而是available因为 page cache 占掉的部分是可回收的盯着free会得出错误结论。磁盘除了容量还要看%util和await容量没满但 IO 打满同样会把接口拖到超时。观察对象命令关键字段判读参考系统负载uptime、cat /proc/loadavg1/5/15 分钟均值持续超过核数 1.5 倍需介入内存free -havailable、swap 读写available 低于 10% 且 swap 有持续读写磁盘 IOiostat -x 1%util、await%util 长期高于 80%await 高于 20ms进程热点top -H -p PID线程级 CPU 占用定位到线程号后接jstack看栈2.2 一条巡检命令把五类指标一次性打出来面试时被要求「现场写个巡检脚本」很常见重点是结构清晰、有阈值判断、不依赖额外安装包。#!/bin/bash # ECS 上通用巡检负载 / 内存 / 磁盘 / 连接 / OOM 记录 set -uo pipefail echo 负载对比核数 $(nproc) awk {print 1min$1 5min$2 15min$3} /proc/loadavg echo 内存 free -m | awk /Mem:/{printf total%sM used%sM avail%sM\n,$2,$3,$7} echo 磁盘使用率超过 80% 的分区 df -hP | awk NR1 int($5)80 {print $6, $5} echo 监听端口与连接数 ss -lntp | awk NR1{print $4, $6} | head -20 echo 近 30 条 OOM / 硬件报错 dmesg -T 2/dev/null | grep -iE oom|killed process | tail -30脚本里的阈值判断是最容易得分的地方int($5)80这种写法面试官一眼能看懂你的意图。ss -lntp比netstat快且在新发行版上默认就有-l只看监听、-n不做 DNS 解析、-t限 TCP、-p带进程名。dmesg -T把内核时间戳转成可读时间OOM killer 的记录是内存类问题最硬的证据很多人排查半天内存泄漏其实内核早就把进程杀掉并留了记录。2.3 yum 与 pip 源换成阿里云内网交付的固定动作面试里问「新机器交付第一步做什么」答「换源、校准时间、配监控」比答「装 JDK」更接近岗位实际。CentOS Stream 9 换阿里云镜像源的常见做法是先备份再覆盖避免残留多个源互相打架。# 备份原有源避免和阿里源重复定义同一仓库 mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak/ 2/dev/null # 写入阿里云镜像源 cat /etc/yum.repos.d/aliyun.repo EOF [baseos] nameCentOS Stream $releasever - BaseOS baseurlhttps://mirrors.aliyun.com/centos-stream/$releasever-stream/BaseOS/$basearch/os/ gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/centos-stream/RPM-GPG-KEY-CentOS-Official enabled1 [appstream] nameCentOS Stream $releasever - AppStream baseurlhttps://mirrors.aliyun.com/centos-stream/$releasever-stream/AppStream/$basearch/os/ gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/centos-stream/RPM-GPG-KEY-CentOS-Official enabled1 EOF dnf clean all dnf makecache # 清缓存并重建元数据Python 服务的机器上还要配 pip 阿里源pip config set会把配置写进用户级配置文件比每次命令行拼-i参数更省事。Java 系服务同时会被追问 maven 配置阿里云仓库本质一样改settings.xml的mirror段把mirrorOf设为central或*让所有中央仓库请求走镜像私服场景下要写成*,!internal-repo把内网仓库排除掉否则私有依赖会解析失败。3. 阿里云 ECS、SLB 与证书面试追问最密集的一段3.1 ECS 规格族怎么选安全组和 SLB 怎么串起来阿里云服务器配置类问题基本围绕规格族、安全组、SLB 三件套展开。通用型 g 系列 CPU 内存比 1:4适合大多数业务计算型 c 系列 1:2适合编译、转码、压测施压机内存型 r 系列 1:8适合缓存和数据库。突发性能型 t 系列有 CPU 积分限制用它做持续高负载的服务积分耗尽后性能会被压到基准线以下这是面试里很容易被追问的一个坑。组件常见故障现象第一手排查入口安全组内网能通、公网不通入方向规则、规则优先级数字小优先SLB部分请求 502/504后端服务器健康状态、权重、超时时间ECS服务自己重启或被杀云监控 CPU/内存曲线、dmesg的 OOM 记录带宽高峰期接口慢但不报错公网出带宽是否被限速打满安全组的规则是白名单模型默认拒绝所有入方向流量很多人排障时忘记这一点在机器上折腾半天防火墙结果流量根本没到机器。排查顺序建议是先确认流量有没有到 ECS 网卡再确认进程有没有监听最后才看应用日志。3.2 用 aliyun CLI 把「ECS 上服务打不开」拆成四步验证面试官很喜欢让你「别登机器用命令行确认状态」。阿里云 CLI 是绕不开的工具凭据用 RAM 子账号而不是主账号这本身就是安全意识的加分点。# 1) 凭据配置使用 RAM 子账号的 AK/SK单独一份 profile aliyun configure --profile interview # 2) 实例状态、内网与公网 IP、绑定的安全组 aliyun ecs DescribeInstances \ --RegionId cn-hangzhou \ --InstanceIds [i-bp1example] \ --profile interview # 3) 安全组到底放通了哪些端口源地址范围是否写错 aliyun ecs DescribeSecurityGroupAttribute \ --RegionId cn-hangzhou \ --SecurityGroupId sg-bp1example \ --profile interview # 4) SLB 后端服务器健康状态确认是不是被摘除 aliyun slb DescribeHealthStatus \ --RegionId cn-hangzhou \ --LoadBalancerId lb-bp1example \ --profile interview四步的顺序对应四层可能性实例本身挂了、网络层被拦、转发层摘了后端、应用层自己出错。--InstanceIds接受 JSON 数组格式多个实例要写成[i-1,i-2]单引号不能省否则 shell 会把方括号吃掉。生产环境我一般还会加一个判断如果DescribeHealthStatus显示后端是abnormal说明 TCP 探测没通问题在安全组或进程如果显示normal但用户仍报错那就要往应用层和应用日志走。3.3 阿里云 SSL 证书续期与 OSS 403 的答法证书类问题现在几乎必问尤其是「怎么提前发现证书快过期」。不要等控制台告警直接在边缘节点上探一次拿到真实的到期时间这个命令几十秒就能跑完。# 取线上证书的颁发对象与有效期面试里可直接演示 echo | openssl s_client -connect www.example.com:443 \ -servername www.example.com 2/dev/null \ | openssl x509 -noout -subject -issuer -dates-servername必须带它对应 SNI缺了会拿到默认站点的证书结果完全错位。-dates输出notBefore和notAfter把notAfter换算成剩余天数写进监控告警就行。如果证书部署在 SLB 或 CDN 上续期后要确认新证书已经绑定到对应监听只上传不绑定是最常见的低级失误。OSS 的 403 排障思路是三层账号层看 RAM 策略有没有给oss:GetObjectBucket 层看读写权限和防盗链 Referer 白名单对象层看签名 URL 的过期时间。内网机器访问 OSS 记得走内网 Endpoint 而不是公网地址否则流量绕一圈还可能产生额外费用。4. 单节点 K8s 上若依微服务迁移到阿里云 ECS 的场景题4.1 从 docker 到 kubectl容器排错的命令顺序「单节点 k8s 上跑着若依微服务整套环境」这类场景题考的是你有没有真在集群里排过错。若依微服务版通常包含网关、认证、系统模块加 Nacos、MySQL、Redis单节点集群下资源争抢是常态回答时先把资源视角摆出来。# 1) 先看 Pod 状态和重启次数CrashLoopBackOff 和 Pending 是两类问题 kubectl get pods -n ruoyi -o wide # 2) Pending 看调度原因常见是节点资源不足或 PVC 没绑定 kubectl describe pod ruoyi-gateway-xxxx -n ruoyi | tail -30 # 3) 运行中但报错直接看日志和上一次崩溃的日志 kubectl logs deploy/ruoyi-auth -n ruoyi --tail200 kubectl logs deploy/ruoyi-auth -n ruoyi --previous # 4) 确认是不是被内存限制压死 kubectl top pod -n ruoyi kubectl get events -n ruoyi --sort-by.lastTimestamp | tail -20--previous是最容易被忽略的参数容器反复重启时当前日志可能只有几行启动信息真正的异常在上一次的日志里。kubectl get events按时间排序能一次性看到 OOMKilled、探针失败、镜像拉取失败这些关键事件。若依这类 Java 微服务还要注意 JVM 堆要和容器的resources.limits.memory对齐堆设得比 limit 大进程会被内核直接杀掉表现就是 Pod 莫名其妙重启。4.2 准不停服、不丢数据迁移步骤怎么讲才落地迁移类问题是中高级岗位的分水岭回答要落到「什么阶段允许写、什么阶段切换读」。核心思路是把迁移拆成同步和切换两段同步阶段新旧环境并存切换阶段只做流量指向变更。阶段动作数据一致性手段准备阿里云 ECS 规格与 VPC 规划镜像推到 ACR不改动源环境同步数据库全量加增量同步到云上 RDS源库保持可写增量追平预演云上起全套服务跑通内部接口用只读账号连库验证切换SLB 权重或 DNS 逐步切流源库短暂停写确认延迟归零后切回退保留原环境至少一个观察周期反向同步脚本预先写好把「不丢数据」讲清楚的关键是切换前的短暂停写窗口这一步要说得出停多久、怎么确认增量已经追平。镜像仓库用 ACR 私有实例ECS 拉取走 VPC 内网地址能同时解决速度和流量费用两个问题。4.3 用 jmeter 压测结果回答「云上能扛多少」迁移完成后由压测同学用 jmeter 脚本施压验证云上承载能力这是面试里很好的收尾素材因为它能把你的排查能力和容量判断串起来。看压测报告不要只报 TPS 峰值要报三个数的组合。指标含义需要同步看的云监控项TPS每秒成功事务数SLB 的 QPS 与活跃连接数P95/P99长尾延迟ECS CPU 使用率与平均负载错误率失败请求占比应用日志中的超时与连接拒绝P95 明显高于平均值说明有少量请求在排队这时候要看线程池大小和数据库连接池上限而不是简单加机器。错误率随并发上升而抬升优先怀疑连接数被打满去看 ECS 的ss -s和 RDS 的连接数监控。把这些数据和你的排障结论对上比背一堆压测术语更能说明你真的做过容量评估。5. 面试前一周的可复现演练把答案跑一遍再背5.1 用七天时间把 .docx 题库变成可执行清单把整理好的面试题文档按「命令类、判断类、场景类」重新分类比按产品分类更接近面试节奏。前两天专攻 Linux 与网络把第 2 章那段巡检脚本在自己机器上跑通并且故意制造一次 OOM 看内核记录长什么样第三、四天攻阿里云产品用 CLI 把实例、安全组、SLB 健康状态各查一遍把返回字段和文档对上第五天攻容器本地起一个单节点集群把kubectl logs --previous和get events用熟第六天做场景题口述把第 4 章那张迁移表格不看稿讲一遍控制在三分钟内。5.2 一个能套住大部分场景题的答题模板场景题的回答结构固定成五段几乎不会跑偏现象描述、影响面评估、分层定位、根因确认、止血加长期修复。每一段都要带一个可验证的动作比如「先确认影响面」这一句后面接的是查 SLB 后端健康状态还是查云监控的请求数曲线。面试官追问「你怎么知道是这个问题」时回答里必须有命令和返回结果而不是「经验上一般是这样」。这个模板配合前面章节里的具体命令能把大部分追问接住。5.3 把阈值写进告警模板排障能力之外面试里越来越看重「怎么提前发现」。与其临场编不如提前把阈值定好CPU 5 分钟均值超过 80% 持续 5 分钟、磁盘使用率超过 85%、证书剩余有效期少于 30 天、SLB 后端异常数大于 0、RDS 连接数超过最大连接数的 70%。这几条配好通知渠道被问到监控体系时直接报数字和触发条件比描述「我们有完善的监控」有说服力得多。本文还有配套的精品资源点击获取 阿里云运维面试：故障推进路径与ECS/K8s实战
简介面向准备互联网大厂技术面试的求职者与在校生这份文档以对话形式复现了阿里巴巴技术面试的真实场景对Java方向候选人尤具参考价值。作者从自我介绍、论文项目讲解、简历项目复盘等环节切入详细记录了一面技术面的完整问答过程并穿插面试官的提问思路与阶段总结内容涉及JVM运行时数据区、类加载机制与双亲委派模型、GC内存分配与分代回收、HashMap/Hashtable、ArrayList/LinkedList、JUC并发包等高频考点。压缩包内共1个docx文档约21KB体积轻巧下载后可直接阅读。目前已有1159人学习下载。读者可借此了解阿里面试的真实节奏、回答组织方式与追问方向对照自身知识盲区查漏补缺也可作为模拟面试与面试复盘的自学素材适合有一定基础、目标Java开发或运维岗位的中高级求职者。1. 阿里运维工程师面试真正筛的是故障推进路径很多人把「阿里运维工程师面试.docx」理解成一份题库把两百道题背熟面试时把关键词吐出来就行。真正被刷掉的往往不是知识量而是故障推进路径。面试官问「ECS 上的服务突然 502」他想听的是你从 SLB 后端健康检查、安全组规则、ECS 内网带宽一路收敛到应用进程和连接数的过程而不是你从头背一遍 Nginx 配置项。运维工程师这个岗位在面试里的分水岭是能不能把「现象」翻译成一组可执行的验证动作再用命令逐条排除。这份 .docx 里如果只记结论面试时一追问「你怎么确认的」就露底如果记的是命令加判读标准追问反而变成加分项。下面的内容按 Linux 基本功、阿里云 ECS 与网络链路、容器与 K8s 场景题三条主线展开每个点都落到能当场敲出来的命令和能当场报出来的阈值上。2. 阿里运维工程师面试的 Linux 与软件源基本功2.1 负载、内存、磁盘这三组数为什么总被先问初级运维工程师面试题里出现频率最高的组合就是uptime、free、df、top。面试官不是想看你记得几个命令而是想确认你对「正常」有没有量化概念。负载要看的是它和 CPU 核数的比值8 核机器上 15 分钟均值 4 属于健康堆到 20 就要查是谁在跑满。内存要看的不是free而是available因为 page cache 占掉的部分是可回收的盯着free会得出错误结论。磁盘除了容量还要看%util和await容量没满但 IO 打满同样会把接口拖到超时。观察对象命令关键字段判读参考系统负载uptime、cat /proc/loadavg1/5/15 分钟均值持续超过核数 1.5 倍需介入内存free -havailable、swap 读写available 低于 10% 且 swap 有持续读写磁盘 IOiostat -x 1%util、await%util 长期高于 80%await 高于 20ms进程热点top -H -p PID线程级 CPU 占用定位到线程号后接jstack看栈2.2 一条巡检命令把五类指标一次性打出来面试时被要求「现场写个巡检脚本」很常见重点是结构清晰、有阈值判断、不依赖额外安装包。#!/bin/bash # ECS 上通用巡检负载 / 内存 / 磁盘 / 连接 / OOM 记录 set -uo pipefail echo 负载对比核数 $(nproc) awk {print 1min$1 5min$2 15min$3} /proc/loadavg echo 内存 free -m | awk /Mem:/{printf total%sM used%sM avail%sM\n,$2,$3,$7} echo 磁盘使用率超过 80% 的分区 df -hP | awk NR1 int($5)80 {print $6, $5} echo 监听端口与连接数 ss -lntp | awk NR1{print $4, $6} | head -20 echo 近 30 条 OOM / 硬件报错 dmesg -T 2/dev/null | grep -iE oom|killed process | tail -30脚本里的阈值判断是最容易得分的地方int($5)80这种写法面试官一眼能看懂你的意图。ss -lntp比netstat快且在新发行版上默认就有-l只看监听、-n不做 DNS 解析、-t限 TCP、-p带进程名。dmesg -T把内核时间戳转成可读时间OOM killer 的记录是内存类问题最硬的证据很多人排查半天内存泄漏其实内核早就把进程杀掉并留了记录。2.3 yum 与 pip 源换成阿里云内网交付的固定动作面试里问「新机器交付第一步做什么」答「换源、校准时间、配监控」比答「装 JDK」更接近岗位实际。CentOS Stream 9 换阿里云镜像源的常见做法是先备份再覆盖避免残留多个源互相打架。# 备份原有源避免和阿里源重复定义同一仓库 mkdir -p /etc/yum.repos.d/bak mv /etc/yum.repos.d/*.repo /etc/yum.repos.d/bak/ 2/dev/null # 写入阿里云镜像源 cat /etc/yum.repos.d/aliyun.repo EOF [baseos] nameCentOS Stream $releasever - BaseOS baseurlhttps://mirrors.aliyun.com/centos-stream/$releasever-stream/BaseOS/$basearch/os/ gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/centos-stream/RPM-GPG-KEY-CentOS-Official enabled1 [appstream] nameCentOS Stream $releasever - AppStream baseurlhttps://mirrors.aliyun.com/centos-stream/$releasever-stream/AppStream/$basearch/os/ gpgcheck1 gpgkeyhttps://mirrors.aliyun.com/centos-stream/RPM-GPG-KEY-CentOS-Official enabled1 EOF dnf clean all dnf makecache # 清缓存并重建元数据Python 服务的机器上还要配 pip 阿里源pip config set会把配置写进用户级配置文件比每次命令行拼-i参数更省事。Java 系服务同时会被追问 maven 配置阿里云仓库本质一样改settings.xml的mirror段把mirrorOf设为central或*让所有中央仓库请求走镜像私服场景下要写成*,!internal-repo把内网仓库排除掉否则私有依赖会解析失败。3. 阿里云 ECS、SLB 与证书面试追问最密集的一段3.1 ECS 规格族怎么选安全组和 SLB 怎么串起来阿里云服务器配置类问题基本围绕规格族、安全组、SLB 三件套展开。通用型 g 系列 CPU 内存比 1:4适合大多数业务计算型 c 系列 1:2适合编译、转码、压测施压机内存型 r 系列 1:8适合缓存和数据库。突发性能型 t 系列有 CPU 积分限制用它做持续高负载的服务积分耗尽后性能会被压到基准线以下这是面试里很容易被追问的一个坑。组件常见故障现象第一手排查入口安全组内网能通、公网不通入方向规则、规则优先级数字小优先SLB部分请求 502/504后端服务器健康状态、权重、超时时间ECS服务自己重启或被杀云监控 CPU/内存曲线、dmesg的 OOM 记录带宽高峰期接口慢但不报错公网出带宽是否被限速打满安全组的规则是白名单模型默认拒绝所有入方向流量很多人排障时忘记这一点在机器上折腾半天防火墙结果流量根本没到机器。排查顺序建议是先确认流量有没有到 ECS 网卡再确认进程有没有监听最后才看应用日志。3.2 用 aliyun CLI 把「ECS 上服务打不开」拆成四步验证面试官很喜欢让你「别登机器用命令行确认状态」。阿里云 CLI 是绕不开的工具凭据用 RAM 子账号而不是主账号这本身就是安全意识的加分点。# 1) 凭据配置使用 RAM 子账号的 AK/SK单独一份 profile aliyun configure --profile interview # 2) 实例状态、内网与公网 IP、绑定的安全组 aliyun ecs DescribeInstances \ --RegionId cn-hangzhou \ --InstanceIds [i-bp1example] \ --profile interview # 3) 安全组到底放通了哪些端口源地址范围是否写错 aliyun ecs DescribeSecurityGroupAttribute \ --RegionId cn-hangzhou \ --SecurityGroupId sg-bp1example \ --profile interview # 4) SLB 后端服务器健康状态确认是不是被摘除 aliyun slb DescribeHealthStatus \ --RegionId cn-hangzhou \ --LoadBalancerId lb-bp1example \ --profile interview四步的顺序对应四层可能性实例本身挂了、网络层被拦、转发层摘了后端、应用层自己出错。--InstanceIds接受 JSON 数组格式多个实例要写成[i-1,i-2]单引号不能省否则 shell 会把方括号吃掉。生产环境我一般还会加一个判断如果DescribeHealthStatus显示后端是abnormal说明 TCP 探测没通问题在安全组或进程如果显示normal但用户仍报错那就要往应用层和应用日志走。3.3 阿里云 SSL 证书续期与 OSS 403 的答法证书类问题现在几乎必问尤其是「怎么提前发现证书快过期」。不要等控制台告警直接在边缘节点上探一次拿到真实的到期时间这个命令几十秒就能跑完。# 取线上证书的颁发对象与有效期面试里可直接演示 echo | openssl s_client -connect www.example.com:443 \ -servername www.example.com 2/dev/null \ | openssl x509 -noout -subject -issuer -dates-servername必须带它对应 SNI缺了会拿到默认站点的证书结果完全错位。-dates输出notBefore和notAfter把notAfter换算成剩余天数写进监控告警就行。如果证书部署在 SLB 或 CDN 上续期后要确认新证书已经绑定到对应监听只上传不绑定是最常见的低级失误。OSS 的 403 排障思路是三层账号层看 RAM 策略有没有给oss:GetObjectBucket 层看读写权限和防盗链 Referer 白名单对象层看签名 URL 的过期时间。内网机器访问 OSS 记得走内网 Endpoint 而不是公网地址否则流量绕一圈还可能产生额外费用。4. 单节点 K8s 上若依微服务迁移到阿里云 ECS 的场景题4.1 从 docker 到 kubectl容器排错的命令顺序「单节点 k8s 上跑着若依微服务整套环境」这类场景题考的是你有没有真在集群里排过错。若依微服务版通常包含网关、认证、系统模块加 Nacos、MySQL、Redis单节点集群下资源争抢是常态回答时先把资源视角摆出来。# 1) 先看 Pod 状态和重启次数CrashLoopBackOff 和 Pending 是两类问题 kubectl get pods -n ruoyi -o wide # 2) Pending 看调度原因常见是节点资源不足或 PVC 没绑定 kubectl describe pod ruoyi-gateway-xxxx -n ruoyi | tail -30 # 3) 运行中但报错直接看日志和上一次崩溃的日志 kubectl logs deploy/ruoyi-auth -n ruoyi --tail200 kubectl logs deploy/ruoyi-auth -n ruoyi --previous # 4) 确认是不是被内存限制压死 kubectl top pod -n ruoyi kubectl get events -n ruoyi --sort-by.lastTimestamp | tail -20--previous是最容易被忽略的参数容器反复重启时当前日志可能只有几行启动信息真正的异常在上一次的日志里。kubectl get events按时间排序能一次性看到 OOMKilled、探针失败、镜像拉取失败这些关键事件。若依这类 Java 微服务还要注意 JVM 堆要和容器的resources.limits.memory对齐堆设得比 limit 大进程会被内核直接杀掉表现就是 Pod 莫名其妙重启。4.2 准不停服、不丢数据迁移步骤怎么讲才落地迁移类问题是中高级岗位的分水岭回答要落到「什么阶段允许写、什么阶段切换读」。核心思路是把迁移拆成同步和切换两段同步阶段新旧环境并存切换阶段只做流量指向变更。阶段动作数据一致性手段准备阿里云 ECS 规格与 VPC 规划镜像推到 ACR不改动源环境同步数据库全量加增量同步到云上 RDS源库保持可写增量追平预演云上起全套服务跑通内部接口用只读账号连库验证切换SLB 权重或 DNS 逐步切流源库短暂停写确认延迟归零后切回退保留原环境至少一个观察周期反向同步脚本预先写好把「不丢数据」讲清楚的关键是切换前的短暂停写窗口这一步要说得出停多久、怎么确认增量已经追平。镜像仓库用 ACR 私有实例ECS 拉取走 VPC 内网地址能同时解决速度和流量费用两个问题。4.3 用 jmeter 压测结果回答「云上能扛多少」迁移完成后由压测同学用 jmeter 脚本施压验证云上承载能力这是面试里很好的收尾素材因为它能把你的排查能力和容量判断串起来。看压测报告不要只报 TPS 峰值要报三个数的组合。指标含义需要同步看的云监控项TPS每秒成功事务数SLB 的 QPS 与活跃连接数P95/P99长尾延迟ECS CPU 使用率与平均负载错误率失败请求占比应用日志中的超时与连接拒绝P95 明显高于平均值说明有少量请求在排队这时候要看线程池大小和数据库连接池上限而不是简单加机器。错误率随并发上升而抬升优先怀疑连接数被打满去看 ECS 的ss -s和 RDS 的连接数监控。把这些数据和你的排障结论对上比背一堆压测术语更能说明你真的做过容量评估。5. 面试前一周的可复现演练把答案跑一遍再背5.1 用七天时间把 .docx 题库变成可执行清单把整理好的面试题文档按「命令类、判断类、场景类」重新分类比按产品分类更接近面试节奏。前两天专攻 Linux 与网络把第 2 章那段巡检脚本在自己机器上跑通并且故意制造一次 OOM 看内核记录长什么样第三、四天攻阿里云产品用 CLI 把实例、安全组、SLB 健康状态各查一遍把返回字段和文档对上第五天攻容器本地起一个单节点集群把kubectl logs --previous和get events用熟第六天做场景题口述把第 4 章那张迁移表格不看稿讲一遍控制在三分钟内。5.2 一个能套住大部分场景题的答题模板场景题的回答结构固定成五段几乎不会跑偏现象描述、影响面评估、分层定位、根因确认、止血加长期修复。每一段都要带一个可验证的动作比如「先确认影响面」这一句后面接的是查 SLB 后端健康状态还是查云监控的请求数曲线。面试官追问「你怎么知道是这个问题」时回答里必须有命令和返回结果而不是「经验上一般是这样」。这个模板配合前面章节里的具体命令能把大部分追问接住。5.3 把阈值写进告警模板排障能力之外面试里越来越看重「怎么提前发现」。与其临场编不如提前把阈值定好CPU 5 分钟均值超过 80% 持续 5 分钟、磁盘使用率超过 85%、证书剩余有效期少于 30 天、SLB 后端异常数大于 0、RDS 连接数超过最大连接数的 70%。这几条配好通知渠道被问到监控体系时直接报数字和触发条件比描述「我们有完善的监控」有说服力得多。本文还有配套的精品资源点击获取