弥合差距：DevOps 沟通的重要性

尽管 DevOps 方法已经存在了很长一段时间，但它仍然是激烈讨论的中心。 公司想要它，但不确定如何处理它。

DevOps 无处不在。 虽然这是一个有趣的趋势，但它应该适合产品，而不是相反。

但有些人不这么看。 我经常被问到诸如“你认为我们应该开始使用 Docker，还是直接跳入 Kubernetes？”之类的问题。 甚至不知道产品是关于什么的，这样的问题是毫无意义的。

所有这些花哨的术语——云、Kubernetes、容器、配置管理、基础设施即代码——都有望得到一些改进。 但它们之于 DevOps 就像望远镜之于天文学一样。 它们可能有用，但不是必需的。

DevOps 的核心旨在缩小客户订购的内容与开发团队交付的内容之间的差距。 重点是短发布周期、迭代设计方法和重复步骤的自动化。 您认为将这些变为现实最重要的是什么？

如果您说“良好的沟通”，那您是对的。 工具都很好。 但只有当他们改善沟通时，他们才值得投资于他们的钱。

沟通的一个方面是知道完成工作需要什么。 这项工作并不意味着“将代码提交到存储库”。 可以把它想象成“客户看到了生产中的变化并接受了它”。

一旦确定了第一步，并且每个人都知道需要发生什么，那就是写下来的最佳时机。 在哪里？ 好吧，我是维护README.md的忠实拥护者。 团队中的每个人都可以随时窥视并了解项目的状态，这对于项目新手来说是自然而然的选择。

编写自述文件后的下一步自动化是可选的。 不过，这是记录过程的自然产物。 是的，在考虑 DevOps 时，经常会想到自动化。

等一下……对于 DevOps，自动化是可选的吗？ DevOps 不是部署人员的部门吗？

人们通常在“DevOps 工程师”一词下所理解的，要么是软件可靠性工程师、平台工程师，要么是运维自动化工程师。 这些都是能够实践 DevOps 的有效角色，但使用“DevOps 工程师”这个统称可能有点含糊。

因此，让我们仔细看看 DevOps 本身。

DevOps 解释

首先，让我向您展示 DevOps 不是什么：

1. 它不仅仅是一个职位前缀
2. 它不是一个团队（但“Dev”和“Ops”是）
3. 这不是一项技术
4. 这并不意味着“可以编码的系统管理员”
5. 这并不意味着“自动化的东西”
6. 这并不意味着“现在没有运营团队”

了解了这一点，您现在意识到您不能简单地在公司中“聘请 DevOps 工程师”或“创建 DevOps 团队”以确保您能够适应未来。 DevOps 类似于敏捷开发。 您会雇用这样的敏捷开发人员吗？ 可能不是。 您要么以敏捷的方式开发产品，要么不这样做。

那么如何描述 DevOps？ 这是一种方法论。 或者也许是一种文化。 甚至可能是一种精神。 根据 DevOps 原则做产品意味着每个人——无论是开发人员、运营工程师还是产品经理——都有一个共同的愿景，并通过沟通来维护它。 在较小程度上，这也意味着每个人都使用相同的工具。 这些工具并非旨在帮助任何单一群体。 它们旨在推动产品向前发展。

采用这个概念需要认真改变思维方式，这是主要障碍。 这是为什么？ 这是因为人们必须走出自己的舒适区，开始与具有不同能力的人合作。 开发人员突然需要了解云的工作原理并开始部署自己的代码。 操作人员需要放弃手动设置并开始编码。 每个人都需要学习新概念。 每个人都有新的责任。

这并不容易，但通过良好的沟通和共同的目标，这是可以实现的。 这种沟通涉及建立文化、建立轻量级流程和维护适当的文档。

DevOps 自动化是文档

你可能从来没有这样想过。 但是大多数通常与 DevOps 相关的工具都是文档工具：

• 为可读性而编写的构建脚本用于记录构建过程
• 持续集成管道记录集成过程，从构建单个部件到整个产品
• 通过记录如何部署您的客户可以使用的产品，持续部署管道走得更远
• 配置管理文件记录了安装和配置的过程
• 基础设施即代码规范记录了必要的基础设施（实际上非​​常正式！）
• 容器带有自己的Dockerfile记录如何构建和配置给定的微服务

所有这些花哨的概念基本上只做一件事：它们通过记录流程帮助团队成员更好地沟通。 这些过程可以手动运行或自动运行。 重要的是项目中的每个利益相关者都能够跟随他们。

将您的流程记录为代码与通常的说明手册相比具有一大优势。 代码可以被验证并具有预测性。 给定相同的输入，它会产生相同的输出。

有了书面说明，您就会有与读者一样多的解释。 如果您编写模棱两可或含糊不清的文档，阅读它的人将填补空白。 关键是，您无法控制间隙中的内容。

使用代码要简单得多。 如果没有具体步骤，程序将停止运行。 这些具体步骤是 DevOps 沟通的一个关键方面。

DevOps 沟通：弥合开发和运营之间差距的唯一途径

在《凤凰计划》一书中，我们见证了一位负责部署一个大项目的最近晋升的经理所面临的问题。 由于没有人知道发生了什么，每个人都在灭火，但进展不大。 书的副标题提到这是一个关于 DevOps 的故事。 我同意这一点。

但有趣的是，在本书的整个过程中，没有介绍一个新工具。 您能否仅通过改善沟通来达到 DevOps 的状态？ 这本书的主角做到了，所以你也有希望！

尽管主角的方法可能被认为是“老派”（使用实际的纸卡而不是适当的错误跟踪系统），但只有当所有相关方开始相互交谈时，情况才会开始好转。

