如果将设置和控制基础设施的所有配置文件和脚本都视为独立的开源项目会怎样？如果将代码发布以供审查，并允许开发人员和运维人员协同工作，以确保代码顺利部署到生产环境会怎样？ 这就是惠普的 OpenStack 基础设施团队的工作方式。
Elizabeth K. Joseph 是惠普的自动化和工具工程师，她在 OpenStack 基础设施团队工作，该团队运行一个完全开源的基础设施，专为 OpenStack 开发而构建。 在她即将到来的 All Things Open 演讲中，她概述了她的团队使用的工具，在开放环境中工作如何影响他们的运营，以及其他寻求使其工作流程更加开放的组织可以从惠普的经验中学到什么。
请简单介绍一下你自己。 你是如何开始从事系统管理工作的？
自 2002 年以来，我一直在我的桌面上使用 Linux，并且几乎从一开始我就参加 Linux 用户组并与其他用户协作。 我最初被 Linux 和开源所吸引，是因为它具有自定义能力（你有源代码！），以及令人惊叹的社区，其中有很多人热衷于分享他们的工作。
大约在 2006 年，我开始为费城当地的一家技术服务提供商工作，负责服务器的机架安装和现场 Linux 安装。 最终我被全职聘用为他们的初级系统管理员。 我们专注于基于 Debian 的部署，但也经常成为客户遇到的网络调试和其他棘手技术问题的首选来源。 随着我在那里工作的发展，我开始从事更大的部署和使用 Pacemaker 和 Heartbeat 的高可用集群，以及大量的虚拟化工具。 这确实是我对系统管理充满热情的地方，使用开源工具构建东西令人兴奋，并且触手可及有很多选择 - 而且我的雇主热衷于我们向上游贡献，所以我能够在我在那里的任期内为 Debian 做出贡献。
多年来，我参与了多个开源项目，最值得注意的是 Ubuntu，这导致我在 2012 年获得了 O'Reilly 开源奖，并且是最新（第 8 版）的 The Official Ubuntu Book 的合著者，该书于 7 月出版。
我渴望将我对开源的热情与我的系统管理工作结合起来，于是我加入了惠普的 OpenStack 基础设施团队，为 OpenStack 开发人员提供支持，所以我就在这里了！
在消费 OpenStack 时，似乎有很多执行类似任务的相关工具。 基础设施团队如何选择合适的工具，以及他们如何支持做出不同选择的下游用户？
OpenStack 基础设施团队结合了 Git、Gerrit 和 Jenkins 等多种开源技术，以及一些自制的开源项目，为 OpenStack 项目中的高速环境提供了一个强大的持续集成系统。 从那里，团队消耗来自多个 OpenStack 提供商捐赠的云虚拟机（目前总共约 800 台机器分布在 2 个公共云上，以及 2 个私有 OpenStack 云上的一些裸机测试）。 由于我们的工具连接到配置略有不同的多个云，我们尝试在我们的工具中坚持使用基本的 OpenStack 命令，因此我们可以确保支持大多数符合最佳实践的基于 OpenStack 的云。
我们还使用各种其他流行的开源工具来支持开发者社区，从 MediaWiki 用于我们的 Wiki，到 Cacti 用于跟踪我们的服务器随着时间的推移表现如何。 这些通常由一个或一小队项目成员选择，他们了解项目需求，然后评估可用的选项。 例如，去年夏天，我对 Git Web 前端进行了非常彻底的审查，然后我们召开会议讨论我的发现并决定使用 cgit。
在配置管理方面，我们混合使用 Puppet 和 Ansible 来驱动我们的基础设施。 虽然它对我们来说效果很好，但 Puppet 在项目真正结合在一起时基本上是一个任意的选择，当时 Chef 也可能是一个不错的选择。
随着我们的下游社区的增长，特别是那些使用我们的持续集成系统的社区，我们正在这个周期中努力减少 OpenStack 的特定性，并将我们的基础设施分割开来，使其更易于使用。 然而，我们的任务仍然是支持 OpenStack 项目，所以我们的精力主要集中在那里。 我们只真正提供我们的源代码并要求下游提交补丁，例如，我们不在我们的基础设施中使用 LDAP 或广泛的代理，但是我们有下游用户这样做，所以我们现在正在携带他们的补丁来支持这些东西。
在 OpenStack 基础设施团队工作，让你感到兴奋的是什么？
将我对开源和系统管理这两个激情融合在一起，使这份工作对我来说非常棒。 感谢惠普，我也有机会参加会议并分享我们正在做的工作，从谈论我们如何开源我们的整个 Puppet 配置到我们运行一个完全开源的基础设施在互联网上所学到的经验教训。 与其他开源项目的贡献者联系也很棒，他们也开源了他们的全部或部分基础设施，包括 Debian、Fedora、Mozilla 和 Jenkins。
围绕 DevOps 改变代码管理和部署方式有很多讨论，但仍然有很多组织难以采用更 DevOps 的方法。 你认为是什么阻碍了他们？
我认为有两个主要障碍。 首先是它需要系统管理方面的大量学习，我从未像现在这样写过这么多代码！ 这是一个很大的变化，我们不再只是将各个部分组合在一起并采用提供给我们的东西进行部署，我们正在开发这些部分中发挥重要作用，这可能是一个艰难的转变。
然后你需要管理层的支持。 DevOps 需要对你的运营团队的信任和自由，这可能很难给予，尤其是在更大的组织中。 DevOps 发展迅速，因此由善意的人员制定的大型变更审查流程可能会在其中真正造成阻碍，并使转变几乎不可能。
"The Phoenix Project" 几乎是 DevOps 小说，它深入探讨了更多这些挑战以及一个虚构的“老牌”系统团队如何扭转他们的组织。 强烈推荐。
不要透露太多，请简单介绍一下你即将在 All Things Open 上发表的演讲。 听众可以期待学到什么？
我将谈论开源系统管理。 在我的演讲中，我将介绍我们在 OpenStack 项目中拥有的基础设施，以提供一些背景信息，解释我们如何使用代码审查系统来管理我们的系统管理变更，以便我们可以安全地从整个 OpenStack 社区获得贡献，以及我们如何通过在线开放地完成所有工作来建立一个有凝聚力的远程系统管理员团队。
作为开源项目，我们的案例是一个极端的例子，但我们学到的经验教训对于正在考虑向公司其他人员开放其系统管理存储库的公司也很有价值。 如果贵公司的开发人员可以提出对你的 CI 系统的更改会怎样？ 或者内部 Wiki 如何配置？ 突然之间，你有更多的人可以提供帮助并自行解决痛点，而无需等待你处理他们的工单。 这确实赋予了整个组织力量。
为什么开源对你来说很重要？ 为什么管理员而不仅仅是开发人员将代码贡献回社区很重要？
我现在住在旧金山，并且是一家非营利组织的董事会成员，该组织将电脑送到缺乏电脑的学校（想象一下！ 距离硅谷仅数英里！），2012 年，我花了几个星期在加纳向那里的学校部署基于 Ubuntu 的桌面电脑。 如果没有开源，这项工作是不可能实现的。 这两个项目都由非营利组织中相对较小的团队运营，这些团队只有有限的（或没有）赠款资金和捐赠的计算机，如果我们每年都必须为专有软件付费才能支持这些孩子，那将是不可能的。 除了我在学校所做的工作之外，OpenStack 在亚洲也真正起飞，由于与其相关的许可成本的缺乏，它创造了来自世界这一地区的开发者力量的繁荣，主要公司都在投资开发。 我相信开源软件确实有能力实现平等，并为那些可能没有其他资源的人提供机会。
对于贡献者来说，管理员使用该软件，因此持续拥有他们的协作和反馈非常重要，以便开发人员可以制作他们想要使用的产品。 OpenStack Summit 做了一件非常聪明的事情，就是将用户大会和开发者峰会同时同地举行。 虽然有时由于为期一周的限制而引起争议，但它为构建该软件的开发人员和管理员提供了一个机会，让他们可以在同一时间、同一地点了解更多关于使用情况和需求的信息。
评论已关闭。