SRE 面试扩展题库

[!info] 说明 本文是 SRE 面试备战手册 和 SRE 面试补全内容 的扩展，覆盖之前未涉及的高频面试方向。按简历深挖、监控告警、CI/CD、系统设计、Linux/网络、行为面试六个维度组织，共 30 道题。

---

一、简历深挖题（面试官必问）

[!warning] 核心原则 简历上写的每一条都会被深挖。面试官的逻辑是：你写了什么，就要能讲到什么程度。 写不了的东西不要写上去。

Q16：你简历上写了”管理 4 套 ACK 环境、200 节点、1000 微服务、3000 Pod”，具体怎么管理的？

考察点： 规模化管理能力、多集群治理

[!success] 回答要点

• 4 套环境：dev / staging / pre-prod / prod，分别承担什么职责
• 多集群治理：是否用 KubeSphere/Rancher/自研多集群管理平台？还是纯 kubectl 切 context？
• 1000 微服务：命名规范、label 体系、namespace 划分策略
• 配置管理：Helm/Kustomize？是否有统一的 chart 仓库？
• 成本管控：200 节点的月度成本多少？有没有做成本优化（如 spot 节点、HPA+cluster-autoscaler 联动）？

如果管理方式比较原始（纯手动 kubectl）： 诚实说，然后说”我们正在引入 GitOps（ArgoCD）做统一发布管理”。不要编。

Q17：你的 SSL 证书分发平台，具体做了什么？架构是什么样的？

考察点： 项目设计能力、安全意识

[!success] 回答要点

• 背景：为什么要做？之前证书管理是怎么做的（手动？容易过期？）
• 架构：证书申请（Let’s Encrypt ACME / 内部 CA）→ 证书存储 → 分发到目标节点 → Nginx reload → 到期提醒
• 技术栈：Python 后端 + React 前端 + 数据库（MySQL/PostgreSQL）
• 安全设计：证书私钥怎么存储？（加密？HashiCorp Vault？）分发通道是否加密？谁有权限申请证书？
• 规模：管理多少域名？多少节点？月均签发/续期多少证书？
• 加分项：自动续期（到期前 30 天自动 ACME 续签 + 自动分发 + 自动 reload）

Q18：OpsAgent 是什么？你用 Go 写它解决了什么问题？

考察点： 工具开发能力、对运维痛点的理解

[!success] 回答要点

• 定位：是一个运行在节点上的 agent？还是一个 CLI 工具？还是一个 server-side 服务？
• 解决了什么问题：巡检？信息采集？批量执行命令？健康检查？
• 技术设计：用什么通信（gRPC/HTTP）？怎么管理 agent 生命周期（systemd？daemonset？）？
• 跟现有工具的关系：跟 Ansible/Salt/Puppet 比，你的优势是什么？（如果答不出来，说明这个项目的定位不够清晰）
• 实际效果：节省了多少人天？替代了多少手动操作？

Q19：你的”链路分析项目”具体做了什么？跟 SkyWalking 自带的链路分析有什么区别？

考察点： 对 APM 体系的理解、项目差异化

[!success] 回答要点

• SkyWalking 原生能力：调用拓扑图、慢调用追踪、异常调用统计
• 你的项目做了什么额外的事：
  • 是做了自定义的链路聚合？（把多个 trace 聚合成一个业务流程）
  • 是做了链路异常的自动归因？（自动关联到某个中间件异常）
  • 是做了链路数据的结构化存储和查询？
• 不要说：“我重新实现了一遍 SkyWalking”——这会让面试官觉得你不了解现有工具

Q20：你简历上写”参与公司运维 SOP 制定”，具体参与了哪些 SOP？

考察点： 流程建设能力、运维规范化

[!success] 回答要点 列出至少 3 个你参与制定的 SOP：

• 变更 SOP（发布流程、回滚流程、审批流程）
• 故障响应 SOP（分级响应、值班交接、升级路径）
• 值班 SOP（日常巡检、告警处理、交接班）
• 容量评估 SOP（大促前评估流程、扩容标准）
• 交付 SOP（新服务上 K8s 的标准流程、上线 checklist）

