9 个 DevOps 最佳实践 - 你应该做什么和不应该做什么

       在过去十年中，利用 DevOps 实践来最大限度地提高速度和创造价值一直是软件行业的热门话题。我们已经接受了这些实践，并改变了我们工作和思考开发、运营、项目管理、代码质量、可观察性和持续反馈的方式。
随着组织开始应用这些实践，我们注意到出现了许多反模式。在本文中，我们将看到一些 DevOps 最佳实践和改进工作流程的方法，同时我们还将探讨一些典型的 DevOps 反模式以及如何避免它们。

       到目前为止，您可能已经看到了数百种不同的 DevOps 定义。对我来说，DevOps 是一套围绕软件开发生命周期的最佳实践，以及不断改进和更有效地交付价值的实践。

       在此基础上，DevOps 是一种在开发人员和运营人员之间平等传播的文化，而不是特定角色。实际上，该术语已被用作概括性术语，用于描述精通云计算的人的工程角色，他们分担开发人员和运维人员的痛苦和责任。同时，他们努力在组织内启用和推广 DevOps 实践。

       那么为什么要大惊小怪呢？实践证明，实施这些实践可以提高软件质量。不同的软件和运营团队更有效地协作，减少摩擦和交付时间，持续集成和测试他们的代码，并更频繁地部署。

       这一切都是为了找到我们工作流程中的低效率，并建立一种持续沟通和信任的文化。它的其他方面是处理故障和计划外工作，利用自动化，并重点关注可观察性以获得有意义的反馈。

       现在我们已经奠定了基础，让我们来探索一些 DevOps 的最佳实践。该列表不应该是详尽无遗的，而是包含提示和指导的指南，可以帮助您轻松采用健康的 DevOps 文化。

       首先，要使这一旅程取得成功，我们必须高度关注培养一种允许人们自由协作并消除对失败恐惧的文化。提倡信任和同理心等价值观的组织和团队在采用 DevOps 实践方面往往具有很大优势。打破团队之间的孤岛，让他们朝着一个共同的目标共同努力，为公司带来价值。

       Spacelift 是为 IaC 提供增强协作层的工具之一。在 Spacelift，您可以邀请安全和合规团队合作并批准工作流程和政策。

       经常将小批量代码集成到中央代码存储库是一种允许开发人员有效协作的做法。使用这种方法，存储库始终保持良好状态，因为我们引入了更易于处理的小更改。持续集成 (CI) 可以实现早期错误检测并提高代码质量，因为这些小批量更改每次都通过自动构建和测试进行验证。

       集成我们的代码后的下一步是将其部署到我们的环境中。持续交付 (CD) 是针对每小批量更改持续将代码置于可部署状态的做法。这简化了我们的部署，并为我们的开发人员提供了一种将代码推送到生产环境的简单自动化方法。

       上一点的延续和 DevOps 成功的一个组成部分是设置和策划有意义的自动化测试，作为我们 CI/CD 管道的一部分。这样，我们就不再依赖人类对我们的代码进行手动测试；取而代之的是，我们设置了在引入的每一个微小变化上运行的自动化测试。

       通过增加测试频率和测试数量，我们减少了将错误引入生产系统的机会。测试因用例而异，但通常可能包括单元测试、集成测试、端到端测试、负载测试、冒烟测试等。

        DevOps 实践基于获得反馈和不断改进我们的流程。我们需要找到并跟踪正确的指标来实现这一目标并衡量我们的结果。找出正确的指标是每个组织都必须经历的艰巨旅程。

       这些指标因组织和团队而异，具体取决于目标和所针对的关键结果。尽管如此，它仍然是取得成功的关键练习。DevOps 指标的一些典型示例是部署时间、部署频率、部署失败率、关键服务的可用性、 平均检测时间、平均恢复时间、 单位成本、代码覆盖率和更改提前期。

       向前迈出一步，我们还必须关注在生产中运行的应用程序和软件的可观察性。我们必须定义一种策略来有效地存储、管理和分发我们的应用程序的日志、跟踪和指标，以快速解决问题、提高系统的可理解性并让我们的团队高效运作。

       通过减少手动工作和自动化重复性任务，我们加快了流程并提高了结果的一致性。自动化可以让我们专注于重要的事情，避免人为干预。它还为我们的系统和流程提供了更多信心，消除了人为错误和沟通不畅，并提高了团队的绩效。

       安全性不应该是集成到软件开发中的最后一件事。DevSecOps 的诞生强调在开发生命周期的早期考虑应用程序和基础设施的安全性，将安全性纳入初始设计并将其集成到 CI/CD 管道中。

       安全性应该是不同团队和整个应用程序生命周期共同承担的责任，并且应该被视为流程的一个组成部分，而不是可选的附加组件。最近，由于过去几年恶意攻击的增加，人们将重点放在保护软件供应链上。

       在基础设施领域，即使是最微小的错误也可能导致严重中断。这就是为什么 Spacelift 添加了一个额外的策略层，允许您独立于您的基础设施项目来控制可以执行哪些代码、可以进行哪些更改、何时以及由谁来执行。这不仅有助于保护自己免受坏人的侵害，还允许您实现自动代码审查管道。

       在 IT 世界中，事件是不可避免的。你的团队准备得多么充分并不重要。最终，您将不得不解决一个事件。在这些情况下，必须专注于无可指责的沟通，了解问题，与受影响的各方进行有效沟通，并合作寻找解决方案。

       解决问题同样重要的是有一个过程来记录事件并从中学习。事件解决后，花一些时间与您的团队一起制定事件后审查，并讨论事件的处理方式。尝试在事件处理过程中找到任何可能的改进，以帮助您下次避免出现。

       DevOps 领域的发展速度非常快，每天都会出现新的工具和服务。与其不断集成新的闪亮工具和服务，不如专注于理解允许公司通过 DevOps 实践加速业务的核心概念。

       只有理解了这些概念并相应地优先考虑缺失的部分，您才能成功地为工作选择正确的工具。请记住，您将无法在团队中构建所有内容。在有意义的情况下，可以依赖 DevOps 工具和托管服务。明智地利用团队的时间，尝试了解您的内部专业知识和需求，在有意义的时候努力构建自定义工具，其余的依赖外部工具和服务。

       云基础设施应被视为软件开发的一个组成部分，并与应用程序代码同等对待。通过利用基础架构即代码，我们可以将我们用于软件开发的最佳实践（例如版本控制和 CI/CD）整合到基础架构创建中。该模型消除了通过 UI 手动设置和配置资源的需要，并进一步加强了我们在整个 IT 领域的自动化工作。更改始终是可审计且透明的，当出现问题时，我们可以快速将基础设施系统回滚到以前的状态。

       提前考虑一步，而不是增加等待云基础架构工程师创建必要资源的另一个瓶颈，推动自助服务基础架构模型。在此模型中，开发人员和任何需要基础设施资源的人都可以利用一些工具来生成所需的部分。通过这种方式，我们提高了生产力和速度，同时为我们的开发人员提供了自主权，所有这些都通过单一的工作流程实现。

       随着 DevOps 的兴起，我们也看到了许多反模式的出现。在寻求采用 DevOps 实践的过程中，人们误解了他们的范围并犯了导致常见反模式的错误。让我们看看公司在实施 DevOps 原则时面临的一些常见挑战、陷阱和误解。

       公司在采用 DevOps 实践时常犯的错误是创建一个单独的团队来处理 DevOps 转型。不幸的是，这给流程增加了一个孤岛，并打破了 DevOps 的核心承诺，即增加现有团队之间的协作和共享所有权。

       同样，我们看到运营团队更名为 DevOps 团队，而组织的文化、沟通和协作并未发生实际变化。DevOps 旨在拉近不同的团队，而不是创建一个新团队。

       有时，特定团队成员比其他成员更多地参与 DevOps 实践。这可能是由于积累的知识、更高水平的经验或一个人增加的努力。当这种模式出现时，它可能会迅速导致 DevOps 英雄反模式，在这种模式中，特定的团队成员对团队来说变得不可或缺。

       这种情况很成问题，因为团队的表现和速度取决于一个人。同时，此人可能面临大量工作，最终导致倦怠并可能离开公司。为避免这种反模式，请确保知识在团队和团队成员之间传播。平分工作，不靠英雄，靠团队合作和僵化的流程来取得成果。

       从头开始在组织中应用 DevOps 实践一开始可能会让人望而生畏。与大多数事情一样，试图一次解决所有问题并不是正确的方法。首先，分析公司内部的现状和流程。人们通常不会愉快地接受许多变化，因此您需要进行战略性思考。相应地确定任务的优先级，找到快速的胜利，自动化将产生更大影响的事情，并一次专注于一件事。

       随着几乎每天都会出现新的服务和工具，采用和使用这些闪亮的新玩具总是很诱人。工程师经常陷入引入新工具的陷阱，只是因为它在没有适当分析是否需要或最佳选择的情况下引入。

       为工作选择正确的工具是至关重要的，但也是一个应该仔细审查的过程。对于我们添加的每个新服务或工具，我们还应该考虑它的可维护性以及我们在此过程中引入的操作开销、依赖性、复杂性和新的认知负荷。

       由于 DevOps 成功的主要因素之一是速度，因此许多团队试图以牺牲质量和通常的安全性为代价来加快他们的流程。许多典型的 DevOps 指标是基于我们交付、部署和提供价值的速度，但它们本身还不够，因为它们只说明了一半。由于对速度的过度关注，很容易失去对重要事物的看法；交付高质量的软件。同等对待速度和质量，添加有意义的自动化测试，避免为了加快发货而偷工减料。

       应用有效的 DevOps 实践是一个动态的过程，应该持续进行管理。在实施路线图中的所有 DevOps 最佳实践之后，可能很想休息和放松，但不幸的是，这个过程永远不会停止。

       每一步，我们都应该专注于审查我们的工作流程并不断改进我们的系统、流程和产品。我们必须建立持续的反馈流程，使我们能够审查和反思我们的选择并最终改进。新的范式、最佳实践和改进的模型总是会出现，如果我们希望我们的团队生存、执行和成功，我们就应该焦躁不安。

       根据定义，DevOps 实践的成功采用依赖于在组织内有效地共享信息并创建一个有机地促进协作的工作场所。不幸的是，忽视文档和有效的信息共享是软件团队中经常出现的一种反模式。如果处理得当，文档对于开发人员来说可能是一个方便的工具。

       尝试将文档任务集成到团队积累工作中，并将文档视为组织内的一等公民。文档不是静态的，应该保持最新，始终如一地创建，并且任何需要它们的人都可以访问。

       我们探索了不同的 DevOps 最佳实践和范例，并分析了我们如何将它们结合起来以加速团队绩效和价值创造。我们还看到了一些隐藏的陷阱和反模式，在追求卓越 DevOps 时需要注意和避免。
       感谢您的阅读，我希望您和我一样喜欢这篇文章。