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

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

内容导航：1、sre工程师需要会什么：什么是SRE？SRE需要具备什么能力？2、sre工程师需要会什么，如何成为SRE先了解这些真相和面试情况

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

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

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

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

第一：技能全面，比如网络、操作系统、监控、CICD、研发等，对于研发能力，可能不需要你精通，但是你需要具备可以使用一门语言完成某个功能的设计、开发与迭代。第二：打破传统运维思想壁垒，以产品角度思维贯穿整个业务架构服务质量为前提的沟通协调能力。第三：始终以软件工程解决问题为方向的规划之路。第四：很强的Trouble Shooting与思考、抽象能力，这三个能力在SRE工作当中是至关重要的，是时间与实践积累的最终成果。

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

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

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

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

可观测性系统故障响应测试与部署容量规划自动化软件开发用户支持Oncall制定可交付的SLI/SLO/SLA故障复盘

可观测性系统

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

指标监控：即各种指标监控，比如基础资源指标，服务性能指标，业务的调用指标。日志：各种设备以及服务的运行日志监控。调用链：业务层面的调用链分析，通常在分布式系统中帮助运营、开发以及运维人员快速识别整体调用的瓶颈点

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

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

确定质量标准是什么，并确保系统持续逼近或保持在质量标准极限范围内系统地关注这项工作—而不应该只是随机地查看一下系统

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

完备指标采集：可以对接企业内大部分的设备与技术栈相应的监控指标；同时，支持常见设备的监控指标体系，可以快速接入监控设备和指标，避免所有设备监控都是从头构建；对于日志数据的采集支持海量设备支持：企业IT系统数量和规模越来越大，因此监控系统比以前需要监控海量设备监控。监控数据存储和分析：监控数据是运维分析、运维自动化和智能化的基础，因此海量监控数据存储以及基于监控数据的可视化分析是一个监控系统的基本能力。

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

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

故障响应

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

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

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

关注: 不论是主动发现瓶颈点或异常点，还是通过可观测性系统被动暴露瓶颈点，我们都应该进行主动关注交流: 及时将观察到风险点通知到相关方，并告知影响面以及相关的补救措施恢复: 三方达成一致后，根据补救措施进行修复相关风险点和异常点

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

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

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

告警及时性: 系统有问题需要及时通过告警信息告知运维处理人员及时处理告警;告警准确性: 只要有告警信息系统必然出现问题(对于很多企业可能存在大量的无用告警，比如磁盘问题，mem等相关问题，当然这里涉及到了自动化、业务形态、告警阈值的问题);

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

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

img

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

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

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

测试与部署

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

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

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

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

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

img

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

容量规划

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

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

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

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

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

当前的容量是多少何时达到容量极限应该如何更改容量执行容量规划

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

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

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

自动化工具开发

SRE不仅涉及运营，还涉及软件开发，当然这部分指的是和运维以及SRE领域相关的工具和平台开发。在Google的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“为标准就足够了，因为我们需要考虑如下问题：

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

Service

什么是服务？

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

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

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

SLI

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

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

要测量的指标是什么？测量时的系统状态？如何汇总处理测量的指标？测量指标能否准确描述服务质量？测量指标的可靠度 (trustworthy)？常见的测量指标有以下几个方面：性能响应时间 (latency)吞吐量 (throughput)请求量 (qps)实效性 (freshness)可用性运行时间 (uptime)故障时间 / 频率可靠性质量准确性 (accuracy)正确性 (correctness)完整性 (completeness)覆盖率 (coverage)相关性 (relevance)内部指标队列长度 (queue length)内存占用 (RAM usage)因素人响应时间 (time to response)修复时间 (time to fix)修复率 (fraction fixed)

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