关键： 能说出你在其中承担了什么角色——是起草者？是评审者？是落地推动者？

---

二、监控与告警体系（JD 第 1、3 条）

Q21：你们的监控体系是什么样的？用了什么工具？

考察点： 监控架构全局认知

[!success] 回答要点 监控三层体系：

┌────────────────────────────────────────────────┐
│           统一展示层 (Grafana)                    │
├────────────────────────────────────────────────┤
│  指标监控        │  日志监控        │  链路监控    │
│  Prometheus      │  SLS/ELK        │  SkyWalking  │
│  (时序数据)       │  (日志数据)      │  (调用链)    │
├────────────────────────────────────────────────┤
│  基础设施层      │  中间件层        │  应用层      │
│  node_exporter  │  redis_exporter │  自定义指标   │
│  kube-state     │  mysql_exporter │  (Micrometer) │
└────────────────────────────────────────────────┘

• 指标：Prometheus + Alertmanager + Grafana
• 日志：阿里云 SLS 或 ELK
• 链路：SkyWalking
• 告警：Alertmanager → 路由到企微/钉钉/电话
• 四金指标（Google SRE 四大金指标）：
  1. 延迟 Latency：P99/P95 响应时间
  2. 流量 Traffic：QPS / 并发数
  3. 错误 Errors：5xx 率
  4. 饱和度 Saturation：CPU/内存/连接数/线程池

如果被问”你的告警规则怎么设计的”：

• 按 severity 分级：critical（电话）、warning（企微）、info（记录不通知）
• 按 layer 分层：基础设施层 → 中间件层 → 应用层 → 业务层
• 同类告警收敛：5 分钟窗口内同类告警合并
• 配置告静默窗口：发布期间临时静默非关键告警

Q22：告警太多怎么办？你怎么做告警降噪？

考察点： 告警治理能力（JD 直接提到”问题响应”）

[!success] 回答要点 告警降噪五层策略：

策略	手段	示例
1. 告警收敛	同服务同指标 5 分钟内合并	同一个 Pod 的 CPU 告警只发一次
2. 告警分组	按服务+severity 聚合发送	一个服务的多条告警合并成一条消息
3. 告警抑制（Inhibition）	父告警触发时抑制子告警	节点挂了 → 抑制该节点上所有 Pod 告警
4. 告警分级	按 severity 路由到不同通道	critical→电话，warning→企微，info→不通知
5. 告警静默（Silence）	发布/维护期间临时静默	大促发布期间静默非关键告警

Alertmanager 抑制规则示例：

inhibit_rules:
  - source_match:
      alertname: NodeDown     # 节点挂了
    target_match_re:
      alertname: Pod.*Down     # 抑制该节点上 Pod 告警
    equal: ['node']

如果被追问”你怎么衡量告警治理效果”：

• 告警有效率：有效告警 / 总告警（目标 > 80%）
• 告警处理时间：从告警到响应的 P50/P90 延迟
• 告警总量趋势：治理前后对比

Q23：Prometheus 的数据模型是什么？怎么写一个 PromQL 查询？

考察点： 监控工具理解深度

[!success] 回答要点 Prometheus 数据模型：

• 所有数据都是时序数据（time series）
• 每条数据 = 指标名{label1=v1, label2=v2} value timestamp
• 指标类型：Counter（只增不减）、Gauge（可增可减）、Histogram（分桶）、Summary（分位数）

常用 PromQL（面试必会）：

# 1. 查询某服务当前 QPS（Counter 用 rate）
rate(http_requests_total{service="api-gateway"}[5m])

# 2. 查询某服务 P99 延迟（Histogram 用 histogram_quantile）
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{service="api-gateway"}[5m]))

# 3. 查询错误率（5xx / 总请求）
sum(rate(http_requests_total{service="api-gateway", status=~"5.."}[5m]))
/
sum(rate(http_requests_total{service="api-gateway"}[5m]))

# 4. 多服务对比（by）
sum(rate(http_requests_total[5m])) by (service)

# 5. CPU 使用率（利用 Prometheus node_exporter 的指标）
100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

---

三、CI/CD 与发布工程（JD 第 3 条）

