科学健康资讯 · 内容仅供参考，不替代专业诊疗 联系我们|疾病百科
投稿

sre工程师需要会什么，SRE需要具备什么能力

2023-05-10 投稿 本文链接

关于【sre工程师需要会什么】，今天小编给您分享一下，如果对您有所帮助别忘了关注本站哦。

1、sre工程师需要会什么：什么是SRE？SRE需要具备什么能力？

对于SRE一词，想必大家已经不陌生了，满世界都在讲SRE，但是SRE到底是个什么角色？负责哪些工作呢？今天来给大家解惑一下。

SRE最早是由Google提出的概念，其大概的意思就是：以标准化、自动化、可扩展驱动维护，用软件开发解决运维难题。这个岗位面世的时候，其根本要解决的问题就是打破传统研发人员快速迭代而引发的业务不稳定性，用以保证业务维护侧重的服务质量以及稳定性之间的平衡。

不同公司的SRE定位是不同的，可能某些公司的运维岗位也是SRE，因此，不能以偏概全，国内的SRE基本是以岗位来区分的，比如，有负责网络的SRE，有负责DBA的SRE，有专门负责业务的SRE，还有什么安全SRE等等。就谷歌所提到的SRE的理解来讲，基本都是以服务质量稳定为基线的维护工程师，只是对于SRE的要求是苛刻的，下面是我的个人理解：

综上所述，国内现在的SRE，大致可以分成俩个层级，PasS-SRE和业务SRE，前者主要是维护平台基建服务质量为主的SRE，后者主要是维护业务服务质量稳定性为主的SRE，业务SRE比较像业务运维。

上面的定义只适合大厂，对于还没有传播SRE文化，SRE的岗位是比较模糊的，其定位可能就是一个运维开发工程师，要解决的问题也是全面的、多元化的。在推广SRE文化以及建设SRE工作守则的时候，需要对当前的业务架构、技术架构有全面的了解，并合理的对基建做好设计、规划、调整，这样，SRE文化才会被更好的推行下去。

下面的都是由网上整理而来，因为SRE的工作范围是由谷歌最早提出以及实践过的，所以，他的工作范围就如下所示，万变不离其宗，在这里其实有一个很核心的关键点，那就是基建的稳定性决定了SRE的工作效率，因此，我们在建设SRE文化与工作职责的时候，也要把基建的一些因素考虑进去。

以下为《SRE谷歌运维解密》一书当中已经提到了关键点：

可观测性系统

在任何有一定规模的企业内部，一旦推行起来整个SRE的运维模式，那么对于可观测性系统的建设将变得尤为重要，而在整个可观测性系统中，通常我们会分为如下三个方面：

一整套的可观测系统，它能确保你洞察系统，跟踪系统的健康状态、可用性以及系统内部发生的事情。

对于整个可观测系统的建设，需要注意如下两点：

在整个企业级可观测系统中，我认为至少应该包括如下几个特征：

可观测系统是整个运维体系的基础，它需要提供整个运维体系的数据化支持。

因此，一个企业级的可观测性系统应该是平台化的。一方面可以通过配置或者开发实现更多 运维指标的接入；另一方面，亦可对接更多的专业运维工具，整合并打通多元的运维数据，为更多运维场景提供数据服务。从整体上，可观测性系统为企业运维提供了一个数据基础，让我们对事故响应以及容量预测等方面更多使用数据而非凭借以往经验和拍脑袋做出决策。

故障响应

如果有什么东西出了故障，该如何提醒大家并做出回应？工具可以帮助解决这个问题，因为它可以定义提醒人类的规则。

故障响应是建立在使用可观测性系统构建的数据之上，并借助反馈循环，来帮助我们加强对服务的监控。

故障响应通常包含如下几个动作:

需要注意的是，如果在前期整个可观测性系统能够做好，通常故障应当始于一个简单的告警信息或一个报障电话，因此，通常情况下，可观测系统做的足够好仅能起到追溯和排查的作用，但是无法起到及时发现的作用，此时就需要依赖于各个观测数据进行计算和评估告警，以及时将相关的告警通知到相关人，以暴露风险点。

