SRE 面试备战手册

基于 2026-08-03 模拟面试整理，覆盖 JD 全维度考点、标准答案、薄弱点分析与补强计划。关联知识库已有笔记，形成完整知识网络。

概述

目标岗位：SRE 工程师，JD 核心四条：

MTTR/MTBF 体系建设，线上稳定性负责
云基础架构（容量规划、高可用、问题响应、根因定位）
SRE 工具链与稳定性工程建设
SRE Agent 等 AI 应用提效落地

候选人背景：东北大学 985 本科（非 CS 科班），轻松健康集团运维开发工程师，负责互联网医疗 C 端业务 SRE。

JD 拆解与匹配度

序号	职责	面试考察点
1	MTTR/MTBF 体系建设	SLO/SLI 定义、MTTR 四段模型、错误预算管理、RCA 闭环
2	云基础架构	K8s 调度/HPA/资源治理、故障排查方法论、高可用设计
3	SRE 工具链	CI/CD、监控告警体系、自动化巡检、Runbook
4	SRE Agent / AI 提效	LLM Tool Calling、AIOps 架构、知识库设计、Agent 循环

要求	匹配度	说明
211+ 学历优先，计算机相关	⚠️ 部分	985 满足学历，但专业为资源循环科学与工程
2 年以上经验	✅ 满足	2022.06 至今约 4 年，SRE 方向约 2 年
熟悉 Golang/Python	⚠️ 偏弱	项目中用了 Python/Go，但代码基础能力需加强
熟悉 SRE 方法论	⚠️ 偏弱	有实践但缺乏体系化认知
AI 应用对运维提效	✅ 亮点	AI 根因分析、AI 巡检、Ops Workbench 方向高度匹配

自我介绍优化

[!warning] 原始回答的问题 “核心竞争力是勇于学习新事物” — 学习意愿是基本盘，不是核心竞争力。面试官想听的是”你做了什么别人做不了的事”。

[!tip] 优化版本 “我是徐航，东北大学 985 本科，目前在轻松健康集团负责互联网医疗 C 端业务的 SRE 与运维开发。

核心竞争力三点：

AI 驱动的故障定位：独立设计 AI 根因分析系统，融合 SkyWalking 链路、SLS 日志和 Prometheus 指标，通过 LLM Tool Calling 渐进式分析，故障定位时间从约 1 小时降至约 30 分钟，降幅 50%。

K8s 规模化治理：管理 4 套 ACK 环境、200 节点、1000 微服务、3000 Pod，负责容量规划、HPA 策略、OOM/Pending 治理，保障核心业务 99.9% 可用性。

运维全栈开发：Python/Go/Rust 均有项目落地，独立开发 OpsAgent（Go）、mySSH（Rust）、SSL 证书分发平台（Python+React 全栈）等工具。“

SLI / SLO / MTTR / MTBF 体系

[!info] 关联笔记详见 MTTR 与 MTBF 体系详解，本节为面试精简版。根因定位方法论见根因定位方法论。

SLI 与 SLO

SLI = 成功请求数 / 总请求数    （必须精确定义"成功"）
SLO = SLI ≥ 99.9%              （目标值）

“成功”必须精确定义——面试必答：

维度	必须回答	举例
哪些请求算	全量 HTTP 请求还是特定接口？	排除健康检查/内部探活
什么状态算成功	2xx+3xx？4xx 算不算？	5xx 算失败，4xx（客户端错误）不算 SLI 分母
统计窗口	28 天滚动窗口	Google SRE 标准做法
采样方式	全量还是采样	全量采集

错误预算

99.9% 可用性 = 每月允许 43.2 分钟不可用

预算消耗策略：
  < 50%  → 正常发布，可承担风险
  50-80% → 只允许低风险变更
  > 80%  → 冻结非紧急发布
  耗尽   → 完全冻结发布，强制稳定性建设

MTTR 四段拆解

详见 MTTR 与 MTBF 体系详解，面试精简版：

故障发生 ──→ 检测 ──→ 响应 ──→ 诊断 ──→ 修复 ──→ 恢复
         |-- MTTD --||-- MTTA --||-- Diagnose --||-- Fix --|

MTTR = MTTD + MTTA + Diagnose + Fix

阶段	全称	含义	优化手段
MTTD	Mean Time To Detect	故障发生到告警触发	告警规则优化、指标采集频率
MTTA	Mean Time To Acknowledge	告警触发到人工响应	值班机制、告警分级、告警收敛
Diagnose	诊断时间	开始排查到定位根因	日志/链路/指标关联、AI 根因分析
Fix	修复时间	定位根因到执行恢复	回滚、扩容、切流、自动化 Runbook

[!tip] 关键连接点 你的 AI 根因分析项目 = 优化 Diagnose 环节。这就是项目跟 JD 第 1 条的连接点，面试时一定要这样表述。

