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

PRF:20180117 How to get into DevOps.md

Browse Source 
@belitex @pityonline
This commit is contained in:
Xingyu.Wang 2018-10-07 23:23:00 +08:00
parent bac77f87eb
commit 4e1bd9418c
1 changed files with 23 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
translated/talk/20180117 How to get into DevOps.md
View File

@ -1,5 +1,6 @@
DevOps 实践指南
======
> 这些技巧或许对那些想要践行 DevOps 的系统运维和开发者能有所帮助。
![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/rh_003784_02_os.comcareers_resume_rh1x.png?itok=S3HGxi6E)
@ -11,19 +12,19 @@ DevOps 实践指南
了解历史是搞清楚未来的关键，DevOps 也不例外。想搞清楚 DevOps 运动的普及和流行，去了解一下上世纪 90 年代后期和 21 世纪前十年 IT 的情况会有帮助。这是我的经验。
我的第一份工作是在一家大型跨国金融服务公司做 Windows 系统管理员。当时给计算资源扩容需要给 Dell 打电话（或者像我们公司那样打给 CDW），并下一个价值数十万美元的订单，包含服务器、网络设备、电缆和软件，所有这些都要运到生产或线下的数据中心去。虽然 VMware 仍在尝试说服企业使用虚拟机运行他们的“性能敏感”型程序是更划算的，但是包括我们在内的很多公司都还忠于使用他们的物理机运行应用。
我的第一份工作是在一家大型跨国金融服务公司做 Windows 系统管理员。当时给计算资源扩容需要给 Dell 打电话（或者像我们公司那样打给 CDW），并下一个价值数十万美元的订单，包含服务器、网络设备、电缆和软件，所有这些都要运到生产或线下的数据中心去。虽然 VMware 仍在尝试说服企业使用虚拟机运行他们的“性能敏感”型程序是更划算的，但是包括我们在内的很多公司都还是愿意使用他们的物理机运行应用。
在我们技术部门，有一个专门做数据中心工程和运营的团队，他们的工作包括价格谈判，让荒唐的月租能够降一点点，还包括保证我们的系统能够正常冷却（如果设备太多，这个事情的难度会呈指数增长）。如果这个团队足够幸运足够有钱，境外数据中心的工作人员对我们所有的服务器型号又都有足够的了解，就能避免在盘后交易中不小心搞错东西。那时候亚马逊 AWS 和 Rackspace 逐渐开始加速扩张，但还远远没到临界规模。
当时我们还有专门的团队来保证硬件上运行着的操作系统和软件能够按照预期工作。这些工程师负责设计可靠的架构以方便给系统打补丁，监控和报警，还要定义<ruby>基础镜像<rt>gold image</rt></ruby>的内容。这些大都是通过很多手工实验完成的，很多手工实验是为了编写一个<ruby>运行说明书<rt>runbook</rt></ruby>来描述要做的事情，并确保按照它执行后的结果确实在预期内。在我们这么大的组织里，这样做很重要，因为一线和二线的技术支持都是境外的，而他们的培训内容只覆盖到了这些运行说明而已。
当时我们还有专门的团队来保证硬件上运行着的操作系统和软件能够按照预期工作。这些工程师负责设计可靠的架构以方便给系统打补丁、监控和报警，还要定义<ruby>基础镜像<rt>gold image</rt></ruby>的内容。这些大都是通过很多手工实验完成的，很多手工实验是为了编写一个<ruby>运行说明书<rt>runbook</rt></ruby>来描述要做的事情，并确保按照它执行后的结果确实在预期内。在我们这么大的组织里，这样做很重要，因为一线和二线的技术支持都是境外的，而他们的培训内容只覆盖到了这些运行说明而已。
(这是我职业生涯前三年的世界。我那时候的梦想是成为制定金本位制的人！)
（这是我职业生涯前三年的世界。我那时候的梦想是成为制定最高标准的人！）
软件发布则完全是另外一头怪兽。无可否认，我在这方面并没有积累太多经验。但是，从我收集的故事（和最近的经历）来看，当时大部分软件开发的日常大概是这样：
* 开发人员按照技术和功能需求来编写代码，这些需求来自于业务分析人员的会议，但是会议并没有邀请开发人员参加。
* 开发人员可以选择为他们的代码编写单元测试，以确保在代码里没有任何明显的疯狂行为，比如除以 0 但不抛出异常。
* 然后开发者会把他们的代码标记为“Ready for QA”（准备好了接受测试），质量保障的成员会把这个版本的代码发布到他们自己的环境中，这个环境和生产环境可能相似，也可能不，甚至和开发环境相比也不一定相似。
* 然后开发者会把他们的代码标记为 “Ready for QA”（准备好了接受测试），质量保障的成员会把这个版本的代码发布到他们自己的环境中，这个环境和生产环境可能相似，也可能不，甚至和开发环境相比也不一定相似。
* 故障会在几天或者几个星期内反馈到开发人员那里，这个时长取决于其它业务活动和优先事项。
虽然系统管理员和开发人员经常有不一致的意见，但是对“变更管理”却一致痛恨。变更管理由高度规范的（就我当时的雇主而言）和非常必要的规则和程序组成，用来管理一家公司应该什么时候做技术变更，以及如何做。很多公司都按照 [ITIL][4] 来操作，简单的说，ITIL 问了很多和事情发生的原因、时间、地点和方式相关的问题，而且提供了一个过程，对产生最终答案的决定做审计跟踪。
@ -54,20 +55,20 @@ DevOps 不是一个团队，CI/CD 也不是 JIRA 系统的一个用户组。DevO
我经常被问到这个问题，它的答案和同属于开放式的其它大部分问题一样：视情况而定。
现在“DevOps 工程师”在不同的公司有不同的含义。在软件开发人员比较多但是很少有人懂基础设施的小公司，他们很可能是在找有更多系统管理经验的人。而其他公司，通常是大公司或老公司，已经有一个稳固的系统管理团队了，他们在向类似于谷歌 [SRE][7] 的方向做优化，也就是“设计操作功能的软件工程师”。但是，这并不是金科玉律，就像其它技术类工作一样，这个决定很大程度上取决于他的招聘经理。
现在“DevOps 工程师”在不同的公司有不同的含义。在软件开发人员比较多但是很少有人懂基础设施的小公司，他们很可能是在找有更多系统管理经验的人。而其他公司，通常是大公司或老公司，已经有一个稳固的系统管理团队了，他们在向类似于谷歌 [SRE][7] 的方向做优化，也就是“设计运维功能的软件工程师”。但是，这并不是金科玉律，就像其它技术类工作一样，这个决定很大程度上取决于他的招聘经理。
也就是说，我们一般是在找对深入学习以下内容感兴趣的工程师：
* 如何管理和设计安全、可扩展的云平台（通常是在 AWS 上，不过微软的 Azure，Google Cloud Platform，还有 DigitalOcean 和 Heroku 这样的 PaaS 提供商，也都很流行）。
* 如何用流行的 [CI/CD][8] 工具，比如 Jenkins，GoCD，还有基于云的 Travis CI 或者 CircleCI，来构造一条优化的发布部署流水线和发布部署策略。
* 如何在你的系统中使用基于时间序列的工具，比如 Kibana，Grafana，Splunk，Loggly 或者 Logstash 来监控，记录，并在变化的时候报警。
* 如何使用配置管理工具，例如 Chef，Puppet 或者 Ansible 做到“基础设施即代码”，以及如何使用像 Terraform 或 CloudFormation 的工具发布这些基础设施。
* 如何管理和设计安全、可扩展的云平台（通常是在 AWS 上，不过微软的 Azure、Google Cloud Platform，还有 DigitalOcean 和 Heroku 这样的 PaaS 提供商，也都很流行）。
* 如何用流行的 [CI/CD][8] 工具，比如 Jenkins、GoCD，还有基于云的 Travis CI 或者 CircleCI，来构造一条优化的发布部署流水线和发布部署策略。
* 如何在你的系统中使用基于时间序列的工具，比如 Kibana、Grafana、Splunk、Loggly 或者 Logstash 来监控、记录，并在变化的时候报警。
* 如何使用配置管理工具，例如 Chef、Puppet 或者 Ansible 做到“基础设施即代码”，以及如何使用像 Terraform 或 CloudFormation 的工具发布这些基础设施。
容器也变得越来越受欢迎。尽管有人对大规模使用 Docker 的现状[表示不满][9]，但容器正迅速地成为一种很好的方式来实现在更少的操作系统上运行超高密度的服务和应用，同时提高它们的可靠性。（像 Kubernetes 或者 Mesos 这样的容器编排工具，能在宿主机故障的时候，几秒钟之内重新启动新的容器。）考虑到这些，掌握 Docker 或者 rkt 以及容器编排平台的知识会对你大有帮助。
如果你是希望做 DevOps 实践的系统管理员，你还需要知道如何写代码。Python 和 Ruby 是 DevOps 领域的流行语言，因为它们是可移植的（也就是说可以在任何操作系统上运行），快速的，而且易读易学。它们还支撑着这个行业最流行的配置管理工具（Ansible 是使用 Python 写的，Chef 和 Puppet 是使用 Ruby 写的）以及云平台的 API 客户端（亚马逊 AWS，微软 Azure，Google Cloud Platform 的客户端通常会提供 Python 和 Ruby 语言的版本）。
如果你是希望做 DevOps 实践的系统管理员，你还需要知道如何写代码。Python 和 Ruby 是 DevOps 领域的流行语言，因为它们是可移植的（也就是说可以在任何操作系统上运行）、快速的，而且易读易学。它们还支撑着这个行业最流行的配置管理工具（Ansible 是使用 Python 写的，Chef 和 Puppet 是使用 Ruby 写的）以及云平台的 API 客户端（亚马逊 AWS、微软 Azure、Google Cloud Platform 的客户端通常会提供 Python 和 Ruby 语言的版本）。
如果你是开发人员，也希望做 DevOps 的实践，我强烈建议你去学习 Unix，Windows 操作系统以及网络基础知识。虽然云计算把很多系统管理的难题抽象化了，但是对应用的性能做 debug 的时候，如果你知道操作系统如何工作的就会有很大的帮助。下文包含了一些这个主题的图书。
如果你是开发人员，也希望做 DevOps 的实践，我强烈建议你去学习 Unix、Windows 操作系统以及网络基础知识。虽然云计算把很多系统管理的难题抽象化了，但是对应用的性能做调试的时候，如果你知道操作系统如何工作的就会有很大的帮助。下文包含了一些这个主题的图书。
如果你觉得这些东西听起来内容太多，没关系，大家都是这么想的。幸运的是，有很多小项目可以让你开始探索。其中一个项目是 Gary Stafford 的[选举服务](https://github.com/garystafford/voter-service)，一个基于 Java 的简单投票平台。我们要求面试候选人通过一个流水线将该服务从 GitHub 部署到生产环境基础设施上。你可以把这个服务与 Rob Mile 写的了不起的 DevOps [入门教程](https://github.com/maxamg/cd-office-hours)结合起来学习。
@ -79,22 +80,22 @@ DevOps 不是一个团队，CI/CD 也不是 JIRA 系统的一个用户组。DevO
#### 理论书籍
* Gene Kim 写的 [The Phoenix Project（凤凰项目）][10]。这是一本很不错的书，内容涵盖了我上文解释过的历史（写的更生动形象），描述了一个运行在敏捷和 DevOps 之上的公司向精益前进的过程。
* Terrance Ryan 写的 [Driving Technical Change（布道之道）][11]。非常好的一小本书，讲了大多数技术型组织内的常见性格特点以及如何和他们打交道。这本书对我的帮助比我想象的更多。
* Tom DeMarco 和 Tim Lister 合著的 [Peopleware（人件）][12]。管理工程师团队的经典图书，有一点过时，但仍然很有价值。
* Tom Limoncelli 写的 [Time Management for System Administrators（时间管理：给系统管理员）][13]。这本书主要面向系统管理员，它对很多大型组织内的系统管理员生活做了深入的展示。如果你想了解更多系统管理员和开发人员之间的冲突，这本书可能解释了更多。
* Eric Ries 写的 [The Lean Startup（精益创业）][14]。描述了 Eric 自己的 3D 虚拟形象公司，IMVU，发现了如何精益工作，快速失败和更快盈利。
* Jez Humble 和他的朋友写的 [Lean Enterprise（精益企业）][15]。这本书是对精益创业做的改编，以更适应企业，两本书都很棒，都很好地解释了 DevOps 背后的商业动机。
* Kief Morris 写的 [Infrastructure As Code（基础设施即代码）][16]。关于“基础设施即代码”的非常好的入门读物！很好的解释了为什么所有公司都有必要采纳这种做法。
* Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall Richard Murphy 合著的 [Site Reliability Engineering（站点可靠性工程师）][17]。一本解释谷歌 SRE 实践的书，也因为是“DevOps 诞生之前的 DevOps”被人熟知。在如何处理运行时间、时延和保持工程师快乐方面提供了有意思的看法。
* Gene Kim 写的 《<ruby>[凤凰项目][10]<rt>The Phoenix Project</rt></ruby>》。这是一本很不错的书，内容涵盖了我上文解释过的历史（写的更生动形象），描述了一个运行在敏捷和 DevOps 之上的公司向精益前进的过程。
* Terrance Ryan 写的 《<ruby>[布道之道][11]<rt>Driving Technical Change</rt></ruby>》。非常好的一小本书，讲了大多数技术型组织内的常见性格特点以及如何和他们打交道。这本书对我的帮助比我想象的更多。
* Tom DeMarco 和 Tim Lister 合著的 《<ruby>[人件][12]<rt>Peopleware</rt></ruby>》。管理工程师团队的经典图书，有一点过时，但仍然很有价值。
* Tom Limoncelli 写的 《<ruby>[时间管理：给系统管理员][13]<rt>Time Management for System Administrators</rt></ruby>》。这本书主要面向系统管理员，它对很多大型组织内的系统管理员生活做了深入的展示。如果你想了解更多系统管理员和开发人员之间的冲突，这本书可能解释了更多。
* Eric Ries 写的 《<ruby>[精益创业][14]<rt>The Lean Startup</rt></ruby>》。描述了 Eric 自己的 3D 虚拟形象公司，IMVU，发现了如何精益工作，快速失败和更快盈利。
* Jez Humble 和他的朋友写的 《<ruby>[精益企业][15]<rt>Lean Enterprise</rt></ruby>》。这本书是对精益创业做的改编，以更适应企业，两本书都很棒，都很好地解释了 DevOps 背后的商业动机。
* Kief Morris 写的 《<ruby>[基础设施即代码][16]<rt>Infrastructure As Code</rt></ruby>》。关于“基础设施即代码”的非常好的入门读物！很好的解释了为什么所有公司都有必要采纳这种做法。
* Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall Richard Murphy 合著的 《<ruby>[站点可靠性工程师][17]<rt>Site Reliability Engineering</rt></ruby>》。一本解释谷歌 SRE 实践的书，也因为是“DevOps 诞生之前的 DevOps”被人熟知。在如何处理运行时间、时延和保持工程师快乐方面提供了有意思的看法。
#### 技术书籍
如果你想找的是让你直接跟代码打交道的书，看这里就对了。
* W. Richard Stevens 的 [TCP/IP Illustrated（TCP/IP 详解）][18]。这是一套经典的（也可以说是最全面的）讲解网络协议基础的巨著，重点介绍了 TCP/IP 协议族。如果你听说过 1，2，3，4 层网络，而且对深入学习它们感兴趣，那么你需要这本书。
* Evi Nemeth、Trent Hein 和 Ben Whaley 合著的 [UNIX and Linux System Administration Handbook（UNIX/Linux 系统管理员手册）][19]。一本很好的入门书，介绍 Linux/Unix 如何工作以及如何使用。
* Don Jones 和 Jeffrey Hicks 合著的 [Learn Windows Powershell In A Month of Lunches（Windows PowerShell 实战指南）][20]。如果你在 Windows 系统下做自动化任务，你需要学习怎么使用 Powershell。这本书能够帮助你。Don Jones 是这方面著名的 MVP。
* W. Richard Stevens 的 《<ruby>[TCP/IP 详解][18]<rt>TCP/IP Illustrated</rt></ruby>》。这是一套经典的（也可以说是最全面的）讲解网络协议基础的巨著，重点介绍了 TCP/IP 协议族。如果你听说过 1、2、3、4 层网络，而且对深入学习它们感兴趣，那么你需要这本书。
* Evi Nemeth、Trent Hein 和 Ben Whaley 合著的 《<ruby>[UNIX/Linux 系统管理员手册][19]<rt>UNIX and Linux System Administration Handbook</rt></ruby>》。一本很好的入门书，介绍 Linux/Unix 如何工作以及如何使用。
* Don Jones 和 Jeffrey Hicks 合著的 《<ruby>[Windows PowerShell 实战指南][20]<rt>Learn Windows Powershell In A Month of Lunches</rt></ruby>》。如果你在 Windows 系统下做自动化任务，你需要学习怎么使用 Powershell。这本书能够帮助你。Don Jones 是这方面著名的 MVP。
* 几乎所有 [James Turnbull][21] 写的东西，针对流行的 DevOps 工具，他发表了很好的技术入门读物。
不管是在那些把所有应用都直接部署在物理机上的公司，（现在很多公司仍然有充分的理由这样做）还是在那些把所有应用都做成 serverless 的先驱公司，DevOps 都很可能会持续下去。这部分工作很有趣，产出也很有影响力，而且最重要的是，它搭起桥梁衔接了技术和业务之间的缺口。DevOps 是一个值得期待的美好事物。