告警只是整个故障响应的第一个环节，解决的是故障如何发现的问题，而大多数的故障响应工作都是关于定义处理策略和提供培训的，以便人们在收到警报时知道该怎么做，通常这部分更多的是过去历史经验和运维经历的总结和沉淀，包括经验的一些抽象和工具化沉淀，以保证故障响应的效率和普遍化(即不依赖人为经验)。

而对于整个告警系统来说，需要确保的是告警的有效性，否则，整个报警系统很有可能沦落为垃圾数据制造机，告警有效性意味着需要满足如下两个需求：

在整个运维过程中，我们经常会发现有大量的无关紧要的告警信息，让运维人员的注意力迷失在告警海洋当中，而通常非运维领域的领导会关注整个告警的响应程度，因此，抑制和消除无效的告警，让运维人员不被告警风暴所吞没，也是告警管理中重点建设的内容。

通常情况，在我们的各个可观测系统构建完成后，可以通过整合到监控平台中的各种监控数据，应用趋势预测、短周期检测、间歇性恢复、基线判断、重复压缩等算法和手段实现告警压缩收敛，强化告警的有效性。

sre工程师需要会什么，SRE需要具备什么能力

img

同时，面向一线的运维人员，我们需要根据同一个系统或设备的多个监控指标进行综合性建模和分析，汇总成一个健康度的分值，给予一线运维人员系统的基于健康度的系统分层评价体系，真实、直观反映系统运行状态，实现问题快速定位。

比如，通过基础资源的多个指标进行综合加权计算来整体评估该资源的利用率；通过一个应用关联的全部资源的资源利用率以及应用的运维架构整体建模分析来计算一个分值来整体评估该应用的健康程度。

这个过程如果做得成熟一些，可以根据内部已有的解决方案和告警进行闭环打通，一个简单的场景就是，当磁盘满时，告警会首先触发一次标准化的磁盘巡检，并进行相关的可丢弃数据的删除，如果依然无法解决该报警，下次可直接关联到一线运维进行人工干预，之后进行标准化经验总结。

测试与部署

测试与部署对于整个稳定性和可靠性的主要出于一个预防的作用，预防是指尝试限制发生的事故数量，并确保在发布新代码时基础架构和服务能够保持稳定。

作为一个长期从事运维工作的人，可能内心中最为恐惧的莫过于新应用版本发布。因为除了硬件和网络设备损坏这个属于天灾级别的概率事件外，新应用版本发布的第二天通常是停机与事故的高危期。所以，对于一些量级较大的产品通常会在节假日以及重要活动前夕进行封网操作，以避免新版本上线而导致的业务bug出现。

而测试是在成本和风险之间找到适当的平衡活动。如果过于冒险，你们可能就会疲于应付系统失败；反过来说，如果你太保守，你就不能足够快地发布新东西，让企业在市场上生存下来。

在错误预算比较多（即在一段时间内故障导致系统停机时长较少）的情况下，可以适当减少测试资源并放宽系统上线的测试和条件，让业务可以有更多的功能上线，以保持业务的敏态；在错误预算比较少（即在一段时间内故障导致系统停机时长较多）的情况下，则要增加测试资源并收紧系统上线的测试，让系统的潜在风险得到更多有效的释放，避免系统停机保持系统的稳态。这种敏态与稳态之间的平衡，需要整个运维与开发团队来共同承担。

除了测试外，应用发布也是一项运维团队通常要承担的责任。SRE其中的一个原则是将一切可以重复性劳动代码化和工具化；此外，应用发布的复杂程度往往与系统的复杂程度成正比。因此在应用系统上规模企业，往往已经着手基于自动化框架构建自动化的应用发布过程。

sre工程师需要会什么，SRE需要具备什么能力

img

通过自动化发布工具，我们可以构建流水线实现部署的过程中所有的操作（如编译打包、测试发布、生产准备、告警屏蔽、服务停止、数据库执行、应用部署、服务重启等）全部自动化。

容量规划

容量规划是关于预测未来和发现系统极限的，容量规划也是为了确保系统可以随着时间的推移得到完善和增强。

规划的主要目标是管理风险和期望，对于容量规划，涉及到将容量扩展到整个业务；所关注的期望是人们在看到业务增长时期望服务如何响应。风险是在额外的基础设施上花费时间和金钱来处理这个问题。

容量规划首先是对未来预测性的分析与判断，其预测的基础正是海量的运维数据。因此，容量规划除了有相应的架构和规划团队外，一个全面的运维数据中心是实现系统容量规划的必须设施。

