云架构、可靠性与灾难恢复¶

云 IAM 中 human identity 与 workload identity 应如何分离？¶

技术说明

在云 IAM¹ 中，human identity 应由企业 IdP² 联邦进入云平台，通过 SSO³、MFA⁴、条件访问和短期会话获得角色；workload identity⁵ 则由实例、容器、函数或 CI 的可验证身份换取短期凭证。两者不能共用长期 access key，也不应让机器人模拟个人用户。授权策略围绕角色和资源属性建立，认证、会话签发、权限评估及资源策略各自留审计。

工作负载联邦需校验 issuer、subject、audience、仓库/分支、集群/ServiceAccount 等 claims，信任策略过宽会让其他租户换到同一角色。凭证有效期短不能弥补权限过大；仍需最小权限、来源限制和紧急吊销。人类生产写权限采用按需提升并绑定工单，日常为只读。

实践经验

复合场景中，多个 CI 项目共享一对长期云密钥，其中一个公共构建日志泄露后无法判断哪些任务使用过。止血是吊销密钥、冻结高风险角色并从云审计追踪操作；长期改 OIDC⁶ 联邦，每个仓库/环境独立 subject 条件和短期角色。联邦初期会因 claim 配置错误阻塞发布，需要预生产契约测试和只读诊断工具。

面试回答要点

如何设计云组织、账号/订阅与治理边界？¶

技术说明

组织层应把身份、安全、日志、网络、共享服务与业务工作负载划分到不同管理单元和账号/订阅，生产与非生产隔离。账号是 IAM、配额、账单与故障半径的重要边界，但不是网络自动隔离承诺；仍需显式路由和策略。组织策略/SCP/management policy 等用于限制成员账号可做的最大权限，不能授予本身不存在的权限。

landing zone 提供基线：联邦身份、集中审计、配置检测、KMS、预算、标准网络与应急访问。策略上线先检测再强制，并保留不会依赖成员账号的 break-glass。账号 vending/offboarding 自动化要登记 owner、数据分类、区域、成本中心和生命周期，避免“孤儿账号”成为隐蔽攻击面。

实践经验

复合场景中，所有业务共用一个生产账号，一次配额耗尽和 IAM 误配同时影响无关团队。证据显示 API 限额与管理员角色均无工作负载边界。止血是保护关键资源、临时分配配额；长期按业务/环境拆账号，集中日志与网络但分散执行角色。拆账号增加跨账号网络、观测和成本分摊复杂度，需要平台化支持。

面试回答要点

break-glass 管理员账号如何做到“可用但不可日常使用”？¶

技术说明

break-glass 用于 IdP、联邦或自动化故障时恢复控制，应与日常身份完全分离，拥有有限数量的云原生紧急账号/角色。凭证放在双人控制的安全保管系统，强 MFA、无 API 长期密钥，使用即触发独立通道告警。权限可以很高，但会话时间、来源网络和可执行范围尽可能限制。

可用性必须通过定期演练证明，包括 IdP 不可用、日志平台不可用和人员轮换场景；演练后立即轮换并审计。紧急过程要求事件号、双人批准、屏幕/命令记录、事后复盘。不要把 break-glass 本身依赖在同一故障域的 SSO、密码库或邮件，否则真正事故时无法取用。

实践经验

复合场景中，企业 IdP 故障后团队发现紧急账号 MFA 设备已随前员工离开，恢复延迟。止血通过供应商受控恢复流程重新建立所有权；长期配置两套独立保管的硬件因子、季度演练和人员变更检查。增加保管副本提升可用性也扩大盗用面，因此采用双人解封和即时告警平衡。

面试回答要点

VPC/VNet 中子网、路由表和安全控制如何共同决定可达性？¶

技术说明