Q24：你们的 CI/CD 流程是什么样的？发布怎么保证安全？

考察点： 发布工程能力、变更管理（MTBF 提升）

[!success] 回答要点 标准 CI/CD 流程：

开发提交代码 → CI 流水线 → 构建镜像 → 安全扫描 → 部署 Staging → 自动化测试 → 人工审批 → 部署 Prod

安全发布五层保障：

层级	手段	说明
1. CI 门禁	单元测试 + lint + 镜像扫描	不通过不让合入
2. Staging 验证	自动化回归 + 人工验证	上 Prod 前最后一道关
3. 灰度发布	Argo Rollouts / 自研灰度	金丝雀 → 10% → 50% → 100%
4. 回滚机制	一键回滚 + 版本管理	任何时刻可在 1 分钟内回滚
5. 发布监控	发布期间监控核心指标	5xx/延迟异常自动暂停发布

灰度发布方案（面试常问）：

# Argo Rollouts 金丝雀策略
strategy:
  canary:
    steps:
      - setWeight: 10          # 先灰度 10% 流量
      - pause: { duration: 5m } # 观察 5 分钟
      - setWeight: 50          # 扩到 50%
      - pause: { duration: 5m }
      - setWeight: 100         # 全量

如果被追问”你怎么做回滚”：

• 应用层：Argo Rollouts 自动回滚（配置 auto-promotion-enabled: false + analysis template）
• 镜像层：保留最近 3 个版本镜像，回滚就是改 image tag
• 数据层：数据库变更不可回滚（DDL 慎重），DML 通过备份恢复

Q25：你用过什么 CI/CD 工具？Jenkins / GitLab CI / ArgoCD？

考察点： 工具链广度

[!success] 回答要点 坦诚说出你实际用过的，不要编。但要对主流工具有基本认知：

工具	定位	特点
Jenkins	CI 为主	插件丰富，但流水线即代码（Jenkinsfile）较重
GitLab CI	CI+CD 一体	与 GitLab 深度集成，.gitlab-ci.yml 简洁
ArgoCD	CD 为主	GitOps 模式，K8s 原生，声明式发布
Argo Rollouts	灰度发布	金丝雀/蓝绿发布，替代原生 Deployment
Flux	CD 为主	GitOps 模式，比 ArgoCD 更轻量

趋势认知（加分）： “我觉得 GitOps 是 K8s 时代发布管理的方向——以 Git 为唯一可信源，集群状态自动收敛。我们目前用 Jenkins + 手动 kubectl apply，正在向 ArgoCD 迁移。“

---

四、系统设计题（JD 第 2 条：高可用架构）

Q26：设计一个高可用的 API 网关架构，要求支持 10 万 QPS。

考察点： 高可用架构设计能力

[!success] 回答框架 从上到下分层设计：

DNS (智能DNS + 多线路)
  ↓
SLB (云负载均衡，多可用区)
  ↓
Nginx Ingress (多副本 + HPA)
  ↓
API Gateway (Kong/APISIX，多副本)
  ↓
后端微服务 (HPA + 多副本)
  ↓
缓存 (Redis Cluster) + 数据库 (主从 + 读写分离)

每一层的高可用设计：

层	高可用手段	容量规划
DNS	多 DNS 解析、健康检查剔除	—
SLB	多可用区部署、健康检查	按带宽选规格
Nginx	多副本 + HPA、连接复用	单实例 5万-10万 QPS
API Gateway	HPA + 熔断 + 限流	按 CPU 扩容
微服务	HPA + 多可用区反亲和 + 熔断降级	按 CPU/内存扩容
Redis	Cluster 分片 + 哨兵	按 hot key 分散
MySQL	主从 + 读写分离 + 分库分表	连接池控制

关键设计点（面试一定要主动说）：

1. 多可用区部署：Pod 配 topologySpreadConstraints，跨可用区打散
2. 限流降级：入口限流（Nginx limit_req）→ 服务级限流（Sentinel）→ 资源级限流（DB 连接池）
3. 熔断：下游不可用时快速失败，防止雪崩（Hystrix/Resilience4j/Sentinel）
4. 缓存：热点数据 Redis 缓存 + 本地缓存多级
5. 异步化：非核心链路走 MQ 异步（削峰填谷）