容量趋势预警和分析将综合地从各种运维监控、流程管理等数据源中收集、整理、清洗并结构化地存储各种运维数据，将这些来自于各种工具的运维数据打通融合并且构建各种数据主题。

应用这些数据主题的数据用于帮助运维人员对问题进行评估，包括：

运维平台除了可以提供必要的数据支持外，还需要提供必要的数据可视化支持能力。运维数据可视化提供了一些必要的能力保障运维人员可以更好地利用其中的运维数据评估容量。

首先，运维平台需要有极强的数据检索能力。运维平台存储着海量的运维数据，运维人员为了尝试建立和验证一个探索性场景的时候，往往多次反复检索和查询特定数据。如果运维数据分析平台的数据查询很慢或者查询角度很少的情况下，运维人员建立场景的时间就会拖得很长甚至进行不下去。因此，运维人员可通过平台可以实现关键字、统计函数、单条件、多条件、模糊多维度查找功能，以及实现海量数据秒级查询，才能更有效帮助运维人员更便捷分析数据。

其二，平台需要强大的数据可视化能力。人们常说“千言万语不及一图”，运维人员经常会通过各系统的运维数据进行统计分析并生成各类实时报表，对各类运维数据（如应用日志、交易日志、系统日志）进行多维度、多角度深入分析、预测及可视化展现，将他们分析的预测结果和经验向他人表达和推广。

自动化工具开发

SRE不仅涉及运营，还涉及软件开发，当然这部分指的是和运维以及SRE领域相关的工具和平台开发。在Google的SRE体系中，SRE工程师将花费大约一半的时间来开发新的工具和服务，这些工具的一部分用于自动化一些手动任务，而其他部分用于来不断填补和修复整个SRE体系内部的其他系统。

通过编写代码把自己和其他人从重复的工作中解放出来，如果我们不需要人类来完成任务，那么就编写代码，这样人类就不需要参与其中了。

SRE从内心上鄙视重复性的工作，将从原有的人工加被动响应，转变为更高效、更为自动化的运维体系。

自动化运维框架：

sre工程师需要会什么，SRE需要具备什么能力

img

自动化运维工具的优势和必要性:

构建自动化运维体系就必须以运维场景为基础，这些运维场景是在本企业内反复迭代和打造，是企业中最常用的运维场景。

比如常见的运维场景：软件安装部署、应用发布交付、资产管理、告警自动处理、故障分析、资源申请、自动化巡检等等。因此，整个自动化运维体系建设时也应支持多种不同类型的自动化作业配置能力，通过简单的脚本开发、场景配置和可视化定制流程实现更多运维场景的实现。

用户支持

用户体验这一层要说的是，作为SRE来讲，从用户的角度来保证业务的稳定性和可用性才是最终目标。这个才传统意义上的运维人员是不会关注这一点的，因为大家通常只会考虑到我底层运维的系统或底层资源是否稳定，但实际上整个业务的稳定才是SRE需要关心的问题，而业务的稳定性和可用性通常需要站在用户的角度来模拟和衡量整体的可用性和可靠性。

在前面提到的所有SRE相关的工作范畴，无论是监控、事故响应、回顾、测试与发布、容量规划以及构建自动化工具，无非都是为了提供更好的系统用户业务体验而服务的。因此，我们在运维的过程中无不需要注意关注系统的用户体验。

而在实际运维工作中，我们往往可以通过应用日志、监控数据、业务探测等业务相关的用户体验信息。在运维数据平台中，通过这些用户体验监测数据之间的关联和串联，重现用户的最终业务调用链路以及各应用环节对性能数据的关系。最终形成从业务用户体验数据入手，逐步实现系统运行状态数据、设备运行状态数据链路的打通，让运维体系实现以最终用户体验为中心的目标。

这些用户体验的信息，对于运维团队掌握客户整体的用户体验情况、系统可用性的监测以及系统针对性的优化提供着无可替代的作用。

其实，SRE运维体系更为强调以用户的体验为核心，以自动化和运维数据为手段，实现应用业务连续性保障，从这个点出发，我们会发现和以往的传统运维还是有很大的区别的，我们不再仅仅是单纯的安装和部署工程师，我们需要通过一系列的技术手段来不断保障上层业务的稳定性和可靠性。

