正确掌握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最佳实践的这方面，而不是获得另一个技术证书。