尽管DevOps方法已经伴随我们很长时间了, 它仍然是激烈讨论的中心. 企业想要它，但不确定如何接近它.

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

但有些人不这么认为. 我经常被问到这样的问题, “你认为我们应该开始使用Docker吗?, 或者直接跳转到Kubernetes?“在不知道产品是关于什么的情况下，这些问题毫无意义.

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

其核心是, DevOps的目标是缩小客户订购的产品和开发团队交付的产品之间的差距. 它强调较短的发布周期, 迭代设计方法, 重复步骤的自动化. 你认为实现这些目标最重要的是什么?

如果你说“沟通很好”，你是对的. 工具都很好. 但是，只有当它们改善了沟通时，它们才值得投资.

沟通的一个方面是知道完成工作需要什么. 而且这项工作并不意味着“将代码提交到存储库”.不妨这样想:“客户看到了产品中的变化，并接受了它。.”

只要这第一步确定了, 每个人都知道该怎么做, 这是写下来的最好时机. 在哪里? 我非常支持维持 自述.md. 团队中的每个人都可以随时查看内部并了解项目的状态, 对于项目新人来说，这是一个很自然的选择.

编写自述后的下一步是自动化，这是可选的. 不过，这是记录这一过程的自然结果. 是的，在考虑DevOps时，自动化经常会出现在脑海中.

等一下，谈到DevOps，自动化是可选的? DevOps不就是负责部署的部门吗?

人们通常对“DevOps工程师”一词的理解是 软件可靠性工程师平台工程师或操作自动化工程师. 这些都是能够实践DevOps的有效角色, 但是使用“DevOps工程师”这个统称可能有点模棱两可.

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

DevOps解释

首先，让我告诉你DevOps不是什么:

1. 这不仅仅是 工作头衔前缀
2. 这不是一个团队(但“开发”和“运维”是)。
3. 它不是 一个技术
4. 它的意思不是“会写代码的系统管理员”
5. 它的意思不是"自动化的东西”
6. 这并不意味着“现在没有运营团队”

知道了这一点, 你现在意识到，你不能简单地在公司里“雇佣一个DevOps工程师”或“创建一个DevOps团队”来确保你是面向未来的. DevOps类似于敏捷开发. 你会雇佣敏捷开发人员吗 像这样? 可能不是. 你要么用敏捷的方式开发产品，要么不用.

那么如何描述DevOps呢? 这是一种方法论. 或者 文化. 甚至可能是鬼魂. 根据DevOps原则开发产品意味着每个人——包括开发人员, 操作工程师, 或者产品经理——拥有共同的愿景, 通过沟通来维护. 在较小程度上，这也意味着每个人都使用相同的工具. 这些工具并不是为了帮助任何一群人. 它们的目的是推动产品向前发展.

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

这并不容易，但如果有良好的沟通和共同的目标，这是可以实现的. 这种沟通包括建立一种文化, 设置轻量级流程, 保持适当的文件记录.

DevOps自动化是文档

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

• 构建可读性强的脚本 用于记录构建过程
• 持续集成管道 记录集成过程，从构建单个部件到构建整个产品
• 持续部署管道 进一步说明如何部署客户端可以使用的产品
• 配置管理文件 记录安装和配置过程
• Infrastructure-as-code规格 记录必要的基础设施(事实上，相当正式)!)
• 集装箱随附 他们自己的 Dockerfiles 该文档描述了如何构建和配置给定的微服务

所有这些奇特的概念基本上都在做一件事:它们通过记录流程来帮助团队成员更好地沟通. 然后可以手动或自动运行这些流程. 重要的是，项目中的每个利益相关者都能够遵循它们.

将过程记录为代码比通常的说明手册有一个很大的优势. 可以对代码进行验证并预测其行为. 给定相同的输入，它产生相同的输出.

有了书面说明，你就会有和读者一样多的解释. 如果你写的文件模棱两可或含糊不清，阅读它的人会填补空白. 重点是，你无法控制空隙里的东西.

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

DevOps沟通:弥合开发和运维之间鸿沟的唯一途径