VPC/VNet⁷ 提供逻辑网络与地址空间，子网划分地址和故障/路由边界；路由表按最长前缀和平台规则选择下一跳，如本地、NAT⁸、网关、对等或黑洞。安全组/NSG 等通常在网卡/实例层过滤，网络 ACL/防火墙可在子网或集中路径再过滤，状态性与无状态性依产品而异。可达性是 DNS→路由→策略→目标监听→回程的组合，不存在“安全组已开所以一定通”。

设计需避免 CIDR 重叠，保留扩容地址，并明确东西向、南北向与管理面路径。排障使用有效路由、流日志、reachability analyzer、主机路由/抓包和目标日志逐层证实；尤其关注非对称路由经过状态防火墙被丢弃。IaC 变更应做路由冲突和暴露面政策检查。

实践经验

复合场景中，新私网连接建立后请求单向到达，回包走默认 NAT 而非新网关，状态防火墙丢弃。两端流日志和有效路由显示非对称。止血是增加更具体回程路由并限制范围；长期在连接验收中检查双向路径与重叠 CIDR。添加具体路由会改变既有流量优先级，必须模拟受影响前缀。

面试回答要点

私网访问云托管服务有哪些方式，如何防止数据外泄？¶

技术说明

常见方式包括服务端点、Private Link/Private Endpoint、私有 API endpoint 或经代理/防火墙访问。服务端点可能仍使用服务公共地址但在云骨干内并以策略识别来源；Private Endpoint 通常在 VPC/VNet 中分配私有地址并通过私有 DNS 指向服务。具体路由、源 IP、跨区费用和可访问服务范围依平台，设计前需验证。

防外泄不仅“走私网”，还要在服务资源策略限制允许的账号、endpoint、网络和操作，关闭或限制公共入口，控制 DNS 防止回落到公网，并限制 egress。跨网络解析需要 split-horizon DNS 与转发链。监控 endpoint 流量、拒绝、DNS 答案及服务审计，避免私网 endpoint 成为跨租户绕过点。

实践经验

复合场景中，创建私有数据库 endpoint 后应用仍解析到公共地址，因为自建 DNS 未转发云私有 zone；出站 NAT 使访问“看似正常”。抓包与 DNS answer 揭示路径。止血是修正条件转发并临时限制数据库公共来源；长期关闭公网、在部署门禁验证解析地址和资源策略。关闭公网会影响供应商支持/应急工具，需要受控跳板或代理替代。

面试回答要点

NAT 网关如何成为容量、可用性和成本瓶颈？¶

技术说明

NAT 为私有地址到外部建立地址/端口转换状态，容量受连接数、源端口、吞吐和单目的热点影响；高并发短连接可能发生端口耗尽，即使带宽不高。托管 NAT 的区域/可用区语义、扩展和故障转移依云平台，架构要避免跨 AZ 绕行造成单点与流量费。NAT 不等于应用层出口策略，也不自动过滤允许访问的域名。

监控活跃连接、端口分配失败、丢包、字节与每目的地址分布，结合客户端 connect timeout。缓解包括连接复用、减少不必要公网访问、为云服务使用私网 endpoint、按 AZ 部署 NAT、增加出口 IP/分片，以及显式代理。扩大 NAT 只缓解容量，不修复连接泄漏或重试风暴。

实践经验

复合场景中，批量任务启动后访问同一第三方 API 大量超时，NAT 端口分配错误激增，但吞吐仅中等。应用每请求新建连接且多层重试。止血是限批、启用连接池并扩出口地址；长期设置出口连接预算、按 AZ NAT 与重试上限。更多公网 IP 会增加白名单和治理成本，应优先减少连接放大。

面试回答要点

云负载均衡、DNS 与健康检查如何实现可靠流量切换？¶

技术说明

DNS 将名称解析到区域入口，TTL 和递归/客户端缓存决定变化传播；云负载均衡器在 L4/L7 将连接或请求分配到 target，并依据健康检查摘除后端。DNS 健康路由常只判断入口健康，不能自动了解所有业务依赖；LB health check 若过浅会送流到坏实例，过深则共享依赖抖动时全摘。

