Get best of the week

OpenShift如何改变IT组织的组织结构。转向PaaS时组织模型的演变

尽管仅PaaS（平台即服务）解决方案无法改变个人与团队交互的方式，但是它们通常可以作为组织变革的催化剂，以应对IT技术灵活性的提高。



实际上，只有在组织角色，职责范围（任务）和关系发生变化的情况下，PaaS的最大投资回报率才有可能实现。幸运的是，PaaS解决方案（例如OpenShift容器平台）足够灵活，因此每个IT组织都可以独立地确定相对于相关人员和发生的过程的变更速度和程度。

在企业容器化的第一阶段，主要优先事项是将容器平台作为新的应用程序部署系统来实施。此时，组织将熟悉的工作与熟悉的角色联系在一起，以响应开发团队在存储系统，部署环境等问题上的标准要求。在容器化的下一阶段，我们已经在谈论自动化或为开发人员提供自助服务功能，以减轻系统管理员的负担并将开发人员的自治性和响应能力提高到更高水平。这就是组织开始走向DevOps的方式。在企业容器化的最后阶段，它涉及到一种更清洁，规范的DevOps模型，在此框架中，以前的许多任务和工作都在跨职能团队的控制之下，这些团队不是根据平台或技术进行分组的，而是从确保应用程序或应用程序服务的运行角度进行分组的。

在这篇文章中，我们将为必要的组织变革提供指导，并描述随着企业中容器技术的引入，传统的IT角色是如何变化的。

将新工作链接到旧角色


PaaS组织模型以其基本的初始形式形成，以便更灵活高效地将IT资源分配给作为运行时环境的应用程序。尽管这给系统管理员带来了一定的优势，但通常来说，此处的开发人员不会获得任何显着的好处和新的机会，因为在此阶段，企业很可能无需启动自动化，引入自助服务或从根本上改善部署流程就可以做到。在此阶段，PaaS最小地影响了开发过程，但是却增加了IT系统的活力，使管理员可以更好地满足开发人员的要求。例如，如果从多个虚拟机和存储卷创建开发环境可能需要几天甚至几周的时间，并且需要几个不同的管理员的参与，然后在PaaS中，只需一个管理员的帮助，一切都可以更快地完成。换句话说，开发团队可以像以前一样提交申请，但是根据新方案已经在执行这些应用程序的工作。

建立DevOps组织


通过启动PaaS并转移IT系统操作专家和应用程序开发人员，组织可以继续实施DevOps方法，该方法除其他外包括以下基本原则：

  • 将工作分为几个阶段，以便在早期获得反馈，降低风险并避免“分析性瘫痪”；
  • 充分自动化操作，以免在应用程序部署过程中造成障碍或瓶颈；
  • 分享知识是建立信任的关键。
  • 定期支付技术债务，在每个工作周期中分配一定的时间进行系统改进。

在实施容器技术的第二阶段，开发团队自然会开始看到改进的机会，并且公司正在倾向于更规范的DevOps模型。现在，传统的提交和执行服务请求的机制被视为瓶颈，因此组织寻求自动执行重复性操作并为开发人员提供自助服务功能。此外，开发人员在特定应用程序框架内的这些功能是由IT专家在平台操作以及负责交付应用程序的人员的共同努力下确定的。换句话说，应开发人员的要求执行操作的系统管理员已由负责描述和应用策略管理的上述两类员工所代替究竟允许开发人员自己做什么。自动化程序有助于确保符合这些要求，并在情况超出现有政策范围时协调行动。

对于在企业中构建成熟的DevOps系统而言，切换到IT环境和操作模型随时间进行迭代更改的迭代时间表是至关重要的里程碑。DevOps方法的采用程度取决于每个特定组织对变更的容忍度，以及哪种变更最有利。例如，如果很少出现创建新环境或应用程序的需求，那么优化适当的操作将不如在应用程序生命周期中加强对开发人员的控制那么重要。

IT组织在转向OpenShift时面临的新挑战


在本节中，我们将研究转换为OpenShift的组织通常使用的角色和任务，以使用技术和PaaS加速自动化和自助服务。

下表列出了实施OpenShift的任何组织中存在的最高级别的主要任务，并提供了相关工作和技能的示例。此任务列表不应与工作共享方案或团队的组织结构混淆，这只是一组任务，负责支持IT环境以成功实现容器平台的人员必须关闭这些任务。实际上，我们将进一步展示容器技术的实施为企业形成更成熟的DevOps战略创造了前提条件，这反过来又增加了团队的跨职能程度，并降低了单个员工和团队层面专业化狭窄的风险。

