SRE面试完整指南

本指南整理自 sre-interview-prep-guide 项目，旨在帮助准备SRE（Site Reliability Engineer）面试的工程师系统性地学习和复习相关知识。

一、SRE概述与技能要求

1.1 什么是SRE

Google定义：

"SRE is what happens when you ask a software engineer to design an operations team."
（当你让软件工程师来设计运维团队时，你得到的就是SRE）

更广泛的定义：构建和维护大规模可靠SaaS平台的实践

SRE核心理念：

理念	说明
减少Toil	开发工具和系统减少重复性工作
自动化一切	部署、维护、测试、扩缩容、故障缓解
全面监控	可观测性是基础
可扩展设计	从一开始就考虑扩展性
弹性架构	构建足够可靠的架构
风险管理	通过SLA/SLO/SLI管理变更和风险
从故障中学习	事后复盘和持续改进

1.2 SRE核心职责

职责领域	说明
基础设施管理	管理和维护生产环境的基础设施
监控	建立和维护监控系统，确保服务可观测性
事件管理	响应和处理生产环境中的故障和事件
基础设施与可靠性相关自动化	自动化运维工作，减少人工干预
应用性能（可选）	部分组织将其视为开发团队的职责

1.3 SRE技能图谱

graph TD A[SRE核心技能] --> B[系统与网络] A --> C[编程与自动化] A --> D[可观测性] A --> E[可靠性工程] B --> B1[Linux系统管理] B --> B2[网络协议TCP/IP/HTTP] B --> B3[容器与编排Kubernetes] C --> C1[Python/Go/Shell] C --> C2[IaC工具Terraform/Ansible] C --> C3[CI/CD流水线] D --> D1[监控Prometheus/Grafana] D --> D2[日志ELK/Loki] D --> D3[追踪Jaeger/Zipkin] E --> E1[SLI/SLO/SLA] E --> E2[容量规划] E --> E3[故障管理]

1.4 必备技能详解

技能	重要性	说明
编程	⭐⭐⭐⭐⭐	语言不限，当前市场Go和Python最流行
监控	⭐⭐⭐⭐⭐	实现良好可靠性的关键，需要持续进行监控
CI/CD	⭐⭐⭐⭐⭐	已融入每个开发流程
IaC	⭐⭐⭐⭐⭐	通过代码管理基础设施，避免手动操作
配置管理	⭐⭐⭐⭐⭐	与IaC配合，实现基础设施的代码化管理

1.5 SRE vs DevOps

DevOps：一套通用原则
SRE：一个清晰、详细的模型，有明确的规则和指南

Google的SRE实践是独特的，其他公司可能只采用部分实践。

1.6 SRE团队成熟度模型

graph LR A[阶段1: 运维] --> B[阶段2: 自动化] B --> C[阶段3: 产品] A --> A1[响应问题] A --> A2[处理请求] B --> B1[构建自动化思维] B --> B2[提供工具和自服务] C --> C1[提升可靠性] C --> C2[优化性能]

二、简历撰写指南

2.1 SRE简历结构

graph TD A[SRE简历结构] --> B[个人简介] A --> C[工作经历] A --> D[技能清单] A --> E[教育背景] B --> B1[3-4句话总结] B --> B2[为什么选择SRE] C --> C1[相关工作经历] C --> C2[量化成果] D --> D1[技术技能] D --> D2[软技能] D --> D3[工具经验] E --> E1[学位] E --> E2[认证]

2.2 量化成果（最重要！）

Quantify, quantify, quantify!（量化、量化、再量化！）

量化维度	示例
系统规模	"管理了200+台服务器的基础设施"
MTTR改进	"将平均恢复时间从2小时降低到15分钟（87.5%改进）"
事故率	"在任期内将事故率降低了60%"
可用性	"将服务可用性从99.9%提升到99.99%"
自动化	"自动化了80%的重复运维任务"
成本节省	"通过资源优化每月节省$50,000云成本"

2.3 具体工具展示

类别	工具示例
混沌工程	Gremlin, Chaos Monkey, Litmus
监控	Prometheus, Grafana, DataDog, New Relic
容器编排	Kubernetes, Docker Swarm
IaC	Terraform, Pulumi, CloudFormation
CI/CD	Jenkins, GitLab CI, ArgoCD, GitHub Actions
云平台	AWS, GCP, Azure

2.4 简历Tips

优先级排序：最重要的技能放最前面
简洁明了：避免冗长描述
仔细校对：SRE需要注重细节，简历上的错别字可能影响专业性
没有直接SRE经验？：挖掘相关经历，创造性地展示

