文章

SRE 面试 BOSS直聘专项

#sre#面试#boss直聘#混沌工程#容灾#高可用#生产环境#业务理解

BOSS 直聘 SRE 面试专项补充

[!info] 说明 本文针对 BOSS 直聘 SRE JD 相比之前 JD 的新增考察点做面试导向补充。

  • 之前 JD：2年经验，强调 AI 提效
  • BOSS 直聘 JD：6年经验，强调混沌工程、高可用设计、容灾建设、对生产环境问题敏感

知识库已有学习笔记（不重复内容，只做面试转化）：

本文聚焦：面试会怎么问、你怎么答、答到什么程度。

Part A：BOSS 直聘业务理解（面试官必考）

Q59：你对 BOSS 直聘的业务了解多少？你觉得这个业务对 SRE 有什么特殊挑战？

考察点： 业务理解深度（JD 第一条”核心业务线”直接相关）

[!success] 标准答案 BOSS 直聘业务模型：

  • 双边撮合平台：B 端（企业 HR / 招聘方）+ C 端（求职者），核心价值是匹配效率
  • 核心功能链路：简历投递 → 在线沟通（IM）→ 视频面试 → 入职
  • 商业模式：免费 + 增值（企业端付费会员、直聘卡、广告），IM 和推荐是转化引擎

对 SRE 的特殊挑战：

挑战说明SRE 应对
IM 不能断消息丢失/乱序 = 撮合失败 = 直接影响营收IM 链路 SLA 99.99%+，消息有序性保障，离线消息推送
视频面试不能卡音视频卡顿 = 面试体验崩塌 = 用户流失实时音视频专项保障，边缘节点加速，QoS 监控
强季节性流量金三银四/秋招峰值 3-5 倍容量按峰值规划，HPA+预扩容+大促预案
蓝领夜间流量蓝领下班晚，夜间也是高峰不能只保白天，夜间自动恢复能力更重要
推荐/搜索依赖 GPUML 推理延迟影响匹配转化率GPU 资源治理，推理延迟 SLI，推理服务弹性伸缩
双边依赖B 端挂了 C 端没意义，反之亦然双端 SLO 联动，不能只保一端

面试表述（原话）：

“BOSS 直聘跟纯 C 端业务最大的区别是双边依赖——不能只保 C 端可用性，B 端如果发不了职位，C 端再快也没用。所以 SLO 不能只看单端，要看撮合成功率。另外 IM 和视频面试是核心转化链路，这两条链路的 SLA 要求比其他业务高一个量级。“

Q60：如果让你来保障 BOSS 直聘核心业务线的稳定性，你会怎么切入？

考察点： 体系化思维、优先级判断（6 年经验画像核心考察点）

[!success] 标准答案 分三步切入，每步解决一个问题：

Step 1（0-1月）：摸清家底——核心链路识别 + SLI 重建
────────────────────────────
做的事：
  1. 梳理核心业务链路：IM 沟通链路、视频面试链路、简历投递链路、推荐链路
  2. 为每条核心链路定义 SLI（不是笼统的"成功率"，而是链路级 SLI）
     - IM：消息可达率、消息有序性、端到端延迟 P99
     - 视频面试：通话建立成功率、卡顿率、掉线率
  3. 梳理当前 SLO 水平，对比目标，找出 gap
  4. 梳理告警有效性——有多少告警是噪音，有多少真正有用

  验收标准：能画出核心链路拓扑图 + 每条链路的 SLI 定义和当前值

Step 2（1-3月）：补短板——可观测性 + 告警治理
────────────────────────────
做的事：
  1. 核心链路全链路追踪（SkyWalking / OpenTelemetry）
  2. 告警降噪：收敛/分组/抑制/分级（参考 [[SRE 面试扩展题库]] Q22）
  3. 告警有效率度量：多少告警真正触发了人工响应
  4. 四金指标覆盖所有核心服务（Latency/Traffic/Errors/Saturation）
  5. 错误预算管理：99.99% 意味着每月允许 4.3 分钟不可用

  验收标准：告警数量降 50%，告警有效率 > 80%

