企业官网建设流程全解析

说实话，我对“考证”这件事的偏见曾经非常重。做了八年多的运维，从机房搬机器、半夜救故障，到云原生环境下管上百个微服务和一套复杂的可观测性体系，我一直信奉一个朴素道理：运维能力是日夜盯着监控、一次次复盘总结出来的，不是靠一纸证书撑起来的。所以去年公司推进数字化运维转型，要求核心骨干去拿 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 Foundation，DevOps Foundation 对技术深度要求更低，但对“流程”和“组织”的理解要求更高。它不会问你 Kubernetes 里的某个参数怎么配，而是问你在一个传统 IT 部门里推动变革，第一步最应该推动什么。

两门考试的差异，我用一张表总结：

表格里的数字我记得是这个范围，但 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 官方样题、自己整理的概念对照表。网上那些来路不明的“题库”我完全没碰，一方面涉及版权风险，另一方面那些所谓“原题”很多是旧版本，答案也未必对。最靠谱的路径就是官方教材为纲、官方样题测理解、用实际工作场景反过来验证概念。

给你一张我当年的时间表做参考：

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 不重点讲的组织变革、文化转型内容。考试时最容易翻车的，就是把这个词安到另一套体系的考纲里。建议备考时专门记一张对照表：

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 清单说服领导投入自动化改造时，大家讨论问题的方式变了，从互相抱怨变成了共同找方法。证书本身不会替你干活，但它会给你的经验装上一套被行业验证过的思维框架。如果你也在犹豫要不要考，我的建议很直接：先弄懂这两套框架适不适合你的处境，再决定要不要拿证。方向对了，双证就是水到渠成的事。