持续创新迈向 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 实践，将组织业务术语转化为通用语言，并引入不熟悉的概念，例如 scrums、kanban、sprint 节奏、短交付周期、快速而轻量级的反馈循环以及在生产中持续实验。虽然许多组织看到了将开发和运营部门拉近距离的价值，但你将遇到习惯于严格的顺序、详细且可预测的范围以及以里程碑为中心的项目瀑布团队的抵制。你还可能会遇到领导层无意中干预工程团队，模糊了区分“做什么”和“为什么”（由领导层拥有）与“如何做”和“何时做”（由工程部门拥有）的自主权界限。
Skelton 在他的博客中讨论的完全嵌入式或顺畅协作模型已被证明在自然而然地拥抱 DevOps 的大型组织中是成功的。对于其他组织，DevOps 即服务和临时 DevOps 团队模型是将不同团队拉近距离的理想选择。
正确的策略
DNA：文化、领导力、流程和团队
每个组织都是不同的，评估正确的策略是多种特征的组合，与规模无关。
DevOps 中的人员、流程、产品挑战
重要的是对组织的人员、流程和产品进行评估，以揭示其文化、领导力、团队和对变革的渴望。更重要的是，评估将突出显示自然转型的领域以及需要深思熟虑地培养的领域。
核心在于人及其文化，而不是组织的规模，塑造了组织并使组织彼此区分开来。
如需更多见解，请浏览 Microsoft Azure 的 DevOps 资源中心，其中收录了关于转型和采用 DevOps 的视频和文章，包括经验教训。
2 条评论