Oncall

Oncall 简单来说就是要保证线上服务的正常运行。典型的工作流程是：收到告警，检查告警发出的原因，确认线上服务是否有问题，定位到问题，解决问题。

收到告警并不总意味着真正的问题，也有可能告警设置的不合理。告警和监控面板并不是一个静态的配置，它应该是每天都在变化的，时刻在调整的。如果发现没有标志真正线上问题的告警发了出来，就应该修改告警规则。如果发现当前的监控无法快速定位问题，应该调整监控面板，添加或者删除监控指标。业务在发展，请求量在变化，某些阈值也需要不断地调整。

定位问题没有一概而论的方法了，需要根据看到的实时监控数据，结合自己的经验，然后做推测，然后使用工具验证自己的推测，然后确定问题的根因。

但是解决问题是可以有方法论的，叫做 SOP，标准操作流程。即：如果出现了这种现象，那么执行那种操作，就可以恢复业务。SOP 文档应该提前制定，并且验证其有效性。

需要注意的是上述定位问题、解决问题并没有顺序关系。一个经常犯的错误是，在出现故障的时候，花了很长时间定位到故障的根因，然后再修复。这样花的时间一般会比较长。正确的做法是先根据现象看现有的 SOP 能否恢复业务。比如说当前错误只发生在某一个节点上，那么就直接下线这个节点，具体的原因后面再排查。恢复当前的故障永远是第一要务。但是恢复操作也要经过测试，比如猜测可以通过重启解决问题的话，可以先重启一台做测试，而不是一次性将所有服务重启。大部分情况是需要临场分析的，是一个紧张又刺激的过程。

故障到底多久恢复算好？出现多少故障是可以容忍的？怎么检测服务的稳定性到底如何？我们使用 SLI/SLO 来衡量这些问题。

制定可交付的SLI/SLO/SLA

SLO 和 SLA 是大家常见的两个名词：服务等级目标和服务等级协议。

云计算时代，各大云服务提供商都发布有自己服务的 SLA 条款，比如 Amazon 的 EC2 和 S3 服务都有相应的 SLA 条款。这些大公司的 SLA 看上去如此的高大上，一般是怎么定义出来的呢？

说 SLA 不能不提 SLO，这个是众所周知的，但是还有一个概念知道的人就不多了，那就是 SLI（Service Level Indicator），定义一个可执行的 SLA，好的 SLO 和 SLI 是必不可少的。

另外必须要提到的是，SLI/SLO/SLA主要是为服务指定的，如果没有服务作为依托关系，那这些概念也就失去了原有的意义。

下面是一个 SLA 在制定过程中需要考虑到的一些问题：

例如：设计一个可用率的时候，并不是说达到了”4个9“为标准就足够了，因为我们需要考虑如下问题：

  1. 如何定义这个可用率？比如我们以可用率 > 99.9% 为目标，有一个服务部署了 5 个 区域, 那么有一个 区域 挂了，其余的 区域 是可用的，那么可用率被破坏了吗？这个可用率是每一个 区域 的还是所有的 区域 一起计算的？
  2. 可用率计算的最小单位是什么？如果 1min 内有 50s 没有达到可用率，那么这一分钟算是 down 还是 up？
  3. 可用率的周期是怎么计算的？按照一个月还是一个周？一个周是最近的 7 天还是计算一个自然周？
  4. 如何设计与规划 SLI 和 SLO 监控？
  5. 如果错误预算即将用完，有什么处理措施？比如减少发布以及配置变更？

Service

什么是服务？

简单说就是一切提供给客户的有用功能都可以称为服务。

服务一般会由服务提供者提供，提供这个有用功能的组织被称为服务提供者，通常是人加上软件，软件的运行需要计算资源，为了能对外提供有用的功能软件可能会有对其他软件系统的依赖。

客户是使用服务提供者提供的服务的人或公司。

SLI

SLI 是经过仔细定义的测量指标，它根据不同系统特点确定要测量什么，SLI 的确定是一个非常复杂的过程。

SLI 的确定需要回答以下几个问题：

  1. 要测量的指标是什么？
  2. 测量时的系统状态？
  3. 如何汇总处理测量的指标？
  4. 测量指标能否准确描述服务质量？
  5. 测量指标的可靠度 (trustworthy)？
  6. 常见的测量指标有以下几个方面：