表1. OpenShift任务定义
任务必备技能
(provisioning) -

:

  • -
  • Linux

OpenShift

:

  • Linux
  • (Ansible)
  • Kubernetes OpenShift

(tenant provisioning), -

:
  • RBAC

  • Kubernetes OpenShift
  • , ,



:

  • Linux
  • runtime- middleware
  • (application build frameworks)
  • , imagestream



:

  • immutable
  • – , . .
  • OpenShift, buildconfigs, deploymentconfigs, services, routes, configmaps



:

  • (cloud native)



:
  • ( )
  • -




:
  • UI ( )

  • 测试框架
  • 应用设计模板


迁移到OpenShift时IT组织中出现的新角色


当您转向基于DevOps的组织模型时，角色专业化的数量趋于减少，而跨职能团队和角色的数量反而增加，以最大化协作。我们认为，这是使用OpenShift的IT组织中关键职位的列表：

  • 应用程序运营工程师或站点可靠性工程师。以前，该职位可以称为“ Application Server Administrator”。
  • 应用程序开发人员/软件开发人员/软件工程师。
  • 群集/应用程序平台管理员。以前，此角色可以称为“系统管理员”或“ Linux平台管理员”。
  • 软件发行经理（构建工程师）。

RACI角色和任务矩阵


最后，我们继续比较上面讨论的职位和任务，以大致了解在OpenShift平台上实现DevOps的组织的结构应该是什么样的。最初，以下角色可以由旧的传统组织结构的不同部门执行。但是随着时间的流逝，合并发生了，新的团队围绕完成以下大部分甚至所有任务的应用程序而建立。

任务的角色
应用程序运营工程师/站点可靠性工程师应用程序开发人员/软件开发人员/软件工程师群集/应用程序平台管理员软件发布经理/组装工程师
IT基础架构的自动化和配置一世一世R /一C
安装和管理OpenShift平台C一世R /一C
设计和管理部署管道CC一世R /一
管理租户置备，隔离和IT功能C一世R /一一世
建立和管理基本映像[RCR /一C
应用和测试开发CR /一一世一世
运营监控和应用管理R /一CC一世
定制验收测试C[R一世一世

RACI矩阵中的约定
来源：维基百科

  • 负责任 -执行者是完成任务所需的人员。
  • Accountable – – , ; , .
  • Consulted – – , , ; .
  • Informed – – , (, ); .

DevOps-


通常，获取资源的传统方案是一系列资源分配请求，然后由几个命令执行。最终，所有必要的资源都由请求者分配和确认。通常，这些过程是部分或什至全部手动执行的，并且需要团队之间频繁且众多的交互才能成功处理每个请求。

图1.传统的IT组织



上图说明了传统IT组织中团队之间的典型关系。作为该计划的一部分，一些团队要求其他团队使用或多或少的正式通信手段（例如票务系统或电子邮件）执行必要的工作。然后，这些请求排在队列中，等待着等待，漫长的等待常常导致恶化，甚至加剧团队之间的关系。不同团队的成员很少互相见面，并且通常只共享最少的必要信息，这加剧了紧张局势。

图2. DevOps IT组织



此图显示了DevOps组织中的协作方式。在这里，上图中的相同团队放弃了低效率的通信，从而增加了不团结，并用个人联系代替了他们，从而创建了团队之间的永久性交互渠道。这些渠道有助于建立一个混合技能组，以帮助员工更好地理解并代表他们所代表的团队的需求，挑战和能力。团队彼​​此之间有机会通过自动化自助服务门户执行必要的工作，而不是像以前那样手动处理其他人的变更请求。由于存在互动渠道，这些自助服务系统能够快速适应团队的需求，为此创建它们。为了在组织内实现更大的相互理解和知识共享，团队成员会定期轮换角色，以获取与各个团队进行交互的经验，并更好地了解他们所服务的IT系统的整体情况，从而提高其跨功能和实用性的水平。

总结


在本文中，我们讨论了PaaS解决方案的实施如何能够鼓励组织实施DevOps方法，并且传统角色和任务在此过程中可能会发生变化。因此，我们列出了向OpenShift过渡时组织中出现的主要IT任务，以及实现这些任务所需的技能。我们还介绍了建立跨职能的DevOps团队时发生的主要组织角色集，以及将新角色与新任务联系起来的RACI矩阵。最后，我们讨论了OpenShift平台及其相关的DevOps方法如何在从传统的层次结构和应用程序处理系统过渡到具有更高水平的个人沟通的跨职能团队时，如何改变组织的组织结构。

More articles:


All Articles