可靠切换采用分层健康：入口可达、服务接流能力、业务 SLI；权重逐步转移，监控目标错误/延迟和连接排空。TTL 不是最大切换时间，既有长连接、JVM DNS 缓存和中间代理可持续更久。TLS 证书、SNI、源 IP、sticky session 与状态存储也决定是否能无损切换。

实践经验

复合场景中，区域切流把 DNS 权重改为 0，但大量 WebSocket 仍连旧区域，维护时被切断。连接统计证明 DNS 变化不影响已建连接。止血是保留旧区容量并向客户端发优雅重连；长期把长连接 drain 纳入切流状态机，客户端支持带抖动的重连。延长双区并存增加成本，但避免突发重连风暴。

面试回答要点

跨可用区高可用架构如何避免“名义多 AZ、实际单点”？¶

技术说明

多 AZ 要让入口、计算、数据、NAT、队列、控制面依赖和运维路径跨独立故障域，并确保任一 AZ 故障后的剩余容量可承载降级目标。仅把实例分布到多个 AZ 不够：单区数据库、单 NAT、共享的单区缓存或所有副本依赖同一子网 IP 都可形成隐性单点。

数据层需明确同步/异步复制、quorum 与写延迟；应用层使用无状态或外置状态、拓扑分散和快速健康摘除。容量模型用 N-1 条件而非正常平均，故障演练应真正隔离一个 AZ 的网络/资源并验证自动扩缩、配额和运维访问。跨 AZ 流量成本和延迟也要可见。

实践经验

复合场景中，API 实例均匀分三 AZ，但所有私有子网默认路由指向单 AZ NAT，该区故障后外部依赖全部失败。路由审计揭示共享出口。止血是切换路由到健康 NAT；长期每 AZ 独立出口、合成探针验证，并将路由纳入故障演练。多 NAT 增加固定成本，可按业务重要性分层使用。

面试回答要点

多区域 active-passive 与 active-active 如何选择？¶

技术说明

active-passive 平时单区写入，备用区域热/温/冷程度决定成本和 RTO，数据复制滞后决定 RPO；故障转移相对易控制，但必须持续验证备用容量、配置和凭证。active-active 可降低区域故障切换时间和全球延迟，却要求全局流量、数据冲突、幂等、分区容忍和一致性模型，复杂度远高于“部署两份”。

选择由业务 RTO/RPO、写冲突概率、延迟、合规和成本决定。可以分层：静态/读流量 active-active，单写数据 active-passive；或按租户/地域分片。要定义 region fencing、防止恢复区与旧区双写，并让灾备切换是状态机：宣告、隔离、确认复制点、提升、切流、验证、回切。

实践经验

复合场景中，团队宣称双活，但数据库只有单主，主区域断网时两个自动化分别提升备用和恢复旧主，险成双写。止血是冻结写入、人工选权威主并对账；长期引入外部仲裁/fencing、单一灾备编排器和演练。更强一致仲裁可能在网络分区时牺牲写可用性，这是必须被业务接受的取舍。

面试回答要点

高可用设计中如何识别共享命运与级联故障？¶

技术说明

共享命运指表面冗余组件依赖同一控制面、配额、身份、DNS、KMS、网络或发布系统，因而会一起失败。分析时建立依赖图并标注故障域、资源上限和控制环；对每个关键路径问“哪个单点可同时移除多个副本”。级联常由重试、故障转移、自动扩缩和缓存失效把局部故障转成下游过载。

隔离措施包括 bulkhead、独立配额/账号、每租户限流、重试预算、熔断、降级和预留容量。高可用不是所有组件都双份，而是端到端 SLO 下消除关键相关故障。故障注入要覆盖依赖慢而非只断、凭证过期、配额耗尽和控制面不可达，并验证人工 kill switch。

实践经验