MTBF 提升

故障 RCA 闭环：每起故障产出 action item → 跟踪落地 → 同类故障不再复现
容量治理：提前扩容，别等挂了才扩 — 详见容量规划方法论、弹性伸缩策略
变更管理：灰度发布、变更评审 — 详见变更管理全流程
混沌工程：主动注入故障 — 详见混沌工程与故障注入

K8s 容量与 HPA 故障排查

[!info] 关联笔记弹性伸缩详见弹性伸缩策略，故障排查详见故障生命周期管理。

场景题

某核心服务配 HPA：CPU request=2 核，target utilization=80%，min=2，max=20。大促流量来了，Pod 从 2 扩到 20，但扩容跟不上，出现 503。

HPA 关键参数

参数	作用	默认值
target utilization	触发扩容的 CPU 阈值	80%
scaleUp behavior	扩容速率限制	max(2, 当前×25%) 每 15 秒
scaleDown behavior	缩容速率限制	更保守
HPA controller 轮询间隔	多久评估一次	15 秒
metrics-server 延迟	指标采集延迟	15-30 秒

排查思路（自上而下）

步骤	排查方向	关键命令
①	HPA 扩得慢不慢	`kubectl describe hpa <name>` 看 Events、LastScaleTime
②	Pod 有没有 Pending	`kubectl get pods -o wide` + `kubectl describe pod`
③	Pod Ready 慢不慢	`kubectl describe pod` 看 Events 中的 Readiness probe
④	Ready 了流量没进来	SLB/Ingress backend health check 更新状态
⑤	下游瓶颈	DB/Redis 连接数和负载

根因概率排序

根因	概率	说明
节点不足导致 Pending	高	集群没有多余节点可调度，最常见
HPA 扩容速率限制	中高	默认 behavior 太保守
Pod 冷启动慢	中	应用初始化 + readiness probe 延迟
上游 LB 健康检查延迟	中	SLB backend 更新有延迟
下游依赖瓶颈	低	水平扩容不解决下游

HPA 加速扩容配置

behavior:
  scaleUp:
    stabilizationWindowSeconds: 0  # 不做稳定窗口等待
    policies:
      - type: Percent
        value: 100
        periodSeconds: 15           # 每 15 秒最多扩 100%
    selectPolicy: Max

[!tip] 预防措施预扩节点池、优化 readiness probe 缩短 initialDelaySeconds、大促前手动扩到目标副本数。

AI 根因分析系统架构

[!info] 关联笔记 SRE Agent 落地详见 SRE Agent 运维落地实践，LLM 辅助 RCA 详见 LLM 辅助 RCA 与日志分析，AIOps 详见 AIOps 实践与智能运维。

系统整体架构

graph TD
    ALERT[告警系统 Prometheus] -->|Webhook| ENTRY[AI根因分析入口<br/>构建初始Context]
    ENTRY --> LLM[LLM 推理 + Tool Calling 循环]
    LLM -->|调用| TOOLS[Tool 注册表]
    TOOLS --> T1[query_skywalking_trace]
    TOOLS --> T2[query_sls_logs]
    TOOLS --> T3[query_prometheus_metrics]
    TOOLS --> T4[query_k8s_status]
    TOOLS --> T5[query_k8s_events]
    TOOLS --> T6[search_rca_knowledge]
    LLM -->|输出| RESULT[根因分析 + 处理建议]
    RESULT --> KB[知识库/案例库<br/>结构化存储]
    KB -.->|相似度匹配| LLM

502 故障分析完整链路

[!example] 标准示例：502 错误率飙升的渐进式分析

Round 1 — 定位故障层

LLM 思考：502 是网关错误，先看调用链定位失败在哪一跳
→ Tool：query_skywalking_trace(service="service-A", time_range="最近10分钟")
→ 结果：SLB→Ingress→service-A 正常，service-A→service-B 大量 502
→ 收敛：故障在 service-A → service-B 这一跳

Round 2 — 查后端日志

LLM 思考：service-B 连不上或异常，查日志
→ Tool：query_sls_logs(service="service-B", keyword="error", time_range="最近10分钟")
→ 结果：日志出现 “OOMKilled” / “connection refused”
→ 收敛：service-B Pod 可能挂了

Round 3 — 确认 Pod 状态

→ Tool：query_k8s_status(namespace="prod", resource="service-B")
→ 结果：3/5 Ready，2 个 Pod 处于 CrashLoopBackOff
→ Tool：query_k8s_events(namespace="prod", resource="service-B")
→ 结果：“OOMKilled”，最近 5 分钟重启 8 次

Round 4 — 监控指标确认

→ Tool：query_prometheus_metrics(metric="container_memory_working_set_bytes", service="service-B")
→ 结果：内存使用在流量高峰突增到 limit 上限

