如果您将所有用于设置和控制基础结构的配置文件和脚本本身视为一个开源项目，该怎么办？ 如果您将代码放在那里进行审查，并允许开发人员和操作员协同工作以确保顺利地将代码推出生产，该怎么办？ 惠普的OpenStack基础架构团队就是这样工作的。

Elizabeth K. Joseph是HP的自动化和工具工程师，他在OpenStack Infrastructure团队工作，该团队运行为OpenStack开发而构建的完全开源的基础架构。 在即将举行的“万物开放”演讲中，她概述了团队使用的工具，公开工作如何影响其运营以及其他组织希望使其工作流程更加开放，可以从惠普的经验中学到什么。

告诉我们一些关于你自己的事。 您是如何开始从事系统管理的？

自2002年以来，我一直在台式机上使用Linux，从一开始我就进入Linux用户组并与其他用户进行协作。 我之所以被Linux和Open Source所吸引，首先是因为它具有自定义功能（您拥有源代码！），然后是一个令人惊叹的社区，许多人都热衷于共享他们的工作。

在2006年左右，我开始为一家本地（到费城）的技术服务提供商从事服务器机架和现场Linux安装的工作。 最终我被聘用为他们的初级系统管理员。 我们专注于基于Debian的部署，但通常还是客户向我们带来的网络调试和其他麻烦的技术问题的首选资源。 随着那里工作的进展，我开始使用起搏器和心跳以及许多虚拟化工具来进行更大的部署和高可用性集群。 这确实是我对系统管理充满热情的地方，使用开源工具构建事物并拥有众多选择触手可及-我的雇主很兴奋-再加上我的雇主对我们向上游做出贡献充满热情，因此我能够在Debian期间为Debian做出贡献我的任职在那里。

多年来，我参与了多个开源项目，其中最著名的是Ubuntu，这导致他在2012年获得了 ，并且是最新（第8版） 合著者。七月。

希望惠普能够在OpenStack基础架构团队中为OpenStack开发人员提供支持，以期希望将我对开源的热情与我的系统管理工作结合起来，所以我来了！

似乎有很多相关工具在使用OpenStack时执行相似的任务。 基础架构团队如何选择合适的工具，以及他们如何支持做出不同选择的下游企业？

OpenStack基础架构团队结合了Git，Gerrit和Jenkins等几种开源技术，以及一些自制的开源项目，为OpenStack项目内的高速环境提供了强大的持续集成系统。 从那里开始，该团队使用了来自多个OpenStack提供商的捐赠的云虚拟机（目前在2个公共云中总共有大约800台机器，以及在2个私有OpenStack云上进行了裸机测试）。 由于我们的工具与配置稍有不同的多个云连接，因此我们尝试坚持使用工具中的基本OpenStack命令，因此我们确保支持大多数遵循最佳实践的基于OpenStack的云。

我们还使用各种其他流行的开源工具来支持开发人员社区，从用于Wiki的MediaWiki到用于跟踪服务器随着时间的变化的Cacti。 这些通常是由了解项目需求然后评估可用选项的一个或一小组项目成员选择的。 例如，去年夏天，在我们召开会议讨论我的发现并决定使用cgit之前，我对git Web前端进行了相当全面的回顾。

在配置管理方面，我们结合使用Puppet和Ansible来驱动基础架构。 尽管它对我们很好，但是当项目真正成立时，Puppet基本上是一个任意选择，并且在那时也可以当厨师。

随着下游社区（尤其是那些使用持续集成系统的社区）的增长，我们正在这个周期内进行工作，以减少针对OpenStack的需求，并拆分基础架构的各个部分，以使其更易于使用。 尽管我们的任务仍然是OpenStack项目的支持，所以我们的精力主要集中在这里。 我们仅真正提供源代码并要求下游提交补丁程序，例如，我们在基础架构中不使用LDAP或广泛的代理，但我们有下游代理人这样做，因此我们现在携带其补丁程序来支持那些事。

与OpenStack基础架构团队合作对您来说是什么激动？

我对开源和系统管理这两种热情的融合，对我来说是一项很棒的工作。 多亏了惠普，我也有机会参加会议并分享我们正在做的工作，从谈论我们如何开源整个Puppet配置到在基于Linux上运行完全开源基础结构中学到的经验教训。互联网。 与其他开源项目的贡献者建立联系也非常好，这些开源项目也开源了其全部或部分基础架构，包括 ， ， 和 。

DevOps改变了代码的管理和部署方式，这引起了很多讨论，但是仍然有许多组织仍在努力采用更多的DeveOps方法。 您认为是什么阻碍了他们？

我认为有两个主要障碍。 首先，它需要在系统管理方面进行大量学习，而我一生中从未编写过太多代码！ 这是一个很大的变化，我们不再只是简单地将各个部分放在一起，并根据部署给我们的东西进行部署，我们在开发各个部分中扮演着重要角色，这可能是一个艰难的转变。

然后，您便有了管理层的支持。DevOps需要您的Ops团队信任和自由，这很难做到，尤其是在大型组织中。 DevOps行动Swift，因此，由好心的人执行的庞大变更检查流程之类的东西可能会给事情带来麻烦，使切换几乎是不可能的。

《 》几乎是DevOps小说，它深入探讨了这些挑战以及虚构的“守旧派”系统团队如何扭转组织困境。 强烈推荐。

在不花太多钱的情况下，请告诉我们您即将在All Things Open上进行的演讲。 与会者可以学到什么？

我将谈论开源系统管理。 在我的演讲中，我将介绍OpenStack项目中拥有的基础架构，以提供一些背景知识，解释我们在系统管理变更中使用代码审查系统的方式，以便我们可以安全地从OpenStack社区中获得贡献，以及我们如何通过公开进行在线所有工作，我们成功地建立了一个由远程系统管理员组成的团队。

作为开放源代码项目，我们的案例是一个极端的案例，但是我们所汲取的教训对于那些正在考虑向其公司中的其他人开放系统管理存储库的公司也很有价值。 如果贵公司的开发人员可以对CI系统提出更改建议，该怎么办？ 还是内部Wiki如何配置？ 突然之间，您会有更多的人可以自己帮助解决痛点，而不必等待您上车。 它确实为整个组织增添了力量。

为什么开源对您很重要？ 为什么管理员（而不仅仅是开发人员）向社区贡献代码很重要？

我现在住在旧金山，并且是一个非营利组织的董事会，该组织将计算机投入缺少计算机的学校中（想象一下！距离硅谷仅数英里！），2012年，我在加纳花了几周时间部署了基于Ubuntu的计算机桌面到那里的学校。 没有开源，这项工作将是不可能的。 这两项计划都是由非营利性的相对较小的团队运营的，这些团队只有有限的（或没有）拨款和捐赠的计算机，如果我们每年必须付费购买专有软件来支持这些孩子，那将是不可能的。 除了我在学校所做的工作之外，OpenStack确实在亚洲起飞了。由于缺乏相关的许可成本，OpenStack吸引了来自世界各地的开发者力量，各大公司都在投资开发。 我相信开放源代码软件确实具有均衡能力，并为那些可能没有其他资源的人提供机会。

对于贡献者，管理员使用该软件，因此拥有他们的协作和反馈对于持续重要，以便开发人员可以制作他们想要使用的产品。 OpenStack峰会做了一件非常聪明的事情，即将用户会议和开发者峰会同时放在同一地点。 尽管有时由于一周的限制会引起争议，但它为开发人员和管理员提供了一个机会，使他们构建的软件可以同时位于同一位置，并了解有关使用和需求的更多信息。

翻译自: