如何高效维护和管理IT基础设施，不如试试这个？
小长假匆匆而过，不知道各位小伙伴们节后的工作状态如何？思绪是不是还飘在空中，无法集中精力呢？告诉你个事情，本年度余额也将严重不足，毕竟无缘支付宝中国锦鲤大奖的我们，还是要不断努力学习的。
今天用一本新书来唤醒大家，咱们就来说说“基础设施即代码”。说到这个词，你可能没听过，不过只要你对 DevOps 感兴趣，你一定也会有兴趣了解它。运维人员怎样才能像程序员一般维护和管理 IT 基础设施呢？不如试试这个！
什么是基础设施即代码?
基础设施即代码是一种基于软件开发实践的基础设施自动化方法。它强调系统及其配置的日常置备和变更，具有一致性和可重复性。先修改配置的定义代码，再通过包括全面验证的无人值守过程应用到系统中去。
这种方法的前提是，现代工具可以把基础设施作为软件和数据进行处理。这允许人们在管理基础设施时应用软件开发工具，如版本控制系统（VCS）、自动化测试类库和部署编排工具。这也为利用诸如测试驱动开发（TDD）、持续集成（CI）和持续交付（CD）等开发实践打开了大门。
基础设施即代码已在最苛刻的环境中得到了验证。对于像亚马逊、Netflix、谷歌、Facebook 和 Etsy 这样的公司，IT 系统不仅是业务的关键，而且本身就是业务。宕机是无法容忍的。亚马逊的系统每天处理数亿美元的交易。因此，诸如此类的组织为大规模、高可靠性的 IT 基础设施开拓新的实践不足为奇。
基础设施即代码的目标
很多团队和组织期待通过基础设施即代码实现如下目标。
IT 基础设施支持并允许变更，而不是成为阻碍或者约束。
对系统的变更是家常便饭，不应该对用户或者 IT 人员造成惊吓或者压力。
IT 人员把时间花费在体现自身能力的有价值的事情上，而不是花费在处理日常的重复性工作上。
用户可以自行定义、置备和管理他们需要的资源，不需要 IT 人员参与。
团队能够轻松、快速地从故障中恢复，而不是假设可以完全避免故障。
持续地改进，而不是通过昂贵且危险的“大爆炸”项目去改进。
通过实施、测试和测量来验证问题解决方案，而不是利用会议和文件进行讨论。
基础设施即代码不仅仅适用于云
基础设施即代码经常和云一起出现，因为在云上不这么做很难管理好服务器。但是基础设施即代码的原则和和实践不仅可以应用在云和虚拟化系统上，甚至可以直接应用在物理硬件上。
使用“动态基础设施”一词指代程序化创建和销毁服务器的能力。云可以很自然地处理这些，虚拟化平台也可以通过配置来实现同样的功能。即便是硬件，也可以自动化置备，从而以完全动态的方式使用。有时候这也叫作“裸机云”。
静态基础设施也可以使用基础设施即代码的很多概念。手动置备的服务器可以通过服务器配置工具进行配置和更新。然而，对于很多高级实践，毫不费力地销毁并重建服务器的能力是不可或缺的。
为什么采用基础设施即代码?
虚拟化、云、容器、服务器自动化和软件定义网络（software-defined network，SDN）理应简化 IT 运维工作。服务的置备、配置、更新和维护理应花费更少的时间和精力。问题应该被迅速地发现和解决，系统配置应该全部一致并且及时更新。IT 人员应该减少在日常苦差事上投入的时间，有余暇快速地执行变更和改进，以帮助组织适应现实世界里不断变化的需求。
然而，即便拥有最新、最好的工具和平台，IT 运维团队也很难完成每天的工作。他们没有时间去解决系统长期存在的问题，更没有时间去掌握这些最新的工具。事实上，云和自动化往往让事情变得更糟。新基础设施的置备（provision）很容易，导致系统组合不断增长，而防止这一切崩溃又需要投入越来越多的时间。
采用云和自动化工具立刻降低了基础设施变更的门槛，但这些工具并没有可以提高一致性和可靠性的现成方法来管理变更。这需要人们去思考如何使用这些工具，并且形成高效使用它们的系统、流程和习惯。
一些 IT 组织使用他们在云和自动化时代以前用于管理基础设施和软件的流程、结构和治理方式来应对挑战。但是，那些原则在需要花费几天或几周来置备新服务器的时代或许有效，而在当今这个只需要几分钟甚至几秒钟就能完成同一任务的时代，它们已经力不从心了。
急着完成任务的人们往往会忽略、绕过或者否决传统的变更管理流程。（1）可以越来越多地看到，成功推行这些流程的组织被技术上更灵活的竞争对手超越。
（1）“影子 IT”是指人们绕过正式的 IT 管理，使用自己的设备，并且购买和安装未受认可的软件，或者采用云托管服务。这个迹象表明内部 IT 无法跟上所服务组织的需求。
传统的变更管理方法难以应对云和自动化提供的变更节奏。尽管云和自动化工具导致系统日益增长、不断变化，我们仍然需要积极应对。这就是基础设施即代码（2）的用武之地。
（2）“基础设施即代码”（infrastructure as code）这个说法并没有明确的来源或作者。在写作本书时，我关注了一群影响了这一概念的人，而每个人都说自己没有创造这个概念，只是提供了一些建议。他们之间互相进行了借鉴。我能找到对其的最早引用出于 2009 年 Andrew Clay Shafer 和 Adam Jacob 在 Velocity 大会上的演讲。John Willis 可能是第一个记录了这一说法的人，详见其在 IT Knowledge Exchange 上关于此次大会的文章“Infrastructure as Code”。Luke Kaines 承认他可能也参与其中，是最接近于接受这个荣誉的人。
“铁器时代”和“云时代”
在 IT 的“铁器时代”，系统都直接安装在物理硬件上。基础设施的置备和维护都是手动作业，迫使人们花费时间点击鼠标、输入命令来保持系统运转。由于变更涉及很多工作，变更管理流程强调细致的前期考虑、设计和审查工作。因为错误的代价非常昂贵，所以这个流程是合理的。
在 IT 的“云时代”，系统与物理硬件解耦了。日常的置备和维护可以委托给软件系统，让人类从苦差事中解放出来。在几分钟甚至几秒钟之内就能做出变更。变更管理可以利用这样的速度，提供更快的上市速度和更高的可靠性。
动态基础设施的挑战
下面介绍了团队采用动态基础设施和自动化配置工具时常见的一些问题。这些问题是基础设施即代码要着力解决的，因此充分了解它们是学习后续原则和概念的基础。
1. 服务器蔓延
利用云和虚拟化，从资源池置备新的服务器可谓小菜一碟。这会导致服务器的数量飞速增长，甚至超过团队能够管理或者希望管理的规模。
当这种情况发生时，团队会忙于给服务器打补丁并且让它们保持更新，系统容易受到已知漏洞的影响。当发现问题时，补丁无法及时地应用到可能受影响的所有系统上。服务器之间的版本和配置差异意味着在一些机器上运行良好的软件和脚本无法在其他机器上运行。
这会导致服务器之间的不一致，也叫作配置漂移。
2. 配置漂移
即便服务器在最初创建和配置的时候是一致的，其差异也会随着时间而增加。
有人在一台 Oracle 服务器上做了一次修改，修复了一个特定用户的问题，现在它和其他的 Oracle 服务器就不同了。
新版本的 JIRA 需要新版本的 Java，但是没有时间去测试其他所有基于 Java 的应用是否都可以升级。
3 个人在几个月内分别在不同的 Web 服务器上安装了 IIS，并且每个人配置得都不一样。
某台 JBoss 服务器比其他服务器接受了更多的流量并且开始出现性能问题，有人对它进行了性能调优，之后它的配置就和其他 JBoss 服务器不同了。
不一样并非不好。相比负载较低的服务器，负载高的 JBoss 服务器理应有不同的调优配置。但是这些变化应该以一种易于重现和重建服务器及服务的方式进行捕获和管理。
服务器间未经管理的变化会导致雪花服务器的产生和对自动化的恐惧。
3. 雪花服务器
雪花服务器和网络中的其他所有服务器都不同。它非常特殊，无法复制。
几年前，作者在一家为客户构建 Web 应用的公司里管理服务器，其中大部分 Web 应用都是庞大、复杂的 Perl CGI 脚本。（不要批评我们，那是 .COM 年代，大家都这么做。）作者一开始使用的是 Perl 5.6，但是后来最好的类库都升级到了 Perl 5.8，而且不兼容 5.6。最后，几乎所有的新应用都是基于 Perl 5.8 实现的，但是有一个特别重要的客户应用程序就是无法运行在 5.8 上面。
“实际的情况比这更糟糕。这个应用程序在升级共享的预发布服务器到 5.8 时运行正常，但是在升级预发布环境时却崩溃了。不要问我们为什么没有解决预发布环境的问题就把产品环境升级到了 5.8，最后的结果就是这样的。我们有一台特殊的服务器可以运行 Perl 5.8 的应用程序，但其他服务器都不行。
我们就这样可耻地持续了很长时间——在预发布服务器上保留 Perl 5.6，每次部署到产品环境时都祈祷不要出问题。我们不敢触碰产品服务器上的任何东西，害怕解除能使唯一服务器运行客户应用的魔法。
这样的情况促使我们发现了 Infrastructures.org，这个网站为我打开了基础设施即代码的大门。我们确保以可重复的方式构建所有的服务器，用全自动安装（fully automatic installation，FAI）工具安装操作系统，用 CFEngine 配置服务器，并将所有的东西都用版本控制系统管理起来。
大多数 IT 运维团队都有过这样的尴尬：不能触碰或者难以复制服务器。如此脆弱的原因并非总是神秘莫测，有时是因为某个重要的软件运行在与其他服务器完全不同的操作系统上。我记得有个会计软件需要运行在 AIX 上，而另一个运行在 Windows NT 3.51 服务器上的 PBX 系统则是由一个已被遗忘的承包商特别安装的。”
再次强调，不一致并非坏事。问题在于拥有服务器的团队对于服务器如何以及为何不一致一无所知，并且无法重建服务器。运维团队应当能够自信、快速地重建基础设施中的任意服务器。如果有任何服务器不能满足这个需求，团队的最高优先级应该是设立一个可复制的全新流程，来构建一台新的服务器并替换掉老的服务器。
4. 脆弱的基础设施
脆弱的基础设施很容易中断，而且不容易修复。这是由于雪花服务器问题扩展到了整个系统组合。
解决方案是逐步将基础设施中的一切迁移到可靠、可复制的基础设施里。Visible Ops Handbook 一书论述了如何在困难的基础设施上实现稳定性和可预测性。
不要碰那台服务器，别指它，甚至不要看它
这也许是一个虚构的故事：数据中心里有一台服务器，没有人知道登录的信息，也没有人知道那台服务器的作用。有人以身犯险，将那台服务器的电缆从网络中拔掉。整个网络彻底断了。于是，电缆被重新插回，没有人敢再动那台服务器了。
5. 自动化恐惧症
在 DevOpsDays 大会上关于配置自动化的开放空间演讲中，在问及在座的人当中有多少在使用类似 Puppet 或者 Chef 之类的自动化工具。大多数人都举手了。又问到，有多少人以无人值守、自动排期的方式运行这些工具。只剩少数人的手还举着。
很多人都存在早期使用自动化工具时所遇到的问题。那时选择性地使用自动化，例如为了构建新的服务器，或者进行特定配置的修改。每次运行自动化工具的时候，都会调整配置，让它去适应在做的任务。
之所以不敢完全信任自动化工具，是因为我们对它们做的事情缺乏信心。
之所以缺乏对自动化的信心，是因为我们的服务器不一致。
服务器之所以不一致，是因为我们没有频繁和一致地执行自动化。
这就是自动化恐惧恶性循环，如图 1-1 所示。基础设施团队需要打破这种恶性循环，才能成功实施自动化。最有效的方式是直面恐惧。挑选一组服务器，调整配置定义，确保它们可以工作，并安排它们至少每小时以无人值守的方式运行一次。然后，挑选另一组服务器并重复这个过程，直到所有的服务器都持续更新。
图 1-1：自动化恐惧恶性循环
6. 侵蚀
理想情况下，一旦基础设施被自动构建出来，你就永远不需要去触碰它了，除非需要支持更新或者修复问题。可悲的是，熵力 (4) 意味着即使没有新的需求，基础设施也会随着时间衰败。Heroku 的人们把这称为侵蚀（erosion resistance）。侵蚀的意思是，问题随着时间的推移蔓延到正常工作的系统之中。
(4). 熵力在物理学中是指系统中的一种宏观作用力，其性质表现为整个系统对于熵增加的统计趋势。——编者注
Heroku 列举了以下随着时间侵蚀系统的因素。
操作系统升级、内核补丁以及基础设施软件（如 Apache、MySQL、SSH、OpenSSL）修复安全漏洞的升级补丁。
服务器磁盘被日志文件塞满。
一个或者更多应用进程崩溃或者卡住，需要有人登录并且重启它们。
底层的硬件失败导致一台或者更多服务器以及在它上面运行的应用出现问题。
怎么样？看过之后是不是对基础设施即代码有了一定的了解呢？其实这些只是对它的一个简单介绍，具体如何操作，小伙伴们可以读读这本新书《基础设施即代码》。
这本围绕广义的基础设施，分为“基础设施－服务器－服务”三层架构，着重从服务器的创建、配置、打包、远程执行、中央注册等不同的环节来对工具和方法进行细致入微的介绍。
在模式和实践的实施方面，也结合了敏捷开发方法，从构建、测试、实施和组织变革这几个维度进行了深入浅出的讲解。作者写作风格很有趣，内容层层叠叠却脉络清晰，令人豁然开朗。
Infrastructure as Code
基础设施即代码：云服务器管理
作者：基夫·莫里斯
译者：金明，钱伟，马博文，黄博文，禚娴静
定价：89.00元
ThoughtWorks 的 Kief Morris 执笔
实现IT基础设施管理向云时代转型，提升自动化程度、效率和可靠性
DevOps之父Patrick Debois、《重构》作者Martin Fowler、中国 DevOpsDays 社区组织者刘征联合推荐
本书旨在解释如何有效使用 DevOps 运动开创的原则、实践和模式来管理云时代的 IT 基础设施。书中内容分为基础、模式和实践三个部分，涵盖用来实施基础设施即代码的各种工具和技术、使用这些工具的模式以及正常运作的实践，适合系统管理员、基础设施工程师、团队领导和架构师阅读。
作译者简介
译者: 1. 金明，益辅金服 CTO，ThoughtWorks 前首席咨询师，ScaleWorks 云创始人及首席架构师。拥有超过十年的互联网产品以及云计算的研发管理经验，为国内外多家银行、华为、中兴等大中型企业提供了技术变革的咨询服务，并多次在国内外软件大会上做主题演讲。译有《敏捷软件开发实践》《项目百态》等书。
2. 钱伟，千米网内部敏捷教练，在通信行业有十年研发、售后、交付经验，两年 IT 咨询经验，深信“只要姿势对，敏捷治百病”。
3. 马博文，ThoughtWorks 前咨询师，AWS 助理架构师、开发者。拥有多年 Web 开发和 DevOps 经验，熟悉持续交付、微服务。曾参与翻译《Scala编程实战》《DevOps实践》和《DevOps实践指南》，是西安 DevOps Meetup 活动的发起人。
3. 黄博文，阿里巴巴技术专家，多年一线开发老兵，在持续集成、持续部署等 DevOps 领域拥有丰富的经验。曾在国内外多家企业从事过技术教练以及技术咨询工作，擅长敏捷工作方式。拥有 AWS 解决方案架构师以及开发者证书，译有《面向对象的思考过程》。
4. 禚娴静，ThoughtWorks 咨询师，拥有多年企业和互联网应用的一线开发经验，参与和主导过多个大型敏捷项目的技术交付、遗留系统重构和微服务架构转型。曾参与翻译《遗留系统重建实战》，享受跳跃的代码和专注带来的乐趣。
如何阅读本书？
阅读第 1 章，至少快速浏览一遍，以理解本书中的术语以及提倡的原则。你可以基于它们来决定应该专注于本书的哪个部分。
如果你对这些自动化、云和基础设施编排工具比较陌生，需要先了解第一部分，再继续第二部分。对前两部分都有所得之后，再阅读第三部分。
如果你使用过本书介绍的自动化工具，但在阅读第 1 章之后，觉得之前并没有遵照这些工具的设计意图来使用，那么可以跳过或者快速浏览第一部分，集中精力在第二部分。第二部分描述了使用动态和自动化基础设施的方法，并且这些方法与第 1 章概括的原则一致。
如果你对第 1 章描述的动态基础设施与自动化方法已经很熟悉了，可以快速浏览第一部分和第二部分，集中精力在第三部分。第三部分更深入地探讨了基础设施管理领域：架构方式与团队工作流。
目
第一部分 基础
第1章 挑战与原则...........3
1.1 为什么采用基础设施即代码 .........3
1.2 什么是基础设施即代码.......4
1.3 动态基础设施的挑战 ..........5
1.4 基础设施即代码的原则 .........8
1.5 实践 .......11
1.6 反脆弱性：超越“稳健性” .......14
1.7 结语 .........15
1.8 下一步 ......15
第2章 动态基础设施平台 ........16
2.1 什么是动态基础设施平台 ......16
2.2 对动态基础设施平台的要求 .........17
2.3 平台提供的基础设施资源 ........19
2.4 动态基础设施平台的类型 ......23
2.5 如何选择动态基础设施平台 ........25
2.6 与云和虚拟化的“机械通感” .........29
2.7 结语 ......30
第3章 基础设施定义工具 ..........31
3.1 选择基础设施即代码的工具 .......31
3.2 配置定义文件 ........36
3.3 使用基础设施定义工具 ......37
3.4 配置注册表 ..........42
3.5 结语 .........44
第4章 服务器配置工具 .........45
4.1 自动化服务器管理的目标 ......45
4.2 具有不同的服务器管理功能的工具 .....46
4.3 服务器变更管理模型 ............51
4.4 容器 .........52
4.5 结语 .........58
第5章 基础服务概述 .......59
5.1 基础设施服务和工具的考虑 .....59
5.2 团队之间共享服务 ........62
5.3 监控：告警、指标和日志 .......63
5.4 发现服务 ..........66
5.5 分布式进程管理 ..........67
5.6 软件部署 ........68
5.7 结语 .......70
第二部分 模式
第6章 置备服务器的模式 ........73
6.1 服务器置备 .........74
6.2 创建服务器的模式 ......80
6.3 引导新服务器的模式 ........83
6.4 结语 .........85
第7章 管理服务器模板的模式 .........86
7.1 供应模板：不能让别人来做吗 ........86
7.2 使用模板置备服务器 ...........87
7.3 构建服务器模板的流程 ...........89
7.4 原始镜像 ..........90
7.5 更新服务器模板 .............92
7.6 构建基于角色的模板 ............95
7.7 自动化服务器模板管理 ........96
7.8 结语 ........97
第8章 服务器更新与变更模式 .........98
8.1 服务器变更管理模型 .........99
8.2 通用模式和实践 ..........100
8.3 持续部署的模式与实践 ........102
8.4 不可变服务器的模式与实践 .......106
8.5 管理配置定义的实践 ........109
8.6 结语 ..........110
第9章 定义基础设施的模式........111
9.1 环境 .........112
9.2 组织基础设施 .........116
9.3 运行定义工具 .........128
9.4 结语 .........128
第三部分 实践
第10章 基础设施的软件工程实践 .......131
10.1 系统质量 ........132
10.2 基础设施管理的版本控制系统 .....133
10.3 持续集成 .........134
10.4 持续交付 .........137
10.5 代码质量 ........140
10.6 管理重大的基础设施变更 .......141
10.7 结语 .........142
第11章 测试基础设施变更 ......143
11.1 敏捷测试方法 .......144
11.2 构建测试套件：测试金字塔 ......145
11.3 实现均衡的测试套件 ..........149
11.4 管理测试代码 ........156
11.5 测试的角色和工作流 .......161
11.6 结语 .......164
第12章 基础设施的变更管理流水线 .......165
12.1 变更管理流水线的好处 ........166
12.2 设计流水线的准则 ........166
12.3 基本流水线设计 .........169
12.4 使用流水线的实践 ........174
12.5 扩展流水线到更复杂的系统 .......175
12.6 处理组件之间依赖的技巧 ........181
12.7 管理组件间接口的实践 .........186
12.8 结语 .......189
第13章 基础设施团队的工作流 .......190
13.1 任何可以自动化的都要自动化 .......190
13.2 使用本地沙箱 ........194
13.3 代码库组织模式 .......197
13.4 工作流的效率 ...........199
13.5 结语 .............202
第14章 动态基础设施的连续性 .....203
14.1 服务连续性 ......204
14.2 零停机变更 ........208
14.3 数据连续性 .......214
14.4 灾难恢复 .......216
14.5 安全 .........220
14.6 结语 ..........225
第15章 基础设施即代码的组织要求 ......226
15.1 演进式架构 .......226
15.2 度量有效性 .....229
15.3 组织授权用户 ......233
15.4 持续变更管理的治理 ......237
15.5 结语：永无止境 .....239
扫一扫，京东购
扫一扫，当当购
扫一扫，亚马逊购
☟☟ 点击【阅读原文】查看图灵架构书单
相关内容
微信扫码咨询专知VIP会员