在书中 凤凰计划 我们目睹了一位最近被提拔的经理负责部署一个大项目时遇到的问题. 由于没有人知道发生了什么，每个人都在灭火，没有多大进展. 这本书的副标题提到这是一个关于DevOps的故事. 我同意这一点.

但有趣的是在这本书的整个过程中, 没有一个新工具被引入. 你能仅仅通过改善沟通就达到DevOps的状态吗? 书中的主人公都做到了，所以你也有希望!

尽管主角的方法可能被认为是“老式的”(使用真正的纸质卡片而不是适当的漏洞跟踪系统)。, 只有当所有相关方开始相互交谈时，事情才会开始好转.

您可能认为只有通过在开发和运维之间创建更好的接口才能改善它们之间的协作, 比如服务水平协议或事件积压. 但事实恰恰相反. 通过拆除界面，引入同理心和共同的事业, 你将拥有一个朝着共同目标努力的团队.

DevOps团队结构:谁在一个团队中?

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

我曾经在一个开发团队中，那里没有与其他团队的共同目标. 开发团队想要推动尽可能多的更改. 验证团队的任务是防止引入缺陷. 他们有不同的管理者，他们被单独评估.

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

发行周期迅速膨胀, 当然, 因为正确填写报告需要大量的开销, 的counter-reports, 等等....... 大多数人似乎没有意识到的是，就产品而言, 两个团队应该有一个共同的目标，并共同努力实现它. 但缺乏适当的合作和竖井心态使它很难被注意到.

反对浪费需要共同努力

启发《欧博体育app下载》(这反过来又把我们引入了DevOps是关于对抗浪费的. 所谓浪费，我们指的是与客户订购的东西没有直接关系的所有东西. 成堆的未完工作是一种浪费. 没有明确导致发布的过程的每一步都是浪费.

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

要弄清楚哪些努力是浪费的，你必须联合起来，考虑已交付产品的生命周期. 你还需要从客户的角度考虑问题. 这个特性是客户想要的吗? 如果没有，你最好在这个时候跳过它. 你的流程简单和精益吗? 深入研究一下那些跨团队的项目.

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

DevOps原则:保持冷静

CALMS非常准确地描述了一个人应该如何实践DevOps:

• Culture
• Automation
• Lean
• Measurement
• S哈林

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

分享也是一样. 分享一些基本的东西，比如食物，不需要交流. 然而，这个手势本身也可以被视为一种交流行为. “我关心你，所以我和你分享.“我们不想把范围局限于口头交流.

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

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

DevOps使业务更接近开发

有人说DevOps使运维更接近开发. 这是事实，但这不是全部事实. 如果做得好，DevOps可以拉近每个单元的距离. 它允许业务和客户几乎实时地看到开发正在做什么.

这种较短的反馈循环使所有利益相关者受益. 工作通常更容易被看到, 和开发人员, 太, 可以很容易地看到客户端如何使用他们生成的代码. 使用传统部署, 您可以等待几个月，直到有人注意到bug或遗漏的需求. 通过持续部署，每个人都可以对出现的任何问题做出反应. 开发人员, 操作, 业务, 客户可以坐在一个房间里，根据当前需求修改工作应用程序.

首先是开发运维工具? 再想想

当然，这需要所有的工具来实现.

但是，再多的工具也不能取代公司内部良好的沟通和同理心. 我曾经观察过一个产品，其中构建过程由一个团队拥有, 而提供的代码由另一个人拥有.

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

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

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

建立DevOps的最快方法? 更好的沟通!

在引言中, 我提到了客户经常问我的问题:“我应该使用Docker还是直接跳到Kubernetes ??读完这篇文章后, 你可以看到，这样的问题最好在做了一些准备工作之后——以DevOps的心态来回答.

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

一旦所有的需求都被记录下来，技术选择就容易多了.

我是所有伟大的DevOps自动化工具的倡导者，它们使我们的工作更容易、更易于管理. 但我们的日常工作是与 人. 让我们花点时间来改进DevOps最佳实践的这一方面，而不是去获得另一个技术证书.