您可能认为只有通过在开发和运营之间创建更好的接口（例如服务级别协议或事件积压）来改善开发和运营之间的协作。 但事实恰恰相反。 通过拆除界面并引入同理心和共同事业，您将拥有一个朝着共同目标努力的团队。

DevOps 团队结构：谁在团队中？

理想情况下，每个产品应该只有一个团队：产品团队。

我曾经在一个开发团队中，与其他团队没有共同目标。 开发团队希望推动尽可能多的变化。 验证团队的任务是防止引入缺陷。 他们有不同的经理，他们被单独评估。

结果？ 开发和验证与缺陷报告打乒乓球。 当验证发现一个无法通过的测试时，开发人员更感兴趣的是发现测试代码本身的缺陷，而不是试图让自己的代码没有错误。

当然，发布周期急剧膨胀，因为正确填写报告、反报告等需要大量开销。 大多数人似乎没有意识到，在产品方面，两个团队应该有一个共同的目标，并共同努力实现它。 但是缺乏适当的合作和筒仓心态使得它很难被注意到。

与废物作斗争是共同努力

启发敏捷软件开发宣言（又将我们介绍给 DevOps）的精益生产心态是关于消除浪费。 我们所说的浪费是指与客户订购的东西没有直接关系的所有东西。 堆积的在制品是一种浪费。 没有明确导致释放的过程的每一步都是浪费。

但浪费只能从高处看。 在一个团队的范围内，一些程序似乎是必不可少的。 但是，从产品的角度来看，它们很可能毫无用处。

要弄清楚哪些努力被浪费了，您必须联合起来并考虑已发货产品的生命周期。 您还需要从客户的角度思考。 这个功能是客户想要的吗？ 如果没有，你也可以在这个时候跳过它。 您的流程简单且精益吗？ 更深入地研究那些跨越团​​队界限的人。

您想确保产品的开发尽可能高效吗？ 邀请一个局外人看看你是如何工作的。 不属于您团队的人将能够提出有见地的问题并发现需要改进的新领域。

DevOps 原则：保持冷静

CALMS 非常准确地描述了应该如何实践 DevOps：

• 文化
• 自动化
• 精益
• 测量
• 分享

请注意，它的形状像三明治。 三个中间值更具技术性，而外部值与软技能有关。 但所有文化的基础是沟通：我们与其他团队成员交换我们的价值观和信念，直到我们就事情应该如何表现达成共识。

分享也是一样。 分享食物等基本的东西不需要交流。 然而，手势本身也可以被视为一种交流行为。 “我在乎你，所以我分享给你。” 我们不想将范围仅限于口头交流。

然而，分享想法和工具需要沟通。 我们应该如何分享它们？ 我们应该把它们放在哪里？ 它们对团队中的每个人有用还是只对较小的群体有用？

如果您只关注更技术性的方面——自动化、精益和测量——你就错过了 DevOps 的重点。 拥有一个除了作者之外没人使用的自动部署脚本有什么好处？ 如果脚本为她节省了一些时间，那么它可能是合理的。 但是想象一下，如果每个人都共享这个脚本，可以节省多少时间。 这说明了与浪费作斗争！

DevOps 让业务更接近发展

有人说 DevOps 使运营更接近开发。 这是事实，但不是全部事实。 如果做得好，DevOps 会让每个单元更接近。 它允许企业和客户几乎实时地看到开发正在做什么。

这种更短的反馈循环有益于所有利益相关者。 这项工作通常更加明显，开发人员也可以轻松地看到客户如何使用他们生成的代码。 使用传统部署，您可以等待几个月才能有人注意到错误或遗漏的需求。 通过持续部署，每个人都可以对出现的任何问题做出反应。 开发人员、运营人员、业务人员和客户可以坐在一个房间里，根据当前需要修改工作应用程序。

DevOps 工具优先？ 再想一想

当然，需要所有工具来实现它。

但是，任何工具都无法替代公司内部的良好沟通和同理心。 我曾经观察过一个产品，其中构建过程归一个团队所有，而提供的代码归另一个团队所有。

构建系统的问题很常见。 开发人员不确定如何使用它。 它基于标准工具，但它们经过定制，以至于网络上可用的每个文档都被证明是无用的。

每个人都想改善情况，但两支球队之间没有任何默契。 这意味着双方在没有与对方协商的情况下引入了新工具。 这只会扩大差距，而不是缩小差距。

如果您想在组织内开始 DevOps 转型，请从改进沟通方式开始。 不要简单地假设解决方案：首先以开放的心态进行头脑风暴。 然后您可能会发现，例如，工具支持不足以满足您的需求。 那时您可以考虑调整您当前的工具或引入一些新的工具——否则您可能会增加原来的问题。

建立 DevOps 的最快方法？ 更好的沟通！

在介绍中，我提到了客户经常问我的问题：“我应该使用 Docker 还是应该直接跳到 Kubernetes？” 阅读本文后，您可以看到，在做一些准备工作之后，最好以 DevOps 的心态回答这样的问题。

如果您知道您的产品团队了解 DevOps 对自己和客户的好处，那么团队和客户可以从设定他们的期望开始。 然后工程师可以弄清楚开发和部署模型。 最后，您可以确定需要哪些工具。

一旦记录了所有需求，就更容易做出技术选择。

我是所有伟大的 DevOps 自动化工具的拥护者，这些工具使我们的工作更轻松、更易于管理。 但我们的日常工作是与人打交道。 让我们花一些时间来改进 DevOps 最佳实践的这一方面，而不是获得另一个技术证书。