Appearance
06 - 阿里云面试问答集
本章目标：24 问综合演练，覆盖架构选型、运维实战、规划综合三类。每题：标准回答（200+ 字口语段落，结论→原理→我的例子→收尾）+ 追问应答（100+ 字）+ 双云对标提示。全篇诚实口径：阿里云=产品体系了解+移动云对标，真实生产经验在移动云——每题的"我的例子"都落在移动云真实用例上，绝不编造阿里云项目。
第一类：架构与选型（Q1-Q8）
Q1：RDS 和自建 MySQL 怎么选？
水位：【必背】
标准回答：
我选型时算三笔账。第一笔可靠性账：RDS 把主备自动切换、自动备份加 binlog 任意时间点恢复、监控告警这些"平时看不见、出事致命"的能力工程化了，自建团队要么投人力把这套做扎实，要么长期裸奔，多数团队达不到云厂商的切换可靠性。第二笔成本账：RDS 实例费高于同配机器，但自建的隐性成本是人力——备份、监控、切换演练、补丁全是活，摊到中型业务上托管反而划算。第三笔自主性账：需要特殊内核、插件或数据完全自主的强合规场景，自建不可替代。我的实践两边都有：移动云生产用云数据库 MySQL 主备高可用 8C16G/300G，看中的就是托管切换和自动备份，把人力省下来做业务优化；同时我有自建 MySQL 主从、备份脚本、慢查询优化的经验。结论：标准业务托管，特殊场景自建且要为可靠性补课。
追问：RDS 有什么短板？
两个真实短板。一是内核与参数自由度受限，平台只开放部分参数，特殊插件、UDF、自定义存储引擎用不了；二是成本随规模线性上涨，超大规模集群自建的机器成本优势会显现。所以我的口径是"规模和定制需求决定分界线"：中小和中型业务 RDS 全面占优，超大或深度定制场景再评估自建。
Q2：为什么你的项目用自建 K8s 而不用 ACK？
水位：【必背·核心实战】
标准回答：
这是我在移动云项目里真实做过的决策，四个维度论证。成本：三台 2 核 4G master 承载控制面，年成本低于托管控制面费用，我们集群规模小，控制面负载轻，托管费不划算。自主性：客户是政企背景，对平台依赖敏感，证书、组件版本、调度策略完全自持，排障不跨平台提工单。能力建设：项目要求沉淀 K8s 全栈运维能力，自建过程把控制面高可用、etcd 仲裁、证书管理全练了一遍，这套能力可迁移到任何云。风险：自建多出的三大责任——etcd、证书、升级——我都有预案，三副本仲裁加备份、到期台账加轮换演练、测试集群验证升级路径加快照兜底。最终三主三从平稳运行，apiserver 走 CLB 四层统一接入零故障。反过来我也讲得出何时该选托管：规模大、扩缩频繁、要重生态集成时，ACK 的节点池、Terway、SLB 联动能省大量工作——条件决定结论，我对两边工作量分布有真实体感。
追问：自建最大的三个坑？
etcd：三节点奇数仲裁、SSD 盘、定期备份、master 打污点防业务抢占。证书：kubeadm 默认一年期，到期台账加提前轮换演练。版本升级：测试集群先演练路径，生产逐台滚动加快照兜底。这三个坑我全部写进了部署 SOP 和巡检清单，是防在事前。
Q3：SLB 四层和七层怎么选？
水位：【必背】
标准回答：
本质是转发时看得多深。四层在传输层只看 IP 和端口，收到连接原样转发，不解析内容，性能高、协议无关，数据库、MQ、apiserver 这类非 HTTP 服务只能用四层；七层要完成 HTTP 解析才能按域名、路径、Header 转发，还能做 HTTPS 证书统一卸载和会话保持，开销更大但能力更强。阿里云产品线上对应：ALB 专攻七层、NLB 专攻四层高性能、CLB 是传统型四层七层都支持。我的真实用例是移动云 CLB 四层 TCP 做 K8s apiserver 统一接入：三台 master 挂 6443 后端，TCP 健康检查秒级探测、自动摘除故障节点，客户端统一连 VIP 零改动——这个场景不需要内容解析，四层透传就是最优解。如果是多域名多路径的 Web 入口，我会选七层做证书卸载和内容路由。选择标准一句话：非 HTTP 或要裸 TCP 性能选四层，要按业务内容路由选七层。
追问：健康检查配 TCP 还是 HTTP 探测？
TCP 探测只验证端口可建连，兼容一切但防不了进程假死；HTTP 探测要求返回 2xx/3xx，能确认应用逻辑活着。Web 服务配 HTTP 探测并约定健康端点；协议敏感的服务如 apiserver 用 TCP 探测，深度健康交给 K8s 自身探针分层兜底。原则是探测深度与服务能力匹配，探太浅防不住假死，探太深容易误杀。
Q4：OSS 和块存储（云盘）有什么区别？
水位：【必背】
标准回答：
访问形态完全不同。云盘是块存储，挂给单台 ECS 当磁盘，有文件系统，数据库、日志目录这类系统级场景用它，跟着机器走；OSS 是对象存储，不挂盘，应用和用户通过 API 或 HTTP URL 直接读写，Key-Value 形态，容量无限弹性，官方持久性 12 个 9，适合图片视频、静态资源、备份归档这类海量非结构化数据。中间还有 NAS，多机共享目录。选择口诀：要挂盘选云盘，要多机共享选 NAS，要 URL 海量分发选 OSS。OSS 还有个我重点掌握的能力是存储分层：标准、低频、归档、冷归档、深度冷归档五档，越冷越便宜，用生命周期规则按天数自动转换，我在移动云的备份体系用的就是同样的分层思路——近期备份在线可回滚，历史下沉归档控制成本。要注意各档位有最短存储时长，生命周期规则的天数要和它对齐，否则提前转出触发不足时长容量费。
追问：备份放 OSS 还是用快照？
两者互补。快照是磁盘时点副本，恢复整台机器最快，适合变更兜底和整机回滚，但和实例绑定、按盘计费；OSS 备份是文件级，跨实例、跨地域可迁移，适合数据库逻辑备份、配置文件这类需要长期分层保存的数据。我的分层：磁盘层快照兜整机、数据库层托管备份加 binlog、长期归档数据转 OSS 低成本档位。
Q5：安全组和防火墙（iptables/ACL）有什么区别？
水位：【必背】
标准回答：
都是包过滤，但层级和管理面不同。安全组是云平台虚拟化层的分布式实例防火墙：跟实例网卡绑定，与机器生命周期解耦，控制台统一管理，重装系统规则不丢，平台托管有审计；三个关键特性是有状态——入放行则响应回包自动放行、默认拒绝、支持授权另一个安全组。iptables 在实例操作系统内部，规则跟着机器走，重建即丢，我把它只当主机层兜底。网络 ACL 在子网层，无状态、进出各配规则，做子网边界粗防。我的生产姿势是三层纵深：ACL 做子网粗边界（如平台支持）、安全组做主策略——按角色分组加组间授权，master 组只放行 worker 组和负载均衡网段，管理端口收口堡垒机；iptables 留默认拒绝兜底。我在移动云 K8s 集群就是这套落地的，组间授权让机器扩缩容时规则自动跟随组，不用维护 IP 清单，等保检查时安全组规则清单直接出示。
追问：为什么主策略放安全组不放 iptables？
三个理由：管理成本低——有状态特性规则量减半，组间授权不维护 IP 清单；生命周期稳定——机器迁移重建规则跟组走；合规友好——平台托管、变更留痕、可导出清单。策略要有单一事实来源，散在每台机器的 iptables 里，审计和排障都是灾难。
Q6：业务要迁到阿里云，你怎么规划？
水位：【必背·综合】
标准回答：
我按七步走。一调研盘点：资产清单（机器、数据库、中间件、域名证书）、应用依赖拓扑、数据量与增长、停机容忍度，产出迁移方案初稿。二网络规划：目标 VPC 网段不与现有网络重叠、确定混合云期专线或 VPN 打通、出口收敛走 NAT。三选型映射：规格按现有负载水位加余量选（ECS 规格族）、数据库评估上 RDS 还是保持自建、中间件评估托管还是搬运自建。四试点先行：选一个非核心系统全流程走通，验证网络、镜像、数据链路。五数据迁移：用 DTS 做全量加增量迁移，业务低峰停写追平，数据校验后切连接串。六割接：割接手册逐项核对（DNS/负载均衡/客户端配置）、回滚预案预演、割接后监控窗口值守。七复盘优化：水位复核、成本优化（包年包月/存储分层）、文档交接。这套方法论我在移动云项目里实践过完整落地——从资源规划到 K8s 底座搭建到安全配套，七个环节都有真实产出物，迁移工具的差异（DTS 或其他）只是通道替换，流程是通用的。
追问：割接当晚你怎么保障？
割接手册预演过、每项有检查人和回退点；时间线倒排——停写窗口、增量追平、数据校验、切流量、验证清单、观察期；监控大盘提前加带宽和错误率看板；回滚预案明确触发条件——验证项失败即回，不恋战；值守分工明确到人。我的原则：割接最大的风险不是技术，是流程不熟，所以一定要在测试环境全流程走过一遍。
Q7：上云后成本怎么优化？
水位：【理解】
标准回答：
我按四个抓手讲。规格层：上线前压测定规格，避免先买大再降配；上线后看水位——长期低于 30% 的降配，CPU 密集和内存密集业务选对实例族（计算型或内存型）同价拿更多资源。计费层：长期稳定负载包年包月，临时和峰值按量，批任务可用抢占式实例但要无状态；预留折扣类工具按承诺周期评估。存储层：OSS 生命周期自动转冷档位，快照和备份配保留策略防"隐性囤积"，这是最常见的成本黑洞。架构层：静态资源走 CDN 降低源站带宽费，无公网 IP 加 NAT 统一出口，弹性伸缩削峰填谷。我的实践：移动云项目全程预算制，规格是容量评估反推的——master 2C4G、worker 8C16G、监控 4C8G 三档都是按角色画像定的，上线后水位长期 60% 以下说明选型准确，扩容走加节点不升配。成本优化的本质是"让每一分钱对准真实负载"，所以水位监控本身就是成本工具。
追问：怎么向领导汇报成本优化？
给数据不给感觉：分项账单对比（优化前后）、水位曲线佐证规格合理性、单项节省金额汇总、剩余风险说明。我习惯用"动作—依据—结果"三列汇报，比如"worker 规格定为 8C16G—依据容量评估和压测—结果水位 55% 且支撑全年业务增长"，让决策可追溯。
Q8：等保合规在云上怎么满足？
水位：【理解】
标准回答：
等保的核心要求落在云上主要是四块：身份与访问控制——RAM 子账号最小权限、MFA、AK 轮换，权限清单文档化；审计留痕——操作审计覆盖所有控制台和 API 动作、数据库审计覆盖数据访问、日志留存期达标；安全防护——WAF 过应用攻击、DDoS 防护抗流量攻击、主机安全做防病毒漏洞基线、传输和存储加密；备份与应急——备份策略和恢复演练记录、应急预案文档。我的实战：移动云项目二是按这套配套走过的——WAF、DDoS 原生防护、主机安全企业版、数据库审计四件套是我参与采购部署的，权限体系、操作留痕、安全报告是我日常维护的，等保检查时这些直接出示：权限清单、审计报告、漏洞闭环记录、演练记录。阿里云侧产品一一对应：RAM、ActionTrail、WAF、DDoS 防护、云安全中心、数据库审计——产品名不同，检查项的满足逻辑完全同构。
追问：检查前你们怎么准备？
按检查项做自查表：每项对应"证据材料+责任人+现状"，缺口提前补——补配置、补演练、补文档；再跑一轮漏洞扫描和基线核查把高危项闭环。我的经验是等保材料是"平时运营的自然产物"，临时补的痕迹检查人员一眼能看出来，所以我把日常 SOP 和等保要求对齐，检查时就是调档而不是突击。
第二类：运维实战（Q9-Q14）
Q9：K8s 控制面高可用你是怎么做的？（真实用例核心题）
水位：【必背·核心实战】
标准回答：
我的方案是"三 master 仲裁 + 负载均衡统一接入"。移动云项目里三台 2 核 4G 的 master 组成控制面：etcd 三副本奇数仲裁防脑裂，apiserver 每台都跑；接入层用 CLB 四层 TCP 监听创建 VIP，后端挂三台 master 的 6443，开 TCP 健康检查——秒级间隔探测，连续失败自动摘除故障 master，恢复自动回归，客户端（kubectl、集群组件、CI）全部只连 VIP，任何一台 master 故障切换对客户端零感知。配套三件：master 打污点禁业务 Pod，防止控制面资源被抢；etcd 定期备份快照异地存放；系统盘用 SSD 保 etcd 磁盘性能。我还排查过一次健康检查异常：新加 master 转发不通，定位是 CLB 网段到该节点 6443 在安全组没放行，补组间授权即恢复——这让我记住了"健康检查失败先查探测路径的网络授权"。这套方案在阿里云上就是 CLB/NLB 四层加三 master 的同构组合，我可以直接落。
追问：为什么不用 keepalived 虚 IP？
keepalived+VIP 在云上要依赖底层 ARP 和网络模型支持，云平台对 gratuitous ARP 的支持各有限制，配置约束多；云负载均衡是平台原生能力，自带多可用区容灾、健康检查和监控，不占机器、不依赖云下网络行为。我的取舍是"能用平台能力就不自造"，keepalived 方案留给物理环境或纯私有化场景。
Q10：NAT 网关和 SNAT 你怎么用的？
水位：【必背·真实用例】
标准回答：
我的移动云生产环境是出口收敛模式：K8s 集群七台节点全部不绑公网 IP，出公网统一走公网 NAT 网关的 SNAT——NAT 网关绑定一个 EIP，SNAT 条目指定业务子网，拉外部镜像源、系统更新、调第三方 API 全部从这个出口出去。三个好处：安全上机器无公网 IP，外部主动连不进来，攻击面只剩负载均衡 VIP 和堡垒机；管理上出口 IP 唯一，第三方白名单只登记一个 IP，抓包排查链路清晰；成本上一个 EIP 服务整段网段。有个生产细节我会主动讲：实例一旦绑了 EIP，出网优先走 EIP、优先级高于 SNAT 条目——如果某台机器临时绑 EIP，出口 IP 就变了，对有白名单的场景是隐形故障，所以变更流程里"动 EIP"是高风险项。入方向我不走 DNAT 而走负载均衡——SLB 有健康检查和流量分发，DNAT 是点对点映射，后端挂了它不知道。阿里云 NAT 网关的 SNAT/DNAT 模型和这套完全同构。
追问：SNAT 出口带宽怎么规划？
按业务出网峰值评估：拉镜像、更新这类是突发大流量，我按"最大单任务带宽乘以并发任务数"估峰值，配多 EIP 或带宽包分流镜像拉取这类可错峰的流量；同时监控出口带宽水位，接近阈值再扩。另一个技巧是镜像尽量走内网仓库，外网拉取只发生在同步环节，日常运行流量很小。
Q11：Redis 架构怎么选？说说你的实践。
水位：【必背】
标准回答：
阿里云全托管 Redis 现在叫云数据库 Tair 兼容 Redis，三种架构：标准版主备双机热备、集群版多分片水平扩展、读写分离版加副本读扩展。我的纪律是标准主备起步、触顶再升级——中小业务缓存和会话场景，主备热备已是生产级可用性，直接上集群是浪费。我的真实配套：移动云生产用 Redis 主备双机热备，承载缓存和会话，主故障平台自动切换、业务连连接地址无感。我的运维动作四件：内存水位监控防打爆、命中率跟踪防缓存设计失效、连接数异常告警、过期策略巡检防大 key。演进路径我清楚：内存水位长期 70% 以上评估升集群版，托管平台上是变配动作不用数据重建。补充两个生产坑：大 key 拖慢单线程处理要定期扫描拆分，热 key 要本地缓存兜底。这套选型逻辑到阿里云 Tair 直接平移，架构名都一样。
追问：缓存与数据库一致性怎么保证？
缓存旁路模式：读先查缓存未命中回填，写先更新数据库再删除缓存让下次读重建；用删不用改是因为并发写下改缓存易脏数据，删除幂等。兜底靠过期时间，即使同步失败也能过期自愈；强一致场景用延迟双删或订阅 binlog 异步删，但多数业务容忍秒级不一致，不过度设计。
Q12：数据库误删或故障，你的处置流程？
水位：【理解·实战】
标准回答：
五步处置。止损：立即停止写入，能停应用先停，防错误扩散；定位恢复点：从操作审计和 binlog 找到误操作确切时间，决定 PITR 目标；克隆恢复：用全量备份回放 binlog 建临时实例恢复到该时间点，验证数据完整；差异回导：只把误删数据导回生产——不是整库回滚，要保住误删之后产生的正常数据，这步最容易出二次事故，我会导差异 SQL 走变更流程执行；复盘加固：权限最小化、危险语句拦截、操作二次确认。我的底气来自演练：移动云项目里我把备份核对和恢复演练写进季度 SOP，实测恢复耗时作为应急预案的 RTO 数据——没演练过的备份等于没有备份，这句是我的原则。托管数据库的优势在这时体现：平台的全量加 binlog 和克隆实例让 PITR 是控制台动作，自建要走 xtrabackup 加 binlog 手工恢复，流程一样但自动化程度低。
追问：怎么预防误删？
三道防线：权限——生产库删表删库权限独立授权、默认无人持有；流程——危险 DDL 走审批和二次确认，变更脚本先在测试库跑；技术——平台侧开 SQL 拦截规则、备份保留期兜底。预防的本质是把"人犯错"当常态设计系统，而不是指望人不犯错。
Q13：监控体系怎么搭？云监控和自建 Prometheus 什么关系？
水位：【必背】
标准回答：
我按两层设计。资源层用云监控开箱即用：主机 CPU 内存磁盘网络、云产品自身指标、站点拨测，配阈值告警零成本；应用层自建 Prometheus 加 Grafana：接口指标、JVM、中间件状态、K8s 集群指标这些云监控不覆盖的深度。两层互补不替代。我的真实实践：移动云项目里监控独立一台 4 核 8G 节点，Prometheus 抓集群和应用指标，Grafana 出大盘，云平台监控管七台节点水位；规格给到 8G 内存是因为时序数据开销大，而且监控独立部署防"业务故障拖垮监控"互相放大。告警设计三条原则：分级——告警/预警/提示分开，需要人动的才进值班；带上下文——阈值、当前值、初步指引都在告警里；防风暴——聚合抑制，一场故障不能炸出几百条。另外告警要季度复盘修剪，误报调阈值、无行动价值的删掉——告警系统的可信度是运营出来的。阿里云上对应的组合就是云监控加托管 Prometheus 加 Grafana 托管，结构同构。
追问：线上一个接口突然变慢，你的排查路径？
自上而下：监控确认范围——单接口还是全局、什么时间开始、有没有变更关联；应用层看接口耗时分解和错误率、上游依赖（数据库慢查询、Redis 命中率、下游超时）；资源层看节点 CPU 内存 IO 和连接数；变更关联——先问"刚发布或改过配置没有"，大部分突发的慢是变更引起的，回滚快过排障。我的习惯是先把监控证据链拉齐再动手，不在生产上盲改。
Q14：快照、备份、镜像怎么配合使用？
水位：【理解】
标准回答：
三者分工：镜像是造新机的模板，解决批量一致性——我移动云项目里 master/worker 用统一自定义镜像固化容器运行时和内核参数基线，七台机器零漂移；快照是磁盘时点副本，解决变更回滚——重大变更前手动打一个，自动快照策略每日一份保留七份；备份是数据层的持续保护——数据库托管备份加 binlog 做任意时间点恢复，配置文件进 Git。我的分层恢复策略：机器级故障用快照或镜像重建，数据级问题用数据库 PITR，环境级重建用镜像加 Git 加配置管理——基础设施工代码化是最高级的备份，环境随时可重建。两个纪律：快照备份都计费，策略带保留份数定期清理；恢复演练季度执行记录实测 RTO。阿里云上这三样机制完全同构，配合关系也一样。
追问：一台 ECS 系统盘坏了怎么恢复？
先确认数据盘是否完好——数据盘通常独立存活；然后用最近的系统盘快照或原镜像重建系统盘，机器如果整体不可用就从自定义镜像新建实例挂回数据盘；期间用 EIP 或负载均衡把流量切到备机。关键是平时要保证"镜像基线新"——镜像太旧重建出来还要补丁半天，所以我会定期把打补丁后的机器固化成新镜像。
第三类：规划与综合（Q15-Q20）
Q15：移动云和阿里云有什么差异？你怎么看待双云经验？
水位：【必背·身份定位题】
标准回答：
定位上：阿里云是全客群公有云，产品最全生态最成熟；移动云背靠中国移动，优势在属地化——机房下沉地市、云网融合、政企渠道，政务和央企项目落地多。产品上核心同构：虚拟机、负载均衡、VPC、数据库、Redis、容器、监控这些产品能力一致，差异在命名（移动云 CLB 对阿里云 SLB 家族、Nacos 对 MSE）、规格命名风格、控制台交互和计费口径。我的双云经验价值在于：移动云给了我完整的生产实操——K8s 三主三从、CLB 四层 apiserver 接入、NAT SNAT、MySQL 主备、Redis 热备、RocketMQ、Nacos、安全四件套；阿里云我做了逐一对标学习，同构概念秒懂，差异点我能明确指出。所以我的能力锚点是"公有云能力"而非"某一家云"——架构、选型、运维方法可迁移，这也是运维这个岗位真正需要的能力。
追问：让你接手阿里云环境，多久能上手？
我的迁移验证经验是：同构产品当天能做日常操作——控制台逻辑读一遍文档就通；一周内完成变更权限和巡检流程接管——因为巡检清单和 SOP 是云无关的；难点在生态链路的细节差异，比如它的网络插件、日志集成，我会用一两周集中过文档加测试环境实操。我在移动云就是从零把完整生产环境搭起来的，学习迁移能力是被验证过的。
Q16：现有业务迁阿里云，数据库部分怎么迁移？
水位：【理解·流程题】
标准回答：
用 DTS 做全量加增量的无缝迁移，五步：一评估——库表规模、版本字符集兼容、业务停写容忍度、网络链路（专线或公网加密）；二准备——目标 RDS 规格按源库水位加余量，参数模板对齐，账号白名单先配好；三迁移任务——DTS 先结构迁移、再全量、然后自动增量同步源库 binlog 追平；四校验——行数比对加抽样比对，关键表内容级校验；五切换——低峰停写、增量追平确认、应用连接串切到 RDS、观察窗口、释放旧库，停机窗口压到分钟级。两个关键决策点：要不要顺手从自建转 RDS——评估内核参数依赖，没有特殊依赖就转，一步到位拿到托管高可用；要不要 PolarDB——兼容 MySQL 且要读扩展的评估，稳字当头先 RDS。我在移动云虽然不是跨云迁移场景，但全量加增量加校验加切换这套工程方法是通用的，我也清楚 DTS 三种任务类型——迁移一次性、同步长期实时、订阅把 binlog 当消息流。
追问：迁移期间业务停机吗？
增量同步阶段业务正常读写，不停机；真正停写只在最后切换瞬间——停写、等增量追平（秒级到分钟级）、校验、切连接串，窗口可控在分钟级。要提前和业务方谈定这个窗口并演练一次全流程，切换夜就是照剧本执行。
Q17：弹性伸缩 ESS 和 K8s 的 HPA 有什么区别，怎么配合？
水位：【理解】
标准回答：
扩的对象不同：ESS 扩整机 ECS 实例——伸缩组定义最大最小数，伸缩配置定义新机规格镜像，触发规则按定时或 CPU 等指标自动加减机器，新机自动挂负载均衡；HPA 扩 Pod 副本——按 CPU、内存或自定义指标调整 Deployment 副本数。层级是节点层与 Pod 层。配合方式：大流量场景 HPA 先扩副本，节点资源不够时节点层自动扩（ACK 节点池伸缩或 ESS），形成两层弹性。适用判断：ESS 适合无状态、能快速进入服务的 Web/API 层，不适合有状态服务和启动预热慢的应用——实例拉起十分钟才就绪的，弹性就失去意义。我的实践视角：移动云 K8s 底座是固定节点包年包月，业务平稳不需要动态伸缩，这是预算制项目的合理选择；但 ESS 的三件套模型——伸缩组、配置、规则——我对标清楚了，需要时直接落阿里云。我的判断标准一句话：从触发扩容到新实例承接流量要多久，跟不跟得上流量上涨速度。
追问：什么业务不适合弹性伸缩？
有状态服务——数据库、消息队列，扩容要走专门的数据迁移流程不是加机器；预热慢的服务——注册中心、缓存集群，拉起和就绪周期长；强依赖本地数据的计算。这些用提前扩容（定时规则）或容量冗余解决，不硬上动态伸缩。
Q18：云上安全你配过哪些产品？纵深怎么设计的？
水位：【必背·真实配套】
标准回答：
这是我真实采购部署过的部分。移动云项目二的安全四件套：WAF 过七层 Web 攻击——SQL 注入、XSS、CC；DDoS 原生防护抗流量层攻击保入口可用；主机安全企业版管主机内部——防病毒、漏洞检测修复、基线核查、异常登录和 Web 后门检测，全节点装 agent；数据库审计把数据访问操作全部留痕。加身份层的最小权限账号体系和操作层审计，构成完整纵深：流量层保"能通"、应用层管"内容干净"、主机层管"机器内部"、数据层管"访问留痕"、身份层管"谁能操作"。阿里云一一对应：WAF、DDoS 防护、云安全中心、数据库审计、RAM 加 ActionTrail，能力维度同构。我可以讲运营细节：安全告警当日闭环流程、漏洞按等级限期修复、基线定期核查、月度安全报告存档备查——我在等保检查里出过这些材料。我的核心观点：安全产品买了不等于安全，告警处置和漏洞闭环的运营节奏才是价值。
追问：WAF 误杀正常业务怎么处理？
先定位：从 WAF 日志找到命中的规则和请求特征，判断是规则过严还是业务请求确实异常；再处置：自定义白名单放行该特征（要评估绕过风险，白名单尽量收窄到具体参数），或调规则等级；最后跟踪：观察一段时间确认不复发。我强调流程：误杀处理不能一放了之，每次都要记录原因，如果是业务接口设计不规范引起的（比如参数里带 SQL 关键字），推动开发侧一并修正。
Q19：你如何理解"上云"给运维带来的变化？
水位：【理解·开放题】
标准回答：
我有三层体会。工作重心变了：硬件采购、机房、装机这类工作消失，重心转向架构合理性——规格选型、网络规划、高可用设计，以及成本治理和云产品运营，运维从"管机器"变成"管架构和配置"。能力要求变了：手工操作转向代码化和流程化——基础设施即代码、配置进 Git、变更走流水线；同时要懂云产品边界，知道什么交给平台、什么自己扛，比如托管数据库的切换逻辑要理解才能正确监控它。价值定位变了：运维的价值从"保证机器活着"升级为"让系统又稳又省"——稳定性工程（高可用设计、故障演练）和成本水位治理都成了核心产出。我的移动云项目就是缩影：从资源规划文档、K8s 部署 SOP、巡检清单到安全配套运营，全程是"设计先行、配置即代码、留痕可审计"的现代化运维形态。阿里云也好移动云也好，这个趋势是同一个。
追问：云上运维还需要懂底层吗？
更需要但用法变了。懂 Linux 内核参数、网络协议、数据库原理的人，才能判断云产品指标异常的根因——比如知道 fsync 原理才懂为什么 etcd 对磁盘敏感；但重心从"自己搭"变成"能诊断"：不需要天天配 iptables，但要读得懂安全组规则不通时的抓包。我的自建 K8s 经验就是例子：正因为亲手防过 etcd、证书、升级的坑，我才能准确评估托管服务替我省了什么、自己还剩什么责任。
Q20：如果阿里云某产品你没实际用过，面试官深问怎么办？
水位：【必背·兜底话术】
标准回答：
我的标准动作三步：第一步如实定位水位——"这个产品我是体系化了解加对标移动云实操，生产级深度在移动云上"，绝不编造阿里云项目经验，编造会在追问两轮后穿帮，诚实反而建立信任；第二步立刻挂靠同构经验——比如没在生产用过 ALB，但我配过移动云 CLB 四层的监听和健康检查，七层转发的域名路径规则我理解原理，"同类能力我用另一家云真实做过"是有说服力的；第三步展示学习方法——我给个具体例子：OSS 的生命周期转换我是读官方文档学的，学完立刻对齐我移动云备份分层的实际做法，知识就挂住了。然后给出"给我环境我能多快上手"的承诺——我的经验是同构产品几天上手，因为我在移动云从零搭过完整生产环境，学习迁移能力是验证过的。我的简历写"熟悉阿里云核心产品"，我的定义是定位、选型、概念对标的熟悉，这个口径我主动讲清楚，不让面试官来戳破。
追问：为什么不好好把阿里云练熟再说？
练熟的方式我选了"对标学习"而不是"另起炉灶"：在移动云做深生产实操、用阿里云文档做体系对标，一份时间两份收获——如果脱离真实业务环境去刷阿里云控制台，练出来的只是操作熟练度，不是生产能力。我的路径是先在一家云做到生产深度，再用同构思维快速覆盖第二家，这个效率是最高的，而且双云视角本身是差异化优势。
Q21：CLB 健康检查异常，你怎么排查？（真实案例题）
水位：【必背·真实案例】
标准回答：
这是我的真实案例。移动云项目里新扩一台 master 后，CLB 后端状态显示异常、流量不转发。我的排查按探测链路走：第一步看 CLB 侧配置——健康检查协议端口是 6443、探测间隔和阈值都正常，排除配置错误；第二步看服务侧——登上新 master 确认 apiserver 正常监听 6443，本机探测通，排除服务本身；第三步查网络路径——从 CLB 集群网段到节点的访问要经过安全组，对比老 master 的授权发现新 master 没加进"放行 CLB 网段访问 6443"的组间授权规则，补上规则后健康检查立即转绿、流量自动恢复。沉淀两条经验：一是健康检查异常先查"探测路径上的网络授权"再查服务，因为服务本机探测通不代表外部探测通——探测源不同，路径不同；二是扩容节点要把"加入安全组组间授权"写进操作 SOP，我的扩容检查单从此多了这一项。这个案例的通用性在于：四层探测三要素——探测源、路径授权、目标监听——缺一个都是异常，按链路排查几分钟内可定位。
追问：健康检查正常但业务还是不通呢？
继续分层。健康检查只验证端口可达，业务不通可能是应用层问题——apiserver 返回错误、证书问题导致 TLS 握手失败；也可能是连接级问题——老连接还挂在故障节点上，新连接已走健康节点，表现为"部分客户端异常"；再或者客户端配的是直连地址没用 VIP。我的顺序：先看故障范围是全部还是部分客户端，再从客户端侧验证实际走的路径，最后逐层对齐配置。故障范围缩小到哪一层，答案就在哪一层。
Q22：ECS 宿主机故障迁移、变配停机这类平台动作怎么应对？
水位：【理解】
标准回答：
云平台有两类"不以运维意志为转移"的动作要提前设计。一类是故障迁移：宿主机故障时平台对 ECS 做迁移或重启，实例短暂不可用——应对之道是架构上假设"单机随时消失"：多实例加负载均衡、会话集中化、数据不依赖本地盘或可重挂，单机迁移就成了无感事件。我的移动云集群就是按这个假设设计的：三台 worker 反亲和打散，一台故障 Pod 自动漂移重建，apiserver 靠 CLB 摘除故障 master。另一类是主动维护动作：变配、规格调整要停机重启，这是可计划的，走变更窗口加快照兜底。两类动作的管理要点一致：把不确定性收进架构，再订阅平台事件——实例重启、故障迁移事件平台会推送通知，接到事件立即核查服务健康，而不是等用户报障。我在移动云项目的巡检清单里专门有"平台事件核查"一项。云上运维和传统运维最大的差异就在这层认知：平台会替你做很多事，你要做的是让这些事发生时业务无感。
追问：怎么验证架构真的扛得住单机故障？
演练。定期做单机故障演练——挑低峰期主动停止一台 worker 或 master 的服务，观察自动恢复是否符合预期：Pod 是否漂移、CLB 是否摘除、客户端是否无感、恢复耗时多少。演练后记录实测恢复时间，作为架构可用性的证据，写进容量与可用性报告。我的观点：没演练过的高可用只是纸面高可用，建议每季度至少一次，并把演练发现的弱点转化为架构改进项。
Q23：K8s 应用发布流程怎么设计？出问题怎么回滚？
水位：【必背】
标准回答：
标准链路五段。一，CI 构建产出镜像打唯一 tag——应用名版本构建号，禁 latest；二，更新 Deployment 镜像 tag 触发滚动更新；三，readiness 探针门控——新 Pod 就绪才接流量，坏版本天然隔离；四，灰度验证——先小比例流量切新版本，对比错误率和耗时，稳定后放全量；五，观察收尾——发布后监控大盘打标记，关联观察一段时间。回滚设计两点：K8s 保留历史 ReplicaSet，rollout undo 秒级回上一版本；镜像 tag 唯一性保证回滚到的是"确切的旧版本"，同名 tag 覆盖会让回滚变成赌博。参数上 maxSurge 控发布加速、maxUnavailable 控容量下限，配 PodDisruptionBudget 保护滚动期容量。我在移动云集群把这套写成发布 SOP——tag 核对、探针配置核对、回滚命令预置、灰度比例约定都在检查单里，真实发布和回滚都执行过；发布期间还经历过一次消费堆积尖峰，之后把"消费能力核对"加进了发布检查单。这套流程在 ACK 上语义完全一致，K8s 原生机制不因托管而改变。
追问：灰度怎么做最简单有效？
最简方案是双 Deployment 按副本比例灰度：新旧各一个 Deployment，Service selector 加版本标签，先放一个新副本对满量旧副本，验证后逐步调比例；更精细用 Ingress 按 Header 或权重分流，可给测试账号定向导流。我的原则：灰度的目的是用最小爆炸半径发现问题——比例多大不重要，发布前后指标对比能力和秒级回滚能力才重要。灰度发现问题的第一动作是切流量回旧版本，不是线上调试新版本。
Q24：怎么看懂云账单？成本怎么持续管理？
水位：【理解】
标准回答：
成本管理我分三层。第一层看结构：账单按产品分项导出，算清大头——通常是计算实例、存储流量、数据库三类，占比清楚了才知道刀往哪下。第二层对水位：成本合理性的证据是资源水位——CPU、内存、磁盘、带宽的长期曲线；长期低于 30% 的实例进降配评估；磁盘、快照、备份这类持续增长项设保留策略，防"隐性囤积"——这是我见过最普遍的成本黑洞，快照从不清理的账单能悄悄涨一倍。第三层建机制：资源标签体系按项目、环境、负责人打标分账，让每个业务为自己的成本负责；到期台账管包年包月续费；测试环境用完即释放，防闲置资源。我的移动云实践：全程预算制项目，规格按容量评估反推——三档规格上线后水位长期 60% 以下；台账加标签管全部资源，成本账随时拿数据说话。阿里云的成本中心、账单分项、标签分账机制同构，方法直接平移。
追问：怎么把成本讲给业务方听？
用"单价乘以水位"的语言：这台机器一年多少钱、支撑多少业务量、水位多少——三个数一摆，合理还是浪费一目了然。优化建议永远带选项和代价：比如降配省多少钱但峰值水位升到多少、风险是什么，业务方选的是取舍而不是接受结论。我汇报时用趋势图，成本曲线和业务量曲线放一起——成本增长低于业务增长，就是治理有效的直接证据。
压力追问快答包（连环追问应对，每答 30 秒内）
面试官对强项会连环追问。以下 10 个高频快答，答完主动留钩子。
快 1：四层 CLB 下面挂的是 Pod IP 还是节点 IP？
挂节点 IP 加 NodePort 更常见也更稳——Pod 会漂移，四层后端注册 Pod IP 要配合直连模式且 Pod 网络是 VPC 真实地址（Terway）才可行；自建环境我用的就是节点 IP，apiserver 挂三台 master 的 6443。要直挂 Pod 得满足两个条件：CNI 是 Terway 这类 VPC 原生地址、后端服务器组支持自动同步 Pod 状态。
快 2：apiserver 证书里 SAN 没写 VIP 会怎样？
TLS 校验失败，kubectl 报证书错误。SAN 必须包含 VIP、各 master 地址和集群域名——所以 VIP 和证书要在部署前一起规划，事后补 SAN 要重新签发证书并分发到所有客户端。我部署时 SAN 清单是过评审的。
快 3：数据库连接走内网还是外网，为什么？
永远内网：免费、低延迟、不暴露公网面。外网串只在临时导数时短暂开启用完即关。生产出现外网连接串就是审计问题。
快 4：RDS 的主备切换应用要改配置吗？
不用。切换后连接地址指向不变，只是后端主备角色互换，应用用连接地址重连即可——这正是托管高可用的价值。自建主从切换要改应用配置或上 VIP，这就是我选托管的原因之一。
快 5：Redis 热备切换期间会丢数据吗？
会有秒级窗口：主故障到备提升之间的写入可能丢失，取决于同步方式。缓存场景可接受——丢失的数据会从数据库回源重建；要是把 Redis 当强一致存储用，那架构本身就错了。
快 6：你监控大盘必放哪几张图？
五张：集群与节点资源水位、核心接口耗时与错误率、数据库连接数与慢查询、Redis 命中率与内存、消息堆积。每张都配阈值告警，大盘是给人看趋势的，告警才负责叫人。
快 7：安全组和防火墙规则冲突时听谁的？
都要过，取交集：安全组拒绝就到不了主机，主机 iptables 拒绝照样断——排查时两层都要核对。这也是我主张主策略收敛在安全组单一层面的原因：多层规则互相叠加，故障排查是乘法级的复杂度。
快 8：等保检查时你负责出什么材料？
权限清单与最小权限证明、操作审计记录、安全产品报告——WAF 拦截记录、主机安全漏洞闭环、数据库审计报告、备份与恢复演练记录。这些我在移动云项目里是日常维护的，检查时调档不是突击补。
快 9：没实际用过 PolarDB，为什么敢聊？
因为我聊的是架构不是操作：存算分离解决的是 RDS 主备架构的扩展瓶颈——读扩展要搬数据、存储要预分配，这些瓶颈我在主备形态里真实观察过，PolarDB 的设计动机我是从痛点的另一面理解的。我会明确说这是概念级理解，不会假装有生产经验。
快 10：给你一个新项目，第一周做什么？
四件事：需求盘点——业务形态、流量预期、合规要求；架构设计——网络规划、高可用形态、资源清单，出方案文档过评审；基线准备——镜像、安全组模型、监控告警框架；试点——小环境走通全链路再铺开。规划先行是我一贯的纪律，在移动云项目里资源规划和网络规划文档都是部署前定稿的。
快 11：你说经验都在移动云，阿里云的动手经验呢？
诚实回答加证据：个人学习环境我会明确说明，生产操作没有。但我的学习方法有具体产物——双云对标笔记、选型对照表、每个产品的场景化问答，这些都能出示。我更愿意用"我能多快上手"来回答这个问题，而上手速度的证明，是我从零把移动云完整生产环境搭起来的这段经历——学习迁移能力是被验证过的。
快 12：如果面试官问的阿里云产品你完全没听过怎么办？
直说没听过，然后现场推理：请对方给一两个关键词——判断它属于计算、网络还是数据类——用产品族谱定位它大概在哪一层，说出我猜的同类产品，再请对方确认。这个动作展示的是产品体系的框架感：具体产品可以没听过，但地图在我脑子里。诚实加推理，永远比不懂装懂体面，也比沉默加分。
快 13：你平时怎么学云产品？
三个渠道叠加：官方文档按场景读——带着要解决的问题读，比如"内网机器怎么出公网"去读 NAT 网关，比通读产品手册高效；真实环境动手——移动云生产环境加个人学习环境，操作过的知识才是自己的；对标法——每学一个移动云产品就去对齐阿里云的对应产品和文档，差异点记进对标笔记。我的学习循环是"问题→文档→实操→对标→笔记"，闭环到笔记的知识才不会忘。
章末自测（一句话答案）
- 问答集 24 题分哪三类？——架构与选型（Q1-8）、运维实战（Q9-14）、规划与综合（Q15-24）。
- RDS vs 自建的三笔账？——可靠性、成本、自主性。
- 我自建 K8s 的四个论证维度？——成本、自主性、能力建设、风险评估（均有预案）。
- apiserver 高可用我的方案一句话？——三 master 仲裁 + CLB 四层 VIP 健康检查自动摘除，客户端统一连 VIP。
- 出口收敛模式一句话？——机器无公网 IP，NAT SNAT 统一出口，入向只留负载均衡与堡垒机。
- 数据库误删五步？——止损、定位恢复点、克隆恢复、差异回导、复盘加固。
- 监控两层分工？——云监控管资源层开箱即用，Prometheus 管应用与集群深度。
- 迁移五步？——评估、准备、DTS 全量+增量、校验、低峰切换。
- 双云身份定位一句话？——"能力锚点是公有云能力而非某一家云：移动云生产实操+阿里云体系对标"。
- 兜底话术三步？——如实定位水位、挂靠同构经验、展示学习方法并给上手承诺。
参考资料（链接采集时间 2026-10）
本章为问答集，链接与前五章共用知识域；核心官方入口重列如下，均于 2026 年 10 月通过搜索与抓取核实可用。
- 云服务器 ECS 文档首页：https://help.aliyun.com/zh/ecs
- ECS 实例规格选型指导：https://help.aliyun.com/zh/ecs/user-guide/best-practices-for-instance-type-selection
- 负载均衡 SLB 产品家族介绍（CLB/ALB/NLB）：https://help.aliyun.com/zh/slb/product-overview/slb-overview
- CLB 健康检查原理概述：https://help.aliyun.com/zh/slb/classic-load-balancer/user-guide/health-check-overview
- NAT 网关用户指南（SNAT）：https://help.aliyun.com/zh/nat-gateway/user-guide
- 云数据库 RDS 文档总入口：https://help.aliyun.com/zh/rds
- RDS 产品选型（高可用系列/只读实例）：https://help.aliyun.com/zh/rds/product-overview/purchase-guide
- 自建数据库迁移至 RDS MySQL（DTS 教程）：https://help.aliyun.com/zh/rds/apsaradb-rds-for-mysql/step-3-migrate-a-user-created-database-to-an-rds-mysql-instance
- DTS 功能特性：https://help.aliyun.com/zh/dts/product-overview/product-function-node-dts
- 云数据库 Tair（兼容 Redis）标准架构（主备）：https://help.aliyun.com/zh/redis/product-overview/standard-master-replica-instances
- 使用 Terway 网络插件（ACK）：https://help.aliyun.com/zh/ack/ack-managed-and-ack-dedicated/user-guide/work-with-terway
- 什么是容器服务 Serverless 版：https://help.aliyun.com/zh/ack/serverless-kubernetes
- 对象存储 OSS 存储类型：https://help.aliyun.com/oss/user-guide/overview-53
- OSS 生命周期规则概述：https://help.aliyun.com/oss/user-guide/overview-54
- 云安全中心功能（版本对比）：https://help.aliyun.com/zh/security-center/functions-and-features
- 数据库审计：https://help.aliyun.com/zh/dsc/database-audit
- 云监控 CMS 产品文档：https://help.aliyun.com/zh/cloudmonitor
- 操作审计 ActionTrail 产品概述：https://help.aliyun.com/zh/actiontrail/product-overview
- 弹性伸缩 ESS 产品概述：https://help.aliyun.com/zh/auto-scaling/product-overview/what-is-auto-scaling
- 访问控制 RAM 产品文档：https://help.aliyun.com/zh/ram