您当前的位置:首页 > 常识摘抄 > 内容

正确掌握DevOps的基本原理然后再考虑工具

尽管DevOps方法已经伴随我们有一段时间了,但它仍然是热烈讨论的中心。公司想要它,但不确定如何接近它。

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

但有些人不这么看。我经常被问到这样的问题:“你认为我们应该开始使用Docker,还是直接跳到Kubernetes?”在不知道产品是什么的情况下,这样的问题毫无意义。

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

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

如果你说“很棒的沟通”,你是对的。工具都很好。但只有当它们能改善交流时,投资在它们身上的钱才值得。

沟通的一个方面是了解完成工作的必要条件。而且该作业并不意味着“将代码提交到存储库”。应该把它看作是“客户看到了生产中的变化并接受了它”。

一旦第一步确定了,每个人都知道需要做什么,那就是最好的时间写下它。在哪里?我是维护area .md的坚定拥护者。团队中的每个人都可以窥探内部,了解项目的状态,对于项目新手来说,这是很自然的选择。

自动化(编写自述文件之后的下一步)是可选的。不过,这是记录过程的自然结果。是的,自动化是DevOps中经常出现的。

等一下……自动化在DevOps中是可选的吗?DevOps不是负责部署的部门吗?

人们通常理解的“DevOps工程师”是软件可靠性工程师、平台工程师或操作自动化工程师。这些都是支持实践DevOps的有效角色,但是使用集合术语“DevOps工程师”可能有点模糊。

所以让我们更仔细地看看DevOps本身。

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

了解了这一点,你就会意识到你不能简单地在公司里“雇佣一个DevOps工程师”或者“创建一个DevOps团队”来确保你是经得起未来的。DevOps类似于敏捷开发。你会雇佣这样的敏捷开发人员吗?可能不会。你要么以敏捷的方式开发产品,要么不。

那么如何描述DevOps呢?这是一个方法。或者文化。甚至可能是幽灵。按照DevOps原则来开发产品意味着每个人——无论是it开发人员、运营工程师还是产品经理——都共享一个共同的愿景,并通过交流来维护它。在较小的程度上,这也意味着每个人使用相同的工具。这些工具并不是用来帮助任何一组人的。他们的目的是推动产品的发展。

要实现这一理念,需要认真改变思维方式,而这正是主要障碍。这是为什么呢?这是因为人们必须走出自己的舒适区,开始与拥有不同能力的人合作。开发人员突然需要学习云是如何工作的,并开始部署他们自己的代码。操作人员需要放弃手工设置,开始编码。每个人都需要学习新的概念。每个人都hasnew责任。

这并不容易,但只要有良好的沟通和共同的目标,这是可以实现的。这种交流包括建立文化、建立轻量级流程和维护适当的文档。

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

所有这些花哨的概念基本上只做一件事:它们通过记录流程帮助团队成员更好地沟通。然后可以手动或自动地运行这些流程。重要的是项目中的每个干系人都能够遵循它们。

将过程记录为代码比通常的指令手册有一个很大的优势。代码可以被验证并具有预测性。在相同的输入条件下,它产生相同的输出。

有了书面说明,读者越多,你就会有越多的解释。如果你写了模棱两可的文件,读的人会填补空白。关键是,你无法控制什么会进入缺口。

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

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

但有趣的是,贯穿全书的整个过程,没有一个新的工具被介绍。你能仅仅通过改善沟通来达到DevOps的状态吗?书中的主人公都这么做了,所以你也有希望!

尽管参与者的方法可能被认为是“老派的”(使用实际的纸质卡片而不是适当的bug跟踪系统),但只有当所有相关方开始相互交谈时,情况才会开始好转。

您可能认为只有通过在开发和操作之间创建更好的接口,比如服务水平协议或事件积压,才能改进开发和操作之间的协作。但事实正好相反。通过拆除接口,引入同理心和共同的事业,你将拥有一个朝着共同目标工作的团队。

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

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

结果呢?开发和验证与缺陷报告打乒乓。当验证发现一个无法通过的测试时,开发人员更感兴趣的是在测试代码中找到缺陷,而不是试图使他们自己的代码没有缺陷。

当然,发布周期膨胀了,因为适当地填充报告、反报告等等需要巨大的开销。大多数人似乎没有意识到的是,就产品而言,两个团队应该共享一个共同的目标,并一起工作来实现它。但由于缺乏适当的合作和筒仓心态,很难注意到它。

精益生产的思维模式激发了敏捷软件开发宣言(这又将我们引入了DevOps),它是关于对抗浪费的。所谓浪费,我们指的是与客户的订单没有直接关系的所有东西。堆积在一起的工作是一种浪费。过程中的每一个没有明确导致发布的步骤都是一种浪费。

但是,浪费只能从高的层面上看。在一个团队的范围内,有些过程似乎是必要的。但从产品的角度来看,它们可能毫无用处。

为了找出哪些工作是浪费的,您必须联合各方并考虑已交付产品的生命周期。你还需要从客户的角度思考。这个特性是客户想要的吗?如果没有,你也可以跳过它。你的流程简单和精益吗?请更深入地观察那些跨越团队界限的行为。

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

calm是一个非常准确的描述如何实践DevOps:

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

分享也是一样。分享一些基本的东西,比如食物,不需要交流。然而,手势本身也可以被视为一种交流行为。“我关心你,所以我与你分享。”“我们不希望只局限于口头交流。

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

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

有人说DevOps让运维更接近开发。这是真的,但不是全部的事实。如果做得好,DevOps会让每个单位更近。它允许业务和客户几乎实时地看到开发在做什么。

这种较短的反馈循环有利于所有涉众。工作通常更加可见,开发人员也可以很容易地看到客户如何使用他们生成的代码。在传统的部署中,您可以等待几个月,直到有人注意到错误或遗漏的需求。通过持续部署,每个人都可以在出现任何问题时做出反应。开发人员、操作人员、业务人员和客户可以坐在一个房间里,根据当前的需要修改工作应用程序。

当然,这需要所有的工具来实现。

但是,再多的工具也无法替代公司内部良好的沟通和同理心。我曾经观察过一个产品,其中构建过程属于一个团队,而提供的代码属于另一个团队。

构建系统的问题是常见的。开发人员不确定如何使用它。它是基于标准工具的,但它们是定制的,以至于web上的所有文档都是无用的。

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

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

在介绍中,我提到了客户经常问我的问题:“我应该使用Docker还是直接跳到Kubernetes?”在阅读了这篇文章之后,你会发现这样的问题最好在用DevOps的思维方式做一些准备工作之后才能得到最好的回答。

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

一旦所有的需求都被记录下来,技术选择就更容易了。

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


声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,谢谢。

上一篇: Facebook删除了近200个与白人至上组织有关的帐户这些组织希望利用抗议活动

下一篇: 微软再次为其改进后的基于chrome的Edge推出广告



推荐阅读

网站内容来自网络,如有侵权请联系我们,立即删除! | 软文发布 | 粤ICP备2021106084号