业务连续性（BCP）与团队与文化建设

• 掌握 RTO/RPO/MAO 的定义与区别
• 理解业务影响分析（BIA）过程与关键流程识别
• 掌握与业务方对齐的沟通与数据依据

RTO（恢复时间目标）指从故障到业务恢复允许的最大时间，RPO（恢复点目标）指允许丢失的数据量（对应最后一次备份时间），MAO（最大可接受中断时间）指业务容忍的最长中断时长。制定这些指标不能由技术团队拍脑袋，而需通过业务影响分析（BIA）：识别关键业务流程、评估流程中断造成的财务与声誉损失、估算每类流程可接受的中断时间与数据丢失。通过对齐，把业务容忍度转化为技术指标（RTO/RPO），再据此设计容灾方案与保护级别。与业务方对齐的关键是用"业务语言"沟通（如"中断 1 小时损失 X 元"），并让业务方确认指标、参与评审。指标一旦设定，应定期复审，因为业务价值随时间变化。

面试官关注候选人能否从"业务容忍度"推导"技术指标"，而非凭空设定。回答应体现 BIA 过程、关键流程识别、与业务方对齐的方法与定期复审。

• 掌握技能矩阵的维度与评估方法
• 理解 on-call 能力从入行到独立的培养路径
• 掌握培养机制（培训、影子值班、导师制）

技能矩阵用于评估团队能力覆盖与差距，维度通常包括：操作系统/网络、容器与编排、云平台、监控告警、日志分析、故障排查、自动化脚本、安全与合规、业务知识等，按熟练度分级（了解/应用/熟练/专家）。基于矩阵识别能力缺口，定向安排培训与轮岗。on-call 能力培养体系通常是渐进式：先通过文档与培训掌握系统与 runbook，再以"影子值班"（shadow）跟随资深工程师学习，逐步获得独立值班资格，最后能担任值班主力并反向指导他人。培养机制还包括：值班前培训与模拟、事故复盘作为学习材料、导师制、以及"值班后"的能力沉淀。目标是让每个值班工程师都能处理常见故障并正确升级，同时避免"只有少数人能值班"的 bus factor 风险。

面试官关注团队能力的系统性建设。回答应体现技能矩阵的评估与缺口分析、on-call 的渐进培养路径（影子值班→独立→带教），以及降低单点依赖。

• 掌握两地三中心与多活架构的区别
• 理解成本、RTO/RPO、一致性、运维复杂度的权衡
• 能按业务场景做合理选型

两地三中心通常指同城双中心（双活或主备）+异地灾备中心，兼顾单点故障与区域性灾难；同城多活/异地多活则让多个数据中心同时承载流量，实现高可用与就近接入。选型需在多个维度权衡：成本上，多活需要更多资源和带宽，且要处理跨机房数据一致性，成本显著更高；RTO/RPO 上，多活与强同步可做到接近零 RPO、分钟级 RTO，而异地灾备通常 RPO 为秒级到分钟级、RTO 更长；数据一致性上，跨机房同步面临网络延迟与 CAP 约束，需接受最终一致性或采用强同步（有性能代价）；运维复杂度上，多活要处理流量调度、数据冲突、故障切换与回切，复杂度远高于主备。选型应结合业务容忍度：对可用性要求极高、成本可承受的业务用多活，对容忍一定 RPO/RTO 的业务用两地三中心主备。

面试官关注候选人对"高可用与成本复杂度"权衡的清醒认识。回答应体现各维度权衡、多活与主备的适用边界，以及按业务需求选择而非一律追求多活。

• 掌握 3-2-1 备份策略
• 理解备份到恢复的完整链路验证
• 掌握恢复演练的频率与评估标准

3-2-1 备份策略指"至少 3 份数据副本、存储于 2 种介质、其中 1 份异地保存"，以抵御单点故障与灾难。备份策略还需考虑 RPO（决定备份频率）与保留策略（决定恢复点可回溯范围）。备份不等于可用，必须通过恢复演练验证：定期从备份实际恢复数据到测试环境，验证数据完整性、可加载性与业务可启动。恢复演练频率按业务重要性分级（关键业务高频演练，如每月/每季度；一般业务低频），评估标准包括：恢复成功率、恢复耗时是否满足 RTO、数据是否完整一致（校验和/行数/业务可用性）、演练是否发现备份损坏或配置问题。演练发现的问题（如备份缺失、恢复失败）要跟踪闭环。核心原则是"演练是为了在真出故障前暴露备份方案的缺陷"。

