要在团队中推动 DevOps 实践落地，一个良好的 DevOps 服务层必不可少。本文总结了构建 DevOps 服务层需要关注的要点和常见的错误。原文：Five DevOps AntiPattern and How to Avoid Them[1]
如今几乎每个开发人员都在为某个已经实施了 DevOps 或者正在致力于推动 DevOps 战略的项目或公司工作，但我们在实施 DevOps 的时候，经常做错一些最基本的事情。本文解释了以错误的方式实施 DevOps 时的五种反模式。
什么是 DevOps
DevOps 是开发和运维的结合，目标是使软件团队可以在整个应用程序生命周期中独立的开发和运行他们的软件，如下图所示。
DevOps 应用程序生命周期：计划，开发，构建，测试，发布，部署，监控，反馈-迭代
人们普遍认为 DevOps 团队积累了大量运维知识来帮助运行应用程序，但事实却与此相反，他们依赖各种服务帮助管理应用程序的运维，这些服务由各领域专家实现，专门为了简化 DevOps 团队的应用程序运维而构建。
服务层
这些服务构建在特定的基础设施或其他软件之上，并提供易于访问的抽象。服务可以是运行应用程序的数据库即服务(Database as A service, DBaaS)、平台即服务(Platform as A service, PaaS)等。下图展示了 DevOps 团队如何从服务层使用服务，通过提供开箱即用的解决方案来简化他们的工作。
服务层为软件开发团队提供服务——软件开发团队可以使用服务来管理整个软件生命周期
应用程序的开发人员使用服务，被称为服务使用者，服务层的开发人员提供服务，被称为服务提供者。
反模式 1：服务层不是自助服务层。
假设服务层需要它的消费者与某人或某物取得联系，在这种情况下，引入的依赖关系会减缓开发流程，浪费使用者和提供者的时间，因为最好将其自动化。
在 DevOps 团队中，更少的依赖会带来更高的生产力！
为了提高效率并使服务层能够扩展，有必要在整个过程中提供自助服务功能。这样，使用者就可以独立使用服务，而无需等待或依赖于服务提供者。
反模式 2：使用者需要知道服务实现的技术细节才能使用它。
如果人们想要使用特定服务，不应该需要知道它的技术规范。例如，如果消费者需要知道服务层引入了新的语言或框架，那就会增加 DevOps 团队所需的知识。而由于团队需要在核心技术栈和服务层的其他语言、框架之间切换，这将降低人们的工作效率。如果配置不能通过服务接口快速完成，那么就需要记住大量的技术知识。
抽象的技术实现，让服务易于使用！但只是将不相关的复杂性进行抽象，而不会影响到重要的功能。
消费者也是特定应用程序的开发人员，他们知道自己应用程序的技术栈，并且是这个领域的专家。如果他们使用来自第三方的服务，技术实现必然与他们无关。当然，他们需要知道服务以及它是如何工作的，但是实现细节并不相关。
反模式 3：对消费者而言，服务不够一目了然。
如果不够一目了然，那么这个服务要么不会被使用，要么使用者需要联系提供者以获得所需的信息。和人的接触会大大减缓使用过程。既浪费了时间，又浪费了金钱。
记住，消费者不是专家！
为了提供更好的消费体验，服务应该是一目了然、不言自明的。通过创建一个向导来描述必要的步骤，或者提供内置在服务接口中的步骤指南。同时，倾听消费者的诉求。反馈很关键，消费者和提供者之间的工作反馈循环是高质量服务层的支柱。
反模式 4：开发人员不知道服务存在或找不到它。
营销是关键！作为供应商，你的工作是向消费者宣传你提供的产品以及告诉他们如何消费这些产品。提供包含消费者所需的所有信息的完整的服务中心、最新的概述，提供订阅功能，从而使新信息也成为自助服务，从而能够自动通知消费者关于更改或新版本的信息。
博客文章是描述和介绍服务层的新服务并更深入的解释它们的好方法。
如果服务不为人知，就不会被使用。
如果你有一个大型服务层，组织定期的谈话或小型的活动，让消费者了解最新的新闻和功能。
反模式 5：在服务层中没有版本控制。
如果没有实现版本控制，那么当新版本发布时，所有使用者都必须立即切换到新版本，这既不稳定也不安全。要提供安全的环境，请确保支持服务层的旧版本，直到所有使用者都切换到新版本。一旦旧版本不再使用，提供者可以安全的删除它。
始终以新版本提供服务的变更，同时继续维护旧版本的服务！
不要强迫用户立即切换到更新的版本，这将使得他们不得不做不能为应用程序提供额外价值的事情，而这可能会阻止某些更重要的更改。
看看语义版本控制[2]，学习如何使用版本号来提供一个自我解释的结构，并自动描述实现的更改。Semver.org 将其描述为:
“给定某个版本号 MAJOR.MINOR.PATCH：
- 当你做出了无法兼容的 API 变更时，递增 MAJOR，
- 当你增加了支持后向兼容的功能时，递增 MINOR，
- 当你做出了支持后向兼容的问题修复时，递增 PATCH。” — semver.org
结论
不完备的服务层实现只会让事情变得更糟，会让公司离高效、高质量和令人满意的 DevOps 组织的目标更远。
因此，如果你正在构建 DevOps 基础设施，请确保你的服务层……
- …是一个自助服务层。
- …提供使用简单的功能。
- …为用户抽象技术细节。
- …在 DevOps 团队中是众所周知的。
- …有一个适合大多数用例的默认配置，但在必要时可以更改。
References:
[1] https://medium.com/geekculture/five-devops-antipattern-and-how-to-avoid-them-c5b3dfcabe20
