企业中的敏捷运维

最近我们听到很多关于敏捷运维的消息。包括很不错的演讲、文章，还有一些激烈的讨论。它被称作是“创业公司的秘制调味酱”。对于我们这些并非处在创业公司或者 Web 2.0 公司中的人来说，它的意义何在呢？我们是否可以让敏捷运维在已经创建的大型企业中发挥作用呢？

我想答案应该是：“可以，但并不容易。”本文中，我会和你一起讨论采用敏捷运维的障碍，以及你可以使其发挥作用的一些方式。

敏捷运维概述

敏捷运维来自于两个截然不同的阵营。首先，敏捷和精益软件开发者意识到，很好的、密集的迭代会快速生成可发布的产品，但部署却比较花费时间。由于产出量的要求，这些团队发现，当他们将代码签入到源代码控制系统中时，价值流并没有到达终点；只有把代码部署到网络上并开始创收的时候，价值流才到达终点。也就是说，情况是“完成，完成，才会完成”而不是“完成，就完成了”。在短迭代之后，发布会有很大的延迟，这样也是不合理的。更坏的是，手动的部署和配置会引入人为的错误。真正的敏捷团队希望可以自动完成 _ 所有 _ 重复性的任务，当然也包括部署在内。

另外一群将我们引入到敏捷运维的人来自于快速增长的 Web 2.0 公司。这些公司有时会在两个星期内增加上千台服务器。如果他们试图手工完成，那么全美国一半的人会是 Facebook 的用户，而另一半的人都是 Facebook 的管理员。显然，他们需要一些办法来将架构纳入到管理之中。这些公司从命令式（手工的）操作转换为声明服务器所需要的最终状态，从而达到可扩展的运维。

尽管大多数关于敏捷运维的演讲都以工具为中心，但其实工具的重要程度最低。从工具开始讨论敏捷运维，就像是通过学习 JUnit 和 Hudson 来学习敏捷软件开发一样。你可以模仿那些实践，但是当环境发生变化的时候，你就无法做出有效的响应。工具应该是用来支持敏捷原则的。对于运维来说，敏捷原则包括：

• 沟通
• 短的反馈周期
• 简单
• 勇气
• 透明
• 承担责任
• 反应
• 对技术优势的持续关注

这些原则以多种方式得到了证实：

• 完全自动化的系统构建（并非只是启动服务器，而是重新构建 _ 一切 _）
• 通过版本控制系统进行配置管理
• 对监控和统计数据的广泛访问
• 自愿的“坏了就换”机制
• 优先使用从系统中自动抽取文档
• 针对硬件随需而变的态度添加或者替换服务器并不是大事件

和敏捷软件开发一样，敏捷运维显然与那些“牛仔”管理员的方式 _ 不同 _，他们只会狂乱地管理系统而没有任何计划和文档。与之截然不同的是，敏捷运维需要很好的自律。运维必须确保所有一切内容都在版本控制之下。他们只会接受彻底自动化的东西。永远不会允许手动操作的存在。

障碍和冲突

敏捷运维听起来很美好。只要签入你的代码，确保它在 CI 服务器上构建，然后更新一个方法，就可以看着你的改变去改变世界。有些人看不到这样做明显的好处，他们都是老土，毫无希望，或者只是在保护他们的饭碗，不是吗？

但是，看花容易绣花难。就像 Scott Adams 所说：“任何你不懂的东西都很容易。”但道理会更加复杂。人们不会因为愚蠢的或者武断的原因而支持实践，但是会因为他们要缓解在外行看来不明显的压力而那么做。

运维小组总是会关注于利益相关者的不同甚至相反的需求。试图引入变更，而不考虑这些力量，这会让你非常沮丧，很可能会导致失败。下面是运维——不管是否是敏捷的——所要关心的问题。

审计和遵从

在努力达成有效监管的过程中，运维起到了很重要的作用。任何公开上市的公司都必须能够证明他们的财务状况的准确性。在美国，从 2002 年塞班斯法案通过以来，如果发现财务结果被篡改，那么公司的主管就有可能被刑事逮捕。最关键的条款是第 404 条，它提出了公司要通过财务报表达到内部控制。这没错，如果审计者发现系统管理员和 ICFR 状况很差，那么 CFO 最多可能会被判入狱 20 年。