Step 3（3-6月）：建体系——MTTR/MTBF + 混沌 + 容灾
────────────────────────────
做的事：
  1. MTTR 度量：每个故障打时间戳（发生/告警/响应/定位/恢复）
  2. MTBF 提升：RCA 闭环 + 变更管理 + 容量治理
  3. 混沌工程：从 L1（单 Pod）开始，逐步验证核心链路韧性
  4. 容灾建设：IM 和视频面试链路做同城双活
  5. AI 辅助：根因分析系统接入核心链路告警

  验收标准：MTTR < 15min，核心链路混沌实验通过率 > 90%

[!tip] 面试加分表述 “我不会上来就搞 AI 或 ServiceMesh——第一步是摸清核心链路和当前 SLI 水平。如果连’哪条链路最重要”当前可用性多少’都不清楚，后面所有建设都是盲目的。“

Part B：混沌工程面试题

[!info] 知识库已有 混沌工程与故障注入 已覆盖：核心理念、故障注入类型、ChaosMesh 实战、实验分级 L1-L5、游戏日、安全护栏。

以下面试题不再重复知识点，只讲面试怎么答。

Q61：你们做过混沌工程吗？具体怎么做的？注入了什么故障？发现了什么问题？

考察点： 实操经验（JD 第 3 条”混沌工程”直接相关）

[!success] 回答框架 如果你实际做过：

  • 场景设计 → 注入故障 → 观察指标 → 发现问题 → 修复 → 纳入定期执行
  • 重点讲”发现了什么”——面试官想听的是混沌的价值，不是过程

如果你没做过（诚实但要展示方法论）：

“我们目前还没正式在生产做混沌工程，但我做过设计。我的思路是分三步走：

  1. 先在预发环境做，用 ChaosMesh 注入 Pod Kill 和网络延迟，验证 HPA 和超时重试是否生效
  2. 然后在生产做 L1 级（单 Pod Kill，每小时自动执行），验证多副本高可用
  3. 逐步升级到 L3（单 AZ 故障），验证跨 AZ 流量切换

安全护栏我会配 SLI 自动回滚——成功率低于 95% 或 P99 超过 2s 立即停止实验。

我预期会发现的问题：超时重试配置不合理（重试放大流量）、跨 AZ 分布不均匀（topologySpread 没配好）、降级策略只在文档里没在代码里落地。”

[!warning] 面试官追问方向

  • “你怎么保证混沌实验不会搞垮生产？” → 安全护栏（SLI 自动停止 + 爆炸半径控制 + 工作时间窗口）
  • “混沌工程跟压测有什么区别？” → 压测验容量，混沌验韧性；压测是”能不能扛住流量”，混沌是”挂了能不能恢复”
  • “你发现了问题之后怎么修复？” → 不是全修，按优先级修；核心链路问题先修，非核心的记录跟踪

Q62：混沌工程的实验分级怎么设计？什么级别的实验可以在生产自动执行？

考察点： 安全意识 + 工程化能力

[!success] 标准答案

级别范围风险执行方式批准自动化
L1单 Pod Kill极低生产自动无需✅ 每小时
L2单节点 Drain低生产自动SRE✅ 每天
L3单 AZ 故障中生产手动SRE 负责人❌ 每周
L4跨 AZ / 网络分区高生产手动 + Game Day技术负责人❌ 每月
L5跨 Region极高桌面推演为主CTO❌ 每季度

自动化条件（L1-L2 才自动）：

  1. 爆炸半径可控——只影响非核心服务或有足够冗余的核心服务

  2. SLI 自动回滚——成功率/延迟超阈值立即停止

  3. 工作时间窗口——10:00-16:00，大促/发版期间禁止

  4. 有完善 Runbook——出问题能快速恢复

[!tip] 面试表述 “我的原则是 L1-L2 自动化，L3 以上必须人工批准。自动化的前提是安全护栏到位——不是’我敢在生产做混沌’，是’我有把握在出问题时 30 秒内回滚’。“

Q63：给你一个场景：BOSS 直聘的 IM 链路，你想做混沌实验验证它的韧性。你会怎么设计实验？

考察点： 场景设计能力 + 业务理解

[!success] 标准答案

先明确假设（Hypothesis）：

  • H1：单个 IM 服务 Pod 被杀，30 秒内 HPA 扩容恢复，消息不丢
  • H2：IM 服务到 Redis 的网络延迟 200ms，消息送达 P99 < 5s
  • H3：单个 AZ 故障，IM 服务跨 AZ 切换，RTO < 2min

实验设计：

实验注入故障验证指标安全护栏级别
E1杀 IM 服务 1 个 Pod消息送达率 > 99.9%，恢复 < 30s消息送达率 < 99% 停止L1
E2IM→Redis 网络延迟 200ms消息 P99 < 5s，无消息丢失P99 > 10s 停止L2
E3IM→Kafka 网络丢包 10%消息不丢（Kafka 副本+重试）丢消息率 > 0.1% 停止L2
E4单 AZ 网络分区跨 AZ 切换 < 2min消息送达率 < 95% 停止L3
E5Redis 主节点故障自动 failover < 10s消息延迟 > 30s 停止L3

执行顺序： E1 → E2 → E3 → E4 → E5，每级通过才升下一级。

预期发现的问题：

  • 超时重试配置不合理（重试次数太多导致流量放大）

  • 跨 AZ 分布不均匀（topologySpreadConstraints 没配）

  • Redis failover 期间消息丢失（没做本地缓存兜底）

  • HPA 扩容太慢（冷启动 60 秒 + readiness probe 太严格）

[!tip] 面试加分表述 “IM 链路做混沌最怕的是消息丢失——所以我不会一上来就注入 AZ 级故障。先从单 Pod 开始，确认多副本+持久化+ACK 机制能保证消息不丢，再逐级升级。每级实验的安全护栏都跟消息送达率挂钩，不是跟 CPU/内存挂钩。“

Part C：高可用设计面试题

[!info] 知识库已有 高可用架构设计总览 已覆盖：RTO/RPO、冗余设计模式、故障转移层次 L1-L5、数据保护、降级容错、成熟度模型、设计 Checklist。

Q64：你们的高可用架构是怎么设计的？消除单点做了哪些事？

考察点： 架构设计能力（JD 第 3 条”高可用设计”直接相关）

[!success] 标准答案 五层消除单点：

流量层：SLB 多可用区 + Nginx Ingress 多副本 + HPA
    ↓
应用层：K8s 多副本 + podAntiAffinity + topologySpreadConstraints
    ↓
缓存层：Redis Cluster（多分片+哨兵）或 Redis Sentinel 主从
    ↓
数据库层：MySQL 主从 + MHA/Orchestrator 自动切换 + 半同步复制
    ↓
消息层：Kafka 多副本 + ISR 机制 + 跨 AZ 副本分布

关键设计点（面试时挑 3 个讲深）：

设计做法为什么
Pod 反亲和podAntiAffinity 让同服务 Pod 分散到不同节点避免单节点故障导致所有 Pod 挂
跨 AZ 打散topologySpreadConstraints maxSkew: 1避免 AZ 级故障导致服务全挂
PDB 保护PodDisruptionBudget minAvailable: 2防止节点维护时误杀所有 Pod
半同步复制MySQL rpl_semi_sync_master_wait_for_slave_count=1至少一个从库收到 binlog 才返回成功，RPO≈0
探针分离liveness 和 readiness 用不同端点readiness 失败摘流量但不重启，liveness 失败才重启

[!tip] 面试表述 “高可用不是’多加一台机器’，是从架构层面消除单点+缩短故障恢复时间。我们的做法是五层都消除单点，但重点在应用层的跨 AZ 打散和数据层的半同步复制——这两个是最容易出问题的。“

Q65：你们服务的 RTO 和 RPO 是多少？怎么保证的？

考察点： RTO/RPO 理解 + 生产实践

[!success] 标准答案

RTO/RPO 跟 SLO 挂钩：