面试官关注"备份可靠"而非"备份存在"。回答应体现 3-2-1 策略、RPO/保留策略、恢复演练的频率与评估标准，以及演练暴露缺陷的闭环。

• 掌握 blameless 的核心（聚焦系统而非人）
• 理解落地的手段与领导层示范
• 掌握避免"口号化"的机制

blameless culture 的核心是"审视系统与流程的缺陷，而非归咎个人"，因为复杂系统故障通常是多因素叠加。落地需从多个层面：领导层公开示范，事故复盘聚焦"为什么系统允许这个错误发生"而非"谁犯了错"；用标准化复盘模板引导，把"人为失误"进一步追问到系统/流程/工具层面；设立明确边界，区分"无意的系统性失误"与"明知故犯或重大过失"，后者仍需追责；用数据与制度保障（复盘不进入绩效评价、鼓励如实上报）。避免流于口号的关键是"机制化"：把无指责原则写入复盘规范、用行动证明（如不因事故处罚主动上报者）、让复盘产出建设性改进项而非形式报告。真正的 blameless 是"让错误成为改进机会，而非惩罚对象"。

面试官关注候选人能否理解无指责文化的本质并给出落地机制。回答应体现领导层示范、复盘聚焦系统、边界界定、机制化而非口号化。

• 掌握容灾切换演练的完整流程
• 理解演练场景设计与参与角色
• 掌握回切条件、报告与改进闭环

容灾切换演练先要设计场景（如单机房故障、区域级故障、数据同步中断），明确演练范围、目标与指挥链。参与角色包括：总指挥（决策）、专家团队（各系统负责人）、操作执行者、观察记录员、业务方与第三方（如厂商）。演练流程：事前准备（状态基线、通知、回滚预案）→ 模拟切换（按预案切到灾备）→ 验证（业务功能、数据完整性、性能）→ 评估（切换是否成功、RTO/RPO 是否达标）→ 回切。回切是关键环节：需满足回切条件（数据一致、灾备验证通过、原中心可恢复、低风险窗口），回切前做数据同步与校验，回切后验证原中心业务正常。演练产出报告：记录时间线、各环节耗时、问题与改进项，并跟踪闭环。演练的核心价值是暴露预案缺陷，反复演练使切换成为"肌肉记忆"。

面试官关注候选人是否理解"切换容易、回切难"的现实。回答应体现切换与回切的完整流程、回切条件的严谨性、角色分工与演练报告改进闭环。

• 掌握平台团队与业务团队的责任划分原则
• 理解 Spotify 模型（squad、chapter、tribe）的协作
• 掌握"平台提供能力、业务自行操作"与"双方共担"的边界

平台团队与业务团队的责任边界通常遵循"平台即产品"原则：平台团队负责提供通用的能力与基础设施（CI/CD、监控、运行环境、平台服务），并保证其可用性、稳定性与易用性；业务团队负责其业务应用的开发、功能、业务逻辑与自身运行质量。Spotify 模型以 squad（跨职能小队）为基本单元，chapter（同职能小组）维护专业能力，tribe 管理多个 squad。落地时常见的边界问题：平台建了但业务不用（平台需做产品化、易用、服务化）；业务职责与平台职责重叠（需明确"平台负责平台本身、业务负责应用"）；"平台提供工具+业务自服务"是主流模式，业务团队用平台能力部署、监控自己的服务，平台团队则对平台服务本身负责。责任边界需通过文档、SLA 与评审明确，避免"三不管"或"责任真空"。

面试官关注候选人对"平台与业务边界"的清晰界定。回答应体现平台即产品、自服务模式、Spotify 模型下的角色划分，以及边界模糊的落地问题。

• 掌握技术债与 Toil 的定义与区别
• 理解量化方法（指标、成本、频率）
• 掌握优先级决策框架

