获取与自己内心的基础编码器
但事实是，OPS今天的工作远远超出了简单的脚本。事实上，因为它已经投入了很大精力投入建设基础设施的虚拟化和云基础设施本身成为密码。
想想你如何部署和今天管理服务器。也许你已经设置了几个脚本来自动执行某些进程，但脚本本身必须由人来拉开序幕。如果是这样，你采取更长的时间才能完成你的工作比你应该和你可能固定本来是可以避免的，许多的错误。换句话说，你可能是脚本，但你还没有完全接受你的内在基础编码器。
Because of this, it's time to move away from "server thinking" and instead take up a more "services thinking" mind-set, the kind most developers employ when working on their projects. The capability to build, configure, and destroy servers via code is one matter. Evolving an abstraction layer to think more about workloads and services than servers is the key to becoming an infrastructure coder, not an infrastructure administrator. The server is not a unique entity but rather a source of power for a software service. We don't have time to focus our energy on a single server now. It’s all about the bigger picture of servers as services you can control with code.
重建的基础设施代码
Defining your infrastructure -- compute, storage, and network -- as code is becoming an important concept for admins in managing IT resources today.
在最基本的，“基础设施代码”的手段对待自己的基础设施软件。该代码是不是在服务器上执行写的;它写入到构建服务器。把它看成是采取代码下来堆栈的层，从传统软件的角度。取而代之的是软件开发人员添加新的功能，网页的，在基础设施代码的新功能可以在云中而不是处所或也许是自动调出新的虚拟机基于流量水平的能力来配置服务器。这是有关定义每个组件的状态，并使用工具，以确保它保持这样。
例如，传统上，新服务器的请求都需要服务支持票，以试图查明在哪里建立新的虚拟机以及哪些存储，这个过程意味着服务器请求一个数内应验OPS然后解释的备案天，如果不是几个星期。相反，想象我们有一个自助服务门户，客户和同事可以把请求，和他们的虚拟机配置自动根据预先建立的架构。这是可能的基础设施代码。
基础设施as code allows you to define what any given infrastructure component should look like. From there, all the logic on how to provision that component is already built. As such, developers and business users can simply build their own VMs. You've defined all the criteria for the VMs ahead of time, and it's simply a matter of coding a manifest of instructions for performing the build.
品尝源控制
软件开发人员使用源代码控制管理的变化。通过服务，如Git的，CVS，水银，Team Foundation Server的，所以源控制在允许在同一时间一个代码库的开发工作全部队。开发人员在检查他们定期代码，源代码控制不断变化的跟踪，为开发人员提供一个合并更改，检测冲突等的能力。源代码控制工具还允许您回滚随意改变。
想象一下，能够在片刻的通知只是回滚服务器上的任何变化。另外，你知道是谁拦了服务今天还是谁删除的重要文件？如果您的所有更改代码执行并签入源代码控制，变化是那么容易，因为其帐户变更集中检查眼见。
Source control might seem foreign at first. Terms like "repositories," "branching," "changesets," and "merging" may even sound like Greek. At its most basic, source control enables you to retain versioning control over changes to a bunch of text files. For example, a typical piece of infrastructure code might contain all the parameters to build and maintain a particular application server. This application server is critical to the business and must adhere to a set of specific configuration items. Your company might soon roll out new features that require a tweak to a website. By using source control and practicing infrastructure as code, you can simply add the new configuration item into a local script on your computer and check the script into source control, which will then kick off that change on all of the applicable servers和此应用程序的目的建造任何新的服务器。
源控制的另一个好处是回滚变化的能力。也许你修改了错误的项目，并在生产中被立即改变。没问题 - 只需回滚所做的更改，并有服务器抢恢复配置，在新的状态下提供。
Once you get the hang of source control, you'll soon see this will be the method in which configuration changes are implemented rather than the ad hoc manner you might have been making changes previously.
速度
当你把你的基础架构代码，部署配置更改数百个服务器只需要一个文本文件的编辑。你的自动化工具做休息。您可以还原任何不需要的变化快为好。如果外发生的代码的变化，工具可以恢复在几分钟之内的变化，保证服务器在你为他们定义的状态。这将确保所有服务器都处于一致的状态在任何时候。
您可以通过管理基础架构的代码实现的速度将被证明至关重要，因为在你的服务器生命周期的每个过程一定要快如闪电。毕竟，你将不得不跟上你的开发商，谁 - 在拥抱DEVOPS /敏捷方法 - 将快速移动自己。你必须打入的谁在与客户不断的反馈而推出的新功能和修补的bug开发商不断迭代的心态。想象自己敏捷OPS，快速迭代您的基础架构来支持你的开发人员，因为他们也通过在他们的代码连续改变速度。
列车上的新工具
Many new tools await your devops transformation. If you manage Windows servers, I highly encourage you to学习的Windows PowerShell, an invaluable scripting language for automating server deployment, maintenance, and the like. Once you have PowerShell down, focus on Desired State Configuration (DSC). Microsoft built DSC as a platform on which operations teams and technology vendors can create tools. As with other configuration management technologies, DSC is a way of managing your infrastructure declaratively. Simply write a configuration script and deploy to a server -- it adheres to the state in which it was told!
对于异构环境，你会想看看配置管理工具，如Chef, Puppet, Ansible, SaltStack和Cfengine的。这些工具支持Windows和Linux的各种口味，您的基础架构的顶部基本应用管理层。现在，你知道如何安装IIS或Apache。你为什么要被迫贯穿每一次你需要一个新的Web服务器？你不应该。配置管理工具已经知道该怎么做。使用他们在更高的层次来管理基础设施，并把你的时间到管理Web服务器服务，而不是Web服务器本身的软件。毕竟，这是有可能在您的组织的业务优点在于：在软件或服务。
拥抱永恒不变的基础设施
有一个在软件开发领域的一个术语：“不可改变的对象。”在面向对象的程序设计，这仅仅意味着一个对象，也不会改变。这是确保对象的方式是一个特定的状态并且在这样的。如果需要改变，整个对象被销毁，而另一个被创建。把这个概念，并将其应用到虚拟机，存储LUN，网络VLAN或容器，和你有不变的基础设施。
当基础设施是物理的，我们不能心血来潮重建服务器。这需要大量的工作！现在，基础设施作为代码处理，在基础设施组件可以被视为对象。因此，由于在我们可以做出改变，我们现在可以享受基础设施组件作为一次性的速度。
Once you nail down this concept, your infrastructure will gain the predictability and standardization necessary to navigate constant change. Being able to manage the constant flux of enterprise architecture is vital. But trying to control each and every little change is maddening. To be sure that any given server is in the state you need, you can simply blow it away and create another. Since your entire infrastructure is defined in code, all the instructions to do so are stored in source control. Rebuilding a server in PowerShell could simply be a matter of Get-Server | Remove-Server –PassThru | New-Server. All the logic and instructions to make this happen already exist.
DevOps的做对
操作需要发展以保持其相关性。该行业持续更以软件为中心。一切都是服务现在，很多企业都选择在传统的内部部署解决方案的云。跟上，我们必须接受我们的内部开发人员和对待我们的基础架构软件和管理它这样。我们必须管理我们的服务器如牛 - 匿名的生物只在这个世界给我们提供的寄托，而不是名称和自定义项圈的宠物。这需要代码，并根据我们的能力编写脚本来充分利用这些新的工具。
In previous years, it was not possible for developers and operations to work side by side. Now that we're able to represent traditionally physical components as software, operations can stand on common ground as developers through code. But doing so will take a developer’s-eye view of your traditional administration tasks.
相关资源
- 7 signs you're doing devops wrong
- 9 hidden talents of devops ninjas
- 快速指南：20个提示和技巧Git和GitHub上
- PowerShell的强大：适用于Windows Server管理员的前奏
- PowerShell的强大：基本技巧的Windows管理员会喜欢
- 开始使用Windows PowerShell DSC
这个故事，“职业改造：从OPS到DEVOPS”最初发表InfoWorld的 。