Windows Server 2012、Windows PowerShell 3.0 和 DevOps，第 1 部分
在这个分为两部分的系列文章的第一部分中，我提供了有关 PowerShell 和 DevOps 的一些背景信息。在第二部分中，将向您介绍一些具体细节。PowerShell 3.0 与 Windows Server 2012 类似，有大量的新功能和增强功能，因此这里仅介绍一些浅显的内容。
--Jeffrey
我是在介绍 2009 Velocity 大会的播客中第一次听说 DevOps 的。在业界大多数人每年部署几次发布版本都感到吃力时，John Allspaw 和 Paul Hammond 却高调宣称“每天部署 10 次：开发人员与运维人员在 Flickr 上的合作”。他们创造了通过改变文化和工具交付业务结果的案例，并催生了一个新词：DevOps。问题是开发人员认为他们负责交付功能，运维人员认为他们负责维持站点运行。开发人员与运维人员的分工不同导致在出现错误时相互指责。成功的业务需要共担责任和相互尊重的 IT 文化：开发人员应考虑运维人员的需求和关注事项，同样运维人员也应考虑开发人员的需求和关注事项。
他们的谈话说明了企业需要如何快速变化，而该变化也是大多数站点关闭事件的根本原因。他们避开了传统的“避免变化”的做法，主张通过自动化使变化更安全一些并将风险降至最低。这就是 DevOps 的工作 – 安全变化。这是应用于 IT 操作的 Taguchi 质量方法。Taguchi 注意到，质量差的根本原因是变化。解决的办法是首先弄清楚如何重复做一些事情。如果能够这样做，则可以在该过程中进行一些小小的改动，以了解这些改动是使事情变得更好还是更糟，停止使事情变得更糟的变化。继续做使事情变得更好的事。关键是可重复性。可重复性使我们能够执行一些促使改进的实验。我们通过自动化在 IT 操作中获得可重复性。
我们通过发布 Monad Manifesto 开始了 PowerShell，该版本清楚地说明了我们看到的问题、解决这些问题的方法以及要交付的组件。我们构了一个分布式自动化引擎和一种脚本语言。初级运维人员和经验丰富的开发人员将使用该引擎和语言。催生 DevOps 的思想和价值同样可以推进 PowerShell 的设计：
- 专注于业务
- 通过自动化进行安全更改
- 消除开发人员和运维人员之间的隔阂
专注于业务
PowerShell 始终专注于在业务环境中使用计算机的人。PowerShell 需要 一致、安全 和 高效 。PowerShell 和 UNIX 之间有许多相似之处，但在这一点上，我们与 VMS/DCL 和 AS400/CL 更相像。
一致： 运维人员和开发人员没有太多的时间学习新知识。一致的体验可让他们一次性投入精力于一套技能，然后可以反复使用这些技能。PowerShell 对所有命令使用一个通用的分析程序并执行通用的参数验证，在命令行语法中提供绝对的一致性。PowerShell cmdlet 的设计方式是，普遍存在的参数可以向所有命令提供一致的函数（例如，–ErrorAction、–ErrorVariable、–OutputVariable 等）
安全： 运维人员曾经告诉我，有时他准备做某事时就会意识到，如果做错了，他就会被解雇。在 PowerShell 中，如果您曾经执行了某个对系统有负面影响的 cmdlet，则始终可以键入 –WhatIf 来测试如果执行此操作会发生什么情况。我们还支持 –Confirm、-Verbose 和 –Debug。尽管有这些保障，但仍可能发生错误，如果发生错误，PowerShell 将做出许多努力以加快诊断和纠正错误的过程。
高效： PowerShell 设计的每个方面都是为了最大限度提高用户的能力（因此得名）。PowerShell 可以跨大量计算机轻松执行批量操作。PowerShell 还可以让运维人员与开发人员之间轻松高效地协作，因为 PowerShell 允许他们使用共同的语言并在脚本中相互帮助。
通过自动化进行安全更改
关于 PowerShell 是 .Net 语言、脚本语言还是交互式 shell 已经讨论了许多。PowerShell 是一个带有脚本语言和交互式 shell 的分布式自动化引擎。交互式 shell 和脚本语言是关键组件，但重点始终在于通过脚本实现的自动化。自动化是减少和/或消除由人执行的操作的过程。脚本记录要发生的事情。人们可以查看脚本并且您可以根据他们的反馈修改该脚本。您可以测试脚本，观察结果，修改脚本，如果修改效果良好，则可以保持，如果效果不佳，则可以停止。换言之，脚本提供将 Taguichi 方法应用到 IT 操作的可重复性。在拥有自动化过程之后，便可以安全地反复应用该过程。现在技能较低的管理员可以执行这些过程。使用传统的 GUI 管理工具时不可能执行这些步骤。
弥合开发人员和运维人员之间的差别
我们的目标始终是交付可以满足运维人员执行临时操作、简单脚本、正式脚本、高级脚本和开发人员执行系统级编程所需的单一工具。
PowerShell 花费了大量的精力尝试计划面向任务且具有统一语法和语义的高度抽象语法的环境。我们将这些称为 cmdlet。这也正是运维人员切实有效地管理系统所需的方法。要使用 API 复制文件，需要执行以下操作：
您有没有想过为何 PowerShell 使用花括号 {}（和其他 C 语言构造函数）而不使用其他脚本语言使用的 BEGIN/END？这样做是因为我们想让开发人员更轻松地采用其他基于 C 语言的编程语言：C++、Objective C、Java、JavaScript、Perl、PHP 等。我们做了一些测试并确定运维人员能够轻松适应这种语法。我们还希望提供一种在 PowerShell 和 C# 之间顺利转换的途径。这为希望转为开发人员的运维人员提供了职业移动性。
最重要的是，我们希望开发一种运维人员和开发人员都可以使用的工具，以弥合这两个团队之间的差别，并允许他们创作通用脚本，互相学习，携手合作。
Windows Server 2012 和 PowerShell 3.0 是卓越的 DevOps 工具
DevOps 是一个新术语，关于它会带来什么存在一些分歧，但在本质上它完全是通过自动化保证变化的安全性并弥合运维人员和开发人员之间的差别。在该领域有许多工作要做，但 Windows Server 2012 和 PowerShell 3.0 为实现这些目标取得了卓有成效的进步。PowerShell 不会是您的 DevOps 工具箱中的唯一工具，但它是每个 DevOps 工具箱中不可或缺的工具。立即下载 Beta 版并亲自体验一下。
此致！
Jeffrey Snover
Windows Server 团队的特聘工程师和主要架构师