采用 PaaS 平台的企业该如何变更组织架构，推动 DevOps 转型成功？
(阅读时间: 大约 12 分钟)
采用 PaaS 平台时，组织是否已做好准备？(IT 成熟度模型)
虽然 PaaS (平台即服务技术) 本身无法改变个体和团队在企业组织内部的交互方式，但该技术通常是组织变革的催化剂，以推动企业向敏捷 IT 转型。 事实上，要想从 PaaS 平台投资中获得最高的回报，组织内角色、职责和关系的转变至关重要。而像 OpenShift Container Platform 之类的 PaaS 产品具有足够的灵活度，允许每个组织按自己的实际情况和节奏来改进相关的人员安排和工作流程。
在企业采用容器技术的第一阶段，最重要的是把容器平台作为新的应用部署环境。在此阶段，企业组织需要将熟悉的工作活动映射到熟悉的人员角色上，以响应对存储、部署环境的请求。在第二阶段，自动化流程将为应用团队提供自助服务，以减轻系统管理员的负担，也让应用团队变得更加高效、更具自主性。这便是 DevOps 实践走向成熟的开端。在最后一个阶段，企业组织将 DevOps 理念运用得更加炉火纯青，许多先前的职责将由新的跨职能团队负责。跨职能团队的核心目标将不再是技术或平台，而是交付应用或应用服务。
本指南旨在给企业组织提供有关指导。即，随着容器技术的引入，传统 IT 角色该如何转变。
第一阶段: 给已有人员分配工作
一开始，PaaS 只是为了给应用提供更加灵活的计算资源，作为应用的运行时环境。虽然这可能会给系统管理员带来一些好处，但开发人员通常并不会从中获得任何实质性的附加功能；因为，组织可能尚未引入自动化的自助服务流程，或改进已有的部署流水线。虽然 PaaS 在早期采用阶段对开发流程的影响极小，但它确实会给管理员们提供一个更加动态的系统，以便能为应用团队提供更好的服务。例如，以前配置一个由多个虚拟机和后端存储卷组成的开发环境，可能需要多个团队配合，花费数天、甚至数周才能完成；现在系统管理员可以更快地满足需求，提供服务。开发团队仍像往常一样提出请求，但系统管理员提供服务的方式将与以往有所不同。
第二阶段: 建立一个 DevOps 组织
一旦平台开始运行，运维团队和应用团队上了平台之后，企业组织就可以继续 DevOps 之旅。DevOps 的一些主要原则如下：
- 将工作拆分为易于管理的小块。以便尽早获得反馈，降低风险，避免分析瘫痪 (analysis paralysis)。
- 使用自动化工具。这样，您就不会再成为应用部署过程中的瓶颈。
- 共享知识。这是建立信任的关键。
- 减少技术债。通过在每个工作周期中花一些时间来进行系统性改进，以减少技术债。
在采用容器的第二阶段，应用团队自然会看到改进已有流程的机会；企业组织内的 DevOps 实践也会变得更加纯熟。创建工单、等待响应的模式将被视作瓶颈，组织内部将通过自动化和自助服务来改进旧的流程。通过平台运维工程师和应用交付团队的紧密协作，可以更快地满足应用团队的请求。系统管理员的工作将不再是执行请求，他们将负责定义并实施管理策略，并确保应用团队能够自助服务。此外，当已有策略不能满足需求时，自动化程序可提供特殊的审批流程。
对 IT 运维环境和运维模式采用迭代、渐进式的变更，这是 DevOps 实践在企业成功落地的关键。DevOps 在每个组织的采纳程度，取决于组织对变更的容忍度，以及组织自身认为哪些变更可能带来最大价值。例如，如果组织不经常创建新环境或新应用，那么继续优化创建流程，可能就不如帮助应用团队更好地管理应用的生命周期，来得重要。
IT 组织的职责
本节中，我们将讨论使用 OpenShift 的组织，在使用容器和 PaaS 技术加速自动化和自助服务 (self-service) 的进程中，通常该如何具体安排相关的角色和职责。
下表概述了任何希望采用 OpenShift 的组织所需的关键职责，以及每个职责背后的人员所需掌握的技能和完成的活动内容。需要注意的是，以下列出的是一份能力清单，负责维护环境的人员应涵盖所有的职责，以确保组织能成功采用容器平台；但这份清单并不等同于组织内的人员分工或团队结构。事实上，正如我们稍后将看到的，容器技术的引入，为 DevOps 成熟化进程提供了一个切入点，这将导致更多的跨职能定位。个人或团队出现责任孤立化的情况会随之减少。
IT 组织的角色
随着组织向 DevOps 持续转型，组织内跨职能的团队和角色会逐步增加，协作效率将得以最大化，而专家型角色可能会减少。我们认为，以下是正在使用 PaaS 的 IT 组织中所需的核心角色。
- 应用运维工程师 (Application Operations Engineer / App Operator) 或 可靠性工程师 (SRE / DevOps ) 他们以前可能是 “应用服务器管理员”
- 应用开发者 / 软件开发者 / 软件工程师
- 应用平台 / 集群管理员 他们以前可能是 “系统管理员” 或 “Linux 平台管理员”
- 发布经理 / 构建工程师
将角色映射到责任: RACI
最后，我们将刚才定义过的职责映射到角色上，以便了解一个通过使用 PaaS 来提高 DevOps 成熟度的企业的整体组织状态。最初，下面的这些角色可能是由多个不同的团队在孤立的情况下执行完成的。但随着时间的推移，这些角色可能被合并到以应用为中心的团队中，应用团队可能会承担起下面大部分或全部角色。
RACI 的定义
资料来源：维基百科
- 谁负责 (R = Responsible) 即，干活的、执行人。负责执行、完成任务的角色。
- 谁批准 (A = Accountable) 即，拍板的、定调的。对任务成果承担最终责任的角色，把工作委派给其他人。只有经他们同意后，项目才能得以进行。
- 咨询谁 (C = Consulted) 即，专家团。通常是领域内的专家，拥有完成项目所需的信息或能力。其他角色会向他们寻求意见，往往是双向沟通。
- 通知谁 (I = Informed) 即，邮件中被 CC 的人。当任务有可交付成果或进展，他们需要被及时通知。却不必向他们咨询、征求意见，往往是单向沟通。
在 DevOps 组织中，团队之间如何协作？
在传统环境中，需求方往往需要反复提出申请才能获取到资源。一个团队先请求资源，然后会由许多团队来提供服务；最终，需求方获得了所需资源。这些过程通常是半自动或完全手工的，不同团队之间需要频繁地来回往复，才能完成一个请求。
上图展示了传统 IT 组织中，团队之间的典型关系。在这里，不同团队通过正式或非正式的通信形式（例如，工单系统，电子邮件等）向其他团队请求所需资源。这些请求工单堆积在一个队列中，如果等待时间过长，团队之间的关系可能会变得紧张。不同团队的成员很少见面，并且几乎不分享信息。这会恶化团队之间的紧张局面。
上图展示了成熟的 DevOps 组织是如何协同工作的。在这里，团队们放弃了之前低效的沟通机制，取而代之的是，将联络员派遣到团队中。这些联络员拥有混合技能，能理解并代表他们团队所面对的需求、困难和已具备的能力。团队们通过自动化的自助门户来完成工作，而不再手工填写工单。因为有了联络员，这些自助门户系统能快速适应团队们的需求。为了在组织内实现更高水平的知识共享和相互理解，团队成员应该定期轮换，与不同的团队打交道，逐渐在这过程中担当起跨职能、有价值的角色。
结论
本指南描述了如何在企业组织内引入 PaaS 和 DevOps。在这个过程中，现有的角色和职责将会发生变化。在决定采用 OpenShift 的组织中，我们需要引入 IT 职责及相关技能。我们描述了一组跨职能 DevOps 组织所需的核心角色，提供了一个 RACI 模型矩阵，并将这些核心角色映射到职责上。最后，我们描述了 OpenShift 和 DevOps 实践将如何改变组织结构。即，从使用工单流程的孤立化 IT 组织转变为更利于人际沟通的跨职能组织。
原文链接: OpenShift and The Organization
翻译：Jamie Fang
题图：Alonso Reyes