面试官可能追问的容量计算：

• 10 万 QPS → Nginx 单实例 5 万 QPS → 至少 3 个 Nginx（冗余）
• 后端假设单 Pod 2000 QPS → 至少 50 个 Pod + 冗余 → 约 60 个 Pod
• Redis 假设单 key 10 万 QPS → 需要分片，按服务分到多个 key

Q27：如果让你设计一个容灾方案，你怎么做？

考察点： 容灾架构能力

[!success] 回答要点 容灾分层：

级别	方案	RTO	RPO	成本
L1	同 AZ 多副本	分钟级	0	低
L2	跨 AZ 部署	分钟级	0	中
L3	同 Region 跨 AZ + 数据备份	小时级	分钟级	中高
L4	跨 Region 容灾	小时级	分钟级	高
L5	异地多活	秒级	秒级	极高

RTO/RPO 概念（面试必答）：

• RTO (Recovery Time Objective)：恢复时间目标，故障后多快恢复服务
• RPO (Recovery Time Objective)：恢复点目标，允许丢失多少数据

K8s 层面容灾：

# 跨可用区打散
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: critical-service

# 跨节点反亲和
affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: critical-service
          topologyKey: kubernetes.io/hostname

数据层面：

• MySQL：主从复制 + 半同步 → 异步 binlog 到异地
• Redis：Cluster 分片 + AOF 持久化 → AOF 同步到异地
• 对象存储：云厂商跨区域复制（如 OSS 跨区域复制）

Q28：你们有没有做过容量规划？大促前怎么评估？

考察点： 容量规划能力（JD 第 2 条直接提到）

[!success] 回答要点 容量规划三步法：

Step 1: 基线评估（当前水位）
  → 采集当前 QPS、CPU、内存、连接数、磁盘
  → 找到当前系统的瓶颈点（木桶短板）

Step 2: 容量预测（未来需求）
  → 大促预估 QPS = 日常 QPS × 峰值倍数（如 5 倍）
  → 推算各层需要的资源量
  → 各层链路推演：入口 QPS → 各服务 QPS → DB QPS → 缓存 QPS

Step 3: 预扩容 + 压测验证
  → 提前扩到目标副本数（不完全依赖 HPA）
  → 全链路压测验证（模拟真实流量）
  → 压测发现瓶颈再调整

容量评估表（面试时可以说”我们大促前会做这张表”）：

层级	当前容量	预估需求	是否达标	补充计划
Nginx	3 副本 × 5万 QPS	10万 QPS	✅ 15万>10万	—
核心服务	10 Pod × 2000 QPS	10万 QPS	❌ 2万<10万	扩到 50 Pod
Redis	3 节点, 5万 QPS	10万 QPS	❌	扩到 6 节点
MySQL	主从, 5000 QPS	2万 QPS	❌	读写分离+缓存兜底

加分项： “容量规划最大的坑是只看入口 QPS，不看下游链路。上次压测发现 Redis 连接数先到瓶颈，而不是应用 CPU。所以容量评估要从入口逐层推演到 DB 和中间件。“

---

五、Linux 与网络基础（SRE 基本功）

Q29：线上一个服务响应变慢了，你怎么从 Linux 层面排查？

考察点： Linux 性能排查能力

[!success] 回答要点 性能排查四维法（USE 方法 + 四层下钻）：

应用层 → 系统层 → 网络层 → 硬件层

第一步：快速定位瓶颈在哪层

# CPU/内存/IO/网络 一眼看
top -p <pid>            # CPU 和内存概览
vmstat 1                # CPU 是否在 wait/run 队列
iostat -x 1             # 磁盘 IO 是否瓶颈
sar -n DEV 1            # 网络带宽是否打满

第二步：按瓶颈深挖

CPU 高：

top -H -p <pid>         # 看哪个线程 CPU 高
# 如果是 Java：
jstack <pid> | grep -A 20 <thread_hex>  # dump 线程栈
# 如果是 Go：
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30

内存高：

