it部门内部结算_内部采购如何挽救我们的IT部门

最新推荐文章于 2024-09-27 10:47:12 发布

cumj63710

最新推荐文章于 2024-09-27 10:47:12 发布

阅读量361

点赞数

文章标签：大数据编程语言 python 人工智能 java

原文链接：https://opensource.com/open-organization/18/1/open-orgs-and-inner-source-it

版权

it部门内部结算

红帽是一家拥有大约11,000名员工的公司。 IT部门由大约500名成员组成。尽管它仅占整个组织的一小部分，但IT部门仍然配备了足够的人员，可以在其中拥有许多应用程序服务，基础架构和运营团队。我们的目标是“使所有功能中的“红色帽子”都能有效，高效，创新和协作，使他们感到自己可以有所作为”，更具体地说，是通过在网站上提供技术和相关服务来做到这一点。尽可能开放的时尚。

这样的开放需要时间，精力和精力。尽管我们始终努力做到尽可能开放，但这可能很困难。由于多种原因，我们并不总是成功。

在这个故事中，我将解释一个时期，在急于创新的过程中，红帽IT组织忽视了其开放的理想。但是，我还将探讨回到这些理想的方式以及使用“内部资源”的协作策略如何帮助我们恢复并极大地改善我们提供服务的方式。

关于内部来源

在解释内部资源如何帮助我们的团队之前，让我提供一些有关概念的背景知识。

内部资源是组织内部团队之间采用开放源代码开发实践，以促进更好，更快地交付，而无需将项目资源公开或公开许可。它使组织可以在自己的范围内获得开源开发方法的许多好处。

通过这种方式，内部资源与开放组织的策略和原则非常吻合。它提供了开放，协作开发的路径。虽然开放组织将开放性原则大致定义为透明性，包容性，适应性，协作性和社区性，并且涵盖了如何将这些开放性原则用于沟通，决策和许多其他主题，但是内部来源是关于采用特定的来自开源社区的战术实践，流程和模式 ，以改善交付。

例如，开放组织成熟度模型建议为透明起见，团队至少应与项目团队共享所有项目资源（尽管这建议与整个组织共享这些资源通常更好）。内部源代码开发和开放源代码开发中的通用模式是将所有资源托管在一个公开可用的版本控制系统中，以进行源代码管理，从而实现高度透明的开放组织目标。

内部资源与开放组织的策略和原则非常吻合。

价值一致性的另一个例子出现在开源社区接受捐款的方式中。在开源社区中，源代码是透明可用的。补丁或合并请求形式的社区贡献是普遍接受的做法（甚至是预期的做法）。这提供了一个示例，说明了如何实现开放组织的促进包容性和协作性的目标。

挑战

2014年初，红帽IT部门开始迈出第一步，使Amazon Web Services（AWS）成为业务关键系统的标准托管产品。尽管此时红帽IT团队已经在AWS中构建了几个系统和服务，但这些都是定制的，我们希望简化和标准化将服务部署到AWS中的IT标准。

为了使AWS云托管满足我们的运营标准（同时具有可扩展性），红帽IT部门的Cloud Enablement团队决定将AWS代码中的所有基础架构都通过代码配置，而不是手动配置，并且每个人都将使用一套标准的工具。 Cloud Enablement团队设计并构建了这些标准工具。平台运营团队是一个单独的小组，负责使用这些工具在AWS中配置和托管系统和服务。

Cloud Enablement团队基于包装在管理层中的AWS Cloud Forms配置，构建了一个工具集（俗称“模板Util”），以强制执行某些配置要求，并简化跨环境的多个服务副本。尽管Template Util工具集在技术上满足了我们所有的初始要求，并且最终我们为其提供了十几个服务的基础架构，但是使用该工具的每个团队的工程师都发现使用它很痛苦。使用该工具的一位工程师迈克尔·约翰逊（Michael Johnson）说：“这样做相对简单，确实非常复杂。”

Template Util展示的问题包括：

底层云形成技术隐含了对应用程序堆栈管理的约束，与我们管理应用程序系统的方式不一致。
该工具使用多层模板技术和语言，不必要地变得复杂而脆弱，从而使语法问题难以调试。
该工具的代码以及一些用户操作该工具所需的数据被保存在大多数用户难以访问的存储库中。
没有贡献或接受变更的标准流程。
文档很差。

随着越来越多的工程师尝试使用“模板实用程序”工具集，他们发现这些工具还有更多问题和局限性。不幸继续增长。更糟的是，Cloud Enablement团队随后将优先级转移到了其他可交付成果上，而又没有放弃该工具的所有权，因此，错误修复和对该工具的改进被进一步推迟了。