SLO月度允许不可用RTO 目标RPO 目标实现手段
99.9%43 min< 30 min< 5 min主从切换+备份恢复
99.99%4.3 min< 4 min≈ 0同城双活+半同步复制
99.999%0.43 min< 1 min0异地多活+同步复制

具体保障手段：

层RTO 保障RPO 保障
应用层K8s 自动重启+HPA 扩容（秒级）无状态，不涉及
缓存层Redis Sentinel 自动切换（10-30s）异步复制，秒级丢失
数据库层MHA 自动切换（30s-2min）半同步复制 RPO≈0
Region 级DNS 切换（分钟级）异步 binlog，秒级丢失

[!tip] 面试表述 “核心业务 SLO 99.9% 意味着 RTO 要在 30 分钟以内。我们的保障是：应用层靠 K8s 自动恢复（秒级），DB 层靠 MHA 自动切换（分钟级），RPO 靠半同步复制保证接近 0。如果要做 99.99%，就必须上同城双活——单 AZ 故障自动切换，RTO < 4 分钟，但这需要 DB 半同步+跨 AZ 部署+GSLB 配合。“

Q66：你做过降级策略吗？核心服务挂了，你怎么保证用户体验不崩？

考察点： 容错设计能力

[!success] 标准答案 降级三级：

级别触发条件动作用户体验
L1 限流入口 QPS > 阈值返回排队/稍后重试部分用户受影响
L2 降级非核心依赖故障关闭非核心功能，返回兜底数据功能减少但能用
L3 熔断下游连续失败快速失败，不调下游返回缓存/默认值

BOSS 直聘场景示例：

故障降级策略用户体验
推荐服务挂了返回热门职位列表（缓存兜底）推荐变”热门”，不影响核心流程
搜索 ES 挂了降级到 MySQL LIKE 查询 + 限流搜索变慢但能用
IM Redis 挂了切到本地缓存 + 持久化队列消息延迟但不丢
视频面试服务挂了降级到电话面试/预约重排面试不中断，换方式

降级实现关键：

  1. 自动触发——不能靠人工判断，要有健康检查+自动开关

  2. 分级降级——不是一刀切，先限流再降级再熔断

  3. 可观测——降级触发要有告警，不能默默降了不知道

  4. 可恢复——故障恢复后自动解除降级

[!tip] 面试表述 “降级的核心是’非核心依赖挂了不影响核心链路’。BOSS 直聘的核心链路是 IM 沟通和简历投递，推荐和搜索是锦上添花。如果推荐挂了，返回热门列表兜底，用户照样能找工作。但如果 IM 挂了，就是 P0 事故。降级策略要按链路重要性分级设计。“

Part D：容灾建设面试题

[!info] 知识库已有 灾备与容灾方案 已覆盖：容灾等级 L1-L6、备份策略、同城双活架构、异地多活架构、灾备切换流程+Checklist、容灾演练。

Q67：你们现在的容灾是什么级别？如果要升级，你的规划是什么？

考察点： 容灾现状认知 + 规划能力

[!success] 标准答案 先诚实说现状，再讲规划：

“我们目前是 L2-L3 之间——有异地备份（Velero 定期备份到 OSS）和同城主备（MySQL 主从+MHA），但没有做同城双活。核心业务的 RTO 大约 5-15 分钟，RPO 接近 0（半同步复制）。”

“如果要升级到 L4 同城双活，我的规划是：“

阶段做的事预期 RTO/RPO
1. 流量层双活GSLB 按权重分流到两个 AZ分钟级切流
2. 应用层跨 AZtopologySpreadConstraints + 两 AZ 同时跑秒级（Pod 级故障自动转移）
3. 缓存层跨 AZRedis Cluster 跨 AZ 分片秒级 failover
4. DB 层半同步MySQL 半同步复制（已有）RPO≈0
5. 消息层跨 AZKafka 副本跨 AZ 分布不丢消息
6. 切换演练每季度做一次 AZ 切换演练验证 RTO

[!tip] 面试表述 “容灾升级最大的坑不是技术，是验证。很多团队搭了双活但从来没演练过切换，真出事发现 DNS TTL 太长、跨 AZ 延迟超标、DB 切换有脑裂。我的原则是搭完必须做切换演练，至少每季度一次，度量实际 RTO vs 目标 RTO。“