下面通过一个例子来说明一下：hotmail 的 downtime SLI

  1. 测量时的系统状态，在什么情况下测量会严重影响测量的结果
  1. 如何汇总处理测量的指标？
  1. 测量指标能否准确描述服务质量？
  1. 测量指标的可靠度

SLO

SLO (服务等级目标) 指定了服务所提供功能的一种期望状态。SLO 里面应该包含什么呢？所有能够描述服务应该提供什么样功能的信息。

服务提供者用它来指定系统的预期状态；开发人员编写代码来实现；客户依赖于 SLO 进行商业判断。SLO 里没有提到，如果目标达不到会怎么样。

SLO 是用 SLI 来描述的，一般描述为： 比如以下 SLO：

设置 SLO 时的几个最佳实践：

设置 SLO 时的目标依赖于系统的不同状态 (conditions)，根据不同状态设置不同的 SLO：**总 SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …

为什么要有 SLO，设置 SLO 的好处是什么呢？

监控 / 测量 SLIs 对比检测到的 SLIs 值是否达到目标 如果需要，修正目标或者修正系统以满足目标需要 实施目标的修改或者系统的修改 该控制系统需要重复的执行以上动作，以形成一个标准的反馈环路，不断的衡量和改进 SLO / 服务本身。

我们讨论了目标以及目标是怎么测量的，还讨论了控制机制来达到设置的目标，但是如果因为某些原因，设置的目标达不到该怎么办呢？

也许是因为大量的新增负载；也许是因为底层依赖不能达到标称的 SLO 而影响上次服务的 SLO。这就需要 SLA 出场了。

SLA

SLA 是一个涉及 2 方的合约，双方必须都要同意并遵守这个合约。当需要对外提供服务时，SLA 是非常重要的一个服务质量信号，需要产品和法务部门的同时介入。

SLA 用一个简单的公式来描述就是：SLA = SLO + 后果

SLA 是一个很好的工具，可以用来帮助合理配置资源。一个有明确 SLA 的服务最理想的运行状态是：增加额外资源来改进系统所带来的收益小于把该资源投给其他服务所带来的收益。

一个简单的例子就是某服务可用性从 99.9% 提高到 99.99% 所需要的资源和带来的收益之比，是决定该服务是否应该提供 4 个 9 的重要依据。

故障复盘

故障复盘就是对于过去的一些服务异常和服务中断情况进行回顾和总结，以确保相同问题下次不会再出现。为了让大家团结协作，我们希望建立一种无指责、透明的事后文化。个人不应该害怕事故，而是确信如果事故发生，团队将会响应和改进系统。

备注: 其实在国内的SRE文化中，一般只有对大型，对业务有重大影响的事故才会进行复盘，但实际上如果在时间和经历允许的情况下，对于一般的普通事故也应该在小范围进行复盘，正所谓大的故障都是从不断的小问题一点一点积累的。另外，其实对于运维相关的个人而言，我们也应当及时的进行小故障复盘，以不断加强个人的故障处理和修复能力。

我认为SRE的一个关键共识正是承认了系统的不完美性，追求永不停机的系统是不现实的。基于不完美系统，我们无可避免要面对和经历系统故障与失败。

所以我们重要的并非找到为这个故障责任的这个人或者那个人，而是更应该刨根问底地复盘这个故障和失败的根本原因是什么，以及如何避免再次出现相同的故障。系统可靠性是整个团队共同奋斗的方向，从失败中快速恢复并吸取教训，每个人放心地提出问题，应对停机，并努力改进系统。

备注: 通常很多企业内部在故障复盘过程中，相关人员可能将故障和失败的根因追溯 不经意间 当做了故障定责和一系列的惩罚措施，通过一些惩戒措施来强行约定故障的发生，这种方式往往是非常不可取的，试想每个人都不想出现事故，要么是认知之外，要么是规则缺陷，永远没有一个人明知会有故障而偏偏去制造故障的。

需要牢记的是: 故障是我们可以从中学习的东西，而不是让人害怕和羞耻的事情！