三、面试流程与准备

3.1 SRE面试流程概览

graph TD A[人才发现] --> B[简历筛选] B --> C[HR电话初筛] C --> D[技术电话面试1] D --> E[技术电话面试2] E --> F[现场面试Onsite] F --> G[反馈汇总] G --> H{是否录用} H -->|是| I[发放Offer] H -->|否| J[感谢信] F --> F1[编程面试] F --> F2[系统排障] F --> F3[网络知识] F --> F4[系统设计] F --> F5[Linux内核]

3.2 各阶段时间线

阶段	时长	间隔
HR电话初筛	~30分钟	-
技术电话面试1	~45-60分钟	约1周后反馈
技术电话面试2	~45分钟	约1周后反馈
现场面试	5轮 × 45分钟	几天内安排
最终结果	-	约1周后反馈

3.3 理想候选人特质

graph TD A[理想SRE候选人] --> B[聪明Smart] A --> C[执行力强Gets things done] A --> D[自我驱动Self-directed] A --> E[多样化背景Diverse] A --> F[主动性Takes Initiative] A --> G[独立解决问题]

核心问题：

"这是一个我想与之共事的优秀人才吗？"

3.4 Google SRE技能自评表

在电话面试前，会被要求对以下技能进行0-10分自评：

技能领域	细分
网络	TCP/IP、OSI模型、DNS等
系统	Unix/Linux内核、系统管理
编程	算法与数据结构
语言	C、C++、Python、Java、Perl
脚本	sh、Bash、ksh、csh
数据库	SQL、数据库管理

重要提示：面试问题会基于你自评较高的领域提问！

3.5 面试准备清单

领域	准备内容
编程	算法、数据结构、至少一门语言精通
系统	Linux内核、进程管理、文件系统
网络	TCP/IP、DNS、HTTP、OSI模型
脚本	Bash、Python自动化脚本
排障	系统化的问题解决方法
设计	大规模系统设计方法论

四、求职经验与面经分享

4.1 如何进入SRE领域

graph TD A[当前位置] --> B{距离SRE多远?} B -->|近| C[直接申请SRE] B -->|远| D[规划跳跃路径] D --> E[识别需要的技能] E --> F[获取这些技能] F --> G[获得更接近SRE的工作] G --> H{是否到达?} H -->|否| E H -->|是| I[成为SRE]

4.2 可能的职业路径

起点	可能的路径
学生	Bootcamp → 开发实习 → 初级开发 → 运维工作 → SRE
客服/支持	技术支持 → 系统管理员 → 运维 → SRE
开发工程师	开发 → 参与on-call → DevOps → SRE
系统管理员	系统管理 → 自动化 → DevOps → SRE

4.3 面试考察的五大领域

领域	考察内容	深度要求
编程	算法、数据结构、实际编码	中等（非脑筋急转弯）
系统	Linux内核、进程、文件系统	深入
网络	TCP/IP、DNS、HTTP	深入应用层
故障排查	问题诊断、系统化思维	实战经验
可扩展架构	系统设计、容量规划	高层设计能力

4.4 编程面试技巧

先写正确版本：即使效率低
再考虑优化：时间允许的话
大声思考：让面试官了解你的思路
主动提问：澄清需求和约束
考虑边界情况：空输入、大数据等
防御性编程：异常处理、输入验证

4.5 经典开放问题

"你在浏览器输入URL并回车，会发生什么？"

答题框架：

DNS解析
TCP连接建立
TLS握手（如果是HTTPS）
HTTP请求发送
服务器处理
HTTP响应返回
浏览器渲染

4.6 关键经验教训

成功因素：

充分准备：不要低估面试难度
保持冷静：紧张是最大的敌人
展示思考过程：比答案更重要
不要放弃：一次失败不代表终结
持续学习：这是终身的过程

常见失败原因：

系统设计准备不足
遇到困难时过于紧张
只知其然不知其所以然
沟通不畅，无法清晰表达

五、系统设计案例

5.1 系统设计面试方法论

graph TD A[系统设计面试] --> B[1. 需求澄清] B --> C[2. 容量估算] C --> D[3. 高层设计] D --> E[4. 组件设计] E --> F[5. 数据模型] F --> G[6. 优化方案] G --> H[7. 瓶颈处理]

5.2 需求澄清框架

类型	问题示例
功能性需求	用户能做什么？核心功能是什么？
非功能性需求	可用性、延迟、一致性要求？
规模	用户数量？请求量？数据量？
约束	技术限制？预算？时间？