Q68：灾备切换的流程是什么？切换过程中怎么保证数据不丢？

考察点： 容灾实操 + 数据一致性保障

[!success] 标准答案 标准切换流程（7 步）：

1. 决策切换（IC 确认故障不可恢复）
2. 通知相关方（开发/业务/客服）
3. 主集群设只读（停止写入）
4. 等待数据同步延迟归零（确认 RPO=0）
5. 提升灾备 DB 为 Master（DB failover）
6. DNS 切换（指向灾备集群）
7. 验证服务（SLI 正常 + 数据完整性校验）

数据不丢的三个保障：

保障做法验证方法
切换前等同步检查 Seconds_Behind_Master = 0SHOW SLAVE STATUS
半同步复制主库写入至少一个从库收到 binlog 才返回成功SHOW GLOBAL STATUS LIKE 'rpl_semi_sync_master_yes_tx'
切换后数据校验对比主备数据行数 + 抽样校验pt-table-checksum

回滚机制（切换失败怎么办）：

  • 切换前保留旧 Master 状态（不删数据）

  • DNS 切换失败 → 手动改 DNS / GSLB 回切

  • DB 切换失败 → 旧 Master 恢复为 Master，灾备重建从节点

  • 设置超时：切换 5 分钟未成功 → 自动回滚

[!warning] 面试官可能追问

  • “DNS 切换太慢怎么办？” → 短 TTL（60s）+ 预热 + GSLB 健康检查自动切
  • “切换后有数据不一致怎么修？” → 对比工具（pt-table-checksum）+ 人工校验 + 按 Master 为准修复
  • “怎么保证切换不脑裂？” → 只有一个 Master 能写，切换前必须先设置旧 Master 只读

Q69：异地多活你们做过吗？异地多活最大的难点是什么？

考察点： 高阶容灾能力（6 年经验期望）

[!success] 标准答案

异地多活三大难点：

难点说明解决方向
数据一致性跨 Region 网络延迟 30-100ms，同步复制不现实单元化架构，按用户分片，跨单元异步同步
冲突解决同一用户双写两个单元路由层保证用户只到一个单元 + 最后写胜/CRDT
路由正确性用户路由到错误单元 → 数据不一致路由层 + 数据层双重保障 + 路由校验

单元化架构（面试要能画图）：

用户请求 → 路由层（按 user_id 取模路由）
    ├── user_id % 2 == 0 → 北京单元（应用+DB+缓存）
    └── user_id % 2 == 1 → 上海单元（应用+DB+缓存）

跨单元数据同步：DTS / Canal 异步双向同步
单元故障 → 切换路由 → 流量全部到另一个单元

诚实表述（如果你没做过）：

“异地多活我没实际做过，但我了解核心难点是数据一致性和路由正确性。我们目前的容灾级别是同城主备，异地只做备份。如果要做异地多活，我的设计思路是单元化架构——按用户维度分片，每个单元自包含，跨单元异步同步。但这个改造量很大，不是 SRE 一个团队能推的，需要架构组+DBA+业务一起。”

[!tip] 面试加分 能主动说”异地多活不是 SRE 一个团队能推的”会显得你有全局视野，不是盲目接活。

Part E：生产环境问题敏感性

Q70：JD 里说”对生产环境问题敏感”，你怎么理解这句话？

考察点： SRE 职业素养理解（JD 第 3 条原文）

[!success] 标准答案 “对生产环境问题敏感”有三层含义：

层次含义表现
嗅觉敏感能从异常指标中嗅到风险看到某个服务 P99 突然涨了 50ms，不会等告警就去看
操作谨慎对生产环境的任何操作都有风险意识不直接 kubectl edit 改生产，先在预发验证；任何变更有回滚方案
响应迅速故障发生时能快速判断严重程度并行动看到告警不是先翻文档，而是先看影响范围+业务关联

面试表述：

