DevOps 转型：小型、中型和大型组织的关键差异

持续创新迈向 DevOps 之旅正是如此——持续的——意味着您不太可能到达终点。

如下图所示，此旅程的步骤是：评估并将组织与行业中的其他组织进行比较，确保人员认同转型，引入工程流程和产品，使团队能够满足其利益相关者的需求，持续交付价值，并将解决方案从数百用户扩展到数百万用户。从概念上讲，转型对于任何组织都应是相同的。

图片来源：

^{DevOps 转型之旅}

然而，在一家只有少数工程师的公司中进行 DevOps 转型与在一家拥有数百或数千名工程师的公司中进行转型截然不同。

从直觉上讲，DevOps 之旅对于小型组织来说应该最容易，因为它们通常充满激情并渴望变革。然而，小型组织往往在资源、基础设施和预算方面受到更多限制，而大型组织往往有更多的政策、治理和政治因素会影响转型。

那么，规模重要吗？以下是社区成员在关于规模如何影响转型难易程度的调查中的说法。

图片来源：

^{基于组织规模接受 DevOps 的能力}

小型和新兴组织

在小型组织中，管理层和工程部门的责任界限往往模糊不清，这自然而然地创造了一个精益环境。同样，由于资源稀缺，工程部门通常身兼数职，承担技术和运营的双重角色，这自然而然地创建了对其解决方案负责的跨职能团队。此外，小型和新兴组织通常充满激情，渴望新产品和流程，这使得它们成为转型为 DevOps 思维模式的理想候选者。此外，DevOps 转型正日益成为与大型竞争对手竞争的必要条件。

由于小型组织中的管理层和工程部门都很精简，因此重要的是要确保有一个清晰的愿景，工程部门得到授权并承担责任，自治界限得到尊重，并且反馈和快速失败流程处于活跃状态。还需要有一个清晰的“凌晨 2 点呼叫”流程，以应对线上事件影响用户体验的情况——在许多情况下，即使是小型组织的 CEO 也必须在待命名单上。不愿履行跨职能角色的工程师对这些组织来说是一种风险。工程师必须有正确的态度，有些人可能需要找到另一个归宿（在组织内部或外部）。有关 DevOps 团队的更多信息，请参阅“具有 DevOps 思维模式的团队蓝图”。

图片来源：

^{按规模划分的组织中的 DevOps 模式}

考虑 Matthew Skelton 在“哪种团队结构最适合 DevOps 蓬勃发展？”中讨论的 DevOps 即服务 和 完全嵌入式 模型。前一种模型非常适合小型组织，后一种模型是可行的，正如微软的兼职 ALM | DevOps Ranger 社区所证明的那样。

中型组织

中型组织不断增长的资源和预算通常会营造一种环境，在这种环境中，政治、政策和技术治理会抬头。您可能会发现一个专注于 IT 运营的团队、一个或几个工程团队，以及开发和运营之间可怕的鸿沟。这些是各自为政的环境，开发部门构建解决方案，IT 运营部门支持基础设施和解决方案。

中型组织必须专注于打破各自为政的局面，创建通用语言，并建立技术治理，将业务、开发和运营领导层以及工程部门团结起来。谈论宣言（而不是治理）将减少工程部门的焦虑和抵制。

图片来源：

^{按规模划分的组织中的 DevOps 反模式}

考虑 Skelton 在上面链接的“团队结构”文章中描述的 临时 DevOps 团队。这是一个好的，尽管是临时的策略，可以拉近开发和运营部门的距离。

大型和成熟组织

我们很少有人拥有像亚马逊、Facebook、谷歌或微软这样的大型组织那样充裕的资源和预算。大型组织具有多样性、经验和能力，可以将运营和开发团队划分为许多小型、专注的团队。例如，微软有几个以产品为中心的部门，例如 Windows、Office 和 Azure DevOps，每个部门都细分为许多使用通用工程系统的小团队。这些团队自然而然地拥抱敏捷和 DevOps 实践，并得到统一的企业级愿景和转型战略的支持。

考虑建立卓越中心或卓越中心，以创建特别兴趣小组。以这种方式利用熟练知识工作者的思想领导力可以为组织提供最佳实践。这些小组还支持 DevOps 即服务模式的概念，以帮助组织提升到更高的意识和成熟度水平，共享知识，减少浪费并进行创新。确保您有来自业务、开发和运营部门的代表！虽然所有类型的组织都将从 DevOps 即服务中受益，但资源需求——预算和人员——使其仅对中型和大型组织可行。

一些大型组织感觉像中型组织，领导层、业务、运营和开发团队各自为政，只是规模更大、隔离更严重。他们的挑战包括鼓励整个组织考虑和拥抱 DevOps 实践，将组织业务语言转化为通用语言，并引入不熟悉的概念，例如 Scrum、看板、冲刺节奏、短交付周期、快速轻量级的反馈循环以及生产中的持续实验。虽然许多组织看到了拉近开发和运营部门距离的价值，但您会遇到习惯于严格的顺序、详细且可预测的范围以及以里程碑为中心的项目 的瀑布式团队的抵制。您还可能会遇到领导层无意中干预工程团队的情况，模糊了将 WHAT 和 WHY（由领导层拥有）与 HOW 和 WHEN（由工程部门拥有）分开的自治界限。

Skelton 在他的博客中讨论的 完全嵌入式 或 顺畅协作 模型已被证明在自然而然地拥抱 DevOps 的大型组织中是成功的。对于其他组织，DevOps 即服务 和 临时 DevOps 团队 模型是拉近不同团队距离的理想选择。

正确的策略

图片来源：

 ^{DNA：文化、领导力、流程和团队}

每个组织都是不同的，评估正确的策略是多种特征的组合，与规模无关。

图片来源：

^{DevOps 中的人员、流程、产品挑战}

重要的是对组织的人员、流程和产品进行评估，以揭示其文化、领导力、团队和变革意愿。更重要的是，评估将突出显示自然转型的领域以及您需要周到地培育的领域。

核心在于人及其文化，而不是组织的规模，塑造组织并使组织之间产生差异。

如需更多见解，请浏览 Microsoft Azure 的 DevOps 资源中心，其中包含关于转型和采用 DevOps 的视频和文章，包括经验教训。