document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

校对完毕

Browse Source 
校对完毕 @geekpi 中间有几段遗漏，其余都很好，谢谢。
This commit is contained in:
jasminepeng 2017-02-03 11:01:33 +08:00 committed by GitHub
parent 5d0a890aa9
commit 8be941324b
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
translated/tech/20160425 What is SRE.md
View File

@ -39,13 +39,13 @@ sysadmin 服务管理模型有几个优点。对于决定该如何运行和服
### Google 服务管理的方法：网站可靠性工程
冲突不是提供软件服务的必然部分。Google 选择以不同的方式运行我们的系统：我们的网站可靠性工程团队专注于雇佣软件工程师来运行我们的产品，并创建系统来完成那些本来由sysadmins手动完成的工作。
冲突不是提供软件服务的必然部分。Google 选择以不同的方式运行我们的系统：我们的网站可靠性工程团队专注于雇佣软件工程师来运行我们的产品，并创建系统来完成那些本来由 sysadmins 手动完成的工作。
什么是网站可靠性工程，是如它在谷歌定义的那样么？我的解释很简单：SRE 是当你要求一位软件工程师设计一个运维团队时会发生的那样。当我在2003年加入 Google 并负责运行一个由 7 名工程师组成的“生产团队”时，那时我工作的全部都是软件工程。所以我设计和管理了一个假如我是一名 SRE ，_我_想要的团队的样子。这个团队已经成为了 Google 的目前的 SRE 团队，它仍然是一名终生软件工程师所想象的那个样子。
什么是网站可靠性工程，是如它在谷歌定义的那样么？我的解释很简单：SRE 是当你要求一位软件工程师设计一个运维团队时会发生的那样。当我在 2003 年加入 Google 并负责运行一个由 7 名工程师组成的“生产团队”时，那时我工作的全部都是软件工程。所以我假设我是一名 SRE，设计和管理了一个 _我_想要的团队的样子。这个团队已经成为了 Google 的目前的 SRE 团队，它仍如最初一名终生软件工程师所想象的那个样子。
Google 服务管理方法的主要构成部分是由每个 SRE 团队的组成。作为一个整体，SRE可以分为两大类。
50-60％ 的人是 Google 软件工程师，或者更确切地说，是通过 Google 软件工程师的标准程序招聘的人。其他 40-50％ 的候选人非常接近 Google 软件工程师资格（即所需技能集的 85-99％），以及一些具有大多数软件工程师没有的一些 SRE 技术技能的人。到目前为止，UNIX 系统内部和网络（第1层到第3层）的专业知识是我们寻求的两种最常见的替代技术技能。
50-60％ 的人是 Google 软件工程师，或者更确切地说，是通过 Google 软件工程师的标准程序招聘的人。其他 40-50％ 的候选人非常接近 Google 软件工程师资格（即所需技能集的 85-99％），以及一些具有大多数软件工程师没有的一些 SRE 技术技能的人。到目前为止，UNIX 系统内部和网络（第 1 层到第 3 层）的专业知识是我们寻求的两种最常见的替代技术技能。
所有 SRE 的共同点是对开发软件系统以解决复杂问题的信念和能力。在 SRE 中，我们密切跟踪两个团队的职业发展，并且迄今为止发现在两种工程师之间的表现没有实际差异。事实上，SRE 团队的多样背景经常产生聪明、高质量的系统，这显然是几个技能集合成的产物。
@ -53,13 +53,13 @@ Google 服务管理方法的主要构成部分是由每个 SRE 团队的组成
按照设计，至关重要的是 SRE 团队专注于工程。没有恒定的工程，运维工作增加，团队将需要更多的人来上工作量。最终，传统的以 ops 为中心的团队与服务规模呈线性关系：如果服务支持的产品成功，运维工作将随着流量而增长。这意味着雇用更多的人一遍又一遍地完成相同的任务。
为了避免这种命运，负责管理服务的团队需要写代码否则就会被工作淹没。因此，Google _设置了一个 “ops” 工作如 ticket、紧急呼叫、手动任务最多只占 50% SRE 工作的上限_。此上限确保SRE团队在其计划中有足够的时间使服务稳定及可操作。50% 是上限;随着时间的推移，除了自己的设备，SRE 团队应该只有很少的运维工作，他们几乎可以完全从事开发任务，因为服务基本上可以运行和维修自己：我们想要的系统是_自动的_，而不只是_自动化_。在实践中，规模和新功能始终 SRE 要考虑的
为了避免这种命运，负责管理服务的团队需要写代码，否则就会被工作淹没。因此，Google 为 SRE 们 _设置了一个 “ops” 工作的上限，如 ticket、紧急呼叫、手动任务最多只占 50% 工作量_。此上限确保 SRE 团队在其计划中有足够的时间使服务稳定及可操作。50% 是上限;随着时间的推移，除了自己的设备，SRE 团队应该只有很少的运维工作，他们几乎可以完全从事开发任务，因为服务基本上可以运行和维修自己：我们想要的系统是_自动的_，而不只是_自动化_。在实践中，规模和新功能始终 SRE 要考虑的。
Google的经验法则是，SRE团队必须花费剩余的 50％ 的时间来进行实际开发。那么我们该如何执行这个阈值呢？首先，我们必须测量 SRE 如何花费时间。通过测量，我们确保团队不断花费不到 50% 的时间用于开发改变他们实践的工作上。通常这意味着会将一些运维负担转移回开发团队，或者给团队添加新的员工，而不指派该团队额外的运维责任。意识到在运维和开发工作之间保持这种平衡使我们能保证 SRE 具有参与创造性的自主工程的空间，同时仍然保留从运维那学来的智慧。
Google 的经验法则是，SRE 团队必须花费剩余的 50％ 的时间来进行实际开发。那么我们该如何执行这个阈值呢？首先，我们必须测量 SRE 如何花费时间。通过测量，我们确保团队不断花费不到 50% 的时间用于开发改变他们实践的工作上。通常这意味着会将一些运维负担转移回开发团队，或者给团队添加新的员工，而不指派该团队额外的运维责任。意识到在运维和开发工作之间保持这种平衡使我们能保证 SRE 具有参与创造性的自主工程的空间，同时仍然保留从运维那学来的智慧。
我们发现Google SRE 的运行大规模系统的方法有很多优点。由于 SRE 是直接修改代码以使Google的系统运行自己，SRE团队的特点是快速创新以及大量接受变革。这样的团队能相对价廉地支持相同的服务，面向运维的团队需要大量的人。相反，运行、维护和改进系统所需的 SRE 的数量随系统的大小而线性地缩放。最后，SRE 不仅规避了开发/运维分裂的障碍，而且这种结构也改善了我们的产品开发团队：产品开发和 SRE 团队之间的轻松转移交叉培训整个团队，并且提高了那些在学习构建百万级别分布式系统上有困难的开发人员的技能。
我们发现 Google SRE 的运行大规模系统的方法有很多优点。由于 SRE 是直接修改代码以使 Googl e的系统运行自己，SRE 团队的特点是快速创新以及大量接受变革。这样的团队能相对价廉地支持相同的服务，面向运维的团队需要大量的人。相反，运行、维护和改进系统所需的 SRE 的数量随系统的大小而线性地缩放。最后，SRE 不仅规避了开发/运维分裂的障碍，而且这种结构也改善了我们的产品开发团队：产品开发和 SRE 团队之间的轻松转移交叉培训整个团队，并且提高了那些在学习构建百万级别分布式系统上有困难的开发人员的技能。
尽管有这些好处，SRE 模型的特点是其自身独特的挑战。 Google 面临的一个持续挑战是招聘 SRE：SRE 不仅与产品开发招聘流程竞争相同的候选人，而且我们将招聘人员的编码和系统工程技能都设置得如此之高，这意味着我们的招聘池必然很小。由于我们的学科相对新颖独特，在如何建立和管理 SRE 团队方面没有太多的行业信息（尽管希望这本书能朝着这个方向迈进！）。一旦 SRE 团队到位，他们潜在的非正统的服务管理方法需要强有力的管理支持。例如，一旦错误预估耗尽，除非是管理层的强制要求, 否则在季度剩余的时间里决定停止发布可能不会被产品开发团队所接受。
尽管有这些好处，SRE 模型的特点是其自身独特的挑战。 Google 面临的一个持续挑战是招聘 SRE：SRE 不仅与产品开发招聘流程竞争相同的候选人，而且我们将招聘人员的编码和系统工程技能都设置得如此之高，这意味着我们的招聘池必然很小。由于我们的学科相对新颖独特，在如何建立和管理 SRE 团队方面没有太多的行业信息（不过希望这本书能朝着这个方向迈进！）。一旦 SRE 团队到位，他们潜在的非正统的服务管理方法需要强有力的管理支持。例如，一旦错误预估耗尽，除非是管理层的强制要求, 否则在季度剩余的时间里决定停止发布可能不会被产品开发团队所接受。
###### DevOps 或者 SRE？