“我对’生产环境问题敏感’的理解是三件事：第一是告警不是等触发了才看，是日常看大盘时就能发现趋势异常；第二是对生产的任何操作都假设可能出问题，所以变更必须可回滚、必须灰度；第三是故障发生时第一反应不是’怎么修’，而是’影响多大、要不要先止损’——先恢复服务再查根因。“

Q71：线上告警来了，你的处理流程是什么？从告警触发到服务恢复，你怎么走？

考察点： 应急响应能力（跟 MTTR 直接相关）

[!success] 标准答案

告警处理 5 步法（对应 MTTR 四段）：

告警触发 → ① 确认有效性 → ② 定级+通知 → ③ 止损 → ④ 定位 → ⑤ 恢复
            (MTTD)        (MTTA)        (止损)     (Diagnose)  (Fix)
步骤做什么关键问题时间目标
① 确认看告警是否有效是误报还是真故障？影响什么业务？< 1 min
② 定级判断严重程度SEV0/SEV1/SEV2？要不要拉群？< 2 min
③ 止损先恢复服务能不能回滚/切流/限流/降级？< 5 min
④ 定位查根因最近有没有变更？链路哪里断了？5-15 min
⑤ 恢复确认服务恢复SLI 回归正常，持续观察 5 分钟< 15 min

关键原则：先止损再定位

  • 很多 SRE 的错误是先定位再恢复——用户等不了你查日志
  • 告警来了先看能不能回滚/切流/限流，3 分钟内做止损决策
  • 止损后慢慢定位根因，不要急于定位而拖延恢复

BOSS 直聘场景：

告警第一步止损第二步定位
IM 服务 5xx 飙升切流到备用集群 / 降级到离线消息看 SkyWalking 链路→查日志→查变更
视频面试掉线率飙升降级到音频面试 / 提示重试查音视频服务状态→查网络→查 GPU 资源
简历投递失败率升高限流入口 / 降级到异步投递查下游存储→查 Kafka 积压→查 DB 连接池

[!tip] 面试加分表述 “我的原则是’先止损再定位’——告警来了第一件事是看能不能回滚或切流，3 分钟内做止损决策。用户不在乎你的根因是什么，用户只在乎服务什么时候恢复。止损后慢慢查根因，做 RCA，推动改进项闭环。“

Q72：你遇到过最严重的线上故障是什么？你是怎么处理的？

考察点： 实战经验 + STAR 框架表达（6 年经验必考）

[!success] 回答框架（STAR） 准备 2-3 个故事，面试时讲最能体现你能力的那个。

STAR 模板：

要素内容面试官想听什么
Situation背景：什么时间、什么业务、什么规模事情的严重程度
Task你的角色：你是发现者、响应者还是决策者？你在故障中的角色
Action你做了什么：关键决策点你的判断力和执行力
Result结果：MTTR 多少、影响了多少用户故障影响和你的贡献
Follow-up事后：你推动了什么改进？你从故障中学到了什么

加分项（面试官想听的）：

  • 你做了什么关键决策（比如”5 分钟内决定回滚”）
  • 你的决策基于什么数据（比如”看到 P99 飙到 5s 决定切流”）
  • 事后你推动了什么改进（比如”在变更 SOP 里加了核心服务变更必须压测”）

减分项（避免）：

  • 只讲过程不讲决策（“我查了日志，查了链路，查了指标…”）

  • 甩锅给别人（“是开发改的代码有问题”）

  • 没有事后改进（只讲恢复不讲复盘）

[!tip] 面试表述模板 “去年 XX 月，我们的 XX 服务出了 XX 故障。当时我是值班 SRE，告警是 XX 触发的。影响范围是 XX，持续了 XX 分钟。我的第一反应是 XX（止损决策），因为 XX（基于什么数据）。止损后我们定位到根因是 XX。事后复盘，我推动了 XX 改进（变更 SOP/RCA 闭环/混沌实验），之后这类故障没有再出现过。“

Part F：6 年经验画像考察维度

Q73：你觉得 2 年经验和 6 年经验的 SRE，核心差距在哪？

考察点： 自我认知 + 成长意识

[!success] 标准答案