技术债是"短期取巧所累积的长期维护成本"，Toil 是"重复、可自动化、无长期价值、与业务增长线性相关的手工运维工作"。两者都需量化才能优先级决策。技术债量化可用：维护成本占比、缺陷密度、变更交付时间、依赖升级成本、代码复杂度等；Toil 量化可用：单位时间人工操作数、占团队工时比例、可自动化程度、重复性等级。优先级决策框架通常结合"影响强度 × 消除成本"：对 Toil 用"消除后可节省的工时 vs 自动化投入"评估 ROI；对技术债用"不消除的累积风险 vs 修复代价"评估。SRE 指南建议把 Toil 控制在工作量的 50% 以内，优先消除占比高、可自动化、风险小的 Toil。决策要基于数据而非直觉，并定期复审优先级。

面试官关注候选人能否"用数据说话"而非空谈。回答应体现 Toil 与技术债的量化方法、ROI 评估与优先级框架，以及"控制 Toil 占比"的落地目标。

• 掌握事故通信树（communication tree）的构建
• 理解状态页的用途与信息设计
• 掌握内外部通报的时效与口径统一管理

事故通信树是"预定义的通知关系与升级路径"：按角色与层级列出谁通知谁、何时通知、如何升级，确保事件发生时能快速触达相关人员并逐级上报。通信树要定期更新联系人、避免单点（每个节点有备份）。状态页是面向内部与外部的统一信息源，展示当前状态、影响范围、发生时间、已采取措施与预计恢复时间，减少重复询问。时效管理上，内部通报需快速（事件发生即触发），外部通报需在适度确认后发布并持续更新；口径管理要求所有通报由单一负责人（IC/沟通员）统一发布，信息一致、避免矛盾，未经确认的信息不对外承诺。状态页与通信树保证了"该知道的早知道、口径一致不混乱"。

面试官关注沟通机制的"预定义与统一"。回答应体现通信树的结构、状态页的用途、时效分级与口径统一管理，避免信息混乱。

• 掌握 GSLB 的流量调度原理（DNS、Anycast、应用层）
• 理解健康检查与容灾切换条件
• 理解切换的权衡与回切

GSLB（全局负载均衡）在多个地域/数据中心间调度流量，实现就近接入与容灾。实现方式常见：基于 DNS 的 GSLB（按地域/权重返回不同 IP）、基于 Anycast 的调度（同一 IP 就近路由）、应用层 GSLB（结合健康检查与策略）。健康检查是关键：GSLB 定期探测各站点健康状态（HTTP/TCP 探测、业务接口探测），判定站点是否可用。切换条件设计需权衡：健康检查失败即触发切换能快速止损，但误报会导致不必要的切换与震荡；需设置探测次数、超时、只对关键接口判断，并结合"多站点半数仲裁"避免误判。切换后需考虑回切条件（原站点恢复且稳定、数据同步完成、低风险窗口）。GSLB 还支持按权重、容量与用户地理位置调度，实现流量分担与容量不对称下的可用性。

面试官关注候选人对"全局调度与容灾切换"的理解。回答应体现 GSLB 的实现方式、健康检查与切换条件的权衡（快速止损 vs 误切震荡）、回切条件。

• 掌握 squad/chapter/tribe 的结构
• 理解自治与对齐的平衡
• 识别落地常见问题

Spotify 模型中 squad 是跨职能的长期小队，拥有明确使命与自主权，可自行决定如何实现目标；chapter 是同一职能的横向小组，维护专业标准与人才培养；tribe 是多个 squad 的集合，服务于更大的业务域。兼顾自治与对齐需：squad 有明确使命与边界（做什么、不做什么），组织通过使命、SLO 与评审对齐目标，而非微观管理；chapter 与 guild（兴趣小组）提供横向对齐与知识共享。落地常见问题包括：squad 边界不清导致职责重叠或真空；过于追求自治导致重复造轮子、缺乏统一标准；squad 与 chapter 职责混淆；组织结构变化频繁导致团队不稳定；对齐机制缺失导致各 squad 各自为政。成功关键是"自治以对齐为前提，对齐以使命与边界为基础"。

面试官关注候选人对"自治与对齐"这对张力的理解。回答应体现 squad/chapter/tribe 结构、自治与对齐的平衡机制，以及常见落地问题。

• 掌握脑裂问题的成因
• 理解仲裁与 STONITH 机制
• 掌握故障节点隔离策略