复合场景中，两区域应用都依赖同一全局身份服务；证书轮换错误使两个区域同时无法获取 token。证据链显示计算与网络健康但认证失败。止血是恢复上一证书并延长已签 token 的受控接受窗口；长期身份服务多区域独立验证键缓存、轮换 canary 和断依赖演练。延长缓存改善可用性却扩大吊销传播时间，需设置上限。

面试回答要点

RTO、RPO、MTTR 与 SLO 如何转化为架构和演练目标？¶

技术说明

RTO、RPO、MTTR 与 SLO⁹ 分别描述恢复时间目标、恢复点目标、平均恢复时间和服务等级目标，四者不能互换。业务影响分析应按关键旅程和数据集定义，而非给“整个系统”一个模糊数字；例如下单写入 RPO 接近零，报表可接受小时级。

目标必须映射到复制频率、备份间隔、备用容量、人员响应和恢复步骤，并包含依赖恢复时间。测量从何时开始、何为“恢复”要明确：端口可连不等于订单可完成，数据恢复但积压未清也可能未达目标。演练记录检测、决策、执行、验证各段耗时，针对最长路径投资。

实践经验

复合场景中，文档写 RTO 30 分钟，但备用数据库恢复即耗时 45 分钟，且 DNS 切换另需缓存传播。演练以 72 分钟暴露差距。短期将对外承诺调整为可实现值；长期使用持续复制和预置容量把关键路径降到目标内。更热的备用提高固定成本，应由中断损失量化支持。

面试回答要点

3-2-1、不可变备份和跨账号备份如何抵御勒索与误删？¶

技术说明

3-2-1 表达至少三份数据、两类介质/故障实现、一份异地/隔离副本，但云环境更应强调独立故障域与身份。不可变/WORM、版本锁定和延迟删除防攻击者或错误自动化立即清除恢复点；跨账号/订阅备份由独立管理员与 KMS 控制，生产角色没有删除权。复制错误或加密数据也会进入备份，所以保留多时间点。

备份策略记录范围、频率、保留、加密、成本和合法删除；KMS key、备份目录、IaC/state、身份配置同样要备份或可重建。备份成功指标只说明写入，必须校验完整性、恢复权限和应用一致性。不可变保留会带来合规删除与成本挑战，应按数据分类配置期限而非无限保存。

实践经验

复合场景中，误配置清理脚本删除生产数据与同账号快照，因为两者共用管理员角色。跨账号周备份保住数据，但 RPO 达七天。止血从隔离副本恢复并停止 writer；长期提高跨账号复制频率、生产角色无备份删除权限并启用不可变保留。更密备份增加成本，采用增量和分层保留优化。

面试回答要点

如何证明备份“可恢复”，而不只是看到备份任务成功？¶

技术说明

恢复验证应在隔离账号/网络从指定恢复点创建完整依赖，验证解密、schema、日志回放、对象数量/校验和、应用读写和关键业务交易。恢复过程不能连接生产消息队列、邮件或支付，避免测试产生真实副作用。结果记录实际 RPO、阶段耗时、人工步骤和失败原因，并销毁测试数据。

抽样频率按数据关键性与变化率制定；数据库做 point-in-time restore，文件/对象做随机与批量校验，Kubernetes/云平台还需恢复 state、secret 与外部资源映射。runbook 应由未参与编写的人执行，验证凭证与联系方式。恢复演练失败视为可靠性缺陷并有修复 SLA。

实践经验

复合场景中，快照每日成功，但季度演练发现加密 key 已在账号清理时删除，所有快照不可读。止血无法修复历史副本，只能从更旧独立备份恢复。长期为 key 设置删除保护、跨账号副本使用独立 key，并每周自动小规模 restore。长期保留 key 也扩大访问面，需要最小解密权限和审计。

面试回答要点

云迁移前如何做发现、依赖梳理与迁移波次规划？¶

技术说明

