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

当前形势最可悲的是,IT正在逐渐成为一个人均责任数量根本没有“停”字的行业。

在阅读职位空缺时,有时你甚至看到的不是2-3个人,而是一个人整个公司,每个人都很匆忙,技术债务越来越大,旧的遗产在新产品的背景下看起来很完美,因为它至少代码里有码头和注释,新产品以光速写出来,但结果写出来之后就不能再用一年了,而且往往这一年并没有带来利润,而且,成本云的销售额高于服务的销售额。 投资者的资金用于维护尚未运行但已作为可用服务发布到网络的服务。
举个例子:一家知名公司的一款旧游戏的重制版获得了行业历史上最低的评级。 我是购买该产品的人之一,但即使现在该产品的效果也很糟糕,理论上不应该以这种形式发布。 退款、评级下降、论坛上大量用户因投诉服务工作而被禁止。 补丁的数量并不令人高兴,而是令人恐惧,但仍然 - 该产品无法使用。 如果这种做法对于一个91年以来一直在发展的公司来说导致这样的结果,那么对于刚刚起步的公司来说,情况就更糟糕了。

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

我经常听到这样的说法:不应该有 DevOps 团队,这是一种方法论等等,但问题是,出于某种原因,公司已经停止寻找 noks、dba、infructors 和构建工程师 - 现在都是 DevOps 工程师在一个人身上。 当然,个别公司还是有这样的空缺,但是越来越少了。 许多人称之为发展,我个人认为这是退化,不可能在所有领域保持良好的知识水平,同时设法工作不超过8小时。 当然,这些都是幻想。 事实上,许多IT员工被迫工作12小时和14小时,其中8小时是带薪的,而且常常没有休息日,因为“我被分配了一个任务,没有码头或弯道,而且服务要花钱”,对于云中的 1,原则上您可能在几个月内拿不到薪水,特别是如果您在 IP 基础上工作。 事实上,我们在业务上正在失去话语权,随着职责的分离,我越来越面临这样一个事实:管理者在什么都不了解的情况下就进入开发流程,他们混淆了业务数据和应用程序操作,结果是混乱开始。

当混乱开始时,企业想要找到罪魁祸首,而这里需要一个万能的罪魁祸首,很难将责任归咎于10多个人,所以管理者统一他们的立场,因为1个专家的职责越多,就越容易解决问题。证明他的疏忽。 在敏捷的条件下,找出“有罪”并打屁股是这种管理方法论的基础。 敏捷早已脱离IT,其主要理念已成为日常成果的要求。 问题是,高度专业化的专家并不总是每天都有结果,这意味着报告会更加困难,这也是企业希望“样样都是专家”的另一个原因。 但主要原因当然是工资单——他是所有变化的主要原因,为了津贴,人们同意为自己和那个人工作。 但最终,与其他领域一样,它现在只是成为一种义务,即以更少的费用获得更多的服务。

现在你甚至经常可以看到开发人员应该已经能够部署的文章,应该处理 DevOps 工程师旁边的基础设施,但这会导致什么呢? 没错——服务质量下降,开发人员质量下降。 就在两天前,我向开发人员解释说,你可以从不同的主机上写入和读取,他们口吐白沫地向我证明,他们从未见过这样的东西,这里是在设置或主机、端口中,数据库,用户,密码,就是这样...... 但开发人员知道如何启动部署、编写 yaml .... 但他已经忘记了代码中的单元测试和注释。

结果就是——不断地处理,在工作时间之外寻找问题的解决方案,周末不断地训练,不是为了增加收入,而是为了维持生计。 开发人员被迫帮助一个DevOps工程师进行CI/CD,如果开发人员没有时间,他就开始闭嘴,而管理人员则开始堆肥大脑,如果这无助于增加加班的欲望,那就申请处罚和罚款,该人正在寻找新工作,留下了珠穆朗玛峰规模的技术债务,因此,开发商的债务也开始增长。 他们被迫编写较少重构的代码,以便有时间帮助新老 DevOps 工程师,而经理们对一切都很满意,因为有一个有罪的人,他可以立即被发现,这意味着敏捷管理的主要规则是遵守,有罪的人被发现,鞭打的结果是可见的。

有一次在 ITGM 上,我做了一个演讲“当我们学会说不”——其结果非常有启发性。 很多人认为这个词是禁忌,除非我们停止这样想,否则问题只会越来越严重。

部分启发了我写这篇文章。 本文,但稍后我可能会用不太令人愉快的语言来写它。

只有注册用户才能参与调查。 登录拜托

你在工作中是否遇到过雇主试图用你替换几个人的情况?

  • 65,6%是的,我经常遇到它

  • 5,4%是的,遇到过1次15

  • 15,4%没注意到43

  • 13,6%我是工作狂,我自己也加班38

279 位用户投票。 34 名用户弃权。

来源: habr.com

添加评论