错误率 (error rate) 计算的是服务返回给用户的 error 总数如果错误率大于 X%，就算是服务 down 了，开始计算 downtime如果错误率持续超过 Y 分钟，这个 downtime 就会被计算在内间断性的小于 Y 分钟的 downtime 是不被计算在内的。测量时的系统状态，在什么情况下测量会严重影响测量的结果测量异常 (badly-formed) 请求，还是失败 (fail) 请求还是超时请求 (timeout)测量时的系统负载（是否最大负载）测量的发起位置，服务器端还是客户端测量的时间窗口（仅工作日、还是一周 7 天、是否包括计划内的维护时间段）如何汇总处理测量的指标？计算的时间区间是什么：是一个滚动时间窗口，还是简单的按照月份计算使用平均值还是百分位值，比如：某服务 X 的 ticket 处理响应时间 SLI 的测量指标：统计所有成功解决请求，从用户创建 ticket 到问题被解决的时间怎么测量：用 ticket 自带的时间戳，统计所有用户创建的 ticket什么情况下的测量：只包括工作时间，不包含法定假日用于 SLI 的数据指标：以一周为滑动窗口，95% 分位的解决时间测量指标能否准确描述服务质量？性能：时效性、是否有偏差准确性：精度、覆盖率、数据稳定性完整性：数据丢失、无效数据、异常 (outlier) 数据测量指标的可靠度是否服务提供者和客户都认可是否可被独立验证，比如三方机构客户端还是服务器端测量，取样间隔错误请求是如何计算的

SLO

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

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

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

每分钟平均 qps > 100k/s99% 访问延迟 < 500ms99% 每分钟带宽 > 200MB/s

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

指定计算的时间窗口使用一致的时间窗口 (XX 小时滚动窗口、季度滚动窗口)要有一个免责条款，比如：95% 的时间要能够达到 SLO如果 Service 是第一次设置 SLO，可以遵循以下原则测量系统当前状态设置预期 (expectations)，而不是保证 (guarantees)初期的 SLO 不适合作为服务质量的强化工具改进 SLO设置更低的响应时间、更改的吞吐量等保持一定的安全缓冲内部用的 SLO 要高于对外宣称的 SLO不要超额完成定期的 downtime 来使 SLO 不超额完成

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

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

对于客户而言，是可预期的服务质量，可以简化客户端的系统设计对于服务提供者而言可预期的服务质量更好的取舍成本 / 收益更好的风险控制 (当资源受限的时候)故障时更快的反应，采取正确措施SLO 设好了，怎么保证能够达到目标呢？需要一个控制系统来：

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

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

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

SLA

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

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

SLO 不能满足的一系列动作，可以是部分不能达到比如：达到响应时间 SLO + 未达到可用性 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 你应该做些什么。本文是一本指南，可用作书签、参考和分享。它提供了一些见解，读者可以根据具体情况进行映射，以帮助开始自己特定的路径。

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

目录定义现实我自己的路你的道路面试资源定义

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

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

负责事件响应的团队；负责内部部署工具的团队；负责数据中心的团队；负责所有工程可靠性流程的团队；负责容器平台的团队；负责数据库的团队；负责网络的团队；负责监控的团队；嵌入开发团队中，做开发人员不负责的任务的团队

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

那么，SRE 更广泛的定义是什么呢？很难为所有公司确定一个定义，就像很难为所有公司定义软件工程一样。如果软件工程师（SE）是由代码定义的，那么 SRE 也是软件工程师。那么，SRE 和需要 on-call 的软件工程师之间有什么区别呢？

如果你非要让我说，我会将网站可靠性工程定义为：“大规模构建和维护可靠的 SaaS 平台的实践。”我认为 SRE 适用于拥有大型 SaaS 产品的公司，他们通常有高流量的网站和相关服务。也就是说，我是按照“网站可靠性”的字面意思来下的定义。

（你可能认为大型的内部服务（例如数据库）需要 SRE，但我的观点是这样的服务可能支持更大的面向客户的平台）。

一个需要 on-call 的软件工程师知道代码如何工作、破解和修复。网站可靠性工程师知道代码要如何适应公司的架构，并且需要设置整个系统以保证服务成功运行。

那么根据这个定义，SRE 的一些关键技能覆盖哪些领域？

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

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

现实

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

期望

拥有一件皮夹克收入比开发人员多每个人都听你说的话有权推迟交付实践，调整错误的优先级一直研究跨技术的新兴事物几乎不干体力活，只是一直在编码如果要求 on-call（译者：随叫随到，SRE 在 Google 的特色之一）还态度粗鲁，可以随时挂断呼叫

