工程领导者的入门读物
站点可靠性工程 (SRE) 是将 IT 运营职责与软件开发相结合的结果。对于 SRE，有责任满足为他们管理的服务设定的服务水平目标 (SLO) 和我们在合同中承诺的服务水平协议 (SLA)。
SLO 设定了可靠性目标，通常称为错误预算。在系统运行时收集数据，并将其编译为服务级别指标 (SLI)，以帮助指导 SRE 做出关于系统哪些部分需要优先增强的决策。为了帮助解决这个问题，工程师可以自动化任何事情，而不是重复任务。这种自动化通过消除工作来创造更多的工程师时间，这些时间可以花在使站点越来越可靠上。
对可靠性的关注是区分 DevOps 和站点可靠性工程的主要因素，而不是自动化。
对可靠性的关注是区分 DevOps 和站点可靠性工程的主要因素，而不是自动化。在 SRE 团队中，工程师承担责任，即构建软件的人也将其交付并在生产中拥有它。从这个意义上说，SRE 有时被称为 DevOps 的下一阶段。
将这种自动化期望应用到操作任务中，使成为站点可靠性工程师的软件开发人员和系统管理员的任务是学习如何处理可能超出他们以前经验的复杂问题。现在，人们期望他们处理延迟、性能、高可用性 (HA)、复杂的分布式生产系统、系统监控、应急响应和灾难恢复等问题，甚至只需要绝对必要的人工交互即可进行变更管理。这导致越来越高的效率。
SRE 团队是软件开发、系统管理和 IT 运营全部合并在一起的。作为系统管理员、开发人员或 dba，任何给定成员都可能是最强的，但没有成员只做一件事。他们都朝着一个共同的目标共同努力，没有传统的墙壁阻碍沟通和节奏。
本文：
现场可靠性工程的基础和好处是什么？
站点可靠性工程的基本原理很容易解释，但需要一些工作才能应用。我们从基本理解开始，即当今的计算机系统和平台具有前所未有的固有复杂性。
我们的系统很复杂
我们架构中的移动部件和离散的功能单元的数量是巨大的，任何一个人都不可能在任何特定时刻完全理解。此外，我们的系统在不断变化。正在增加新的容量。故障转移系统。负载均衡。金丝雀部署。不再需要的旧容器不断被移除。
过去我们在纸上设计系统，绘制系统图和系统架构，而今天我们的系统在墨迹未干之前就已经发生了变化，任何尝试都这样做了。它们充其量只能被认为是近似值。
自动化帮助我们管理复杂性
如今，大型系统的大部分管理都涉及平凡的重复性任务。由于营销部门发送了一封特殊的机会销售电子邮件后，大量在线购物者涌入我们的网站，我们的负载增加了？提升容量？因为报税季结束了，每个按时报税的人都已经完成并且已经收到了他们的结果，所以负担已经减轻了？删除不需要的冗余应用程序服务器。
没有工程师愿意一遍又一遍地做同样的事情。重复很快就会变得乏味，并导致寻找新的有趣挑战的工作。我们喜欢解决问题并提出有用的解决方案。我们更喜欢它，因为它可以让我们摆脱不喜欢的任务，让我们有更多的时间去做有趣和有益的工作。
当自动化可靠并且使我们的系统对高影响事件更具弹性时，我们更喜欢自动化。当我们不必扑灭由比典型数量更多的并发用户引起的隐喻火灾时，我们都非常感激。当我们的系统在这成为问题之前进行监控、警报甚至做出反应时，每个人都会受益。
谁从现场可靠性工程师那里受益？
任何大到需要超过少数人来管理其系统的公司都将从站点可靠性工程中受益。任何拥有足够大或足够重要以要求 99% 或更高可用性的系统的人都会受益。如果正常运行时间很重要，那么实施良好的 SRE 将帮助您改进它。
最大的好处来自拥有大量用户的公司，无论是公司内部还是外部客户。此外，处理大量数据或工作负载从资源繁重到轻量化的公司。
在这些情况下，许多公司正在将其大部分处理和计算能力转移到基于云的服务上。有些人已将所有内容都移至云端，而另一些人则有理由使用混合架构，将个人身份信息 (PII) 或公司财务等敏感数据保留在内部，同时将其他处理移至云端。还有一些人拥有使用虚拟化或内部云的内部拥有的数据中心。
站点可靠性工程师每天都做什么？
站点可靠性工程师首先查看系统，然后执行最简单和最平凡的任务并将它们自动化。这可以腾出更多时间来编写新功能并为潜在问题做准备。
站点可靠性工程师往往来自软件开发背景或系统或运营背景。我们所有人都花时间完成这些任务：编写代码和管理系统。这就是为什么我们既适合知道什么对自动化有用，也适合编写执行自动化的代码。
减灾
在处理最简单的容易实现的任务的同时，我们还研究了减灾和准备计划，并编写了运行手册，计划在坏事发生时如何处理坏事。
高级和初级 SRE 都值得一起尝试尽可能多地自动化已发现的缓解任务：当响应时间很慢时启动额外的数据库服务器，当 CPU 使用率或网络容量变得有点过时时重新路由过载的应用程序服务器周围的流量接近容量，等等。
配置和使用可观察性监控
所有这些都需要良好的监控，以实现对系统的可观察性以及组件是否按预期运行。猜猜谁负责这件事？是的，SRE。监控需要了解系统以及哪些数据是有意义和有用的。它还需要良好的工具并花时间学习如何很好地使用它。
我们可以监控“一切”，但这样做的结果是大量信息，这些信息势不可挡，很快就会被忽视。相反，我们会花时间深思熟虑地考虑哪些指标告诉我们我们需要了解系统的哪些信息，最好在影响用户的问题发生之前以及在停机时间发生之前很久。
我们无法捕捉到所有东西，但科学地这样做可以帮助我们捕捉到我们知道需要捕捉的尽可能多的东西，同时防止我们因过多的噪音和分心而受到干扰。
网站和软件维护
为了安全和最新，必须维护一个系统。当您以质量、稳定性和安全性为目标时，不能接受过时的软件版本或旧配置。
SRE 会花费一些时间来确保及时正确更新软件。他们可能会自动执行诸如版本检查、安全证书等到期日期和依赖需求之类的事情。
事故管理和事故修复
它就在名称中，“站点可靠性”。 SRE 的主要任务之一是保持站点正常运行，当站点因出现故障而停止运行时，尽快使其恢复正常运行。
发生了一个事件。发出警报。寻呼机职责。随叫随到的 SRE 停止了她正在做的任何事情，并开始努力找出问题所在。待命团队中的每个人都聚集在一起，可能是亲自聚会，也可能是通过视频或音频电话会议。信息被收集和共享。事件手册和运行手册被提取出来，用于确定要查看的内容的优先级，并尝试让事情再次正常运行。如果他们无法提供帮助（有时会发生这种情况），则会讨论想法和潜在的修复方法。职责分散在团队成员之间。每个人都齐心协力进行任何研究和任务，以使系统备份、运行和可用。
有几个指标可用于衡量事件响应的速度和效率，例如：
- 平均检测时间 (MTTD)，测量发现问题所需的平均时间
- 平均解决时间 (MTTR)，衡量修复故障系统所需的时间
- 平均无故障时间 (MTTF)，即有缺陷的系统在出现故障之前可以继续运行的平均时间；这类似于正常运行时间，可帮助团队在系统组件停止工作之前计划未来更换系统组件
- 平均故障间隔时间 (MTBF)，用于衡量系统或组件正常工作的平均时间
防止数据丢失
SRE 最著名且看似显而易见的工作是维护系统可用性。也许不那么明显，但更重要的是保持我们数据的完整性。耐用性。防止数据丢失。
数据是我们系统中最重要的东西。每个组件的存在都是为了处理数据或为数据做某事。输入（接收）数据、存储数据、处理数据、转换数据、使用数据、输出数据，不胜枚举。
有些数据是专有的。有些是敏感的。许多类型的数据只能根据严格的监管标准进行处理。
没有好的数据，我们的系统就没有价值。如果我们的数据没有得到适当的保护而被盗，我们可能会被罚款、被起诉，甚至破产，而委托我们的客户会以我们必须努力防止的方式变得脆弱。
如果我们的数据存储损坏或数据库崩溃，我们最好希望我们有良好的备份系统和内置冗余。SRE 也对此负责，这是另一个需要好的工具和知道如何使用它的地方。
防止过去的问题再次发生
SRE 会查看过去的问题事件并尝试防止它们再次发生。这就是诸如无责回顾之类的活动非常有价值的地方。逐个问题地讨论一个问题，注意发生了什么以及如何发生的，而不让任何人成为替罪羊，这将引发有用的想法和参与，以防止问题再次发生。
有趣的部分是当我们开始自动化缓解并使用一点混沌工程对其进行测试以向自己证明我们实际上已经预防了未来的灾难。
事件分析
这些术语可以以两种方式使用。我们可以分析正在进行的事件，寻找如何修复和恢复。这包含在事故维修中。在这里，我们正在考虑另一种分析，即在解决问题并且一切恢复正常之后发生的分析。
有些地方将信息收集和呈现过程称为事后分析。我们更愿意称其为回顾展。无论名称如何，SRE 文化都坚持以无可指责的方式完成。我们不是在寻找替罪羊，而是在学习。这不是关于谁犯了错误（即使事件是由人为错误引起的），因为人为错误通常是因为有人做了他们不应该被工具或软件允许做的事情。
有关事件的每个可用细节都收集在一起，按逻辑（通常是时间顺序）顺序组装，并由团队呈现。我们分享是为了学习。
有时，回顾会在整个公司或至少在受影响的业务部门之间共享。有时，它甚至被公开分享。在这些情况下，还包括有关如何解决问题以及如何减轻或防止再次发生问题的信息。
学习和分享技能
站点可靠性工程的很大一部分是透视。 SRE 团队致力于互惠互利；以让尽可能多的人受益的方式共享信息。得到这份工作并不是学习的结束。作为成熟和成功的 SRE 团队的一部分，了解系统并对其进行良好管理并不是最后阶段。这种相互尊重、分享、团队合作以及专注于共同构建更美好的未来系统而不是担心上次“谁打破它”的理念是关键。
高级 SRE 会花时间使用专门编写的入职手册来教授初级 SRE，这些手册通过指导和积极交流最佳实践和机构知识来编写他们需要学习的主要任务。做好站点可靠性工程绝对需要在每个团队内部和跨团队发展一个社区。这里的失败最终将导致实践的失败。
具有演讲天赋的工程师通常会在会议和其他活动中找到分享他们知识的机会，通常由其他 SRE 和 DevOps 从业者以及想要了解更多实践的人参加。这为学习新技能、了解新技术以及交叉授粉和混合跨公司工作的实践提供了绝佳机会。最喜欢分享的一件事是停电故事。 SRE 有一种讲故事的能力，可以以一种引人入胜的方式传达有意义的信息。
此外，还有很多机会可以在网上找到其他从业者。许多人为公司或在他们的个人网站上写博客文章来分享他们正在学习的东西。我们在 Twitter、Meetup 组、Reddit、一些 LinkedIn 社区组和专门的 Slack 主题频道（透明时刻……最后一个链接指向 Gremlin 赞助的 Chaos Engineering Slack，它有来自整个行业的参与者很好）超越格雷姆林）。
站点可靠性工程是如何开始的？
历史可以追溯到 2000 年代初，早于市场较好的术语 DevOps。 “站点可靠性工程师”这个头衔是由 Google 的工程副总裁 Ben Treynor 发明的，他最终负责成千上万的软件工程师。他的LinkedIn个人资料说，
如果 Google 停止工作，那是我的错。
亚马逊和 Netflix 等其他公司也在类似的时间开始了类似的活动。他们所有人都在寻找方法，使他们已经大规模的部署更加可靠、高效和可扩展。然而，是谷歌的一个团队根据公司的实践写了一本关于 SRE 的书。
除了将软件工程和运营角色结合起来之外，最大的变化是视角的转变。从出现问题时的被动灭火转变为主动强化基础设施是一件大事。它需要预先更加集中注意力，但最终可以通过防止潜在的失败来节省 SRE 员工的时间和公司的资金。
正是这种观点转变导致了混沌工程的创建，作为 SRE 和 DevOps 从业者所接受的一种实践。任何想要证明实施的缓解方案和预防措施确实有效的人突然手头有工具可以做到这一点。
站点可靠性工程师的报酬是多少？
我们在 SRE 与 DevOps 中更深入地讨论了这个问题——它们能共存还是竞争？简短的回答是，薪水很大程度上取决于地点、工程师经验和公司等因素。
截至 2020 年初，美国各地站点可靠性工程师的年薪范围从低端的约 75,000 美元到某些极端偏远情况下的约 450,000 美元或更多。美国的平均工资约为 236,000 美元。在网站可靠性工程师的薪水和库存中赚多少钱中了解更多信息。
成为站点可靠性工程师需要哪些技能？
我们在 SRE 的角色和责任中更深入地讨论了这个问题。
一流的站点可靠性工程师候选人将有一个自然的优先级排序过程。也就是说，他们能够筛选信息并辨别什么是重要的，什么不是。他们还将具有出色的人际沟通技巧。
他们还将拥有一套技能，包括一定程度的熟悉：
- Git 和 GitHub 和/或 GitLab 等主机
- Vim（因为这个编辑器在你可能遇到的几乎任何服务器上都可以广泛使用）
- Linux 基础知识，如包管理、用户帐户管理以及目录和文件权限
- 基本的服务器软件管理，例如 Apache httpd 或 Nginx
- SSH
- Shell 脚本，例如使用 Bash
- 使用 Python 和 Go 甚至 Rust 等语言进行编程
- 自动化
- 联网
- 监控、日志记录和可观察性
- 测试，包括编写单元测试和用于 CI 的测试的能力
- 数据库，包括 MySQL 和 Postgres 等关系数据库，以及至少熟悉 Cassandra、MongoDB 和 Neo4j 等较新的 NoSQL/NewSQL 选项
那些刚进入 SRE 初级职位的人预计不会一开始就了解所有这些，但预计会了解在他们被雇用的系统上成功运行以保持和高效运行所需的内容。有关更多信息，请参阅我们的示例 SRE 职位描述和面试问题文章。
SRE 使用什么工具？
站点可靠性工程有时会很混乱。它一直在变化。在这种环境中管理工作需要计划。跨团队标准化工具集始终是一个好主意。
- 首先，SRE 必须能够跟踪工作和进度才能取得成功。为此，SRE 组织使用的首批工具之一是一个很好的问题跟踪器，如 JIRA 或 Pivotal Tracker。
SRE 将许多工具与他们管理的软件一起编写。将该代码放在像 Git 这样的存储库中是至关重要的。让每个人都使用相同的 IDE、库和构建过程（例如 Jenkins 或 Spinnaker 等 CI/CD 工具）可以使协作更加高效和顺畅。
- 将 SRE 团队拥有的服务部署到更广泛的云应用程序架构中的过程很重要。许多团队为此使用 Docker 或 Kubernetes 等容器。
团队通常会自动化他们所能做的一切，包括配置。 Ansible 和 Terraform 等工具对此很有用。
站点可靠性工程如何适应更广泛的工程组织？
在拥有大型云部署的年轻组织中，SRE 角色可能是常态。在仍然拥有企业拥有的数据中心和专门的开发与运营团队的旧组织中，SRE 可能是新的、独特的角色。进化似乎只是反向快速。
在过渡期（在某些情况下可能持续多年），公司可能有一个开发团队仍在使用瀑布方法进行产品开发，并将代码扔给负责使该代码在生产中工作的操作人员。当然，这只是在经过变更审查委员会的多次审查和批准、在测试和阶段环境中的部署等之后。
这些公司可能同时拥有新团队作为试点项目运行，并获得使用敏捷开发方法、DevOps 和/或站点可靠性工程实践以及自动化 CI/CD 管道的许可。这些与更传统的团队并肩作战，有时可能被视为竞争对手。
证明站点可靠性工程的价值的最佳方法是精益求精。学习观点。制定核心价值观。以前所未有的速度推动稳定和需要的功能，并让编写代码的人负责保持其在生产中的良好运行。
团队可能由传统的开发人员/工程师角色、运营专家、监控专家等组成，只有少数团队成员拥有“站点可靠性工程师”的头衔。这并不罕见。在这样的地方，整个团队都拥有代码和运营方面，而 SRE 通常是最了解管理代码的人；构建、部署、配置等。数据库工程师可能仍然是专注于数据可靠性的人，但 SRE 在从她的知识中受益的同时，有助于扩大视野。
归根结底，SRE 是关于协作和合作的，将具有不同技能的人聚集在一起，实现共同目标，让他们有效地分享知识和责任，从而提高系统效率和正常运行时间。
我们如何创建我们的第一个站点可靠性工程团队？
成功的最好方法是首先知道我们正在努力完成什么。我们经常看到项目或范式转变始于太少的计划。当我们学习并需要适应不断变化的环境时，我们希望我们的实施具有灵活性，但我们仍然需要制定计划。
我们首先定义我们的需求。我们希望 SRE 团队做什么？管理？一个好的开始是计划这个新团队将接管一个相对较小的服务或系统。
为什么？因为在这一点上，更广泛的组织正在同时学习文化和流程，并且您希望建立您的第一个团队以取得成功，因为他们有两倍的学习量要做。开始为即将发生的事情准备整个组织。他们需要时间来适应这样一个团队运行的想法。有些人可能会退缩。倾听他们，温柔地教导和引导，但不要走神。
接下来，考虑一下该团队成功所需的工具。不要急于购买它们，因为您可能会聘请一组经验丰富的工程师，他们知道更好的方法和更好的工具，但至少对典型成本进行研究，以便您可以设定初步的预算预期。
这个团队将包括多少人？您是否需要 24/7/365，或者这是一个可以根据需要与一两个随叫随到的人一起工作标准时间的团队？我们建议您的第一个团队使用后者，学习如何在低风险的事情上实施 SRE，然后向上移动。
定义你想在这个 SRE 团队中培养的文化。把它写下来，这样你就可以在接下来创建的工作列表中描述它。
要继续您的员工人数计划，请为您希望为该团队雇用的每个理想候选人编写职位描述。请记住，并非每个人都来自相同的背景，这就是您想要的——多视角！明确团队成员的责任和期望。
决定团队成员是否都将被称为“站点可靠性工程师”，还是将 SRE 与传统角色和头衔混合使用？请记住，单个团队成员可能有专长，但他们都应该为整个团队的所有需求和角色做出贡献，因此您需要灵活的人，他们在分享自己的专业知识时乐于一起学习。
现在，设置第一年的工资预算、团队预算和工具预算。估计比你认为你需要的要高。
我们建议雇佣一批经验丰富的 SRE，他们首先热爱自己的工作。预计最初的 3-4 名领导者将通过了解当今存在的情况、其运作方式以及思考他们想要如何接管来开始工作。考虑内部和外部招聘的混合，以帮助使这一过程在制度上顺利进行，同时也提供一些新的见解和观点。
这些第一批员工需要一点时间来了解彼此的个性、优势和才能，以及他们在整个团队中看到的任何差距。当他们告诉你他们作为一个团队需要什么才能取得成功时，请相信他们的直觉。询问他们接下来要雇用谁，并将他们包括在团队成长过程中。
让他们将运行的系统的经验和学到的知识指导事情从这里开始。
我们如何衡量 SRE 团队的成功？
这里有一些想法。如果我们从编制停机时间和导致问题的故障列表开始，即使没有停机时间，并了解这对公司来说有多么昂贵，那么我们可以将其作为衡量基准。
如果我们实施良好的 SRE 实践并为我们的工程师提供我们团队成功所需的工具和人数，您应该会看到停机时间等事件的数量和严重程度的减少，同时看到更快的响应时间和更小的客户和业务影响。
站点可靠性工程的大部分内容是衡量正确的事情并使用该数据来确定未来的工作优先级。当我们得到错误的初始测量和指标时，我们一注意到就会改变。最好转向新的工具、不同的指标和不断发展的政策，而不是仅仅因为我们有一个想要衡量的现有基线而坚持我们现有的东西。
我们知道我们的正常运行时间何时提高。我们知道我们的网站何时或多或少地响应。我们知道内部和外部客户何时对提供给他们的服务感到满意。衡量你认为最重要的东西，并专注于改进它。当您对该指标的成功感到满意时，请关注另一个指标。主要是选择一些东西来改进和改进它。集中改进，即使是小的改进，加起来。
站点可靠性工程不仅仅是加速灾难恢复。它是关于防止停机，提高系统对压力源的响应能力，并使我们的系统尽可能高效和可靠。