DevOps或我们如何失去工资和IT行业的未来

在当今情况下，最可悲的是，IT逐渐成为一个行业，每个人的职责数量没有“停”字。



阅读职位空缺时，有时您甚至看不到2-3个人，而是整个公司合而为一，每个人都在赶时间，技术债务在增加，在新产品的背景下旧的遗产看起来很完美，因为它至少在代码中有文档和注释，新的产品以光速写入，但是最终它们在写入后不能再使用一年，而且今年常常没有带来利润，而且，“云”的成本高于服务的销售。投资者的钱用于维护尚未运行但已作为工作人员发布到网络的服务。

举一个例子：一家知名公司，其对旧游戏的重新制作获得了行业历史上最低的评分。我曾是购买此产品的人之一，但即使现在该产品仍然非常有效，从理论上讲，它不应该以这种形式销售。退款，收视率下降，论坛上大量用户禁止投诉服务。补丁的数量并不惊人，但令人恐惧，但都一样-产品无法使用。如果这种方法为自1991年以来发展的公司带来这样的结果，那么对于刚起步的公司来说，情况就更糟了。



但是，我们从服务用户的角度看了看这种方法的结果，现在让我们看一下员工遇到的问题。



我经常听到这样的说法：DevOps团队不应该存在，这是一种方法论，等等，但是麻烦的是，公司出于某种原因停止寻找麻烦，dba，基础架构工程师和建筑工程师-现在所有的DevOps工程师都是一个人。当然，有些公司仍然有这样的职位空缺，但数量很少。许多人将这种情况称为发展，我个人认为这种情况会恶化，不可能在所有领域保持良好的知识水平，并且同时最多只能工作8个小时。当然，这些都是幻想。实际上，许多IT专家被迫工作12或14个小时，其中8个小时是有偿工作。通常一周工作7天，因为“我被赋予了一项任务，没有停靠点或弯道，甚至服务也要花钱”，并且需要1原则上，云中的错误可能在几个月内无法获得薪水，尤其是在使用IP的情况下。实际上，随着业务职责的分离，我们正在失去口头禅，我越来越多地发现经理们进入了开发流程，通常对它们一无所知，他们混淆了业务数据和应用程序的操作，从而导致混乱。



当混乱开始时，企业想要找到罪魁祸首，而在这里您需要一个普遍的罪魁祸首，因此很难将责任推卸到10个以上的人员上，因此管理人员将职位合并在一起，因为1位专家的职责越多，证明他的过失就越容易。在敏捷的情况下，发现“罪魁祸首”和鞭打行为是这种在管理中开展业务的方法论的基础。敏捷离开了IT很长时间了，它的主要概念变成了-日常结果的需求。问题在于，高度专业化的专家不会总是得到每日的结果，这意味着报告起来会更加困难，这是企业想要“专家”的另一个原因。但是，主要原因当然是工资单-这是所有变动的主要原因，为了获得奖金，人们同意为自己和那个家伙工作。但是最后，与其他领域一样，现在，它已成为一种义务，为更多的服务提供更少的付款。



现在，您甚至经常可以看到有关开发人员应该已经可以部署哪些内容，应该如何处理与DevOps工程师相邻的基础结构的文章，但这会导致什么呢？没错-服务质量下降，开发人员质量下降。就在两天前，我向开发人员解释说您可以在不同的主机上进行读写操作，他们向我吐口水证明了他们从未见过，这是在设置orm主机，端口，数据库，用户，密码中完成的。但是开发人员知道如何运行部署，编写Yamls ....但是他已经忘记了代码中的单元测试和注释。



结果，我们看到以下情况-过度劳累，寻找工作时间以外的问题的解决方案，在周末进行持续的培训，而不是增加收入，而是为了维持生计。开发人员被迫使用CI / CD帮助DevOps工程师，如果开发人员没有时间，他就会开始缝制，管理人员开始动脑筋，如果这无助于增加加班工作的欲望，然后施加罚款和罚款，那么人们正在寻找新工作。留下了像Everest一样大的技术债务，结果，债务在开发商之间开始增加，因为他们被迫编写较少重构的代码，以便有时间帮助新老或新的DevOps工程师，并且经理们对所有事情都很满意，因为有罪的人在那里并且可以立即看到，这意味着遵守敏捷管理的基本规则，发现有罪的人，他的鞭打结果可见。



一次在ITGM上，我做了一个“当我们学会拒绝时”的演讲-其结果非常具有启发性。很多人认为这个词是忌讳的，除非我们停止这种想法，否则问题只会越来越多。



本文的第二部分的灵感来自于这篇文章，但后来我可能会写下来少倜傥的条款。