发现阶段建立应用、主机、数据、网络流、身份、证书、许可证、SLO、合规和 owner 清单；结合 CMDB、流日志、APM、DNS、批处理时刻表与访谈，避免只看服务器列表。依赖按强弱、同步/异步、端口、数据主权和停机窗口标注，并识别无法迁移的硬件、延迟与许可约束。

迁移波次以依赖群和风险组织：先无状态/内部低风险 canary，再逐渐包含共享服务与关键数据；每波有入口条件、容量、回退点和冻结窗口。基础 landing zone、私网/DNS、身份、日志、安全与成本基线先于业务。迁移不是一次复制，还要决定 6R/7R 类型、双运行期限和旧环境退役证明。

实践经验

复合场景中，团队按服务器编号迁移，漏掉夜间批任务通过硬编码 IP 访问旧数据库；白天验收成功，夜间失败。流日志和调度记录补齐依赖。止血是临时恢复旧路径并回滚该批；长期迁移前覆盖完整业务周期采集流量，用 DNS/服务目录替代硬编码。延长观察周期会推迟计划，但显著降低隐性依赖风险。

面试回答要点

rehost、replatform、refactor、repurchase、retain、retire 应如何决策？¶

技术说明

迁移策略不是技术成熟度排名。rehost 快但保留运维债务；replatform 在数据库/容器等层做有限改造；refactor 获取云原生弹性但周期和业务风险最大；repurchase 转 SaaS 涉及流程与数据退出；retain 接受暂留，retire 删除无价值系统。决策依据业务寿命、迁移期限、许可证、SLO、合规、技能和总成本。

可对单个系统分层选择，例如前端 replatform、核心数据库先 rehost，稳定后再重构。必须估算双运行、数据出口、托管服务溢价和人员成本，而非只比虚机单价。每个“暂留”要有 owner 与复审日期，每个 SaaS/托管选择要有数据导出和退出路径。

实践经验

复合场景中，为赶数据中心退出期限，团队试图同时重构核心结算，范围失控。决策改为先 rehost 保持协议与数据不变，迁移稳定后按模块重构。长期把时限风险与架构收益拆成两个项目。两阶段会支付临时重复成本，却降低业务切换与代码改造耦合。

面试回答要点

数据库迁移怎样实现低停机切换和可验证回退？¶

技术说明

常见路径是全量初始复制加 CDC/WAL/binlog 增量追赶，持续监控 lag、错误与 schema 兼容；切换前冻结不兼容 DDL，进行数据校验，短暂限写/停写以收敛 lag，然后切换连接与验证。双写通常比想象复杂，会出现顺序、部分成功和冲突；优先使用单写权威与可靠复制。

回退必须定义写入边界：目标库开始接受写后，直接把流量切回旧库会丢新数据，需要反向复制、双向协议或在 go/no-go 窗口内保持目标只读。校验不只比较行数，还包括分区/主键 checksum、业务聚合、序列、自增、权限、作业和性能。应用连接池与 DNS 缓存会延迟切换。

实践经验

复合场景中，切换后少量旧连接继续写源库，造成分叉。连接日志显示旧 Pod 未重启且池未过期。止血是把源库改只读、停止旧实例并补录差异；长期通过代理集中端点、切换时强制排空连接并对源库设置写 fencing。强制断连会产生短时错误，应配幂等重试和维护窗口。

面试回答要点

混合云专线/VPN 如何设计路由、DNS、加密和失效模式？¶

技术说明

混合连接通常以专线提供稳定带宽/时延，以多个独立 VPN 作为备份或补充加密；需要设备、运营商、接入点和云网关的物理/逻辑冗余。动态路由通过 BGP 传播前缀，但要控制优先级、聚合、最大前缀和 route leak；地址重叠会显著限制互通与并购扩展。

