缩小差距（DevOps通信的重要性） _项目管理

本文概述

DevOps解释
DevOps Automation是文档
DevOps沟通：弥合开发与运营之间差距的唯一途径
DevOps团队结构：谁在团队中？
与废物作斗争是共同的努力
DevOps原则：保持你的CALM(S)
DevOps使业务更接近发展
建立DevOps的最快方法？更好的沟通！

尽管DevOps方法论已经存在了很长时间, 但它仍然是激烈讨论的中心。公司想要它, 但是不确定如何实现它。
DevOps无处不在。尽管这是一个有趣的趋势, 但应该将其应用于产品, 而不是相反。
但是有些人不这样认为。我经常被问到以下问题：” 你认为我们应该开始使用Docker, 还是直接进入Kubernetes？” 这些问题毫无意义, 甚至都不知道产品的含义。
【缩小差距（DevOps通信的重要性）】所有这些花哨的术语(云, Kubernetes, 容器, 配置管理, 基础架构即代码)都有望带来一些改进。但是它们对DevOps的影响就如同望远镜对天文学的影响一样。它们可能有用, 但不是必需的。
DevOps的核心宗旨是缩小客户订购的产品和开发团队交付的产品之间的差距。着重于短发布周期, 迭代设计方法以及重复步骤的自动化。你认为将它们变为现实最重要的是什么？
如果你说” 伟大的沟通” , 那是对的。工具都很好。但是, 只有当他们改善沟通时, 才值得投入他们的金钱。
沟通的一方面是了解完成工作所需的条件。这项工作并不意味着” 代码已提交到存储库” 。可以将其视为” 客户看到了生产的变化并接受了它” 。
一旦确定了第一步, 并且每个人都知道需要做什么, 那么这就是写下它的最佳时机。哪里？好吧, 我是维护README.md的坚定倡导者。团队中的每个人都可以随时查看其中的情况并了解项目的状态, 这对于项目新手来说是很自然的选择。
编写自述文件后的下一步是自动化, 它是可选的。但是, 记录该过程是自然的结果。是的, 在考虑DevOps时, 经常会想到自动化。
等一下… 对于DevOps, 自动化是可选的吗？ DevOps不是部署人员的部门吗？
人们通常用” DevOps工程师” 一词来理解的是软件可靠性工程师, 平台工程师或操作自动化工程师。这些都是可以实践DevOps的有效角色, 但是使用统称” DevOps工程师” 可能有点含糊。
因此, 让我们仔细看一下DevOps本身。
DevOps解释首先, 让我向你展示什么不是DevOps：

不只是职位名称前缀
它不是团队(但” Dev” 和” Ops” 是)
这不是技术
这并不意味着” 可以编码的系统管理员”
这并不意味着” 自动化的东西”
这并不意味着” 现在没有运营团队”

知道了这一点, 你现在意识到, 不能简单地” 聘请公司的DevOps工程师” 或” 创建DevOps团队” 来确保自己具有永续性。 DevOps类似于敏捷开发。你会这??样雇用敏捷开发人员吗？可能不会。你要么以敏捷的方式开发产品, 要么没有。
那么如何描述DevOps？这是一种方法论。也许是一种文化。也许甚至是一种精神。根据DevOps原则进行产品开发意味着每个人(无论是开发人员, 运营工程师还是产品经理)都有一个共同的愿景, 即通过沟通维护产品。在较小程度上, 这也意味着每个人都使用相同的工具。这些工具并不能帮助任何一群人。它们旨在推动产品前进。
遵循这一概念需要认真改变观念, 这是主要障碍。这是为什么？这是因为人们必须走出自己的舒适区, 并开始与具有不同能力的人进行协作。开发人员突然需要学习云的工作原理并开始部署自己的代码。操作人员需要放弃手动设置并开始编码。每个人都需要学习新概念。每个人都有新的责任。
这并不容易, 但是有了良好的沟通和一个共同的目标, 这是可以实现的。这种沟通包括建立文化, 建立轻量级流程以及维护适当的文档。
DevOps Automation是文档你可能从来没有那样想过。但是, 通常与DevOps关联的大多数工具是文档工具：

为提高可读性而编写的构建脚本用于记录构建过程
持续集成管道记录了从构建单个零件到整个产品的集成过程。
通过记录如何部署客户可以使用的产品, 持续的部署流程可以进一步进行
配置管理文件记录了安装和配置过程
基础设施即代码规范记录了必要的基础设施(实际上相当正式！)
容器带有自己的Dockerfile, 用于记录如何构建和配置给定的微服务