# 看进程内存分布
cat /proc/<pid>/status | grep -E "VmRSS|VmSize"
# 看是否有内存泄漏
pmap -x <pid> | sort -k 3 -rn | head
# 如果是 Java：
jmap -histo:live <pid> | head -20

IO 高：

iotop -o               # 哪个进程在写磁盘
iostat -x 1            # await 高不高（>10ms 算高）
lsof -p <pid>          # 看打开了哪些文件

网络慢：

# 看连接状态
ss -s                   # 连接数概览
ss -tna | grep -c TIME-WAIT   # TIME_WAIT 过多说明短连接太多
# 抓包看延迟
tcpdump -i eth0 -w /tmp/dump.pcap host <target_ip>
# 分析
tcpdump -r /tmp/dump.pcap -nn | head

经典排查链路：

top (定位进程) → top -H (定位线程) → 线程栈/火焰图 (定位代码)

Q30：TIME_WAIT 过多怎么处理？TCP 连接相关的问题怎么排查？

考察点： TCP 网络基础

[!success] 回答要点 TIME_WAIT 产生原因：

• 主动关闭连接的一方进入 TIME_WAIT，持续 2MSL（约 60 秒）
• 短连接场景（HTTP/1.0 或没有 keepalive）大量产生 TIME_WAIT

排查：

# 统计各状态连接数
ss -tna | awk '{print $1}' | sort | uniq -c | sort -rn
# 输出示例：
#  5000 TIME-WAIT
#   200 ESTABLISHED
#    10 LISTEN

# 看哪个端口 TIME_WAIT 多
ss -tna | grep TIME-WAIT | awk '{print $4}' | cut -d: -f2 | sort | uniq -c

解决方案（从治标到治本）：

方案	手段	适用场景
治标-内核参数	net.ipv4.tcp_tw_reuse=1	客户端短连接多
治标-增大端口范围	net.ipv4.ip_local_port_range=10000 65535	客户端端口耗尽
治本-长连接	Nginx upstream keepalive、HTTP/1.1 keepalive	根本解决
治本-连接池	应用层连接池（HikariCP、go-sql-driver）	根本解决

面试表述： “TIME_WAIT 不是问题，是 TCP 协议的正常机制。但大量 TIME_WAIT 导致端口耗尽就是问题。治本方法是长连接+连接池，治标是调内核参数。生产中我优先推长连接方案。“

Q31：你们用 Nginx 做什么？Nginx 调优你做过哪些？

考察点： Nginx 运维能力

[!success] 回答要点 Nginx 在你们架构中的角色：

• Ingress Controller（K8s 入口）
• 反向代理 + 负载均衡
• SSL 终结点
• 限流（limit_req / limit_conn）

常用调优参数（面试能说出来加分）：

# Worker 进程数 = CPU 核数
worker_processes auto;

# 每个 worker 的最大连接数
worker_connections 10240;

# 长连接复用（关键优化！）
upstream backend {
    server 10.0.0.1:8080;
    keepalive 32;          # 保持 32 个长连接复用
}

# HTTP 长连接
keepalive_timeout 65;
keepalive_requests 1000;

# 客户端优化
client_body_timeout 30s;
client_header_timeout 30s;
send_timeout 30s;

# Gzip 压缩
gzip on;
gzip_types text/plain application/json;

# 限流
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;
location /api/ {
    limit_req zone=api burst=200 nodelay;
    proxy_pass http://backend;
}

# upstream keepalive 传递（关键！）
proxy_http_version 1.1;
proxy_set_header Connection "";

Q32：DNS 在你们架构中怎么用？DNS 解析慢怎么排查？

考察点： DNS 基础

[!success] 回答要点 DNS 在 K8s 中的角色：

• CoreDNS 提供 Service 名称解析
• Pod 默认 DNS policy：ClusterFirst（先查 CoreDNS）
• 跨 namespace 解析：<service>.<namespace>.svc.cluster.local

DNS 慢的常见原因：

原因	表现	解决方案
CoreDNS 副本不足	DNS 查询超时	扩 CoreDNS 副本 + HPA
ndots:5 导致多次查询	每次解析查 5 次	调 Pod dnsConfig 的 ndots
Conntrack 表满	DNS UDP 包丢	调大 nf_conntrack_max
Pod 用宿主机 DNS	解析外部慢	确认 dnsPolicy 配置

