你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

云卓越中心 (CCoE) 功能

  • 项目

许多 IT 组织都具有实现业务和技术敏捷性的核心目标。 云卓越中心 (CCoE) 是一种功能，可帮助组织在追求这一目标的同时平衡速度和稳定性。

功能结构

CCoE 模型需要以下每个资源之间的协作：

  • 云采用（解决方案架构师）
  • 云策略（计划和项目经理）
  • 云治理
  • 云平台
  • 云自动化

效果

如果正确构造和支持此功能，则参与者可以加速创新和迁移工作，同时降低更改的总体成本并提高业务敏捷性。 成功实现后，此函数可以及时生成明显减少市场。 随着团队实践的成熟，包括可靠性、绩效、安全性、可维护性和客户满意度在内的质量指标将会提高。 如果公司计划实施大规模云迁移工作，或者希望利用云推动与市场差异相关的创新，这些效率、敏捷性和质量的提高尤其重要。

如果成功，CCoE 模型将在 IT 运营中带来重大转变。 在 CCoE 方法中，IT 充当业务的中转站、合作伙伴或代表。 此模型是将 IT 视为业务和 IT 资产之间的操作单元或抽象层的传统观点的一种范式转变。

下图提供了此变化的一个类比。 如果不使用 CCoE 方法，IT 通常侧重于提供控制和中心责任，其作用类似于十字路口的交通信号灯。 如果成功实现 CCoE，则 IT 的角色将类似于十字路口的环岛，侧重于自由和委托责任。

Diagram that shows an analogy for a C C o E paradigm shift.

这两种方案都是有效的；它们体现了责任和管理的替代观点。 如果你想要建立自助服务模型，使业务单位在遵守一系列准则和既定的可重复控制措施的同时做出自己的决策，CCoE 模型可以适应技术策略。

主要职责

CCoE 团队的主要职责是通过云原生解决方案或混合解决方案加速云采用。

CCoE 的目标是：

  • 使用敏捷方法捕获和实施业务需求，帮助构建现代 IT 组织。
  • 使用与安全性、符合性和管理策略一致的可重复使用的部署包。
  • 维护与操作程序一致的功能正常的 Azure 平台。
  • 审核并批准云原生工具的使用。
  • 随着时间的推移，标准化和自动化通常需要的平台组件和解决方案。

会议节奏

请务必允许有机协作并通过通用存储库或解决方案目录跟踪增长。 最大限度地增加自然互动，但尽量减少会议。 定期会议（例如云采用团队托管的发布会议）可以提供数据输入。 但是，在此函数成熟后，请尝试限制专用会议。 共享每个发布计划后主持会议可以为此团队提供最低接触点。

解决方案和控制

CCoE 的每个成员都需要了解导致当前 IT 控制的必要约束、风险和保护。 CCoE 将这种了解转变为云原生（或混合）解决方案或控制，从而实现自助服务业务成果。 创建解决方案后，这些解决方案以控制或自动化流程的形式与其他团队共享，这些控制或自动化流程充当各种工作的防护措施。 这些护栏有助于指导团队活动，并将责任委托给迁移或创新工作的参与者。

下表介绍了此转换的一些示例。

方案 CCoE 前解决方案 CCoE 后解决方案
在生产环境中预配 SQL Server 实例 网络、IT 和数据平台团队在几天或几周内预配组件。 要求服务器部署平台即服务（PaaS）实例Azure SQL 数据库的团队。 或者，部署可以将预批准的模板用于所有基础结构即服务（IaaS）资产（以小时为单位）到云。
预配开发环境 网络、IT、开发和 DevOps 团队就规范和部署环境达成一致。 开发团队定义自己的规范，并根据分配的预算部署环境。
更新安全要求以改进数据保护 网络、IT 和安全团队在多个环境中更新网络设备和虚拟机（VM），以添加保护。 使用云治理工具更新可立即应用于所有云环境中的所有资产的策略。

协商

持续的协商过程是 CCoE 工作的基础。 CCoE 团队与现有 IT 职能部门协商以减少中心控制。 在此协商中，对业务的权衡是自由、敏捷性和速度，而现有 IT 团队的权衡价值以新解决方案的形式提供。 新解决方案为现有 IT 团队提供了以下一项或多项好处：

  • 能够自动执行常见问题
  • 随着日常挫折感的减少，保持一致性的改进
  • 学习和部署新技术解决方案的机会
  • 降低高严重性事件（需要更少的快速修复或深夜寻呼响应）
  • 能够扩大其技术范围并解决更广泛的主题
  • 参与更高级别的业务解决方案，解决技术的影响
  • 减少琐碎的维护任务
  • 提高技术策略，增加自动化

