随着 DevOps 的采用不断加速，许多领导者都希望建立他们的 DevOps 卓越中心 (CoE)。 CoE 的作用是确保更广泛的公司看到 DevOps 的宝贵优势：创新、效率和降低风险。

随着混合和远程工作的持续趋势，同事之间的知识共享不太可能有机地发生，开发人员将默认使用他们喜欢的流程。组装 CoE 可以帮助应对这些挑战并促进 DevOps 的采用，但您应该避免这五个常见的陷阱。

1. 任务没有明确定义

必须在一开始就定义 CoE 的使命。如果没有对其目的的共同理解，CoE 将难以确定目标并发现自己需要证明其工作的合理性。

定义范围和结构很重要。在范围方面，请考虑以下问题：CoE 是简单地建立有效的方法，还是考虑对整个企业的 DevOps 工具进行彻底改革？ CoE 是否有具体目标，还是会更广泛地推动创新？

至于结构，一些企业专门设立了一个全职 CoE 团队，而另一些企业则聚集了来自不同团队的专家，他们合作改进 DevOps 流程。根据 DORA 关于 DevOps 状况的报告，后一种方法类似于实践社区 (CoP)，与传统 CoE 设置相比，它与 DevOps 成功的相关性更强。因此，我建议您的 CoE 尽可能多地借鉴 CoP 模型。

2. CoE 分离

打破 DevOps 团队之间的孤岛是 CoE 的一个关键目标。具有讽刺意味的是，一些 CoE 变成了一个额外的孤岛，并有可能与公司的其他部分分离。虽然构建 CoE 可以保证拥有一个致力于持续改进 DevOps 流程的团队，但找到一种方法来保持 CoE 与并行团队的集成可能很困难。

您的 CoE 可能会成为创新的瓶颈，通过提倡难以实施的理想化流程来拖慢其他团队的速度。通过让 CoE 继续处理现实世界的项目来避免这种情况，这样他们就可以适应整个公司团队使用的实际 DevOps 流程的细微差别。

3.无双向通信

卓越中心模型是关于点对点知识共享的。 CoE 可以为该模型提供结构和决定性，但需要开放的沟通渠道可供其他团队使用，以便将他们的见解和反馈传递给 CoE。

CoE 应创建正式结构以主动获取洞察力。在我公司提供咨询的一些企业中，CoE 会定期审核整个企业的其他团队。审计确定以下内容：

• 团队正在使用哪些工具和流程
• 每个团队维护的环境的利益相关者是谁
• 团队在 DevOps KPI 方面的表现如何（例如发布节奏和提前期）

此数据可帮助 CoE 确定整个组织的最佳实践，而不仅仅是来自 CoE 本身。通过结合每个团队流程的最佳部分，并形成一致的方法，CoE 得出了一个可以在整个企业中共享的流程，并通过数据驱动的分析来证明其合理性。

4. 不准备管理内部政治

没有团队喜欢改变它使用的工具和流程。那些负责设立 CoE 的人应该准备应对内部政治和变革阻力。

鉴于 CoE 的目的是建立和支持最佳实践，不应允许单个团队的偏好影响决策过程。如果发现他们的工具和流程比其他团队更成功，也不应将其视为一个团队的胜利。

在组建 CoE 时，从整个公司的团队中抽取人员是一个好主意。反映组织构成的 CoE 能够更好地处理转型可能引发的潜在争议。

5. 未能衡量影响并证明投资回报率

与任何其他团队一样，CoE 需要展示 ROI，以帮助关键决策者了解它对业务的贡献。否则，管理层可能会削减 CoE 的预算。

为了支持成熟 DevOps 流程的价值，CoE 应该很好地理解需要跟踪以证明成功的关键指标。例如，CoE 应该能够表明发布正在加速并阐明提高敏捷性的业务价值。他们应该能够强调代码质量正在提高，并计算重构或维护不良代码所避免的成本。 CoE 必须表明其工作的投资回报率如何保证进一步投资。

促进协同创新

高性能 CoE 所需的专业知识通常存在于分散在不同团队中的大型企业中。如果您避免了导致 CoE 表现不佳的陷阱，那么将这些专业知识汇集在一起​​，并让团队负责寻找创新的 DevOps 解决方案，这将是很有价值的。

原文：https://www.informationweek.com/devops/pitfalls-to-avoid-when-setting-u…

本文：https://jiagoushi.pro/node/1679