脑裂（split-brain）发生在集群节点间心跳断开但各自仍"活"时，导致多个节点同时声称是主，出现双主、数据不一致。防止脑裂的核心是"确保同一时刻只有一个主干"。仲裁机制通过法定节点数（quorum）保证：只有获得多数节点认可的节点才能成为主，分裂的两半中只有达到多数的一方继续工作，另一方自动降级。fencing 是"隔离故障节点"的强制手段：STONITH（Shoot The Other Node In The Head）通过电源管理或网络隔离强制关闭或隔离故障节点，确保它无法继续访问共享资源或承担主角色，防止双主持续。隔离策略包括：电源 fencing（断电）、网络 fencing（隔离网络）、存储 fencing（撤销存储访问权）。合理组合仲裁与 fencing，能保证"多数派存活 + 少数派被强制隔离"，从而避免双主与数据损坏。

面试官关注候选人对"防脑裂"的系统性理解。回答应体现脑裂成因、quorum 仲裁、STONITH 与隔离策略的组合，以及"多数派+强制隔离"的保证。

• 掌握主备架构的数据同步方式
• 理解切换流程与角色
• 理解 RTO/RPO 如何达成

主备（active-passive）架构中，主节点承担业务，备节点处于待命状态。数据同步方式决定 RPO：同步复制（主备强一致，RPO 接近 0，但延迟高、带宽大）与异步复制（RPO 为非零，从几秒到分钟级，性能好）。同步复制通常要求同城低延迟，异步复制适合异地。切换流程：检测到主节点故障 → 激活备节点（提升为工作主）→ 数据校验与回放 → 对外提供服务（VIP 切换、DNS 更新、客户端重连）→ 验证业务。RTO 由切换自动化程度决定：人工切换分钟级，自动化切换可到秒级；RPO 由数据同步与故障检测间隔决定。备节点平时需持续验证（定期演练、健康检查），确保真正切换时可用。未考虑数据一致性冲突（如双写）与备节点不可用是常见坑。

面试官关注候选人能否把"同步方式→RPO、切换流程→RTO"联系起来。回答应体现同步/异步复制选择、切换流程与验证、以及 RTO/RPO 达成路径。

• 掌握业务分级（Tier 0/1/2）的方法
• 理解关键业务的恢复优先级与资源保障
• 掌握按级别设定的演练频次

Tier 0 级关键业务指"中断会造成严重财务、合规或声誉损失，必须优先恢复"的业务。识别方法可结合业务影响分析（BIA）：按业务中断的影响程度（财务损失、合规风险、客户影响、声誉）与影响范围分级，Tier 0 为最高优先级。为关键业务制定连续性方案：明确恢复优先级（Tier 0 最先恢复，资源优先保障）、设定严格的 RTO/RPO（如分钟级 RTO、接近零 RPO）、设计高可用与容灾方案、确保关键资源（带宽、算力、人力、备件）在灾难时优先分配。演练频次按级别差异化：Tier 0 业务高频演练（如每季度/每月），Tier 1 一般业务低频，Tier 2 可更少。关键业务的连续性方案需持续验证与调整，确保"恢复优先级与资源保障"真正落地，而非停留在文档。

面试官关注候选人对"业务分级驱动资源与演练"的理解。回答应体现基于 BIA 的 Tier 0 识别、恢复优先级与资源保障、以及按级别差异化的演练频次。

• 掌握三层演练的差异与适用场景
• 理解由浅入深的分层节奏
• 掌握各层演练的评估与升级触发

演练分层设计遵循"由浅入深、由局部到整体"原则。桌面推演（Tabletop）成本最低，用于训练流程、决策与沟通，验证预案逻辑，适合新预案或管理层面，可高频进行（如每月）。单组件演练针对单一系统/组件（如数据库、缓存、网络）演练故障隔离与恢复，验证技术预案与 runbook，成本适中，适合有变更或定期进行（如每季度）。全量切换演练在真实环境演练完整容灾切换或业务恢复，验证端到端能力与 RTO/RPO，成本高、风险高，适合关键业务低频进行（如半年/每年）。分层设计的价值：低层演练暴露问题后，高层演练才更有把握；由低到高逐步建立信心，避免直接在高层演练中崩溃。节奏上，低层高频、高层低频，且每层演练的产出（问题与改进项）需闭环后进入下一层。

面试官关注候选人对"分层演练"的系统设计。回答应体现三层演练的适用场景、由浅入深的节奏与成本差异，以及问题闭环后升级。