排查 DNS 问题：

# 在 Pod 内测试
kubectl exec -it <pod> -- nslookup kubernetes.default
kubectl exec -it <pod> -- nslookup <service>.<namespace>.svc.cluster.local

# 看 CoreDNS 日志
kubectl logs -n kube-system -l k8s-app=kube-dns

# 看 CoreDNS 性能
kubectl top pods -n kube-system -l k8s-app=kube-dns

---

六、行为面试题（JD 第 5 条：沟通能力与团队协作）

Q33：说一个你和开发同学产生分歧的经历，你是怎么处理的？

考察点： 沟通能力、冲突处理

[!tip] STAR 框架回答 Situation： “大促前容量评审，开发同学认为当前服务能扛住 5 倍流量，但我从监控数据看 P99 延迟已经 800ms，CPU 利用率日常就 60%，扩容空间不够。” Task： “我需要说服开发同学接受提前扩容，同时不搞僵关系。” Action： “我没有直接说’你的判断不对’，而是拉了 Grafana 看板，把数据摆在台面上：日常 CPU 60%、P99 800ms，按 5 倍算 CPU 到 300% 直接打满。然后我提了一个折中方案——先扩到 3 倍，压测验证后再决定是否扩到 5 倍。” Result： “开发同学认可了数据，同意先扩容+压测。压测结果证明 3 倍确实不够，最终扩到 4 倍。后续大促平稳通过，没有出现服务降级。”

总结（面试官想听的）： “SRE 和开发的冲突本质是稳定性 vs 迭代速度的平衡。我的原则是——用数据说话，不用职位压人；给出方案而不是只提问题。“

Q34：你遇到过最紧急的线上故障是什么？当时你是什么角色？

考察点： 应急响应能力、压力下的决策

[!tip] 回答框架 用 Q4 的 STAR 模板，但重点突出：

• 你的角色：你是发现者、响应者、还是决策者？
• 关键决策点：你在什么时候做了什么决定？（比如决定回滚、决定限流、决定扩容）
• 事后复盘：你从这次故障中学到了什么？推动了什么改进？

加分项： 主动说出自己的失误。比如”这次故障其实我也有责任，变更评审时我没有坚持要求压测，后来我在变更 SOP 里加了’核心服务变更必须附带压测报告’这一条。“

Q35：你怎么看待加班和值班？

考察点： 值班态度、工作生活平衡认知

[!tip] 建议回答

“值班是 SRE 岗位的职责的一部分，我理解并接受。但我认为好的 SRE 应该致力于减少被动救火的时间，把更多精力放在预防性建设上——完善告警、自动化 Runbook、混沌演练。如果天天加班处理告警，说明系统设计或告警策略有问题，需要从根上改进。”

避免说的： “我不介意加班”（显得没有思考） 或 “我不接受频繁加班”（直接被刷）。 好的态度： 接受值班、主动建设、追求减少被动工作量。

Q36：你为什么想来我们公司？你对这个岗位有什么期待？

考察点： 求职动机、职业规划

[!tip] 建议回答

“我看重三个方面：

1. 技术方向：JD 里提到 MTTR/MTBF 体系建设和 SRE Agent 落地，这跟我当前在做的事情高度匹配，我希望在一个更体系化的 SRE 团队里深耕。
2. AI+运维：我自己在做 AI 根因分析系统，希望公司能支持这个方向的持续探索和落地，而不是只是喊口号。
3. 成长空间：我希望能在更大的业务规模和更成熟的团队中提升体系化能力，从’解决问题’走向’预防问题’。”

避免说： “我想学习新技术”（你是来干活的不是来上课的）、“现在公司发展不好”（负能量）。

Q37：你有什么想问我的？（面试最后的反问环节）

考察点： 你对岗位的真实关注点

[!success] 建议问的问题（选 2-3 个）

