月归档：七月 2011

文章出自：http://www.infoq.com/cn/articles/agile-operations 文章内容： 最近我们听到很多关于敏捷运维的消息。包括很不错的演讲、文章，还有一些激烈的讨论。它被称作是“创业公司的秘制调味酱”。对于我们这些并非处在创业公司或者Web 2.0公司中的人来说，它的意义何在呢？我们是否可以让敏捷运维在已经创建的大型企业中发挥作用呢？ 相关厂商内容 最前沿的开发&运维之道InfoQ诚聘：内容/商务策划编辑、资深商务经理等敏捷与精益开发的现状与未来Scrum认证培训及敏捷教练—UPerform 优普丰我想答案应该是：“可以，但并不容易。”本文中，我会和你一起讨论采用敏捷运维的障碍，以及你可以使其发挥作用的一些方式。 敏捷运维概述敏捷运维来自于两个截然不同的阵营。首先，敏捷和精益软件开发者意识到，很好的、密集的迭代会快速生成可发布的产品，但部署却比较花费时间。由于产出量的要求，这些团队发现，当他们将代码签入到源代码控制系统中时，价值流并没有到达终点；只有把代码部署到网络上并开始创收的时候，价值流才到达终点。也就是说，情况是“完成，完成，才会完成”而不是“完成，就完成了”。在短迭代之后，发布会有很大的延迟，这样也是不合理的。更坏的是，手动的部署和配置会引入人为的错误。真正的敏捷团队希望可以自动完成所有重复性的任务，当然也包括部署在内。 另外一群将我们引入到敏捷运维的人来自于快速增长的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）、打开申请等等。我们只需要调用这些程序接口来对工具进行自动化，就像我们对于服务器进行自动化一样。你还是需要在变更审查会议中密切关注主要的事件，但至少你可以将很多烦人的工作自动化。 … 继续阅读 →