说实话我对“考证”这件事的偏见曾经非常重。做了八年多的运维从机房搬机器、半夜救故障到云原生环境下管上百个微服务和一套复杂的可观测性体系我一直信奉一个朴素道理运维能力是日夜盯着监控、一次次复盘总结出来的不是靠一纸证书撑起来的。所以去年公司推进数字化运维转型要求核心骨干去拿 PeopleCert 的 SRE 和 DevOps 双认证时我内心是相当抵触的。但整个备考和考试过程彻底改变了我的判断。这两本证书分别补上了我在“组织协作”和“量化可靠性”两个维度上的系统性空白。考完之后再回看团队里那些争论了很多年的架构问题和流程问题我突然发现大家终于有了共同语言。这篇东西不聊口号只聊我实际踩过的路这两个认证到底考什么、为什么双证组合比单证值、备考期间需要什么样的计算机网络基本功以及怎么把证书真正变成生产力。1. 为什么是“SRE DevOps”这对组合1.1 一个管“怎么协作”一个管“怎么量化”先给结论这两个认证不是二选一的关系也不是谁替代谁而是同一件事的两个侧面。这一点很多人第一眼没看透容易把它们当成两个独立的、可以互相替换的技术证书。DevOps 源于要打破开发与运维之间的那堵墙它关注的是文化、流程、自动化、度量与分享核心是“人和组织怎么协作”。而 SRE也就是 Site Reliability Engineering源自 Google 内部把软件工程方法应用到运维领域的实践它关注的是“系统怎么稳定”强调用工程手段解决运维问题。打个比方DevOps 解决的是“餐厅后厨和前厅到底要不要吵架”SRE 解决的是“客人等菜超过多少分钟算事故一个月能容忍几次超时”。前者是工作方式和团队氛围后者是量化标准和工程手段。PeopleCert 作为全球知名的认证考试机构承接了这两套认证的官方考试与发证。很多人熟悉 PeopleCert 是因为 ITIL 和 PRINCE2其实在收购 DevOps Institute 之后它把 SRE、DevOps、DevSecOps 这一整条数字化运维认证线也纳入了体系。这意味着你可以在同一个账户体系里完成预约、考试、取证流程标准化程度很高对上班族来说非常方便。1.2 单证和双证的差距用一次真实故障说清楚单证玩家和双证玩家在实际工作中的差别我用一次真实故障来举例。某天线上一个核心接口的 5xx 错误率从 0.1% 开始爬升监控告警已经触发。如果只懂 SRE第一反应是看 SLO错误预算还剩多少要不要进入冻结发布窗口。但如果团队没有 DevOps 的协作基础告警打到群里没人认领开发觉得是运维的责任运维觉得是新版本引入的问题双方扯皮半小时故障持续扩大。反过来只懂 DevOps 的人会说“我们应该加强自动化测试、加强协作、加快反馈”但到底多强的自动化才够一个季度的错误预算该怎么定没有 SRE 的量化手段所有口号都会在故障面前变成无休止的会议。双证的价值恰好在这里SRE 提供量化决策依据告诉你错误预算耗尽后必须立即回滚DevOps 提供把决策落地的协作机制告诉你回滚之后如何通过价值流分析找到必须增加的自动化质量门禁。这两套知识在真实故障里是咬合在一起的缺任何一个最终都会落到“道理都懂就是干不动”的尴尬局面。1.3 数字化运维到底需要什么样的人这两年到处在讲数字化运维落到实际工作中我理解的数字化运维不是买几套监控工具、搞一个大屏就算完成而是把运维对象、运维过程和运维决策全部变成可量化的数据闭环。这个闭环里既需要文化层面的推动力也需要工程层面的度量尺子。从招聘侧也能清晰看到这个趋势。越来越多岗位描述里明确写着“熟悉 SRE 方法论、了解 DevOps 实践”不少中大型公司在面试运维和 SRE 岗位时已经把相关认证作为明确加分项。原因不复杂证书本身确实不代表能力但它意味着候选人至少系统接触过一套被行业验证过的话语体系。团队里一旦有几个人拥有共同的话语体系讨论问题时就完全不需要从零解释“什么是错误预算”“什么是价值流”开会效率能提升一个量级。我考完双证后最明显的变化就是和开发、产品、测试开会时大家开始用同一套术语聊可用性和发布节奏。2. 拆解PeopleCert双认证的考试体系2.1 SRE认证考什么从起源到工程实践我在 PeopleCert 体系里考的是 SRE Foundation也就是站点可靠性工程基础认证。它对应的是 DevOps Institute 课程体系里的标准入门认证核心目标是让学员理解 SRE 的起源、价值观和基础工程实践。课程内容大致覆盖这么几个模块SRE 的起源与核心价值观、SLI 与 SLO 的设计方法、错误预算的构建与使用、如何识别和消除琐碎工作toil、可观测性体系的搭建思路、故障响应与复盘方法、容量规划以及安全性和可靠性怎么结合。每个模块都在围绕一个核心问题展开在快速迭代和稳定运行之间到底怎么用软件工程的方式找到平衡点。以 SRE Foundation 为例考试题型是单选题时长约 60 分钟题量大约 50 道合格线在 70% 左右。我备考时最深刻的感受是题目不考死记硬背而是给你一个具体场景让你判断这里应该用 SLI 还是 SLO该选择哪种错误预算策略或者某项重复手工作业到底值不值得自动化。这种出题方式逼着你去理解概念背后的逻辑单纯背定义是过不去的。2.2 DevOps认证考什么CALMS五个维度同期考的 DevOps Foundation内容偏理念、原则和落地路径核心可以概括成 CALMS 五个维度文化Culture、自动化Automation、精益Lean、度量Measurement、分享Sharing。考试覆盖 DevOps 的起源、价值流管理、持续集成和持续交付的基本概念、小批量交付的收益、反馈机制以及 DevOps 工具链的常见分类。相比 SRE FoundationDevOps Foundation 对技术深度要求更低但对“流程”和“组织”的理解要求更高。它不会问你 Kubernetes 里的某个参数怎么配而是问你在一个传统 IT 部门里推动变革第一步最应该推动什么。两门考试的差异我用一张表总结项目DevOps FoundationSRE Foundation定位文化、流程、协作入门可靠性工程入门核心内容CALMS、价值流、CI/CD、反馈SLI/SLO、错误预算、toil、可观测性侧重点人和组织怎么协作系统怎么稳定、怎么量化题量与时长约40题/60分钟约50题/60分钟合格线约65%约70%技术门槛较低中等偏上表格里的数字我记得是这个范围但 PeopleCert 偶尔会调整考试规则具体以官方最新考试手册为准。别拿网上两三年前的旧数据当标准。2.3 双证怎么衔接先考哪个更顺手我的建议是两门一起学、分开考考试顺序没有强制要求但从学习效率角度我强烈推荐先考 DevOps Foundation再考 SRE Foundation。理由很简单DevOps Foundation 先给你搭起一个宏观框架让你理解软件交付和运维的全局长什么样文化和流程的底层逻辑是什么SRE Foundation 再往这个框架里填充具体的工程尺子比如 SLO 怎么定、错误预算怎么算、toil 怎么分类。先宏观后微观符合大多数人的认知习惯知识吸收效率会高很多。当然如果你已经在团队里强力推行 SRE 多年反过来先考 SRE再用 DevOps 认证补齐文化和变革方法论也完全可行。我团队里就有一个同事这么干他的体会是“先有尺子再补文化”同样能走通。关键是别两门课孤立地背要让两套知识在你脑子里形成咬合关系。3. 备考前的知识底色计算机网络是绕不开的基本功3.1 只看官方教材不够用的原因很多准备考 SRE 和 DevOps 的同行来问我同一个问题是不是把官方教材和官方课件背熟就能稳过。我的回答是考试能过但会非常吃力而且考完你会发现知识落不了地。PeopleCert 的这两个认证本质上考的是概念理解和决策判断不是纯技术考试。但题目场景里到处是计算机网络常识。比如 SLO 里定义一个接口的可用性你至少得看得懂 HTTP 5xx 和 4xx 的语义区别知道超时对错误统计的影响理解 CDN 响应和源站响应之间的延迟差在哪。这些知识不会专门出现在 SRE 教材里它们属于工程师的基本功。这也就是大家常搜的那个话题devops 工程师学习的计算机网络到底要学到什么程度。我的答案是不需要你成为 CCNA 级别的网络专家但至少要把“分层定位”的思维刻进脑子里。因为无论是看监控、定 SLO、排查故障还是做容量规划你面对的其实都是网络协议栈上的一层层服务。3.2 按可靠性工程重组的网络知识清单我把计算机网络里跟 SRE、DevOps 最相关的部分按可靠性视角重新梳理了一遍你可以对着自查TCP/IP 分层模型排查连接超时、连接被重置时第一步就是判断问题发生在哪一层。SRE 考试里大量故障场景题本质上就是分层定位题。HTTP 协议族状态码语义、幂等性、Keep-Alive、重试机制。4xx 和 5xx 的边界在计算 SLO 时是分水岭4xx 通常算客户端问题是否计入可用性需要团队明确策略。DNS解析过程、TTL、CNAME、故障切换。DNS 配置错误导致全站不可用是我见过的最高频“低级但致命”的故障没有之一。负载均衡与反向代理流量调度、健康检查、会话保持、超时配置。这部分直接对接 SRE 里的服务路由和容量规划考点。网络性能指标延迟、带宽、丢包、抖动。SRE 特别关注“延迟”这个用户可感知指标但没有网络基础你很难理解为什么延迟分布P50/P95/P99比平均延迟更有意义。常用排查工具ping、traceroute、curl、dig、tcpdump。工具本身不在考试范围内但理解它们的输出能帮你在真实故障场景里快速定位这也是备考时最好的实践题。这些知识零散分布在大学教材、运维博客和各种课程里关键不是背概念而是建立一张“网络知识点到可靠性场景”的映射关系表。比如看到“连接超时”要能想到 TCP 握手、防火墙策略、负载均衡后端健康状态、应用线程池这几个排查方向而不仅仅是“重启一下”。3.3 真实案例网络知识怎么变成SRE决策拿一个真实例子说明。某次服务页面偶发加载慢开发看后端接口的平均耗时只有 200 毫秒坚决声称后端没有问题。运维用浏览器抓包一看TTFB 直接跳到了 3 秒继续分层排查发现是 CDN 回源连接在高峰期出现大量 TCP 重传源站带宽被打满导致丢包。如果没有网络分层思维这个问题大概率会走上“重启服务”或者“盲目加服务器”的老路。SRE 的知识告诉你“延迟是 SLO 的核心指标需要重点盯防”而网络知识则告诉你延迟具体碎在哪一段DNS 解析、TLS 握手、首字节返回、内容传输各占多少毫秒。两套知识总是在这里咬合SLO 告诉你“必须把 P95 延迟降到 1 秒以下”网络知识告诉你“当前瓶颈在回源带宽而不是应用逻辑”。我在双证备考期间把类似案例整理成了十几个小场景每个场景都强制自己回答三个问题这个故障发生在网络哪一层SLO 里哪个指标最受影响如果要写一条告警规则应该用什么指标、什么阈值这套练习对考试和实际工作都有用。4. 双证备考实操路线与考场经验4.1 时间分配与复习资料选择我的备考周期是两个月白天正常上班晚上复习平均每天一小时左右周末多学一些。第一门 DevOps Foundation 用了三周第二门 SRE Foundation 用了四周最后两周用来刷官方样题和做交叉复习。这个节奏适合有至少一年运维或研发经验的人如果是纯零基础建议再多留一个月。复习资料我只用了三类官方课程讲义和官方教材、PeopleCert 官方样题、自己整理的概念对照表。网上那些来路不明的“题库”我完全没碰一方面涉及版权风险另一方面那些所谓“原题”很多是旧版本答案也未必对。最靠谱的路径就是官方教材为纲、官方样题测理解、用实际工作场景反过来验证概念。给你一张我当年的时间表做参考阶段周期核心动作第一阶段第1-2周通读 DevOps Foundation 教材整理 CALMS 笔记第二阶段第3周做 DevOps 官方样题标记错题对应的知识点第三阶段第4-6周通读 SRE Foundation 教材重点啃 SLO/错误预算第四阶段第7周SRE 样题训练同步建立 DevOps 与 SRE 概念对照表第五阶段第8周两科交叉复习重做所有错题看官方大纲自查4.2 亲测有效的三种复习方法第一种概念对照表法。DevOps 和 SRE 两套体系里有大量重叠词汇比如可用性、自动化、监控、告警、容量每一个词在两边的侧重点都不同。我把这些词做成了双栏对照表左边写 DevOps 视角右边写 SRE 视角每天睡前过一遍。这个方法帮我解决了最大的概念混淆问题。第二种讲给别人听。我每周在团队内部做一次小范围分享主题就是 SRE 概念比如错误预算怎么算、toil 怎么分类。能讲明白才是真理解。这个效果比闷头做十道题都管用因为你要面对同事的追问问题会逼着你想清楚每一个边界条件。第三种绑定真实故障复盘。备考期间部门正好出了两次线上故障我刻意用 SRE 的复盘框架去梳理事实时间线、触发因素、缓解动作、根因分析、行动项。这个过程等于是把课程内容在真实场景里完整走了一遍考试遇到类似场景题时我基本就是拿真实经验去套答案准确率很高。4.3 报名考试与线上监考的七个细节PeopleCert 的考试可以选线下考点也可以选线上远程监考。我两次都选的线上图的是时间灵活、不用来回跑。报名流程并不复杂在 PeopleCert 账户里预约考试时间选远程监考提前下载好监考客户端做一次系统环境检查考试当天提前 15 分钟进入等待区按提示完成身份验证和环境检查。有几个细节我必须提醒第一考试房间必须安静且光线充足桌面上不能放手机、纸质笔记连一杯水都最好不放监考员会要求用摄像头 360 度展示房间环境。第二摄像头要能拍到你的手和屏幕房间里不能有其他人走动宠物最好也关到别的房间。第三网络必须稳定强烈建议用有线网络并且提前跟家人打招呼别在你考试的时候开视频会议或者下载大文件。第四提前做系统检查PeopleCert 的监考客户端对操作系统和浏览器版本有要求用公司电脑考的话还要确认没有安全软件拦截。第五考试界面可以选语言我建议英文界面配中文资料复习后面专门讲为什么。第六遇到突发情况千万别慌监考员会通过文字或语音跟你沟通配合调整就行。第七考完立刻就能看到成绩通过的话电子证书一般在几个工作日内发放到账户纸质证书看地区和邮寄时间。5. 常见问题与避坑记录5.1 DevOps和SRE到底什么关系一个流传最广的误读这个问题我被问过不下二十次。最普遍的误读是“DevOps 包含 SRE”或者“SRE 就是 DevOps 的升级版”。我的理解是DevOps 是一套文化和实践框架SRE 是 Google 工程团队用大量实际经验验证过的、具体实现 DevOps 目标的一种工程方法。你可以把 SRE 看作 DevOps 思想在可靠性领域的一个“经过验证的参考实现”但两者不是简单的包含关系。SRE 里有大量 DevOps 框架不涉及的技术细节比如错误预算、容量规划、toil 管理DevOps 里也有 SRE 不重点讲的组织变革、文化转型内容。考试时最容易翻车的就是把这个词安到另一套体系的考纲里。建议备考时专门记一张对照表维度DevOpsSRE核心关注人和流程系统和可靠性关键工具价值流、CI/CD、协作文化错误预算、SLO、toil 管理考纲关键词CALMS、交付、反馈SLI/SLO、可观测性、容量典型问题怎么让开发和运维停止扯皮怎么决定今晚能不能上线5.2 备考资料里的三个深坑第一坑看旧版题解。PeopleCert 的认证体系这几年一直在迭代网上流传的很多中文笔记是两三年前的版本连合格线都跟现版对不上。你按旧版复习很可能在考场上发现考纲变了。第二坑迷信刷题技巧。这两个认证大量使用场景题四个选项看起来都很有道理不真正理解概念就只能靠猜。我在模拟练习里做过统计纯靠排除法做场景题正确率不到一半。第三坑忽视官方考纲。官方最值钱的资料其实是 Syllabus也就是考试大纲它把每个考点分成了“记住、理解、应用”三个层级。按大纲自查能清晰看到自己哪些知识点只停留在“记住”还达不到“应用”。我最后一周就是把大纲打印出来一个考点一个考点过凡是不确定能举出实际例子的回头重看讲义。5.3 考场翻车现场与应对策略第一时间分配。DevOps Foundation 题目数量虽不算多但场景题阅读量大我第一次模拟考时差点在后半段时间不够。后来调整策略每道题最多一分钟拿不准的立即标记25 分钟连做带标记剩下时间回头专门处理标记题。第二中英文术语的映射问题。如果你选中文考试界面一定要注意翻译不一定精准。比如 error budget 有时被译成“错误预算”有时是“失误预算”SLO 有时被译成“服务级别目标”有时直接用英文缩写。我强烈建议平时看英文材料考试也选英文界面避免被翻译干扰。第三远程监考的容差问题。我第二次考试时监考员中途要求我调整摄像头角度中断了大约三分钟好在计时不受影响心态别崩配合调整就行。另外提前关掉所有弹窗通知包括聊天软件和浏览器插件否则切屏行为会被记录严重时可能被判违规。6. 双证到手之后让能力真正翻倍的三个抓手6.1 落地SLO和错误预算拿到证书只是起点真正让能力翻倍的是把方法论用回工作中。我拿到双证后做的第一件事是在团队里推动 SLO 和错误预算。先挑了一个最核心的外部接口花一周时间定出 SLI指标选了两个可用性和延迟。然后根据业务容忍度定了一个季度的错误预算预算耗尽就触发冻结发布窗口。这件事刚开始阻力很大有开发同事觉得“SLO 就是给我找麻烦”。但一旦有了量化数据讨论就变得很务实错误预算还剩 3%要不要为一个小优化冒发布风险数据说话争论自然消失。这个经验让我确信SLO 不只是考核指标更是团队内部“安全感”的来源。6.2 用价值流思维重梳发布流程第二件事是用 DevOps 的价值流思维去梳理发布流程。我把从代码提交到线上发布的整个过程画成价值流图标出每一步的等待时间。结果发现最大的瓶颈不是测试而是人工审批环节一个简单的变更要等两个审批人轮流确认平均耗时超过半天。针对这个瓶颈我们引入了自动化质量门禁把常规变更的审批从“人等审批”变成“机器按规则判断”。这个动作把发布周期从两天压缩到一天以内。值得强调的是这个改进不是因为上了某个工具而是因为价值流图让你看清瓶颈在哪儿DevOps 只是给了你拆掉瓶颈的方法论。6.3 建立Toil清单与后续扩展路线第三件事是建立团队的 toil 清单。我们每周统计重复手动的、没有长期价值的工作按 SRE 的 toil 特征打分手动、重复、可自动化、无长期价值。得分最高的优先处理。光是“手工清理环境”“人工检查证书过期时间”这两项自动化之后每周就省出了大概五六个小时这些时间又投入到更有价值的容量规划和稳定性建设上。双证完成后我建议的后续路线是三条线一是考 SRE Practitioner把基础概念升级成设计能力二是往 DevSecOps 或者云原生方向延伸把安全和云平台能力叠加起来三是补齐工程硬技能比如 Kubernetes、Prometheus、Grafana、混沌工程。证书给你的是框架硬技能给你的是工具两者结合才是数字化运维时代相对完整的画像。写到这里说点我个人的体会。考完双证的那天我并没有感到“能力翻倍”真正的翻倍发生在后面三个月。当我开始用错误预算和其他团队谈发布节奏、用价值流图跟开发解释流程瓶颈、用 toil 清单说服领导投入自动化改造时大家讨论问题的方式变了从互相抱怨变成了共同找方法。证书本身不会替你干活但它会给你的经验装上一套被行业验证过的思维框架。如果你也在犹豫要不要考我的建议很直接先弄懂这两套框架适不适合你的处境再决定要不要拿证。方向对了双证就是水到渠成的事。