5.3 WhatsApp架构设计

功能需求：

一对一聊天
已发送/已送达/已读状态
图片分享
推送通知

容量估算：

指标	数值
月活用户	10亿
峰值活跃用户/秒	65万
峰值消息/秒	4000万

高层架构：

graph TD A[用户Alice] --> B[Chat Server A] C[用户Bob] --> D[Chat Server B] B --> E[Chat Storage] D --> E B --> F[Transient Service] F --> G[Transient Storage]

5.4 Uber架构设计

行程生命周期：

graph LR A[请求行程] --> B[匹配司机] B --> C[司机接单] C --> D[前往接客] D --> E[开始行程] E --> F[行程进行中] F --> G[行程结束] G --> H[支付/评价]

核心组件：

组件	职责
Driver Location Manager	维护司机位置变化
Trip Dispatcher	处理行程请求，派单
ETA Calculator	计算预计到达时间
Trip Recorder	记录行程中GPS信号
Map Matcher	将GPS信号匹配到实际道路
Price Calculator	计算行程价格

5.5 Netflix架构设计

高层架构：

graph TD subgraph 控制平面 A[Content Uploader] B[CDN Health Checker] C[Title Indexer] end subgraph 数据平面 E[Playback Service] F[Steering Service] end G[CDN/Open Connect] --> H[用户设备]

弹性设计：

Chaos Monkey：随机终止生产实例
Hystrix：熔断器，隔离失败服务

5.6 系统设计通用模式

数据存储选择：

类型	代表	适用场景
关系型	MySQL, PostgreSQL	复杂查询、事务
文档型	MongoDB	灵活schema、聚合
列式	Cassandra	高写入、时间序列
图数据库	Neo4j	复杂关系
键值	Redis, DynamoDB	缓存、会话

必知延迟数字：

操作	延迟
L1缓存	0.5ns
L2缓存	7ns
主内存	100ns
SSD随机读	150μs
HDD寻道	10ms
同数据中心网络往返	0.5ms
跨区域网络往返	150ms

六、CI/CD设计模式

6.1 部署策略对比

策略	停机时间	资源消耗	回滚速度	风险控制
Recreate	有	低	慢	低
Ramped	无	低	慢	中
Blue/Green	无	高(2x)	即时	高
Canary	无	中	快	高
A/B Testing	无	中	快	高
Shadow	无	高(2x)	N/A	最高

6.2 部署策略详解

Blue/Green（蓝绿部署）

graph TD subgraph 阶段1[阶段1: Blue运行] LB1[Load Balancer] --> A1[Blue v1] G1[Green v2] -.- |待命| G2[Green v2] end subgraph 阶段2[阶段2: 切换到Green] LB2[Load Balancer] --> G3[Green v2] B1[Blue v1] -.- |待命| B2[Blue v1] end

优点：即时发布/回滚、零停机
缺点：需要双倍资源

Canary（金丝雀发布）

graph TD subgraph 阶段1[阶段1: 5%流量] LB1[Load Balancer] LB1 -->|95%| A1[Version A] LB1 -->|5%| B1[Version B] end subgraph 阶段2[阶段2: 25%流量] LB2[Load Balancer] LB2 -->|75%| A2[Version A] LB2 -->|25%| B2[Version B] end

优点：面向部分用户发布、快速回滚
适用：对新版本稳定性信心不足时

6.3 部署策略选择指南

graph TD A[选择部署策略] --> B{允许停机?} B -->|是| C[Recreate] B -->|否| D{需要快速回滚?} D -->|是| E{资源充足?} E -->|是| F[Blue/Green] E -->|否| G[Canary] D -->|否| H{需要用户测试?} H -->|是| I[A/B Testing] H -->|否| J[Ramped]

6.4 Pipeline设计模式

7大模式：

graph TD A[Pipeline设计模式] --> B[1.Pipeline即代码] A --> C[2.可复用库] A --> D[3.构建与部署分离] A --> E[4.触发正确Pipeline] A --> F[5.快速反馈] A --> G[6.稳定内部发布] A --> H[7.规范产品发布]

核心原则：

Pipeline逻辑代码化，与应用代码一起存储
一次构建多次部署
快速反馈，并行化任务

七、监控与可观测性

7.1 四大黄金指标（Golden Signals）

graph TD A[四大黄金指标] --> B[Latency 延迟] A --> C[Traffic 流量] A --> D[Errors 错误] A --> E[Saturation 饱和度] B --> B1[请求处理时间] C --> C1[服务使用量] D --> D1[失败请求率] E --> E1[资源消耗程度]