在日常运维过程中，出现故障等事故对于我们而言其实是一个很好的复盘学习机会。通过历史监控数据，分析事故其中的根本原因，制定后续应对策略，并且通过运维平台将这些应对策略编辑成标准化、可重用、自动化的运维应用场景，为后续相同问题的处理提供标准且快捷的解决方案。这正是事后回顾这个过程最真实的价值体现。

故障复盘的唯一目的是减少故障的发生。有几个我目前认为不错的做法。

故障复盘需要有文档记录，包括故障发生的过程，时间线的记录，操作的记录，故障恢复的方法，故障根因的分析，为什么故障会发生的分析。文档应该隐去所有当事人的姓名对公司的所有人公开。很多公司对故障文档设置查看权限，我觉得没什么道理。有些公司的故障复盘甚至对外也是公开的。

故障在复盘的时候应该将当事人的名字用代码替代，可以营造更好的讨论氛围。

不应该要求所有的故障复盘都产生 Action。之前一家的公司的故障复盘上，因为必须给领导一个“交待”，所以每次都会产生一些措施来预防相同的故障再次发生，比如增加审批流程之类的。这很扯，让级别很高的领导审批他自己也看不懂的操作，只能让领导更痛苦，也让操作流程变得又臭又长，最后所有人都会忘记这里为什么会有一个审批，但是又没有人敢删掉。你删掉，出了事情你负责。

Blame Free 文化？之前我认为是好的。但是后来发现，有些不按照流程操作导致的问题确实多少应该 Blame 一下，比如下线服务的时候没有检查还没有 tcp 连接就直接下线了，或者操作的时候没有做 canary 就全部操作了，这种不理智的行为导致的故障。但是条条框框又不应该太多，不然活都没法干了。



作者：青牛踏雪御苍穹
链接：https://www.jianshu.com/p/4fcbf6563177

2、sre工程师需要会什么，如何成为SRE先了解这些真相和面试情况

我几年来一直在推文中讲话和怒吼，一次又一次地被问到同样的问题：“如何成为 SRE？”

我的回答通常是漫无边际的。这么久，有时候我甚至都没有回信。可以说的太多了！太多的历史、太多的内容、太多由于不同个人情况而产生的因素。

所以，在这里表达一些我关于如何成为 SRE 的正式的回应：我认为它是什么，我是如何成为 SRE 的，要成为 SRE 你应该做些什么。本文是一本指南，可用作书签、参考和分享。它提供了一些见解，读者可以根据具体情况进行映射，以帮助开始自己特定的路径。

希望你在旅程中发现这些内容很有用。

目录
  1. 定义
  2. 现实
  3. 我自己的路
  4. 你的道路
  5. 面试
  6. 资源
定义

那么，什么是 SRE（网站可靠性工程）？根据 Google SRE 的书：“SRE 就是软件工程师设计一个运维团队的过程。”由于多种原因，这个定义有点争议，尤其是它的含义是运维团队无法进行合理的系统设计，而不是运维团队经常资源不足。这个定义的争议性还在于它暗含着所有的 SRE 都在日复一日地对后端系统进行编码，而这在 Google 甚至都不正确。

虽然谷歌投入了相当多的资金来对外宣传 SRE 的定义，但业内人士根据自己的情况开始实践 SRE，这样就导致了公司与公司之间有很大差异。而对它的定义，我看到的 SRE 指的是：

我想明确一点：本指南不是关于 Google SRE 的。Google SRE 有自身 SRE 的实践风格，某种程度来说是一个完全不同的学科。其他大公司可能会采用 Google SRE 的一部分，但我不知道谷歌以外谁会完全这样实施。如果你想成为 Google SRE，那完全没问题，但是这篇文章并不想这样引导。

那么，SRE 更广泛的定义是什么呢？很难为所有公司确定一个定义，就像很难为所有公司定义软件工程一样。如果软件工程师（SE）是由代码定义的，那么 SRE 也是软件工程师。那么，SRE 和需要 alt="sre工程师需要会什么，SRE需要具备什么能力" src="http://p3.toutiaoimg.com/large/pgc-image/399929df9ed74244b7143c45a4d7dffa" />