Round 5 — 输出根因和建议

根因：service-B memory limit (512Mi) 过低，流量高峰 OOM，Pod CrashLoop
建议：提升 limit 至 1Gi、检查 HPA、排查内存泄漏

Round 6 — 知识库沉淀

存入：{症状:"502飙升", 根因:"OOM", 服务:"service-B", 方案:"提升limit"}
下次类似告警优先匹配历史案例，加速收敛

面试必答的关键设计点

不是一次性丢所有数据给 LLM — 每轮根据上一步结果决定下一步查什么，这是”渐进式收敛”的本质
Tool Calling 的决策权在 LLM — 你设计了 Tool 的 schema 和描述，引导 LLM 走正确排查路径
知识库不是简单文档 — 结构化的”症状→根因→解决方案”案例库，支持相似度匹配
护栏机制 — 限制最大轮次（防死循环）、加超时控制、加结果校验

告警去重器（代码题）

题目

实现 AlertDeduplicator：相同 service+severity 的告警 5 分钟内只保留第一条，支持并发安全。

Python 实现

import threading
import time
from dataclasses import dataclass


@dataclass
class Alert:
    service: str
    severity: str
    message: str


class AlertDeduplicator:
    def __init__(self, window_seconds: int = 300):
        self._lock = threading.Lock()
        self._last_seen: dict[str, float] = {}  # "service:severity" → timestamp
        self._window = window_seconds
        self._stop = threading.Event()
        t = threading.Thread(target=self._cleanup_loop, daemon=True)
        t.start()

    def should_alert(self, alert: Alert) -> bool:
        key = f"{alert.service}:{alert.severity}"
        now = time.time()
        with self._lock:
            last = self._last_seen.get(key)
            if last is not None and (now - last) < self._window:
                return False  # 窗口内重复，丢弃
            self._last_seen[key] = now
            return True  # 首次或已过期，放行

    def _cleanup_loop(self):
        while not self._stop.wait(60):  # 每 60 秒清理一次
            now = time.time()
            with self._lock:
                expired = [
                    k for k, v in self._last_seen.items()
                    if (now - v) >= self._window
                ]
                for k in expired:
                    del self._last_seen[k]

    def stop(self):
        self._stop.set()

Go 实现

package main

import (
    "sync"
    "time"
)

type Alert struct {
    Service  string
    Severity string
    Message  string
}

type AlertDeduplicator struct {
    mu       sync.Mutex
    lastSeen map[string]time.Time
    window   time.Duration
    stopCh   chan struct{}
}

func NewAlertDeduplicator(window time.Duration) *AlertDeduplicator {
    d := &AlertDeduplicator{
        lastSeen: make(map[string]time.Time),
        window:   window,
        stopCh:   make(chan struct{}),
    }
    go d.cleanupLoop()
    return d
}

func (d *AlertDeduplicator) ShouldAlert(a Alert) bool {
    key := a.Service + ":" + a.Severity
    d.mu.Lock()
    defer d.mu.Unlock()

    now := time.Now()
    if last, ok := d.lastSeen[key]; ok {
        if now.Sub(last) < d.window {
            return false // 窗口内重复，丢弃
        }
    }
    d.lastSeen[key] = now
    return true // 首次或已过期，放行
}

func (d *AlertDeduplicator) cleanupLoop() {
    ticker := time.NewTicker(1 * time.Minute)
    defer ticker.Stop()
    for {
        select {
        case <-ticker.C:
            d.mu.Lock()
            now := time.Now()
            for key, last := range d.lastSeen {
                if now.Sub(last) >= d.window {
                    delete(d.lastSeen, key)
                }
            }
            d.mu.Unlock()
        case <-d.stopCh:
            return
        }
    }
}

func (d *AlertDeduplicator) Stop() {
    close(d.stopCh)
}

设计要点

设计决策	原因
数据结构用 map/dict	O(1) 查找，key 用 `service:severity` 组合键
并发用 Mutex/Lock	map 不是并发安全的，多协程同时写会 panic
锁粒度在函数级	简单够用；高 QPS 可优化为分片锁或 sync.Map
后台清理 goroutine/thread	防止 map 无限增长，每分钟扫一次删过期 key
返回 bool 而非直接丢弃	让调用方决定处理方式，解耦

[!question] 进阶追问

告警量大锁竞争严重？ → 分片锁（按 key hash 分 N 个桶），或 sync.Map

进程重启内存丢了？ → 5 分钟窗口短影响有限；严格可用 Redis SET key val EX 300 NX

分布式去重？ → Redis: SET service:severity:timestamp NX EX 300，TTL 自动过期

面试评估总结

各板块评分