指标	定义	关键点
延迟	处理请求所需时间	使用百分位数（p99、p95），避免平均值
流量	单位时间服务使用量	Web应用用请求数，数据库用查询数
错误	请求失败比率	区分4xx和5xx
饱和度	资源消耗程度	CPU、内存、磁盘、网络

7.2 SLI/SLO/SLA概念

概念	定义	示例
SLI	服务水平指标	请求成功率、延迟百分位
SLO	服务水平目标	可用性99.9%、p99延迟<200ms
SLA	服务水平协议	SLO + 违约后果
Error Budget	错误预算	100% - SLO

7.3 为什么100%不是好目标

核心原则：100%可靠性不是正确目标！

原因：

即使有冗余，也有非零概率同时失败
用户体验链路很长，任何环节都可能失败
追求100%意味着无法更新或改进服务
100%目标只会让团队被动响应

7.4 SLO设置流程

graph TD A[开始] --> B[选择关键SLI] B --> C[测量当前性能] C --> D[设定初始SLO] D --> E[获得利益相关者同意] E --> F[制定错误预算策略] F --> G[监控和告警] G --> H[持续改进]

7.5 PromQL查询示例

# API可用性
sum(rate(http_requests_total{host="api", status!~"5.."}[7d]))
/
sum(rate(http_requests_total{host="api"}[7d]))

# P99延迟
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[7d]))

# 每秒错误数
sum(rate(http_requests_total{status=~"5.."}[5m]))

7.6 告警设计原则

级别	响应时间	通知方式
P1/Critical	立即	电话、短信
P2/High	< 1小时	Slack、邮件
P3/Medium	当天	邮件
P4/Low	下个迭代	工单

原则：

针对症状，而非原因
消除噪音：避免误报
可操作：每个告警都应有明确响应
提供上下文：告警包含足够信息

八、SRE核心实践与流程

8.1 Toil（重复劳动）管理

Google定义：

"Toil是一种倾向于手动、重复、可自动化、战术性、缺乏持久价值、且随服务增长线性扩展的工作。"

Toil示例：

处理配额请求
应用数据库schema变更
审查非关键监控告警
从Playbook复制粘贴命令

Google SRE目标：Toil < 50%，工程项目 > 50%

8.2 SRE参与模式

模式	说明	优点	缺点
咨询型	SRE独立运作，提供指导	服务全组织	难以深入技术
嵌入型	SRE加入开发团队	深入理解产品	可能影响力有限
基础设施团队	SRE构建运维关键系统	完全控制路线图	错过协作机会

8.3 事件管理与响应

事件响应 vs 事件管理：

维度	事件响应(IR)	事件管理(IM)
性质	战术性、被动	战略性、主动
范围	立即处理事件	全生命周期管理
目标	控制、缓解、恢复	防止复发、持续改进

事件响应生命周期（NIST）：

graph LR A[准备] --> B[检测与分析] B --> C[控制/根除/恢复] C --> D[事后活动] D --> A

事件指挥官(IC)三大核心职责：

填充事件层级
最终决策者
促进信息流通

8.4 On-Call优化

Follow the Sun模式：

graph LR A[亚太时区] -->|交接| B[欧洲时区] B -->|交接| C[美洲时区] C -->|交接| A

On-Call自动化：

集成到监控告警系统
轻松切换排班
自动路由告警
自动升级
自动创建聊天/作战室

8.5 系统弹性金字塔

graph TD A[测试与可观测性] --> B[容错] B --> C[数据] C --> D[系统设计] D --> E[基础设施]

各层要点：

层次	关键考虑
基础设施	冗余、备份、网络弹性、多区域
系统设计	架构选择、分区、可扩展性
数据	复制、一致性、完整性
容错	冗余设计、优雅降级、重试退避
测试与可观测性	单元测试、集成测试、混沌工程

8.6 大厂SRE实践

LinkedIn SRE三大原则：

Site Up：让每个工程师考虑可靠性
赋能开发者所有权：开发者端到端拥有其工作
运维是工程问题：用工程能力解决问题

Google SRE核心实践：

没有SLO就没有SRE的必要
SLO指导工程工作优先级
错误预算政策指导决策

8.7 风险分析公式

Risk = TTD × TTR × (Freq/Year) × (% of users)

TTD = Time to Detect（检测时间）
TTR = Time to Resolve（解决时间）
Freq = 每年发生频率
Users = 受影响用户百分比