一个需要>软件工程

  • 分布式系统设计
  • 操作系统
  • 网络
  • 数据库
  • 安全
  • 可靠性最佳实践
  • 故障排除
  • 客户支持

    • 有人会抱怨“太多了！”，确实如此。SRE 是一门广泛的学科，因为运行大型分布式站点需要很多的技能。事实上，许多 SRE 倾向于专注上述的一种或两种技能。你可能也发现了，有的公司通常有多个 SRE 团队，支持平台上的不同领域。也有的团队可能正在实践 SRE 但叫法不同，例如叫基础设施工程或生产工程。你还会发现有些拥有 SRE 团队的公司根本就没有在实践 SRE。我鼓励大家把注意力集中在工作本身上，不用太纠结 SRE 的实际含义是什么。

    现实

    每当有人问我如何成为 SRE 时，通常他们最后会问自己为什么要做 SRE。这样说似乎不太礼貌，让我们花点时间来解释一些可能对该领域的误解。根据 Google 的深度营销与行业整体情况，期望与现实之间可能存在很大差异。

    期望

    上述现实并非在每个地方都是如此，但还是比很多人期望的要真实。有时你要为新的花哨平台构建工具，有时候需要与 Puppet（一个自动化部署工具）和 DNS 作斗争。你需要具备灵活性并积累各种技能来完成工作。

    SRE 的其他一些现实

    有一个非常老套的说法：如果是为了权力和荣耀，可能会感到失望。成为 SRE，因为你对这个工作感兴趣。

    我自己的路

    有时人们会根据我职业生涯中的具体步骤来追问：书名，公司，会议等。他们希望得到尽可能多的信息，以便尝试复制我的道路。问题是，我的道路不容易复制。

    我普通的道路

    如果回放，这就是一个电影学生成为科技工作者的故事。 只要努力工作，你也会实现自己的梦想！ 但这条道路是他人无法复制的，例如，当我面试支持方面的工作时，我是一个年轻的、白人、纯女性打扮的女人，由年长的、有家室的白种男性雇佣。 他们决定“给我个机会”，并说我让他们想起了他们的女儿，其中有个人甚至基于他小女儿的学校作业面试了我！ 做这种关联的感觉并不好，虽然它确实对我有利，但我无法帮助你复制它。

    我认为我的道路中可以而且应该复制的，是不断学习。我的整个科技生涯就是我做的工作和我正在学习的工作。我不断阅读书籍，观看讲座，上课，学习新语言，与业界朋友交谈。我不会满足于现状，如果对当前正在做的工作不感兴趣，我会在晚上找到一些有趣的东西，然后会付诸行动。最终，这些新技能可以帮助我完成目前的工作或保证下一个工作。

    我没有做到，但是你应该去做的是利用你的社区。在开始一家科技公司的工作之前，我还不知道技术社区是怎么一回事，我一个人一直在抨击 Python 问题，而不是参加聚会并获得帮助。有一段时间我找不到工作，也不了解技术工作相关的情况。后来我终于找到了工作，但我认为这更多的是一些运气的成分而不是我的能力。利用你的社区吧！它会帮助你找到一份工作。

    你的道路

    我遇到过各种不同背景的人，他们都想要成为 SRE。有些人已经是开发人员，有些人还在训练营，有些人在做 QA 或营销，他们都想知道下一步应该是什么。

    官方的答案是“看情况”，这是认真思考权衡所有情况后的答案！但我知道这个答案没有什么用，所以让我们以不同的方式来往下说。

    如果我现在试图成为 SRE，会做两件事：

    1. 找到离我最近的 SRE 组织（请记住，它可能不会被称为“SRE”！）。
    2. 弄清楚成为 SRE 我需要跳（hop) 几次。

    你可能不熟悉这个术语 - “跳跃”（hops）。它是一种网络概念，指的是数据包在来源和目标之间发生的路由网络设备（路由器、网桥等）的数量。在家用 wifi 上的笔记本电脑和朋友的笔记本电脑之间传输的数据包，可能比在笔记本电脑和另一个国家 / 地区的朋友的笔记本电脑之间传输的数据包少。同样地，我认为与 SRE 团队合作的开发人员，比学习电影毕业后想要成为 SRE 的人之间的跳跃会更少。

    sre工程师需要会什么，SRE需要具备什么能力

    职业生涯中的跳跃就像是技能和网络（人际网络！）间的组合 。这是一个持续的过程，找到需要什么技能来进行下一跳，并找到能帮助你成功的人。你的下一跳很可能不是一个 SRE 工作，但它会让你更接近 SRE！

    与计算机网络非常相似，社交网络越大，道路就越有效率。这取决于谁帮助你、拥有的技能和时间，你的道路可能比同一个地方的其他人更长或更短。一个人的道路可能看起来像新兵训练营 - 自由职业者 - 兼职开发人员 - 副业做做运维 - 系统管理员 - 运维 - SRE。而另一个人可能会在刚毕业就找到 SRE 团队的实习机会。不同的人有不同的机会，你需要找到符合自己实际情况的机会。

    因此，先找到 SRE 有哪些相关的技能然后缩小这些技能范围。缩小到什么程度呢，就是如果你拥有了这部分技能，你就可以得到一份更接近 SRE 的新工作。然后重复。

    例如，如果不知道如何编程：学会编程！去训练营，参加在线课程，获得计算机科学学位，做一切合适的事情。扩展人际网络并找到招聘人员，或做自由职业。尽量让你的简历上有开发经历，然后在新职位中学习下一个技能，例如网络或数据库。参加更多的课程，找到更多的聚会，换新工作，一步步接近 SRE。

    最难的部分，是如何让你的脚踏进那道门槛。一旦有了开发人员或系统管理员的工作，一旦可以在简历上展示出某种形式的“工程师”，你就有空间来呼吸。坚持那份工作 1 到 2 年，获得一些经验，建立自己的网络，并开始下一个支点。这需要时间，但会是你职业生涯剩余的时间中，成为 SRE 并超越它的一个方法。

    面试

    无论你过程如何，最终都会碰到 SRE 工作的面试。恭喜！不同公司和团队的 SRE 面试是不同的，具体取决于你的职责。因此，提前研究好工作岗位（无论如何你都应该这样做），并准备好要涵盖的主要主题。

    除了在所有面试中常见的行为方面的问题之外，SRE 的面试还会包括编码、故障排除和可靠性方面的问题。

    编码

    故障排除

    可靠性

    对于入门级 SRE，我希望能够使用一种灵活的编程语言，比如 Python。可以创建一个小的应用程序，编写测试并处理异常。还希望看到像 Linux 这样的操作系统方面的一些能力，可以在命令行上搜索文件系统，知道如何 grep 日志，可以 ping 一个域。希望看到大规模技能方面的一些预见，例如使用配置管理系统或 CI 工具。可能无法负担运行 AWS 实例的费用，但也许已经使用免费的 Heroku 帐户，并在免费的监控 add-ons 程序中检出了你的应用程序指标。无论在 SRE 职业生涯中，无论是 Kubernetes 还是 MySQL 还是边缘网络，这些基础的技能都将帮助你取得成功。

    一个有趣的部分，每次面试结束时都应该留出时间让你提问 ; 也就是说，你要面试公司。应该提前计划出这些问题，并写下来以供参考。要注意他们的答案。要从感觉上了解他们的工作文化、项目和团队的健康状况。

    可能不会第一次得到你梦寐以求的工作，但是询问其中的一些问题，可以帮你了解这项工作将如何为下一次求职提供帮助。

    “过去六个月你做了哪些项目？”

    “你最后一次被呼叫的时间是什么时候，是因为什么？”

    “你所有的开发团队都>分配>所有开发团队都>如果觉得这个话题还可以继续，可以问问需要你>Ops School (docs collection)

  • SRE Weekly (newsletter)
  • SREcon (conference videos)
  • DevOpsDays (conference videos)
  • Eli the Computer Guy (videos)
  • Katacoda (interactive training)
  • Sysadmin Casts (podcast)
  • The Google SRE Book (book)
  • The Geek stuff (blog)
  • DevOps BootCamp (course)
  • Coursera (courses)

    • Architecture

    Cloud

    Databases

    Git

    Networking

    Operating system internals

    Programming

    Puppet

    Security

    Unix / Linux operations

    Vim

    本文关键词：sre开发工程师，src工程师，sre工程师培训，sqe工程师，sre工程师需要哪些知识。这就是关于《sre工程师需要会什么，SRE需要具备什么能力》的所有内容，希望对您能有所帮助！

    本文内容仅供健康科普参考，不能替代专业医疗诊断和治疗建议。如有身体不适，请及时就医并遵从医师指导。

    相关阅读