所有这些花哨的概念基本上只做一件事：它们通过记录过程来帮助团队成员更好地沟通。然后可以手动或自动运行这些过程。重要的是, 项目中的每个利益相关者都可以跟随他们。
与常规说明手册??相比, 将过程记录为代码具有一大优势。可以验证代码并预测其行为。给定相同的输入, 它将产生相同的输出。
有了书面说明, 你将拥有与读者一样多的解释。如果你编写的文档含糊不清或含糊不清, 则阅读该文档的人员将填补空白。关键是, 你无法控制差距。
使用代码要简单得多。没有具体步骤, 程序将停止运行。这些具体步骤是DevOps通信的关键方面。
DevOps沟通：弥合开发与运营之间差距的唯一途径在《凤凰计划》一书中, 我们目睹了一位新晋升的经理负责部署一个大项目的问题。没人知道发生了什么, 每个人都在扑灭大火而没有太多进展。该书的副标题提到这是DevOps的故事。我同意这一点。
但是有趣的是, 在本书的整个过程中, 没有引入任何新工具。你可以通过单独改善沟通来达到DevOps的状态吗？这本书的主人公做到了, 所以也希望给你！
即使主角的方法被认为是” 老派” (使用实际的纸卡而不是适当的错误跟踪系统), 但只有当所有相关方开始互相交谈时, 情况才会开始好转。
你可能认为, 只有通过在开发和运营之间创建更好的接口(例如服务级别协议或事件积压)来改善开发和运营之间的协作是可能的。但事实恰恰相反。通过拆解界面并引入同理心和共同原因, 你将拥有一个致力于共同目标的团队。
DevOps团队结构：谁在团队中？理想情况下, 每个产品应该只有一个团队：产品团队。
我曾经在一个开发团队中与其他团队缺乏共同目标。开发团队希望推动尽可能多的更改。验证团队的任务是防止引入缺陷。他们有不同的经理, 他们分别进行了评估。
结果？ Development and Validation在缺陷报告方面打了乒乓球。当Validation发现无法通过的测试时, Development对发现测试代码本身中的缺陷比对使自己的代码中没有bug更加感兴趣。
当然, 发布周期迅速增加, 因为要正确填充报告, 反报告等需要大量开销。多数人似乎没有意识到的是, 就产品而言, 两个团队应该共享一个共同的目标并共同努力实现这一目标。但是由于缺乏适当的合作和孤岛的心态, 因此很难注意到。
与废物作斗争是共同的努力精益生产的思维方式启发了《敏捷软件开发宣言》(这反过来又向我们介绍了DevOps)是与浪费作斗争。所谓浪费, 是指与客户订购的商品没有直接关系的所有商品。堆积在进行中的工作是浪费。流程的每个步骤如果没有明确导致释放, 都是浪费。
但是只能从高层次看待浪费。在一个团队的范围内, 某些程序似乎必不可少。但是, 从产品角度来看, 它们可能毫无用处。
要弄清楚浪费了哪些精力, 你必须共同努力, 并考虑已运输产品的生命周期。你还需要从客户的角度考虑。客户想要此功能吗？如果没有, 你最好此时跳过它。你的流程是否简单, 精益？更深入地研究, 尤其是那些跨越团??队边界的人员。
你是否要确保产品开发尽可能高效？邀请局外人看看你的工作方式。一个不属于你团队的人将能够提出有见地的问题, 并找出需要改进的新领域。
DevOps原则：保持你的CALM(S)CALMS是关于如何实践DevOps的非常准确的描述：

文化
自动化
靠
测量
分享分享

请注意, 它的形状像三明治。三个中间值更具技术性, 而外部值则与软技能有关。但是所有文化的基础都是沟通：我们与其他团队成员交流我们的价值观和信念, 直到我们就事物的行为达成共识。
分享也一样。共享基本食物(例如食物)不需要交流。但是, 手势本身也可以看作是一种交流行为。 “ 我在乎你, 所以我与你分享。” 我们不想将范围仅限于口头交流。
但是, 共享想法和工具需要沟通。我们应该如何分享它们？我们该放在哪里？它们对团队中的每个人还是对较小的团队有用吗？
如果仅关注更多的技术方面(自动化, 精益和测量), 那么你会错过DevOps的要点。有一个自动化的部署脚本, 在作者旁边没人使用过, 这有什么好处？如果脚本为她节省了一些时间, 则可能是合理的。但是想象一下, 如果每个人都共享此脚本可以节省多少时间。这说明了与废物作斗争！
如果仅关注更多的技术方面(自动化, 精益和测量), 那么你会错过DevOps的要点。
鸣叫
DevOps使业务更接近发展有人说DevOps使运营更接近于开发。这是真的, 但这不是全部。如果操作正确, DevOps可使每个单元距离更近。它使企业和客户几乎可以实时查看开发的进展。
较短的反馈循环使所有利益相关者受益。通常, 这项工作更加明显, 开发人员也可以轻松地看到客户如何使用他们产生的代码。使用传统部署, 你可以等待几个月, 直到有人注意到错误或错过的要求。通过持续部署, 每个人都可以对出现的任何问题做出反应。开发人员, 运营, 业务和客户可以坐在一个房间里, 并根据当前需求修改工作应用程序。
DevOps工具优先？再想想
当然, 需要所有工具使其成为可能。
但是, 没有什么工具可以替代公司内部良好的沟通和同理心。我曾经观察到一种产品, 其中构建过程由一个团队拥有, 而提供的代码由另一个团队拥有。
构建系统存在常见问题。开发人员不确定如何使用它。它基于标准工具, 但是它们经过定制, 以至于网络上所有可用的文档都被证明是无用的。
每个人都想改善这种状况, 但是两个团队之间并没有了解。这意味着双方都在未与另一方协商的情况下引入了新工具。这只会扩大差距, 而不会缩小差距。
如果要在组织内启动DevOps转换, 请先改善沟通方式。不要简单地提出一个解决方案：首先要头脑开放, 头脑风暴。然后, 你可能会发现, 例如, 工具支持不足以满足你的需求。到那时, 你可以考虑调整当前工具或引入一些新工具, 否则你可能会添加到原始问题中。
建立DevOps的最快方法？更好的沟通！在引言中, 我提到了客户经常问我的问题：” 我应该使用Docker还是应该直接跳到Kubernetes？” 阅读本文之后, 你可以看到, 在进行一些准备工作之后, 以DevOps的心态最好地回答了这个问题。
如果你知道你的产品团队了解DevOps对自己和对客户的好处, 则团队和客户可以从设定期望值开始。然后工程师可以找出开发和部署模型。最后, 你可以确定需要哪些工具。
记录所有要求后, 就可以轻松进行技术选择。
我是所有出色的DevOps自动化工具的倡导者, 这些工具使我们的工作更轻松, 更易于管理。但是我们的日常工作是与人合作。让我们花一些时间来改进DevOps最佳做法的这一方面, 而不是再获得另一项技术证书。