虚拟化、云、容器、服务器租用主动化和软件定义网络( software-defined network,SDN)理应简化T运维工作。服务的置备、配置、更新和掩护理应消费更少的时间和精力。问题应当被迅速地创造和解决,系统配置应当全部一致并且及时更新。T人员应当减少在日常苦差事上投入的时间,有余暇快速地履行变更和改良,以赞助组织适应现实世界里不断变更的需求。
然而,即便拥有最新、最好的工具和平台,T运维团队也很难完成每天的工作。他们没有时间去解决系统长期存在的问题,更没有时间去控制这些最新的工具。事实上,云和主动化往往让事情变得更槽。新基础设施的置备( provision)很容易,导致系统组合不断増长而防止这一切崩溃又需要投入越来越多的时间。
采用云和主动化工具立刻降低了基础设施变更的门槛,但这些工具并没有可以进步一致性和可靠性的现成方法来管理变更。这需要人们去思考如何应用这些工具,并且形成高效应用它们的系统、流程和习惯。
一些T组织应用他们在云和主动化时代以前用于管理基础设施和软件的流程、结构和治理方法来应对寻衅。但是,那些原则在需要消费几天或几周来置备新服务器的时代或许有效,而在当今这个只需要几分钟甚至几秒钟就能完成同一任务的时代,它们已经力不从心了。
急着完成任务的人们往往会疏忽、绕过或者否决传统的变更管理流程。1可以越来越多地看到,成功推行这些流程的组织被技巧上更机动的克争对手超出。
1、“影子T”是指人们绕过正式的T管理,应用自己的设备,并且购置和安装未受认可的软件,或者采用云托管服务。这个迹象表明内部T无法跟上所服务组织的需求。
传统的变更管理方法难以应对云和主动化供给的变更节奏。尽管云和主动化工具导致系统日益増长、不断变更,我们仍然需要积极应对。这就是基础设施即代码2的用武之地。
2“基础设施即代码"( infrastructure as code)这个说法并没有明确的起源或作者。在写作本书时,我关注了一群影响了这一概念的人而每个人都说自己没有创造这个概念,只是供给了一些建议。他们之间互相进行了借鉴。我能找到对其的最早引用出于2009年 AndrewClay Shafer和 Adam Jacob在 Velocity大会上的演讲。 John Willis可能是第一个记载了这一说法的人,详见其在 I Knowledge Exchange上关于此次大会的文章" Infrastructure as Code" Luke Kaines承认他可能也参与其中,是最接近于吸收这个荣誉的人。
“铁器时代”和“云时代
在T的“铁器时代",系统都直接安装在物理硬件上。基础设施的置备和掩护都是手动作业,迫使人们消费时间点击鼠标、输入命令来保持系统运转。由于变更涉及很多工作,变更管理流程强调过细的前期考虑、设计和审查工作。因为毛病的代价非常昂贵,所以这个流程是合理的。
在T的“云时代",系统与物理硬件解耦了。日常的置备和掩护可以委托给软件系统,让人类从苦差事中解放出来。在几分钟甚至几秒钟之内就能做出变更。变更管理可以利用这样的速度,供给更快的上市速度和更高的可靠性。