DNS 使用条件转发与权威区明确责任，避免循环和 split-brain；传输是否原生加密需核实，必要时专线上叠 IPsec。故障转移不仅看隧道 up，还要端到端应用探针、容量和非对称路由。备份 VPN 如果带宽不足，自动切换会把“断网”变成“严重拥塞”，需降级和流量优先级。

实践经验

复合场景中，专线故障后 BGP 正常切到 VPN，但备份带宽只有生产峰值三分之一，重试进一步拥塞。止血是限批处理、优先关键 API 并降低重试；长期按降级流量模型扩备链路，季度在峰值仿真下切换。全容量备份成本高，可用业务优先级换取合理投入。

面试回答要点

多云架构什么时候有价值，什么时候只是增加复杂度？¶

技术说明

多云有价值的场景包括监管/数据主权、并购现实、特定服务能力、供应商集中风险或真正可量化的业务连续性要求。仅为了议价或“避免锁定”而让每个应用同时跨云，往往增加身份、网络、数据一致性、观测、技能和最低公分母成本，却未必能在云级故障时切换。

可移植性应分层：应用制品/协议较易标准化，数据服务和运营流程最难。常见务实方案是按业务/地域分配主云，保证备份格式、身份标准、IaC 接口与数据导出可迁移，而非实时双活。决策需用场景、概率、迁移时间和总成本量化，并演练真实退出。

实践经验

复合场景中，团队要求所有服务同时兼容两云，最终放弃各自托管数据库能力，自建数据库却缺少运维成熟度，可靠性下降。策略调整为核心数据采用主云托管服务，同时建立跨云可恢复备份和季度迁移演练。恢复 RTO 较长，但整体风险和成本更透明。

面试回答要点

如何管理云供应商锁定而不退化为“只用最基础 IaaS”？¶

技术说明

锁定包含 API/代码、数据格式与出口成本、运维知识、商业合同和组织流程。应按能力收益与退出代价逐项评估，而不是拒绝所有托管服务。高价值托管数据库/队列可显著减少运维风险；通过标准协议、领域适配层、数据导出、schema 文档和可重建配置，把锁定限制在清晰边界。

建立 exit plan：数据量/带宽决定导出耗时，目标替代服务、迁移工具、许可证、双运行成本与合同条款均要记录。定期验证备份可在独立环境读取，IaC 只解决资源重建，不解决应用语义。抽象层只封装真实稳定差异，过度自研“通用云接口”会成为新的内部锁定。

实践经验

复合场景中，团队为避免队列锁定自建跨云抽象，掩盖了两种队列不同的确认与顺序语义，故障时出现重复处理。长期保留领域级消息接口，但明确采用主云语义和幂等消费者，备份/重放格式保持开放。接受部分锁定换取可靠托管，同时量化退出周期。

面试回答要点

云上大规模故障时如何组织技术止血、供应商协作与事后改进？¶

技术说明

先建立内部事实：受影响业务/区域/账号、开始时间、错误类型、依赖图和当前变更；云状态页只是信号，不能代替自有遥测。事故指挥角色分离：指挥官控制优先级，技术负责人验证假设，沟通负责人对内外更新时间；所有动作带时间、预期、回退和观察结果。供应商工单提供资源 ID、request ID、时间区间、区域和最小复现，避免只报“云挂了”。

止血选择按可逆性和爆炸半径：冻结发布、限流/降级、切流、扩容或启用备用区；要防所有客户同时故障转移引发目标区容量不足。恢复后验证数据完整、积压、凭证/配额和成本，再回切。复盘区分供应商触发因素与自身促成因素，如单区依赖、无降级、配额不足和未演练。

实践经验

复合场景中，区域对象存储延迟升高，应用线程池被同步调用占满。团队先禁用非关键上传、为读取启用旧缓存并限制重试，再仅将关键流量切备用区；request ID 让供应商确认局部服务退化。长期改异步写、设置依赖隔离池、多区域缓存和切流容量预留。备用区常驻资源增加成本，但避免全量冷切换失败。

面试回答要点