DevOps 是一种不断发展的文化，而不是一个团队

关于 DevOps 的误解似乎越来越多。有时，它被理解为工程架构中的另一个团队。有时，它被理解为现有团队中的某个人（例如 DevOps 工程师）。但在我看来，这些观点都是错误的，并且没有抓住 DevOps 的本质。

DevOps 是一种文化，而非某个团队或个人。它由团队培育的一系列理念、流程和工具组成。它会不断发展，并非一成不变，因为团队和技术都在不断发展。

它打破了团队之间的壁垒，而不是制造新的壁垒。它让具有工程思维的人变得精通运营，反之亦然。两者融为一体。如果做得好，它可以改变一个组织和一个产品。

通过成为一个同质化单元，开发可以更快地进行。他们可以迭代其产品或服务，以更快的速度更好地满足用户需求。同时保持产品或服务的质量、交付和可靠性。

从外部来看，这听起来很复杂。

坦率地说，在“孤立”团队普遍存在的组织中，情况可能会非常复杂。在这种文化下，运营团队感觉自己的工作岌岌可危。开发团队则感觉被要求在现有工作的基础上做更多的事情。

这些文化中的问题比表面上看起来的要深得多。这些感受或信念往往源于对组织缺乏信任。有时，它们源于团队感觉与工作目标脱节。

无论如何，这些文化都需要重置，以便 DevOps 文化能够取而代之。

最简单的方法就是撕掉创可贴。在 DevOps 文化中，开发和运维之间的隔阂被打破，开发和运维不再被分割开来。很多情况下，这两个团队会合二为一。这意味着这个团队会负责整个应用程序的生命周期。从开发到部署，乃至更远的未来，这个团队对每个步骤都负有责任。

这可能会让人感觉非常混乱，就像重大流程变更时一样。但是，应对这种混乱的一个好方法是相信团队能够为他们做出正确的决策。没有什么比对负责过渡的人员缺乏信心和信任更能让这种变革失败得更快了。

通过将两个团队合并，可以在整个团队中建立强大的知识基础。运维人员可以分享他们在部署和监控方面的专业知识。开发人员可以分享他们在应用程序开发方面的专业知识。

这种知识共享通常会使流程自动化，从而减少流程中大量重复、手动且缓慢的任务。这种自动化加快了产品或服务的交付速度，同时也降低了与部署相关的摩擦。

DevOps 文化需要思维模式的转变。这些团队需要获得对其负责的系统和应用程序的控制权。团队掌控着系统的整个生命周期。因此，他们专注于快速迭代、频繁协作和持续改进。

这种完全所有权可减少低效率、加强反馈循环并提高可靠性。

看到一些组织和团队实施与 DevOps 理念相悖的流程，我感到很沮丧。一个团队或个人不应该对 DevOps 负责。

在我看来，这完全违背了 DevOps 的本质。它是一种整个开发团队共同遵守的文化。这种文化并非一成不变，而是随着团队成员的加入和技术的变革而不断流动和发展。

此外，不同组织，甚至不同团队，DevOps 的文化也会有所不同。这是因为一个团队或组织并非完全照搬另一个团队或组织。因此，你可以从其他人那里学习新的想法和概念，但这些想法和概念最终会融入到你的团队或组织中。

在 DevOps 原则支撑的文化中，能够实现真正的业务影响。紧密的反馈循环和相关的自动化使业务能够更快地迭代。更快的迭代意味着更快的决策，更快地将价值交付到用户手中。这些好处是实实在在的，但要获得这些好处，必须做好落地实施。

关注 DevOps 文化创造的好处和成果。

文化在发展，实现文化的流程也在发展，但这些好处才是你的北极星。这种协作旨在团结团队，共同实现业务成果。它打破壁垒，加快产品或服务的交付。

我们给这种快速可靠的迭代、加强协作和大量自动化的文化起了个名字。这个名字就是 DevOps，但实际上我们可以随便叫它什么。

关于 DevOps，需要牢记的重点是其原则以及它能帮你实现的切实好处。它并非针对另一个团队或某个人。它是团队共享的一种文化，它提倡主人翁意识、责任感，加强协作，加快迭代速度，并打破阻碍这些的障碍。

如果您正计划开启您的 AWS 之旅，但不知从何入手，不妨看看我的课程。我们专注于在 AWS 上托管、保护和部署静态网站。这将使我们能够在使用过程中学习超过 6 种不同的 AWS 服务。在您掌握基础知识后，我们将深入学习两个附加章节，涵盖更高级的主题，例如“基础设施即代码”和“持续部署”。