板块	评分	关键问题	补强方向
SLI/SLO/MTTR	⚠️ 偏弱	99.9% 写简历但讲不清落地；MTTR/MTBF 不了解	理解 MTTR 四段模型，把 AI 项目定位为优化 Diagnose 环节
K8s/云原生	⚠️ 中下	HPA 场景排查思路浅，概念混淆	手动跑命令，理解 behavior policies 参数
AI/AIOps 项目	⚠️ 有亮点	方向对但讲不清系统细节	画架构图：Tool 列表→LLM 循环→知识库→输出
代码能力	❌ 需补强	不能默写基础并发代码	去重器、限流器、生产者消费者，手写一遍

[!success] 核心优势

985 院校背景（东北大学）

AI+运维项目方向与 JD 高度匹配

技术栈广（Python/Go/Rust），有技术热情和自驱力

个人项目（OpsAgent/mySSH/Ops Workbench）有实际落地

[!warning] 核心风险

非计算机科班，CS 基础需证明

SRE 方法论缺乏体系化认知

代码能力需要面试中直接证明

简历每一条都可能被深挖

补强行动计划

第一优先级：面试前必做

理解 MTTR 四段模型 — 能画出完整链路，关联 MTTR 与 MTBF 体系详解
准备 AI 项目架构图 — 告警入口→Tool 列表（函数签名）→LLM 循环→知识库→输出
准备 502 分析完整案例 — 按 Round 1-6 格式，准备一个真实经历过的故障
手写代码练习 — 告警去重器、令牌桶限流器，Go 和 Python 各一遍

第二优先级：面试前建议做

HPA 实操 — 在测试集群跑 kubectl describe hpa，理解 behavior 参数
SLO 定义练习 — 为自己负责的业务写一个完整的 SLI/SLO 定义文档
错误预算计算 — 算清楚 99.9% 对应的每月允许不可用时间
Tool Calling 原型 — 用 OpenAI API 写一个最简的 Tool Calling 循环（3 个 Tool 即可）

第三优先级：长期建设

CS 基础 — 数据结构（map/queue/heap）、操作系统（进程/线程/锁）、网络（TCP/HTTP/DNS）
SRE 经典阅读 — 《SRE: Google 运维解密》《The SRE Workbook》
开源贡献 — 参与 kube-prometheus、prometheus-operator 等
代码刷题 — LeetCode 中等难度，重点：并发、数据结构、字符串处理

面试高频问题清单（自测）

SRE 方法论

你负责的业务 SLO 是什么？SLI 怎么定义的？错误预算怎么管理？
MTTR 和 MTBF 你们怎么度量？MTTR 拆成几个阶段？每个阶段怎么优化？
你们做不做混沌工程？做不做变更冻结？RCA 的 action item 怎么跟踪闭环？
你经历过的最严重的一次线上故障是什么？讲一下从发现到恢复的全过程。

K8s / 云原生

HPA 的扩容和缩容策略分别是什么？默认值是多少？怎么加速扩容？
Pod 状态有哪些？Pending 和 CrashLoopBackOff 分别怎么排查？
requests 和 limits 的区别？不设 limits 会怎样？HPA 依赖哪个？
你们 K8s 网络模型是什么？CNI 用的什么？NetworkPolicy 用过吗？

AI / AIOps

你的 AI 根因分析系统，LLM 具体做了什么决策？Tool Calling 的流程画出来。
知识库是怎么建设的？RAG？向量库？图结构？相似度怎么算的？
LLM 分析出错了怎么办？有没有护栏机制？结果怎么校验？
你觉得 AI 在 SRE 领域还有哪些应用场景？SRE Agent 应该具备什么能力？

代码能力

写一个令牌桶限流器（支持并发安全）
写一个简单的 HTTP 健康检查器（并发检查多个 endpoint，超时控制）
写一个日志 tail 工具（监听文件变化，实时输出新增内容）

关联知识

MTTR 与 MTBF 体系详解 — 本篇是其面试应用版，核心概念来源
根因定位方法论 — Diagnose 环节的方法论
故障生命周期管理 — MTTR 各阶段的管理流程
弹性伸缩策略 — HPA 策略详解
容量规划方法论 — 容量治理
变更管理全流程 — MTBF 提升手段
混沌工程与故障注入 — MTBF 提升手段
高可用架构设计总览 — 高可用设计
SRE Agent 运维落地实践 — AI Agent 在 SRE 的落地
LLM 辅助 RCA 与日志分析 — AI 根因分析
AIOps 实践与智能运维 — AIOps 整体实践
SRE 稳定性工程总览 — SRE 方法论总览
无指责复盘与故障分析方法论 — RCA 与复盘

参考资源

Google SRE Book: Service Level Objectives
Google SRE Workbook: Measuring and Managing Reliability
Kubernetes HPA Documentation: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
OpenAI Function Calling Documentation: https://platform.openai.com/docs/guides/function-calling