1. 团队规模：“SRE 团队目前多少人？跟开发团队的比例大概是多少？”
2. 技术栈：“目前线上是全部在 K8s 上吗？有没有传统运维的部分？”
3. SRE 成熟度：“目前团队的 MTTR/MTBF 有没有在量化？告警有效率大概多少？“（问这个说明你真懂 SRE）
4. AI 方向：“JD 里提到 SRE Agent，目前有什么规划吗？是已经有团队在做，还是需要我来推动？”
5. 值班的安排：“值班怎么排？on-call 频率大概是多少？“（关心工作方式是合理的）
6. 成长路径：“这个岗位之前的人是因为什么原因离开的？“（有点大胆，但能获取关键信息）

不要问的： “你们加班多吗？“（显得只想摸鱼）、“薪资范围是多少？“（留给 HR 聊）、“我面试能过吗？“（不专业）。

---

七、加分项问题（展示深度思考）

Q38：你怎么看 AIOps 的未来？LLM 会取代 SRE 吗？

考察点： 对行业趋势的判断力

[!tip] 建议回答

“我的判断是 LLM 不会取代 SRE，但会重塑 SRE 的工作方式。具体来说：

1. LLM 擅长的：信息检索、日志分析、模式识别、报告生成——这些是 SRE 的体力活，会被替代。
2. LLM 不擅长的：架构决策、变更风险评估、跨团队协调、复杂故障的因果推理——这些是 SRE 的脑力活。
3. 趋势：SRE 的价值会从’能快速排查故障’转向’能设计不出故障的系统’。AI 帮你缩短 MTTR，但 MTBF 的提升还是要靠工程能力。
4. 我的选择：我不担心被 AI 取代，我在做的是把 AI 变成我的工具——这就是 SRE Agent 的意义。“

Q39：如果让你从 0 搭建一套 SRE 体系，你会怎么做？

考察点： 体系化思维、优先级判断

[!success] 回答框架 分阶段建设（不要想一口气全做完）：

Phase 1 (0-3月)：止血——可观测性 + 告警
  → Prometheus + Grafana + Alertmanager
  → 四金指标覆盖核心业务
  → 告警分级路由

Phase 2 (3-6月)：提效——自动化 + CI/CD
  → CI/CD 流水线 + 灰度发布
  → 自动化巡检 + Runbook
  → 告警降噪收敛

Phase 3 (6-12月)：体系建设——SLI/SLO + MTTR/MTBF
  → SLI/SLO 定义 + 错误预算
  → 故障 RCA 闭环流程
  → MTTR/MTBF 度量看板

Phase 4 (12月+)：预防性建设——混沌 + AI
  → 混沌工程演练
  → AI 根因分析
  → 容量规划自动化

关键原则： “先止血再提效，先工具化再智能化。不要在告警都没配好的时候就开始搞 AI。“

Q40：你最近在学什么新技术？

考察点： 学习能力、技术敏感度

[!tip] 建议回答（结合自己的实际情况） 谈一个你真正在看的技术方向，而不是泛泛而谈。可选方向：

• eBPF（内核级可观测性，Cilium 用的就是 eBPF）
• WASM（WebAssembly 在边缘计算的探索）
• K8s Operator 模式（CRD + Controller，自动化运维场景）
• OpenTelemetry（统一可观测性标准）
• AI Agent 框架（LangGraph、CrewAI、AutoGen）

关键： 要能说出你看了什么、学到什么程度、打算怎么用。不要说”我在关注 AI”——太泛了。

---

关联知识

• SRE 面试备战手册 — 主文档
• SRE 面试补全内容 — 15 道自测题 + 代码题
• 高可用架构设计总览 — Q26/Q27 系统设计
• 容量规划方法论 — Q28 容量规划
• 故障生命周期管理 — Q22 告警降噪
• 变更管理全流程 — Q24 CI/CD
• 弹性伸缩策略 — Q26 HPA

状态

• 简历深挖题（Q16-Q20）
• 监控与告警体系（Q21-Q23）
• CI/CD 与发布工程（Q24-Q25）
• 系统设计题（Q26-Q28）
• Linux 与网络基础（Q29-Q32）
• 行为面试题（Q33-Q37）
• 加分项问题（Q38-Q40）
• 实际面试验证