维度2 年经验6 年经验
视角执行视角（接告警→查问题→修）架构视角（为什么会有这个告警→设计上怎么避免）
范围单点/单服务全链路/全系统
影响力个人效率跨团队流程/规范
决策按预案执行在没有预案时做判断
预防被动救火主动预防（混沌/容量/变更管理）
业务知道服务名知道业务 SLA 和关键转化路径

面试表述：

“我觉得核心差距不是技术广度——2 年可以学很多工具。差距在’视角’：2 年经验是’告警来了怎么修’，6 年经验是’为什么会有这个告警、架构层面怎么避免再出’。另一个差距是’在没有预案时做判断’——大部分故障不会完全按预案走，6 年经验的人能在信息不全的情况下做出合理决策。我现在处于从执行视角向架构视角过渡的阶段，BOSS 直聘这个岗位的 6 年要求对我来说是拉高目标，我有信心快速对齐。“

Q74：你怎么推动跨团队的稳定性改进？比如开发不配合做混沌实验，你怎么办？

考察点： 跨团队影响力（JD 第 5 条沟通协作）

[!success] 标准答案 推动跨团队改进的三步法：

步骤做法关键
1. 用数据说话拉故障统计、告警数据、MTTR 趋势不要”我觉得”，要”数据表明”
2. 降低门槛给工具/给模板/给 Runbook，不给负担让开发”顺手就能做”，不是”额外任务”
3. 上层支持争取技术负责人/CTO 的背书跨团队的事没有上层支持推不动

具体场景——推动混沌实验：

“如果开发不配合，我的做法是：

  1. 先在非核心服务做——不碰核心链路，降低开发担心
  2. 给数据——拿之前的故障案例说’这个故障如果做过混沌实验，提前发现就能避免’
  3. 给工具——ChaosMesh 的实验我来写，开发只要确认安全护栏就行，不增加他们的工作量
  4. 拉技术负责人背书——把混沌实验纳入技术 OKR，变成团队目标不是个人请求
  5. 从小赢开始——先做一次实验，发现一个问题，修复后拿成果说事”

附：BOSS 直聘面试策略速查

[!summary] 跟之前 JD 的策略差异

维度之前 JD 策略BOSS 直聘策略
经验画像2 年，答技术细节6 年，答架构决策和权衡
AI 项目主线卖点手段（缩短 MTTR），不是卖点
混沌工程不考必考，Q61-Q63
高可用设计不深入必考，Q64-Q66
容灾建设Q27 简要必考，Q67-Q69
生产敏感性不考必考，Q70-Q72
业务理解通用BOSS 直聘业务，Q59-Q60
代码题重点准备仍要准备，优先级降
行为面试通用重点考跨团队推动力，Q74

[!summary] 面试前必做的 5 件事

  1. 准备 2-3 个故障故事——用 STAR 框架写下来，讲架构层面根因和事后改进
  2. 画出你们的高可用架构图——五层消除单点，每层能讲清冗余设计
  3. 设计一个混沌实验方案——选你们的核心服务，写完整实验设计（假设+注入+护栏+预期）
  4. 梳理容灾现状——L 几？RTO/RPO 多少？升级规划？
  5. 准备 BOSS 直聘业务表述——双边平台、IM 不掉线、视频面试不卡、季节性流量

关联阅读

自测题

[!question] 检验掌握程度

  1. BOSS 直聘的业务对 SRE 有什么特殊挑战？双边平台的核心链路是什么？
  2. 混沌工程实验分级怎么设计？L1-L2 在生产自动执行的前提条件是什么？
  3. 给你一个 IM 链路，你会怎么设计混沌实验？验证什么假设？
  4. 你们的 RTO/RPO 是多少？跟 SLO 怎么挂钩？怎么保证的？
  5. 灾备切换的 7 步流程是什么？切换过程中怎么保证数据不丢？
  6. “对生产环境问题敏感”你怎么理解？告警处理 5 步法是什么？
  7. 你最严重的线上故障用 STAR 框架讲一遍，重点讲关键决策和事后改进。
  8. 2 年和 6 年经验的 SRE 核心差距在哪？你处于什么阶段？