但 SOX 内容的含糊一直为人们所不满。安全交易委员会（Securities Exchange Commission）和公共公司财务监管委员会（Public Company Accounting Oversight Board ）都提出了多种指导意见。既便如此，审计者还是需要解释许多问题。每年他们都会创建很多案例，然后对其进行讨论、接受或者推翻。这导致的不确定性，加上提供 _ 没有 _ 发生篡改情况的证据的问题，使得公司对于他们的控制非常急躁。

我要向你讲述一个关于支付卡行业数据安全标准的故事。其中的细节会有所不同，但总体上的意味是相同的。只是 VISA 还不会让任何人坐牢。

这里的关键问题在于对“控制”的定义。在审计术语中，控制 _ 没有 _ 技术上的标准，而只是一些过程，通过它们可以访问标准，并在一定周期的基础上进行审阅。你的审计者会寻找的最重要的控制之一就是 _ 角色的分离 _。也就是说，编写代码的人不能来发布自己的代码。此外，一旦代码被发布，对于管理员来说，就不可以再对其进行改变。在这里，“不可能”并不意味着文件是不可编辑的，而是意味着它不能在任何人都不知道的情况下进行编辑。

在实践中，这意味着敏捷运维——特别是开发运维——会在审计者的检查中出现很多警告。我向你保证，如果开发与审计之间有争论，审计肯定会胜出。你最好祈祷，如果你在已经上市或即将上市的公司中工作，那么在引入敏捷运维之前就会遭遇审计问题。

敏捷运维能够提供补偿式的控制。例如，如果生产环境中所有的变更都完全自动化，那么版本控制系统会保留每个人的修改记录。这样就很容易从版本控制工具中得到报表，从而审计会认为这些变更是被授权了的。如果你对所有部署的程序包进行 SHA 哈希加密，那么就可以证实没有在自动部署过程之外做过任何的修改。这些机制可以支持合理的 ICFR。

然而，如果在切换到敏捷运维 _ 之前 _ 进行讨论的话，那么你还有很多工作要做。

ITIL

IT 架构库是针对 IT 运维过程的配置框架。这一大串文字不会告诉你详细的内容，但是你应该对其有所了解。

ITIL 为 IT 组织提供了高质量运维的蓝图。它是一种模板，源自英国政府十九世纪八十年代对大型机的运维方法。是的，真的是那样。ITIL 现在最高的版本是 3，它已经被多个公司采纳，作为围绕一系列日常任务进行标准化过程的方式：“我们有什么？”，“它是否正常工作？”，“为什么它会出现故障？”，“谁应该对其负责？”等等。

我们都不会喜欢 ITIL。在第一次培训的时候，我个人的反应是对其持怀疑的态度。其中有非常复杂的变更管理过程，但是却没有涉及到真正的变更系统。对于发布管理过程也是一样。

然而，一旦你对其深入研究，就会发现，其实 ITIL 的各个部分都是以合理的方式组合在一起的。大多数公司都不会实现 ITIL 所有的内容，但是一般都实现了最重要的三点：突发事件管理、变更管理和发布管理。

正如我们在关注审计和遵从的时候所看到的，敏捷运维实际上提供了一套很强的支持实践。例如，在变更管理中的一个关键问题就是要识别每个会被变更影响的配置项目。如果所有的系统配置都在配置管理的控制之下，那么就很容易满足这个需求。事实上，答案是它会比之前更加准确。

与 ITIL 之间的冲突不在于基本的原则，而是在工具上。实现 ITIL 的组织一般都会从软件厂商那里购买一套工具。实现 ITIL 通常就意味着要实现这套工具。因此，如果你想要通过你自己的工具集而不是公司的标准来完全满足 ITIL 过程，就会遭到高层的抵制。

对于这个问题，我的建议是“不要同官僚作斗争。”ITIL 工具很昂贵，而且实现它会花费很长时间。那意味着一些任务显然会提交给他们。绕过工具集等同于对那个人挑战。可能这正是你想要的斗争，但是让我们先考虑一下另一种方法：使用 API。所有这些工具都有各种各样的程序接口，用来提交变更申请、更新配置管理服务器（CMDB）中的配置项目（CI）、打开申请等等。我们只需要调用这些程序接口来对工具进行自动化，就像我们对于服务器进行自动化一样。你还是需要在变更审查会议中密切关注主要的事件，但至少你可以将很多烦人的工作自动化。

