mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-30 02:40:11 +08:00
校对中
校对中
This commit is contained in:
jasminepeng
GitHub
parent
45fd1c1fc7
commit
2ac65dbdf9
@ -1,13 +1,13 @@
|
||||
什么是SRE（网站可靠性工程）？
|
||||
什么是 SRE（<ruby>网站可靠性工程<rt>Site Reliability Engineering</rt></ruby>）？
|
||||
============================================================
|
||||
|
||||
网站可靠性工程师是近来越来越多看到的一个职位。它是什么意思？它来自哪里？让我们从 Google SRE 团队来学习。
|
||||
|
||||
|
||||
|
||||
这里有一篇由 Niall Richard Murphy、Jennifer Petoff、Chris Jones、Betsy Beyer 编辑一篇来自[网站可靠性工程][9]的摘录。
|
||||
本文为 Niall Richard Murphy、Jennifer Petoff、Chris Jones、Betsy Beyer 编辑的 [<ruby>《网站可靠性工程》<rt>Site Reliability Engineering</rt></ruby>][9] 一书的摘录。
|
||||
|
||||
网站可靠性工程也在[11月7-10日在阿姆斯特丹举办的 O'Reilly Velocity 会议][10]上有提到。
|
||||
网站可靠性工程在[ 11 月 7-10 日在阿姆斯特丹举办的 O'Reilly Velocity 会议][10]上也有提到。
|
||||
|
||||
### 介绍
|
||||
|
||||
@ -15,16 +15,26 @@
|
||||
>
|
||||
> 传统的 SRE 说
|
||||
|
||||
一个公认的事实是系统不会自己。 那么，一个特定系统的复杂大规模系统_应该_怎么运行呢？
|
||||
一个公认的事实是系统不会自己运行。 那么，一个系统 — 尤其是复杂大规模系统 — _应该_怎么运行呢？
|
||||
|
||||
|
||||
### sysadmin 服务管理方法
|
||||
|
||||
sysadmin服务管理模型有几个优点。对于决定该如何运行和服务的公司而言，这种方法相对容易实现：它作为一个熟悉的行业范例，有很多例子可以从中学习和效仿。相关人才库已经广泛普及。有一系列现有的工具，软件组件（现成的或其他）和集成公司可用于帮助运行这些组装的系统，所以新手sysadmin团队不必重新发明轮子以及从头设计系统。
|
||||
以前，公司雇用系统管理员来运行复杂的计算系统。
|
||||
|
||||
因此，传统运营团队及其在产品开发中的同行往往会发生冲突，最突出的是如何将软件发布到生产环境。在他们核心中，开发团队希望推出新功能，并看到它们被用户采纳。在_他们_的核心上，ops 团队希望确保服务在运行中不会中断。因为大多数中断是由某种变化引起的 - 新的配置、新的功能发布或者新的用户流量类型 - 这两个团队的目标基本上处于紧张状态。
|
||||
系统管理员（或者称为 sysadmin）这种方式包括整合现有软件组件，互相协作来完成一个服务。系统管理员的任务是运行服务，响应事件，并在事件发生时进行更新。随着系统复杂度的增长和流量的增长，事件和更新也相应增长，导致管理员团队也越来越庞大以完成这些额外工作。由于系统管理员的角色需要的技能与产品开发人员有很大不同，开发和系统管理员被分为不同的团队：“开发”和“运维”。
|
||||
|
||||
两个团队都明白，以最可能的条款（“我们可以没有阻碍地在任何时间发布任何东西”以及“我们不想在系统工作后改变任何东西”）来表达他们的利益是不可接受的。因为他们的词汇和风险假设都不同，两个团体经常采用熟悉斗争形式来提高他们的利益。 ops 团队试图通过发布介绍和提高门槛来保护运行中的系统免受更改的风险。例如，发布审查可能包含对_每个_问题的显式审查，这些问题过去都_曾经_引起过服务中断 - 它可能是一个任意长度的列表，并且不是所有元素都提供相等的值。开发团队很快学会了如何回应。他们有较少的“发布”和更多的“标志翻转”、“增量更新”或“cherrypicks”。他们采取诸如分割产品功能的策略，以便更少的功能受到发布审查。
|
||||
sysadmin 服务管理模型有几个优点。对于决定该如何运行和服务的公司而言，这种方法相对容易实现：它作为一个熟悉的行业范例，有很多例子可以从中学习和效仿。相关人才库已经广泛普及。有一系列现有的工具，软件组件（现成的或其他）和集成公司可用于帮助运行这些组装的系统，所以新手 sysadmin 团队不必重新发明轮子以及从头设计系统。
|
||||
|
||||
此方式将公司开发/运维分离，也有一些缺点和困难。主要有两类：直接代价和间接代价。
|
||||
|
||||
直接代价很显而易见了。利用依靠手工干预来进行变更管理和事件处理的团队进行服务管理，当服务和/或流量增长时，成本是很昂贵的，因为团队随着系统负载的增长也在相应增长。
|
||||
|
||||
开发/运维分离的间接代价可能不那么明显，但常常比直接代价还要昂贵。代价来自于两个团队背景，技术，激励都非常不同。他们使用不同的词汇来描述形式；对技术方案的风险和可能性他们持不同的假设；对产品稳定性的目标级别也会有不同的争议。团队的分离很容易导致不只是激励的不同，还有沟通、目标，以及最终，信任和尊重的分离。这是一种恶性循环。
|
||||
|
||||
因此，传统运营团队及其在产品开发中的同行往往会发生冲突，最突出的是如何将软件发布到生产环境。在开发团队核心中，他们希望推出新功能，并看到它们被用户采纳。在_ops 团队_的核心上， 他们希望确保服务在运行中不会中断。因为大多数中断是由某种变化引起的 - 新的配置、新的功能发布或者新的用户流量类型 - 这两个团队的目标基本上处于紧张状态。
|
||||
|
||||
两个团队都明白，以最可能的条款（“我们可以没有阻碍地在任何时间发布任何东西”以及“我们不想在系统工作后改变任何东西”）来表达他们的利益是不可接受的。因为他们的词汇和风险假设都不同，两个团体经常采用常见的斗争形式来提高他们的利益。 ops 团队试图通过提高发布和变更门槛来保护运行中的系统免受更改的风险。例如，发布审查可能包含对_每个_问题的显式审查，这些问题过去都_曾经_引起过服务中断 - 它可能是一个任意长度的列表，并且不是所有元素都提供相等的值。开发团队很快学会了如何回应。他们有较少的“发布”和更多的“标志翻转”、“增量更新”或 “cherrypicks”。他们采取诸如分割产品功能的策略，以便更少的功能受到发布审查。
|
||||
|
||||
|
||||
### Google 服务管理的方法：网站可靠性工程
|
||||
@ -53,12 +63,12 @@ Google的经验法则是，SRE团队必须花费剩余的 50％ 的时间来进
|
||||
|
||||
###### DevOps 或者 SRE？
|
||||
|
||||
“DevOps” 这个术语在 2008 年末出现，并在写这篇文章时（2016 年早期）仍在发生变动。 其核心原则：IT部门在系统设计和开发的每个阶段的参与、对自动化与人力投入的严重依赖、工程实践和工具在操作任务中的应用，与许多 SRE 的原则和实践一致。 人们可以将 DevOps 视为向更广泛的组织，管理结构和人员的几种核心SRE原则。 可以等价地将 SRE 视为具有某些特殊扩展的 DevOps 的特定实现。
|
||||
“DevOps” 这个术语在 2008 年末出现，并在写这篇文章时（2016 年早期）仍在发生变动。 其核心原则：IT 部门在系统设计和开发的每个阶段的参与、对自动化与人力投入的严重依赖、工程实践和工具在操作任务中的应用，与许多 SRE 的原则和实践一致。 人们可以将 DevOps 视为向更广泛的组织，管理结构和人员的几种核心 SRE原则。 可以等价地将 SRE 视为具有某些特殊扩展的 DevOps 的特定实现。
|
||||
|
||||
|
||||
------------------------
|
||||
|
||||
作者简介：Benjamin Treynor Sloss 创造了“网站可靠性工程”一词，他自2003年以来一直负责 Google 的全球运营、网络和生产工程。截至2016年，他管理着全球范围内一个大约4000名软硬件和网络工程师团队。
|
||||
作者简介：Benjamin Treynor Sloss 创造了“网站可靠性工程”一词，他自 2003 年以来一直负责 Google 的全球运营、网络和生产工程。截至 2016 年，他管理着全球范围内一个大约 4000 名软硬件和网络工程师团队。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user