这里真正的核心问题是我们无法建立一个包容性社区来协作构建满足每个人需求的共享工具。

这里真正的核心问题是我们无法建立一个包容性社区来协作构建满足每个人需求的共享工具。对失去“所有权”的恐惧，对不断变化的要求的恐惧以及对努力工作被放弃的恐惧，都导致了长期冲突，进而导致结果恶化。

危机点

到2015年9月，在使用Template Util工具在AWS中启动我们的第一项主要服务之后，我们遇到了一个危机点。

许多工程师拒绝使用这些工具。这迫使所有相关的服务提供工作都由一小组工程师完成，这进一步使社区破裂，并破坏了这些工程师努力应对意外工作的服务交付路线图。我们召开了紧急会议，并邀请所有相关团队寻求解决方案。

在紧急会议期间，我们发现人们通常认为我们需要立即进行更改，应该重新开始进行工具工作，但是即使重新开始的决定也不是一致的。出现了许多解决方案-有时可能来自一个团队中的多个解决方案-所有这些都需要大量工作才能实施。虽然我们无法在本次会议上就使用哪种解决方案达成共识，但我们确实达成了共识，即让不同技术的支持者有两个星期的时间在各个团队中共同努力，以使用原型构建案例，然后社区可以评论。

尽管我们尚未做出最终决定，但这项协议是我们开始回归指导我们使命的开源理想的第一步。通过邀请所有相关方，我们能够做到透明和包容，并且我们可以开始重建内部社区。通过明确表明我们想改进并接受新的选择，我们表明了我们对适应能力和精英管理的承诺。最重要的是，用于构建原型的计划为人们提供了清晰的协作返回途径。

当社区审查原型时，它确定明确的领导者是一个基于Ansible的工具集，最终将在内部被称为Ansicloud。（当时，参与这项工作的人都没有想到Red Hat将在下个月收购Ansible。还应注意的是，即使我们使用特定的Template，Red Hat中的其他团队也发现基于Cloud Formation的工具非常有用。实用工具未成功。）

但是，原型设计和测试阶段并不能在一夜之间解决问题。虽然我们在总体方向上达成了共识，但我们仍然需要改进新原型，以使工程师能够可靠地将其用于生产服务。

从开发人员社区的角度来看，从传统的孤立开发模型转换为内部源代码模型已产生了可量化的重大改进。

因此，在接下来的几个月中，少数工程师致力于进一步构建和扩展Ansicloud工具集。我们建立了三个新的生产服务。当我们共享代码时，共享活动的成熟度很低。由于流程较旧，一些工程师无法访问。其他工程师的工作方向略有不同，每个工程师必须自己重新发现一些核心设计问题。

恢复开放

这导致了一个转折点：在先前的协议基础上，我们专注于开发统一的愿景并提供更轻松的访问权限。为此，我们：

为该项目创建了特定目标清单（“必须具备”和“必须具备”），
为项目创建了一个未解决的问题日志，以避免重复解决相同的问题，
打开我们的代码库，以便Red Hat中的任何人都可以读取或克隆它，并且
使工程师轻松获得可信的提交者访问权限

我们的合作协议，最终的统一愿景以及改进的工具开发方法刺激了我们社区的发展。 Ansicloud的采用遍及所有相关组织，但这带来了一个新问题：该工具的更改开始比用户适应它的速度更快，而且提交的不同小组的改进开始以意想不到的方式影响其他小组。

真正重要的是，我们看到的改进不是像差。内源提供了组织可以用来有效促进协作的常见，易于理解的模式。

这些问题导致我们最近转向内部来源实践。尽管每个开源项目的运作方式都不尽相同，但我们专注于采用一些最佳实践，而这些最佳实践似乎对许多人而言都是相同的。特别是：

我们确定了项目的业务所有者和开发人员的核心贡献者组，他们将负责管理工具的开发并决定接受哪些贡献。尽管我们希望保持开放状态，但是我们不能让人们互相对抗或破坏彼此的功能。
我们开发了一个README项目，以阐明该工具的用途并指定如何使用它。我们还创建了一个CONTRIBUTING文档，解释了如何进行贡献，哪种类型的贡献将是有用的，以及需要通过哪种类型的测试才能被接受。
我们开始为Ansicloud工具本身构建持续的集成和测试服务。这有助于我们确保在项目接受并合并之前，我们可以在技术上快速有效地验证贡献。

有了这些基本协议，文档和工具，我们又回到了开放协作和成功内部采购的道路上。