DevOps让研发人员越来越失望？比如工作量与报酬

　　作为一名工程师，您在开发软件时已经有足够的责任。在您的工作日活动中添加更多任务（比如与DevOps相关的任务）可能听起来不太吸引人。使用DevOps，您不仅负责生成工作软件，而且现在还需要自动化软件的构建，测试和部署阶段。这要照顾很多！但是除了额外的工作，也许你只是厌倦了DevOps运动，而围绕它的所有炒作都会导致DevOps疲劳。

　　作为一名前开发人员，我可以认同这种疲劳感。我也看到一些同事对DevOps达到了一定的挫败感。有些时候我们犯了错误，即使是发布也要承担一切。如果我们是完美主义者并且不喜欢提供带有错误的软件，这种情况尤为常见。我们甚至可以将代码发布到生产中。（虽然现在你正在“做”DevOps，但这可能会成为你的责任。）毕竟，如果我们编码它，我们就知道可能出错的事情以及如果有问题如何解决它。

　　即使现在我更多地处理服务器的操作方面 - 处理服务器并帮助公司实施DevOps - 让我与您分享一些关于为什么我认为工程师正在使DevOps疲劳的想法。

工作更多但获得同样的报酬

　　DevOps已经不再仅仅被认为是开发人员和运营商。但缺点是一些组织正在将DevOps功能转移给开发人员。开发人员现在可能觉得他们在完成工作后被迫处理交付管道。他们已经很难尝试创建没有错误的软件！更有可能的是，开发人员越来越感到沮丧，因为他们用更多（和不同类型）的工作来赚取相同的工资。

　　正如我之前所说，有时开发人员认为需要做的比他们应该做的更多。例如，如果操作人员花费太多时间来回答他们的问题和请求，开发人员总会找到一种方法来解决任何问题。他们甚至愿意学习像云和基础架构这样的新代码。当开发人员完成他们的代码并且它已经准备好运送到生产环境时，会发生很多事情。那时，它不仅仅是构建然后复制/粘贴工件。部署和发布可能更复杂，一个团队无法处理所有事情。

　　我不认为开发人员会加倍努力。但有些时候，这些新职责被视为理所当然。这就是DevOps的问题在于工程师。

经历失去专业化的后果

　　尽管工程师仍然在编程，DevOps仍然希望将基础设施视为代码，但工程师现在需要了解基础设施。在不浪费资源的情况下配置和配置服务器并非易事。当然，软件工程师需要确保他们的代码不会产生内存泄漏，并且不会过度使用线程或网络。但是知识开发人员需要处理这些任务并不足以证明他们称他们为基础架构专家。

　　必须适当扩展应用程序并运行基础架构可能需要一些时间才能正确完成。操作人员需要考虑很多事情，例如服务器是在本地运行还是在云或混合环境中运行。说拥有Chef食谱，Terraform模板或Ansible playbook就足够了。如果组织有一个主题专家来充分利用基础设施并优化成本，那就更好了。什么都没有经验。

　　同样，开发人员更多地了解基础架构以及他们的代码如何影响生产系统并不是一件坏事。但有些开发人员喜欢创建应用程序代开发人员可能会觉得DevOps正在对它们进行去专业化，因为他们需要处理所有其他事情来发布软件。

　　DevOps实践和工具不断发展和发展，开发人员的领域也是如此。与主题专家合作总是好的，因为当那些奇怪的问题出现时......你会打电话给谁？当然不是捉鬼敢死队。

听取每个人谈论DevOps

　　“每个人都在做DevOps，你也应该这样做。” 我相信你已经听到了这个消息。

　　我相信DevOps的结果非常好，但只有在您之前发现DevOps非常适合解决方案的问题时。如果您只是实施DevOps，因为它是新的趋势，那么您可能对当前的交付管道很好。特别是对于DevOps来说，尝试复制对他人有用的东西并不是一个好主意; 每个人都有不同的需求和问题。

　　我喜欢Gene Kim定义DevOps的方式，但我只会引用一篇与这篇文章相关的句子 - 我不想为你的疲劳做出贡献。他说，“DevOps不是关于你做什么，而是你的结果是什么。” 如果DevOps的是你的什么结果是，而不是你做什么，它没有任何采取的DevOps感。您可能已经在做一些DevOps事情并且还没有注意到。

　　如果你只是厌倦了所有DevOps的东西，那很好。我偶尔也会感到疲劳。在我的情况下，这是因为人们对DevOps的理解不正确，导致他们实现DevOps运动开始修复的事情 - 比如通过建立一个单独的团队或为每个人添加“完整堆栈”标题来创建另一个孤岛这创造了每个人都需要了解一切的想法。

获得更多压力以快速交付

　　人们让DevOps错误的另一种方式是设置期望，因为他们现在正在“做”DevOps，组织应该每天进行多次部署。改变一切需要时间。DevOps意味着文化的变化，当组织庞大时，改变文化变得更加困难。认为你能够在一夜之间提供更快的速度是错误的。你需要照顾很多东西。一些示例是自动构建和测试，类似生产的环境，配置管理等。

　　DevOps有很多不切实际的期望，每天几次部署就是其中之一。毫不奇怪，当Flickr的John Allspaw和Paul Hammond谈到每天在一次会议上进行十次部署时，很多人开始听到这个消息。该DevOps的报告的2017年国家还加强了思想，高绩效（如Amazon，Netflix公司，谷歌和其他“独角兽”公司）做每天几个部署。

　　所有这一切都很吸引人，所以我理解为什么有些组织想要“做”DevOps。但要取得成功，首先需要确定问题所在。每天进行多次部署有很多好处，但要做到这一点并不容易。我前一段时间写了一篇文章。

　　您不应该让自己X个月符合DevOps标准，并且提供更快的速度。工程师已经有足够的压力来满足最后期限，增加更多期望并没有任何好处。

结果是重要的

　　让我再一次重复基因的引用。“DevOps不是关于你做什么，而是你的结果是什么。” 当你接受这个想法时，你会开始意识到你对DevOps的许多想法都没有意义。在您的交付管道中向左移动活动并不意味着开发人员现在将处理所有事情，或者操作人员将在系统中编写新功能。拼图中的每一个部分都有其目的，并且迫使人们将超出职责范围的任务添加到他们的工作量中从来都不是一个好习惯。

　　工程师可能会对DevOps感到厌倦，因为他们最终会做更多的工作。当然，他们正在学习新事物，但他们也在他们的领域脱离专业。或者管理层可能会增加更多压力和不切实际的期望，而不是意识到这种变化不会在一夜之间发生。但也有可能工程师刚刚听到每个人都在谈论DevOps。

　　如果您或您的团队感到DevOps疲劳，请暂时忘掉它。在将代码更改推送到生产环境时，确定您遇到问题的位置。原因各不相同，但您的流程，工具甚至是您的员工可能会阻止您轻松地发布软件。DevOps背后的想法并不坏; 问题是每个人都有不同的DevOps定义并以不同的方式实现它，这令人沮丧。

————————————————————