现实

收入与开发人员一样考虑到 on-call 的负担，实际收入可能比开发人员还少要对自己的东西 on-call有时还要对开发人员的东西 on-call！可以一连几个月不写代码同时，你需要知道如何读代码并诊断代码问题可能要负责可靠性，但无权修复它需要高级的客户支持技能，来说服开发人员采用大规模系统运行的最佳实践

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

SRE 的其他一些现实

解决 StackOverflow 无法解决的真正有趣的问题；有机会在整个软件 / 硬件堆栈中学习各种领域；体验大规模问题的快感，比如部署数千台服务器或缓解 DDoS 攻击；推进公司的全新流程；磨练沟通技巧，比如解决内部开发过程中的纠纷，以及对公开事故的很长的事后分析；作为负责和维护生产平台的人，得到该有的信任；与各领域和职业生涯中的工程专业人士合作。

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

我自己的路

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

我普通的道路

在计算机和互联网环境中长大，也就是说如果无聊我可以闲逛拥有电影学位经济衰退期间毕业，无法在创意领域找到工作获得了一份技术支持的工作来支付学生贷款对服务器管理的职位着迷成为了一名光荣的接待员 / 销售代表很无聊地成长，晚上开始学习 Python留下来为不同公司提供更好的支持工作结识了很酷的开发人员，不断地在晚上学习 Python应聘了 Python 工作没得到 Python 工作应聘了内部工具的工作获得了这样的共苦Ops 同事休了陪产假，暂时接过他的职务SRE 经理要我加入 SRE 团队

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

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

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

你的道路

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

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

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

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

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

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

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

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

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

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

面试

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

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

编码

无论是带回家的脚本问题还是现场的白板面试，你都不得不编码。通常他们会告诉你哪些语言是可以接受的。如果他们没有告诉你，请提问。通常，任何面向对象的语言都要会（Python、Ruby、C 、Java 等），Go 是一个例外。一般的建议是描述你正在思考的一切，但这方法在以前对我无效的。花时间静静地考虑你自己的方法，然后解释你将要做什么，如果需要就不断重复。如果没有明确计时、还可以带回家的作业，那就花上你所需要的所有时间！员工肯定被安排在候选人之前去做这些作业，许多编码任务都没有计时，因此你可能需要花比他们认为的还多的时间。如果他们问你需要多长时间，请给一个合理的谎言。除非它恰好是他们专有的应用程序，否则他们无法分辨。（译者：不赞成谎言，更合适的是一个合理的预估）

故障排除

他们希望看到你的思考方式，以及对系统的理解程度。可能采取经验示例的形式，即告诉“碰到过的的故障以及自己的贡献”。也可能采取谜题的形式，即“时区 A 的开发人员抱怨每天下午 3 点网络连接会速度慢，你会怎么调查这个？“随意提问（“我有 root 吗？”）并在墙上抛出示例（“我会先查看日志，以防开发人员并不认为应该看那里。”）这些问题的关键在于了解你对以前使用过的系统的熟悉程度、所拥有的体验以及碰到过的不常见的例子。重点是判断深度，而不是正确性。可以放心地说，“这就是我所知道的”或“我不知道，但我会试试它。”

可靠性

整个工作中，对可靠性的要求是明显的。编写代码时，应该编写异常处理和测试。如果没时间，请写下来或解释你将如何解决这个问题。会测试什么？怎样测？会如何进行变更？会怎么回滚？在进行故障排除时，考虑可靠性以及每个步骤所承担的风险。是否建议重启还在处理生产事务的服务器？如何确保故障不再发生？

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

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

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

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

SRE 的工作是周期性的，是主动和被动的混合体。六个月涵盖两个季度，可以很好地了解如何平衡你的工作。在那段时间编了什么代码吗？或者手动停用了 1,000 台服务器？如果创建了什么，是否写了什么文档？

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

