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定义并以不一样的方式实现它，这使人沮丧。

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

推荐阅读：

老王讲架构：负载均衡

支付宝系统架构内部剖析

大数据Spark与Storm技术选型

【赞】用Python实现Zabbix-API 监控

程序员怎么留住健康？

大数据智慧平台技术方案

大数据聚合平台解决方案