有个领域中敏捷运维和 ITIL 可以很好地协作，那就是问题管理过程。一旦发生了突发事件，它就应该作为问题指出。这会触发完整的分离过程。突发事件管理只是要恢复正常的运维，而问题管理会找到并修正产生突发事件的根本原因。例如，web 服务器崩溃是一种突发事件。目标是恢复服务器并让它正常运行，这可能只是意味着重新启动进程。如果再次发生，它就会被认为是问题，这会让我们对其进行调试，查找内存泄漏，在 QA 中重新创建 bug，等等。

ITIL 问题管理和敏捷运维都喜欢使用“5 个为什么”方法来进行根本原因的分析。也就是说，不是只解决直接的问题，还要知道在什么时候会发生这种错误。在这里我看到的是本能上的调整。

历史和文化

有时我认为创业公司的最大优势就在于没有历史。开发、运维和业务一起会推动企业的文化。在一家已经建立的公司中，在不同的组中同步文化的改变是很困难的。因此，在这项改变面前，总有一个组织的文化会被抛弃。在你自己的组之内的领导是受欢迎的，但是来自于另一个组的领导很少会是那样。特别是当你尤其不喜欢另一个组的时候。

是的，是这样。开发和运维小组有时互相都对彼此不感冒。

事实上，他们可能会是公开敌对的。

就像西弗吉尼亚山上的家庭争吵一样，这些事情会以多种不同的方式开始。通常，它开始于启动失败或者停电，然后是一轮激烈的指责。运维团队的主管和软件开发团队的主管之间的对立会让争吵升级。因为运维和开发团队中所说的话都不一样，所以很难弥补他们之间的鸿沟。几年之后，指责和相互踢皮球就成为了根深蒂固的习惯。

和敏捷开发一样，敏捷运维需要所有团队之间高度的信任。但在从来都是敌对态度的环境中如何建立起这种信任呢？你的策略依赖于你在公司中的地位。在这里我只能提出三种真正的意见：

1. 不要试图使用技术解决方案来解决文化的问题。文化高于过程，每次都是这样。
2. 当你处于防御的姿态时，是不可能敏捷的。
3. 很强的领导力是非常重要的。领导力不需要管理授权。你可以成为公司中任何级别的领导。

总结

在过去的十五年间，我们得到了很多关于引入敏捷软件开发的教训。遵守敏捷原则的团队能够在需要的时候从无到有改造实践。相反，不遵守敏捷原则的团队能够效法实践，但是不会继承优势。（并且，事实上，他们不会坚持执行那些实践！）

采用敏捷运维需要“忘掉”一些关于如何创建可靠过程的假设。涉及到这个事务中的人们必须意识到，它可以更快并且更有规范，质量与便利并不矛盾，并且很值得花费时间来消除最后的 5% 的手工作业。

同时，我们必须记住，运维和开发所服务的利益相关者是不同的。公司会依赖运维团队来保证财务结果的尊严，并保护他们在客户和投资方中的信誉。任何向敏捷运维的转变都必须保持这些重要的责任。

相关资源

ITIL ：IT 架构库的参考站点

敏捷的Web 运维博客：针对网站的敏捷运维的帖子和讨论。

Andrew Schafer 的博客：Andrew 经常会讨论与开发、运维以及网络相关的内容

自动化的架构促进敏捷运维：关于架构即代码的很有用的文章。

定义敏捷运维和开发运维：讨论敏捷运维和更极端的兄弟开发运维之间的相同与不同。

每天部署十次：Flickr 中的开发和运维的协作：John Allspaw 所做的来自于一线经验的讲座，它是重新将开发和运维单元化的关键描述。

敏捷架构：Agile 2009 上所做的关于支持敏捷运维的工具和技术的演讲。首先是原则，但是强大的工具支持是必要的。

查看英文原文： Agile Operations in the Enterprise

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。