呼叫发生了。我们准备好了 on-call，因为我们希望在某个时候被呼叫。但是，“主数据库发生了故障，已经通知到了所有的人”，和“这个旧的服务器无法 ping，这就是重要的一切，但没人有时间修复它”，这两者是有区别的。

“你所有的开发团队都 on-call 吗？”

分配 on-call 的任务，是 DevOps 文化的关键部分，应该知道公司处于什么阶段。所有开发团队都 on-call 吗？到了这个阶段吗？如果是，它有多久了？哪些团队还没有 on-call？适当的时候问这个问题，你会希望了解开发团队以及团队之间的关系。如果觉得这个话题还可以继续，可以问问需要你 on-call 的内容是什么。答案可能很明显，但可能是另一个团队尚未替换旧的 Nagios，你会被安排它的安装 on-call。

问这些问题不是来确保呆在最好的公司，而是要清楚你想要的是什么。例如，如果喜欢未来的队友和福利套餐，但是知道自己正在进行可怕的 on-call 轮换，那么你可以在薪资谈判中提到这一点。重复一遍，可能不会第一次尝试就得到梦寐以求的工作，所有的公司都有其优点和缺点。牢牢地记住哪些因素破坏了双方的印象，并尽力去搞清楚哪些公司存在这个因素。

资源

现在，你已经了解了什么是 SRE，并且有一条通向它的道路。下一步就是发展你的技能！

如上所述，通往 SRE 有很多道路，包括计算机科学学位和编码训练营。但那些要花钱，并且可能对你来说遥不可及。可以利用免费资源进入市场，我认为每个人都应该拥有同样的机会。

以下是 SRE/Ops/Systems 社区提供的免费教育资源的合集，我还没有亲自把所有的都使用过，所以也没有什么排名，但每一个都强烈推荐。这里提供了这些材料的不同类型，以便你根据自己的学习方式进行选择。

你在这里的所有学习都不要停下来。选择看起来很有趣的内容，如果不能解决问题，请选择其它内容。使用以下列表作为学习指南，来作为填补你空白的备忘单，它甚至还是检查你是否会享受 SRE 工作的一个好方法！

一般 / 多个主题

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

The System Design Primer (guide)Distributed Systems (videos)

Cloud

The Open Guide to Amazon Web Services (docs)Architecting Distributed Cloud Apps (videos)

Databases

sqlzoo (interactive SQL training)Andy Pavlo’s courses (online course material)Readings in Database Systems (book)Intro to SQL: Querying and managing data (online course with videos)MongoDB University (courses)

Git

Introduction to git (video)Ry’s Git Tutorial (book)Learn git branching (interactive tutorial)Git Immersion (interactive tutorial)

Networking

How DNS Works (comic)Understanding IP Addressing: Everything You Ever Wanted To Know (whitepaper)Beej’s Guide to Network Programming (book)

Operating system internals

Operating system basics (video)Unix system calls p1 (video)Unix system calls p2 (video)fork() and exec() (video)Wizard Zines (online zines, mostly free)NAND2Tetris (online course / book)Programming from the Ground Up (book)MIT’S Operating System Engineering (course)Crash Course Computer Science (videos)Intro to Operating Systems (videos)Operating Systems: Three Easy Pieces (book)

Programming

Codecademy (interactive tutorials)Learn Python (interactive tutorials)Awesome Python (curated list of resources)Automate the Boring Stuff (book)Learn to Program (book / tutorial)Higher-Order Perl (book)

Puppet

Puppet Learning VM (interactive tutorial)

Security

The Big Blog Post of Information Security Training Materials (blog)Cyber Aces (courses)Over the Wire (capture the flag games)

Unix / Linux operations

The Unix Workbench (book)Advanced bash scripting guide (book)Introduction to Linux (online course)Unix toolbox (cheatsheet)Command Line Challenge (games)

Vim

VIM Adventures (interactive game)

本文关键词：sre开发工程师，src工程师，sre工程师培训，sqe工程师，sre工程师需要哪些知识。这就是关于《sre工程师需要会什么，SRE需要具备什么能力》的所有内容，希望对您能有所帮助！更多的知识请继续关注《犇涌向乾》百科知识网站：！