# 运营模式 2:2 展示图
这些运营模式 2:2 展示图可帮助您了解您环境中的团队之间的关系。这些图表着重说明成员的职责以及团队之间的关系，但我们也将通过这些示例讨论治理和做出决策。
您的团队可能需要在多个模式的多个部分承担责任，具体取决于他们支持的工作负载。您可能希望打破比所描述的高级规范更专业的规范。当您分离或汇总活动，或叠加团队并提供更具体的细节时，这些模式可能会出现无穷无尽的变化。
您可能发现团队中存在重叠或未被认可的能力，这些能力可以提供额外优势或提高效率。您可能还发现您可以计划解决的组织中未满足的需求。
在评估组织变革时，请检查模式之间的权衡，您的各个团队采用的模式（现在和变革之后），您的团队的关系和职责将如何变化，以及所获得的益处是否抵得过对您的组织产生的影响。
您可以成功使用以下四种运营模式。某些模式更适合于特定使用案例或您的开发中的特定点。其中一些模式可能比在您的环境中使用的模式更具优势。
**Topics**
+ [完全分离运营模式](fully-separated-operating-model.md)
+ [通过云托管服务提供商进行 DevOps 工作](devops-with-cloud-managed-service-provider.md)
+ [云运维和平台支持（COPE）](cloud-operations-and-platform-enablement.md)
+ [分布式 DevOps](distributed-devops.md)
+ [分散式 DevOps](decentralized-devops.md)
+ [不断发展运营模式](evolving-your-ops-model.md)
# 完全分离运营模式
在下图中，纵轴上为应用程序和平台。应用程序是指促进取得业务成果的工作负载，可以是自定义开发或购买的软件。平台是指支持该工作负载的物理和虚拟基础设施以及其他软件。
横轴上为我们的工程和运营。工程是指应用程序和基础设施的开发、构建和测试。运营是应用程序和基础设施的部署、更新和持续支持。
![\[传统模型图\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png)
从历史上看，组织采用诸如 ITIL 之类的框架或 ISO 之类的标准，并围绕这些框架构建运营活动，这通常会导致完全分离的拓扑。在此模式下，每个象限中的活动由单独的小组执行。通过工作请求、队列、票证等机制或使用 IT 服务管理（ITSM）系统在团队之间分配工作。
任务向团队或在团队之间的转移会增加复杂性，并造成瓶颈和延迟问题。请求可能会被延迟，直至它们成为重点事项。较迟发现缺陷可能需要大量返工，可能需要再次经历相同的团队及其职能部门。如果存在需要工程团队采取行动的事件，则将因转移活动而延迟响应。
当围绕正在执行的活动或职能组织业务团队、开发团队和运营团队时，出现工作重点偏失的风险较高。这可能导致团队专注于其特定职责，而不是专注于实现业务成果。团队可能专业化水平受限、被物理隔离或逻辑隔离，阻碍了沟通和协作。
# 通过云托管服务提供商进行 DevOps 工作
“通过云托管服务提供商进行 DevOps 工作”模式遵循应用程序团队的*谁构建，谁运行*方法。不过，您的组织现在可能无法为专门的平台工程和运营团队提供相应的技能或团队人员支持，或者您可能不想为此花费时间和精力。
或者，您可能希望有一个平台团队能够专注于打造凸显业务优势的能力，不过您希望将千篇一律的日常运营工作交给外包商。
托管服务提供商（如 [AWS Managed Services](https://aws.amazon.com/managed-services/)、[AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider) 中的提供商）会提供实施云环境的专业知识，并为您的安全性和合规性要求以及业务目标提供支持。
![\[通过云托管服务提供商进行 DevOps 工作\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png)
对于这一变体，我们将治理视为由平台团队集中管理，并使用 AWS Organizations 和 AWS Control Tower 管理账户创建和策略。
此模式需要您修改自身机制，以便使用服务提供商的机制。它不能解决由于团队（包括您的服务提供商）之间的任务转换所造成的瓶颈和延迟，也无法解决由于发现缺陷较晚而存在的潜在返工。
提供商的标准、最佳实践、流程和专业知识将让您受益良多。此外，他们还会不断开发服务产品，您也会从中获益。
将托管服务添加到您的运营模式可以节省您的时间和资源，并使您的内部团队保持精干，专注于凸显业务优势的战略成果，而不是开发新的技能和功能。它还可以让您有时间构建和完善自己的平台功能，而不会减慢云迁移计划的速度。
# 云运维和平台支持（COPE）
这种云运营和平台支持（COPE）模型旨在通过支持应用程序团队为其工作负载执行工程和运营活动，采用 DevOps 文化，建立一种*谁构建，谁运行*的方法。
您的应用程序团队可能负责迁移、采用云或实现工作负载现代化，但现有技能可能无法充分支持云架构和运营。缺乏应用程序团队能力和熟悉度可能会减慢组织的敏捷性并影响业务成果。
要解决这个问题，请利用组织内部现有的运营专业知识来支持应用程序团队的云运营之旅。这可以是一个由专家组成的专门团队，也可以是一个虚拟团队，其参与者是从整个组织中挑选出来的。但是，目标保持不变，即提供运营支持，以增强工作负载团队的能力，使用云优先的自动化原则，消除无差别繁重工作，提供标准化模式并促进自主权。其目标是在云功能方面建立足够的成熟度，降低运营责任的门槛，从而使应用程序团队不再需要额外的支持。
COPE 模型侧重于工作负载级别。如果多个团队同时需要这种方法，如果您将执行为期多年的复杂大规模迁移项目，或者您将构建平台来支持这些计划，请考虑使用云卓越中心（CCoE）。许多人在寻求加快向云的迁移并广泛实现组织转型时都发现了一种成功的机制。
![\[云运维和平台支持（COPE）计划\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png)
您的平台工程团队构建了一层薄薄的核心共享平台功能，这些功能基于供应用程序团队采用的预定义标准，由 COPE 团队提供。平台工程团队编纂了通过自助机制提供给应用程序团队的企业参考架构和模式。使用诸如 AWS Service Catalog 之类的服务，应用程序团队可以部署经批准的参考架构、模式、服务和配置，这些架构在默认情况下符合集中式治理和安全标准。
平台工程设计团队还为应用程序团队提供一套标准化的服务（例如，开发工具、可观测性工具、备份和恢复工具以及网络）。
COPE 团队管理和支持标准化服务，并根据参考架构和模式为应用程序团队提供帮助，以建立云业务。他们与应用程序团队合作，帮助他们建立基准运营。在此过程中，随着时间的推移，应用程序团队会逐渐为其系统和资源承担更多责任。COPE 团队与平台工程团队一起推动持续改进，并充当应用程序团队的支持者。
应用程序团队在设置环境、CI/CD 管道、变更管理、可观测性和监控以及建立事故和事件管理流程方面获得帮助，COPE 团队将根据需要参与其中。COPE 团队与应用程序团队一起参与这些运营活动的执行，随着应用程序团队占据主导地位，COPE 团队的参与将逐渐减少。
应用程序团队受益于 COPE 团队的技能和组织吸取的经验教训。他们受到通过集中治理建立的防护机制的保护。应用程序团队在公认的成功基础上再接再厉，并受益于他们所采用的组织标准的持续发展。通过建立可观测性和监控的过程，他们可以更深入地了解工作负载的运营情况，并且能够更好地了解他们对工作负载所做更改的影响。
COPE 团队还可以保留必要的访问权限，以支持运营活动，提供跨应用程序团队的企业运营视图，并提供重大事件管理支持。COPE 团队保留对被视为无差别繁重工作的活动的责任，他们通过可大规模支持的标准解决方案来满足这些需求。他们还继续为应用程序团队管理众所周知的编程和自动化运营活动，以便他们可以专注于差异化应用程序。
您可以从团队的成功中获得组织的标准、最佳实践、流程和专业知识的优势。您可以建立一种机制来复制这些成功模式，让新团队在云中采用或实现现代化。该模型强调 COPE 团队帮助应用程序团队获取现有知识和工件及转移知识和构件的能力。它减轻了应用程序团队的运营负担，也降低了应用程序团队无法独立的风险。它建立了平台工程、COPE 和应用程序团队之间的关系，创建了反馈回路以支持进一步的发展和创新。
建立平台工程和 COPE 团队，同时定义组织范围的标准，可以促进云的采用并支持现代化工作。通过为应用程序团队充当顾问和合作伙伴以便为 COPE 团队提供额外支持，您可以消除阻碍应用程序团队采用有益云功能的工作负载级别的障碍。
# 分布式 DevOps
分布式 DevOps 模型遵循 [COPE 方法](cloud-operations-and-platform-enablement.md)，会在整个工程团队中分开（或分配）应用程序工程运营和基础设施工程运营职责。
应用程序工程师和开发人员同时执行工作负载工程设计和运营。同样，您的基础设施工程师可以对他们用以支持应用程序团队的平台同时进行工程设计和运营。
![\[分布式 DevOps 模型图\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png)
在此示例中，我们将治理视为集中在组织内的其他地方。标准会被分发、提供或共享给应用程序和平台团队。
您应使用能够跨账户集中治理环境的工具或服务，例如 [AWS Organizations](https://aws.amazon.com/organizations/)。[AWS Control Tower](https://aws.amazon.com/controltower/features/) 等服务扩展了这一管理功能，使您能够定义账户设置的蓝图（支持您的运营模式），使用 AWS Organizations 进行持续治理以及自动预置新账户。
*谁构建，谁运行*并不意味着应用程序团队负责完全堆栈、工具链和平台。
平台工程设计团队为应用程序团队提供一套标准化的服务（例如，开发工具、监控工具、备份和恢复工具以及联网）。平台团队还可以为应用程序团队提供对经批准的云提供商服务、相同或两个团队的特定配置的访问权限。
为部署经批准的服务和配置（例如 Service Catalog）提供自助服务功能的机制可以在实施治理的同时帮助限制与执行请求相关的延迟。
平台团队实现了完全堆栈可见性，因此应用程序团队可以区分应用程序组件的问题以及应用程序所使用的服务和基础设施组件。平台团队还可以提供配置这些服务的辅助措施，以及有关如何改进应用程序团队运营的指导。
如前所述，应用程序团队一定要建立请求补充、更改支持各类活动的标准和添加例外情况，以及请求应用程序创新的机制。
分布式 DevOps 模式为应用程序团队提供了强大的反馈环路。工作负载的日常运营通过直接交互或通过支持和功能请求间接增加与客户的联系。这种更高的可见性使应用程序团队能够更快地解决问题。更深入的互动和更密切的关系可提供对客户需求的洞察，并实现更快速的创新。
所有这些对于支持应用程序团队的平台团队来说也是如此，因为平台团队应该将这些应用程序团队视为他们的客户。
采用的标准可以预先批准以供使用，从而减少投产所需的审核量。采用由平台团队提供的受支持的、业经测试的标准可以减少这些服务出现问题的频率。标准的采用可帮助应用程序团队专注于差异化工作负载。
# 分散式 DevOps
分散式 DevOps 模型是*谁构建，谁运行*方法的变体，在这种方法中，运营主要由工作负载团队负责。
应用程序工程师执行工作负载工程设计和运营。同样，您的基础设施工程师可以对他们用以支持应用程序团队的平台同时进行工程设计和运营。
![\[分散式 DevOps 图\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png)
在本示例中，我们采用分散式治理。标准仍由平台团队分发、提供或共享给应用程序团队，但是应用程序团队可以自由设计和操作新的平台功能来支持其工作负载。
在此模式中，对应用程序团队的约束较少，但是随之而来的是责任的显著增加。必须具备更多技能以及潜在的团队成员，才能支持其他平台功能。如果缺乏相应技能且不能及早发现缺陷，则会增加大量返工的风险。
执行那些没有专门委托给应用程序团队的策略。您应使用能够跨账户集中治理环境的工具或服务，例如 [AWS Organizations](https://aws.amazon.com/organizations/)。[AWS Control Tower](https://aws.amazon.com/controltower/features/) 等服务扩展了这一管理功能，使您能够定义账户设置的蓝图（支持您的运营模式），使用 AWS Organizations 进行持续治理以及自动预置新账户。
为应用程序团队设定可请求添加和变更标准的机制，这作用很大。他们也许能够提出新标准，让其他应用程序团队也因此受益。平台团队可以决定，为这些附加功能提供直接支持是否是对业务成果的有效支持。
由于该模式具有重要技能和团队成员要求，因此限制了创新。它解决了团队之间由于任务转换所造成的诸多瓶颈和延迟，同时还促进了团队与客户之间有效关系的发展。
# 不断发展运营模式
提供的模式在工作负载级别上逐渐转向更多的自主权，符合双披萨团队原则。重要的是要明白，从传统方法到分散式 DevOps（作为持续演变为双披萨团队模式的基础）的旅程可能需要时间，并且需要在许多能力上建立成熟度。因此，我们提供了一个示例，说明随着您的团队和组织在企业转型之旅中前进，您如何在模式之间进行过渡。在每一次变更或每一种模式中，您在向一个更加自主但组织上仍然保持一致的团队发展。
![\[云运营模式从本地到自动化价值流和流程的演变图\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)
在评估团队如何支持组织变革时，请检查模式之间的权衡，您的各个团队在模式（随着模式的改变和发展）中的位置，您的团队的关系和职责可能如何变化，以及所获得的益处是否抵得过对您的组织产生的影响。请记住，变化从来都不是线性的。有些模式更适合特定的用例或旅程中的点，其中一些模式可能比环境中的模式更具优势。