作为这些好处的交换，现有 IT 职能部门可能会交换以下价值：

  • 从手动审批流程中获得控制感
  • 从变更控制中获得稳定感
  • 通过完成必要的重复性任务获得作业安全感
  • 通过遵循现有 IT 解决方案供应商获得一致性的感觉

在运营正常的转向云的公司中，此协商过程是对等方和合作 IT 团队之间的一种动态对话。 技术细节可能很复杂，但在 IT 了解目标并且支持 CCoE 工作时是可管理的。 如果 IT 支持力度不够，以下关于支持 CCoE 成功的部分可以帮助克服摩擦。

支持 CCoE 成功

在继续了解此模型之前，请考虑公司对成长型思维的容忍度，以及 IT 对释放中心责任的舒适度。 如前所述，CCoE 将控制交换为敏捷性和速度。

这种改变需要时间、试验和协商。 在此过程中会有一些坎坷和挫折，但如果团队继续努力、不对试验感到气馁，那么提高敏捷性、速度和可靠性的可能性则非常高。 最大的成功因素之一是来自领导和关键利益干系人的支持。

关键利益干系人

IT 领导是第一位也是最明显的利益干系人。 IT 经理起着重要作用，但实施此模型需要 CIO 和其他高管级别的 IT 领导者的支持。

不太明显的是需要业务利益干系人。 业务敏捷性和上市时间是形成 CCoE 的主要动机。 因此，关键利益干系人在这些领域具有既得利益。 业务利益干系人的示例包括业务线领导人、财务主管、运营主管和业务产品所有者。

业务利益干系人的支持

来自业务利益干系人的支持可以加速 CCoE 工作。 CCoE 工作的大部分重点都集中在对业务敏捷性和速度做出长期改进上。 定义当前操作模型的影响和改进的价值作为 CCoE 的指南和协商工具很有价值。 建议在文档中建立或明确定义以下项目，以提高对 CCoE 的支持：

  • 预期的业务成果和目标。

  • 当前的 IT 流程难题，例如速度、敏捷性、稳定性和成本挑战。

  • 这些痛点的历史影响，如市场份额损失、特性和功能方面的竞争对手收益、客户体验不佳和预算增长。

  • 受当前难题和运营模式阻碍的业务改进机会。

  • 与这些机会相关的时间线和指标。

这些数据点不是对 IT 的攻击。 相反，他们帮助 CCoE 团队从过去学习，建立现实积压工作，并计划改进。

利益干系人的持续支持和参与

CCoE 团队可以在一些领域展示快速回报，但更高级别的目标（如业务敏捷性和上市时间）可能需要更长的时间。 在成熟期间，CCoE 团队可能会感到沮丧，或者让成员们专注于其他 IT 工作。

在 CCoE 工作的第一个六到九个月，我们建议业务利益干系人每月与 IT 领导和 CCoE 会面。 这些会面几乎不需要正式的仪式。 仅仅提醒 CCoE 成员及其领导此计划的重要性，就可以大大促进 CCoE 的成功。

我们还建议业务利益干系人随时了解 CCoE 团队遇到的进度和阻塞问题。 他们的工作可能看起来像技术细节，但业务利益干系人需要了解计划的进度，以便可以在团队失去动力或被其他优先事项分散注意力时参与进来。

IT 利益干系人的支持

IT 利益干系人的支持应包括以下活动：

  • 支持愿景：成功的 CCoE 工作需要与现有 IT 团队成员进行大量的协商。

    如果做得好，所有 IT 都可促成解决方案，并对变化得心应手。 有时，现有 IT 团队的一些成员可能希望保持控制机制。 出现此类情况时，IT 利益干系人对 CCoE 的支持对于 CCoE 的成功至关重要。 IT 利益干系人需要鼓励和加强 CCoE 的总体目标，以解决解决适当谈判的障碍。 在极少数情况下，IT 利益干系人甚至可能需要介入并打破僵局或关联投票，以维持 CCoE 的进展。

  • 保持专注：CCoE 可以是对任何资源受限的 IT 团队的一项重要承诺。

    将强大的架构师从短期项目中移除以专注于长期获益，可能会给不属于 CCoE 的团队成员带来困难。 IT 领导和 IT 利益干系人需要专注于 CCoE 的目标。 IT 领导和 IT 利益干系人的支持可以降低日常运营中断的优先级，从而支持 CCoE 职责。

  • 创建缓冲区：CCoE 团队试用新方法。

    一些新方法与现有操作或技术约束不一致。 CCoE 团队在实验失败时可能会遇到来自其他团队的压力或追索。 必须鼓励和缓冲 CCoE 团队免受“快速失败”学习机会的后果的影响。 同样重要的是，让团队负责成长型思维模式，以确保他们从这些实验中学习，并找到更好的解决方案。

后续步骤

CCoE 模型需要云平台功能和云自动化功能。 下一步是对齐云平台功能。

云平台函数