• 掌握 DevOps 转型的常见阻力
• 理解渐进式推进策略
• 掌握文化、工具与流程的协同

DevOps 转型的阻力主要来自：文化阻力（开发与运维对立、部门墙、零信任）、工具阻力（缺乏自动化基础设施、工具割裂）、流程阻力（传统审批流程、发布周期长）、组织阻力（角色与职责不清、缺乏高层支持）。渐进式推进路径应避免"一步到位"：洞察现状（评估当前交付链路与瓶颈）→ 选一个高价值试点（一个团队或一条链路）→ 建立基础自动化（CI/CD、监控、基础设施即代码）→ 用试点成功案例说服更多团队 → 逐步扩大范围与标准化。同时要文化先行（打破部门墙、共享目标、鼓励协作）、领导支持（提供资源与授权）、以指标衡量（部署频率、MTTR、变更失败率）验证改进。转型是"组织变革"而非"技术替换"，需耐心与持续投入。

面试官关注候选人对"DevOps 是文化+流程+工具"的完整理解。回答应体现阻力分类、试点驱动的渐进路径、文化领导与指标衡量。

• 掌握知识库的结构与内容组织
• 理解保持更新的机制
• 掌握知识库支撑新人培养的用法

知识库要"可用且保鲜"。结构上按主题组织（系统架构、运维手册、runbook、FAQ、最佳实践），每篇文档有清晰标题、标签、负责人与更新时间，避免信息孤岛。保鲜机制是核心：把知识更新纳入工作流（如系统变更时同步更新文档、MR 要求附文档链接）、指定文档 Owner 定期评审、用"文档过期检测"（如标记待复核）驱动更新、把 runbook 与代码联动版本管理。支撑新人培养：知识库作为新人入门的第一手资料（环境搭建、架构说明、常见问题），配合"文档即培训"的理念，让新人先读文档再问问题，减少重复答疑。有效的知识库是"活文档"而非"积灰仓库"，靠流程与习惯而非依赖个人自觉。

面试官关注候选人对"知识库保鲜"与"支撑协作"的理解。回答应体现内容组织、更新机制（纳入工作流、Owner、评审）、以及新人培养的用法。

• 掌握 buddy 机制的具体做法
• 理解其对知识传递与变更质量的作用
• 掌握落地与注意事项

结对/搭档（buddy）机制指为工程师安排搭档，在关键操作（高影响变更、首次执行任务、on-call 首班）中共同合作，一人操作另一人复核/指导。作用上：知识传递方面，新人通过与资深搭档合作快速掌握系统与流程，减少单点知识依赖；变更质量方面，搭档复核能降低误操作风险，因为"第二双眼睛"可发现遗漏与错误。常见落地形式：变更 buddy（变更前有人 review 计划）、on-call buddy（值班初期有人陪同）、任务 buddy（高风险任务两人协作）。注意事项：buddy 需真正参与而非走形式（明确分工、记录问题）、搭配要匹配（资深带新人）、避免依赖 buddy 导致独立能力不足。buddy 机制是低成本、高价值的"人与人的冗余"，能显著提升知识传递与变更可靠性。

面试官关注候选人对"人因冗余"的理解。回答应体现 buddy 的落地形式、对知识传递与变更质量的双重作用，以及避免形式化的注意事项。

• 掌握 bus factor 的概念与识别
• 理解知识备份与文档化
• 掌握单点人员风险的缓解措施

bus factor 指"团队中若有人离开会导致项目无法继续的最少人数"，bus factor=1 意味着单点依赖，风险极高。识别单点风险的方法：盘点关键系统/服务的负责人，判断是否只有少数人掌握其运维知识；观察"只有某人能处理"的工单、文档缺失、值班时只有某人能响应等问题。缓解措施包括：知识备份（文档化系统架构、runbook、决策记录，让知识不只存在个人脑中）、轮岗与交叉培训（让多人都能处理关键系统）、buddy 机制、on-call 轮换覆盖、以及把关键逻辑沉淀到自动化与配置中减少"手工经验"。治理目标是"让任何关键角色都有备份，人员离开不造成业务中断"。持续评估 bus factor 是降低组织脆弱性的重要手段。

面试官关注候选人对"组织级单点风险"的治理意识。回答应体现 bus factor 概念、识别方法、知识备份与交叉培训等缓解措施。