九、附录与资源

9.1 SRE面试常见问题汇总

问题	关键点
什么是SRE？	用软件工程方法解决运维问题
SRE vs DevOps？	SRE是DevOps的一种实现方式
什么是Toil？	手动、重复、可自动化的工作
四大黄金指标是什么？	Latency, Traffic, Errors, Saturation
SLI/SLO/SLA区别？	指标、目标、协议
为什么100%不是好目标？	无法实现、阻止改进、被动响应
解释蓝绿部署	两套环境并行，流量切换，即时回滚
如何计算错误预算？	100% - SLO

9.2 推荐书籍与资源

资源类型	名称	说明
书籍	Site Reliability Engineering	Google SRE官方书籍
书籍	The Site Reliability Workbook	SRE实践工作手册
书籍	Seeking SRE	SRE社区经验分享
书籍	TCP/IP Illustrated	网络基础
书籍	The Linux Programming Interface	Linux深入理解
书籍	Systems Performance (Brendan Gregg)	性能分析
网站	sre.google	Google SRE官方资源
网站	highscalability.com	大厂架构案例
GitHub	System Design Primer	系统设计入门
练习	LeetCode/Codewars	编程练习

9.3 面试准备计划

阶段	时长	重点
基础夯实	2-4周	数据结构、算法、Linux基础
专项突破	2-4周	针对薄弱领域深入学习
模拟面试	1-2周	Mock interview、限时练习
最终冲刺	1周	复习、调整状态

9.4 术语表

术语	全称	含义
SRE	Site Reliability Engineering	站点可靠性工程
SLI	Service Level Indicator	服务水平指标
SLO	Service Level Objective	服务水平目标
SLA	Service Level Agreement	服务水平协议
MTTR	Mean Time To Recovery	平均恢复时间
MTTF	Mean Time To Failure	平均故障时间
MTBF	Mean Time Between Failures	平均故障间隔时间
MTTD	Mean Time To Detect	平均检测时间
Toil	-	重复性、手动、可自动化的运维工作
Error Budget	-	错误预算
Postmortem	-	事后复盘/故障报告
IC	Incident Commander	事件指挥官
SME	Subject Matter Expert	主题专家
IaC	Infrastructure as Code	基础设施即代码
GitOps	-	基于Git的运维方法

📝 文档状态: 完整版

📅 最后更新: 2025-11-25

📚 详细内容: 请参考各分类文档（01-08）获取更详细的内容

posted @ 2025-12-03 11:17 iXiAo9 阅读(0) 评论(0) 收藏举报

刷新页面返回顶部

iXiAo9

SRE面试完整指南

SRE面试完整指南

目录

一、SRE概述与技能要求

1.1 什么是SRE

1.2 SRE核心职责

1.3 SRE技能图谱

1.4 必备技能详解

1.5 SRE vs DevOps

1.6 SRE团队成熟度模型

二、简历撰写指南

2.1 SRE简历结构

2.2 量化成果（最重要！）

2.3 具体工具展示

2.4 简历Tips

三、面试流程与准备

3.1 SRE面试流程概览

3.2 各阶段时间线

3.3 理想候选人特质

3.4 Google SRE技能自评表

3.5 面试准备清单

四、求职经验与面经分享

4.1 如何进入SRE领域

4.2 可能的职业路径

4.3 面试考察的五大领域

4.4 编程面试技巧

4.5 经典开放问题

4.6 关键经验教训

五、系统设计案例

5.1 系统设计面试方法论

5.2 需求澄清框架

5.3 WhatsApp架构设计

5.4 Uber架构设计

5.5 Netflix架构设计

5.6 系统设计通用模式

六、CI/CD设计模式

6.1 部署策略对比

6.2 部署策略详解

Blue/Green（蓝绿部署）

Canary（金丝雀发布）

6.3 部署策略选择指南

6.4 Pipeline设计模式

七、监控与可观测性

7.1 四大黄金指标（Golden Signals）

7.2 SLI/SLO/SLA概念

7.3 为什么100%不是好目标

7.4 SLO设置流程

7.5 PromQL查询示例

7.6 告警设计原则

八、SRE核心实践与流程

8.1 Toil（重复劳动）管理

8.2 SRE参与模式

8.3 事件管理与响应

8.4 On-Call优化

8.5 系统弹性金字塔

8.6 大厂SRE实践

8.7 风险分析公式

九、附录与资源

9.1 SRE面试常见问题汇总

9.2 推荐书籍与资源

9.3 面试准备计划

9.4 术语表

公告