Devops是一种变革精神，许多公司都在利用它。然而，就像任何依赖于文化的事情一样，将一些工具拼凑在一起，添加一些新的流程，然后称自己为开发驱动的组织，这可能太容易了。毕竟，说你的公司拥抱devops和定期实践devops技术现在很流行，它可以作为一个伟大的公关，为你的团队带来伟大的人才。但事实上，许多公司——以及技术招聘人员——宣称他们对devops的热爱并非如此真的Devops组织。
在这里，我们看一下一些最常见的误解和缺陷的Devops实现。有机会是，贵公司已经牺牲了至少一个。这并不一定意味着你没有练习devops。它只是意味着在贵公司能够满足承诺之前，您有办法。Devops不是您可以实现的奖励或标题。这是一个哲学，文化和接近运输代码任务的方式。
读下去，后退一步，评估你的公司对devops使命的承诺。坦诚和诚实是引导你的团队走向正确方向的关键。
标志1:你需要购买“devops”
IT部门需要“人员”来运作。它们需要硬件:计算机、服务器、服务器机架、网络交换机、路由器和负载均衡器。他们还需要软件:操作系统、防病毒产品、生产力软件、项目管理解决方案、各种业务应用程序，以及用于监控硬件和软件运行状况和性能的软件。
IT部门从一开始就在购买“东西”。当第一家公司决定将电脑作为其业务活动的一部分时，作为IT命脉的采购就诞生了。It高层很自然地认为，他们可以购买下一件大事，帮助他们帮助业务成功。这就是为什么一些公司给自己错误的印象，认为他们可以购买“devops”。
但这并不是出于错误的意图。许多参加devops会议或与其他cio谈论devops的cio开始看到devops可以为他们的公司做些什么。有些人决定他们想要“devops”——而且他们现在就想要!他们不明白的是，devops不是一种需要购买的产品或服务。它是一种思维模式或操作模式。
这并不是说你不能从高薪顾问那里购买一段时间来学习devops原则，但通过这样做，最终你购买的知识需要你的重要工作来实现。你的团队必须吸收被教导的东西，只有这样devops实践才会开始扎根。
“Devops”不可能通过简单的检查和一点培训一夜之间获得。这是一种转换核心流程的方法，它需要时间、奉献，尤其是一个能够实现devops实践的团队，其中许多实践将与您公司以前的操作模式背道而驰。
如果你的公司有一个devops预算，你做devops是错误的。
迹象2:你把软件和工具等同于devops
devops的错误应用与上面的第1条并行运行。IT公司获取工具以更有效地完成工作。它被编码在工作中。IT公司拥有管理客户端和服务器以及存储、计算和网络资源的工具。但当涉及到工具和devops时，公司往往会感到困惑。可以肯定的是，devops的伟大离不开工具。但是当公司忽略devops的其他领域而只关注工具本身时，问题就出现了。工具可能是必不可少的，但它们只是devops运行的一部分。
与devops相关的各种配置管理产品肯定会帮助您构建devops文化。没有他们，你无疑不是在练习devops。您可以编写自己的工具来自动化先前的手动过程，如代码测试、部署和服务器构建，或者您可以购买用于完成这些任务的工具;不管怎样，自动化是devops的一个重要组成部分。如果没有工具，您仍然需要手动构建测试服务器，运行运行手册，并在检查表上勾选复选框。
但是devops包含许多超出配置管理的方面;不要只专注于一个，因为解决方案是存在的，而且是有形的。如果你在成为devops忍者的旅程中寻找一些有形的东西，你将失败。
如果你的公司购买了厨师或木偶作为devops需要的万灵丹，你做devops是错误的。
迹象3:您使用检查列表或运行簿来管理代码部署
要强调一点，自动化是devops的关键。自动化在组织的devops文化中是至关重要的。实践devops的公司都强烈希望将一切可能的事情自动化。自动化允许他们消除人为错误，并使整个软件开发生命周期的过程标准化。
企业知道自动化是发展其他devops原则的种子，比如建立一致的例行代码部署。如果没有自动化，可靠的代码部署就不可能实现。自动化是迈向devops文化的关键哲学。
所以，如果你发现自己和同事聊天时听到这样的话，“我们没有时间自动化”或“这次就让我们手动操作吧。”它会更快"然后你就不做devops了。当开始一个新的项目时，如果自动化所有可能的事情并不是你头脑中的第一个想法，那么你可能还没有掌握devops。
注重开发的文化意识到，尽管提前引入自动化可能需要更多的时间，但在未来，它将通过更可靠和更快的代码部署获得回报。你的公司必须明白这一点一切都有可能实现自动化这意味着部署、测试、代码签入策略、服务器构建——一切。
如果您的公司花费数小时钻研检查列表以确保代码已经准备好部署，那么您的devops做法是错误的。
标志4:每隔几个月(或几年)向生产环境发布代码
既然我们已经解决了自动化问题，那么解决部署频率问题就很重要了。devops的唯一目的是修复bug并更快地将新特性发布到生产环境中。这不是通过遵循传统来实现的瀑布模型；这是通过存在来实现的敏捷．
在其核心，敏捷方法包括尽可能频繁地发布小的变更。它的前提是在发布之前不计划每一个小细节。它是关于定义什么被认为是“生产就绪”的，用一组自动化测试来表示，并相信正确编写的测试定义了代码“生产就绪”的含义。
Devops是持续集成和持续部署等概念的同义词。注意这两个词中的关键词:连续．Devops是关于让开发人员尽可能频繁地检入代码，这将启动自动化测试。
对于真正的devops明星来说，它还包括通过持续部署将代码直接发送到生产环境中。如果你的公司允许开发人员检查经过自动化pre-check-in测试的代码,会移交给另一组测试,以确保代码已经准备好生产,然后上线生产服务器上自动如果认为准备好,然后你知道你取得devops的辉煌。
如果您的公司发布代码变更的频率低于丰收之月，那么您的devops操作是错误的——无论更改有多小，或者更改的速度有多快。
迹象5:你认为失败是不可接受的
文化通常被认为是IT的“软”方面，但它对devops来说是最重要的。这就是公司经常无法实现devops承诺的地方。他们可能会使用最优的工具组合进行自动化。他们可能会不断地更新代码。但他们无法完全吸收devops的文化，这让他们每次都很失望。
例如，当您提交的代码继续破坏生产数据库时，会发生什么?你的老板会公开责骂你吗?你是否会立刻被叫到经理办公室参加一个“闭门”会议?提交代码的可能结果是失去工作或再次将代码部署到生产环境中的能力吗?如果是这样，那么你的公司并没有实践devops。
相反，想象一下:生产数据库的崩溃被当作一个学习的机会。你的经理会让每个人参加事后分析会议，提供坦诚的反馈。每个人都表现出某种程度的坦诚，这可能会让你感到不安，但这绝不是一种指责。确定了根本原因，并围绕您的错误构建新的测试，以便下次发现错误，每个人都表现得就像只是另一天一样。这是当你知道你的公司已经采用了一个重要的devops哲学。
如果因为您已经或可能犯了一个错误而不再信任您具有提交产品的权利，那么您执行devops是错误的。
迹象6:你把系统问题归咎于他人
Devops的哲学借鉴了很多精益,不要责怪其他人的系统错误是影响devops人性化的一个关键方面。与接受失败一样，消除个人对与系统相关的问题的指责是成功的devops实践的关键。
真正的devops实践者相信，当出现问题时，问题不在于使用系统的个人，而在于系统本身。为了让开发人员和系统运行人员和谐相处，必须支持一种无可指责的文化。假设一个开发人员创建了一个应用程序，在他的计算机上测试该应用程序，并将代码交给操作。如果在运维将代码投入生产时出现问题，运维不能责怪开发人员写了劣质的代码，开发人员也不能责怪运维不能正确管理服务器。
Devops解决这个问题的方法是首先找出两个测试环境之间的区别。一旦发现，修复就会被实现，最好是创建一个自动化测试，以确保在未来，任何有缺陷的代码都将失败于新的自动化测试，这将阻止更改进入生产环境。
如果你的公司仅仅因为降低产量而解雇员工，那么你做devops是错误的——不管你认为相关人员的角色或职责是什么。
迹象7:开发商和运营团队看起来就像两个粮仓
Devops将“开发人员”和“操作”结合在一起。如果你的开发人员和运营人员仍然不友好，你就没有机会做正确的devops。Devops是关于协作的。而是作为一个团队团结在一起，帮助整个公司实现目标。如果你的运营人员拒绝与开发人员沟通，而不是把工作扔到墙上，你的devops梦想就破灭了。
这是devops哲学中最重要的部分。我之前提到的所有活动都朝着这个最终结果迈进。这并不意味着开发者必须被迫与运营人员共进午餐，或者运营人员必须邀请开发者参加他们的婚礼。这不是喜欢对方;这是关于超越我们的人类情感，以专业团队的方式工作，打造一款推动业务向前发展的产品。
如果您的公司在一层楼有开发人员，而在另一层楼有操作人员，代码提交消息作为唯一的通信手段，那么您执行devops是错误的。
这都是文化的问题
Devops并非适用于所有公司。有些情况需要更细致的代码管理方法。然而，即使你的公司没有完全致力于建立devops文化，devops哲学的许多方面都可以成功地应用到你的实践中。
首先，devops是一种文化哲学。这需要耐心，大量的努力工作，对人的理解，以及支持它真正繁荣的业务。
相关文章
- PowerShell的力量:Windows管理员会喜欢的基本提示
- PowerShell的强大功能:Exchange管理员简介
- PowerShell的力量：Windows Server Admins的介绍
- 为什么devops让开发人员精疲力尽
这个故事，“你做devops错误的7个迹象”最初是由信息世界 ．