DevOps或我们如何失去工资和IT行业的未来，第二部分

上一篇文章已经引起了很多愤慨，我想这篇文章将不再被很多人喜欢，在其中我将描述客户如何看待DevOps工程师。



时间越长，我越会听到“这是devups的职责”，对数据库的请求希望调整devups，猜测软件将如何依赖编码器以及如何依赖编码器-devups，evpn + bgp + ipsec + geo dns +通过证书进行网络授权-开发人员，修复体系结构错误并提出无血腥的选择-开发人员，将常规pg_dump转换为同步复制-开发人员，对服务站/ CEO和团队的心理分析者-开发人员。



另一个有趣的趋势是适用于任何打喷嚏的k8s +负载均衡器。不久前，我什至被提议将负载均衡器放在数据库上，也许平均负载将下降，磁盘的负载将减少……。 K8s通常是一个单独的主题，您可以撰写2-3篇有关其神话的文章。



您越来越多地从企业中听到开发人员和工程师喝醉了，Sberbank陷入了肥皂泡，奇迹即将发生，我们将像普通人一样为老年人提供60-80k的服务。当然，在该地区已经存在，但那里的一切令人难过，但在这里，他们已经梦想着除莫斯科以外的所有城市。



聆听每个人的懒惰，有关员工无用的故事，并且需要寻找不计划工作，架构，思考未来，而是以光速传播低质量代码的方法，这对同一家企业来说甚至更有趣，因为开发人员会“横向扩展”。 “，是的，我们在数据库中有1个查询花费了硬件容量的15％，有5个查询-崩溃了，那又如何呢？没有资源分配的水平扩展将节省我们！ -事实没有说明如何。尤其是如果数据库的体系结构非常不完善，例如默认的PostgreSQL或Elasticsearch。



按预期使用技术？不，很无聊。规划体系结构，数据模式及其处理-为什么昂贵又缓慢。但是该怎么办？有一个解决方案-雇用一名虔诚的人员，并为项目的所有致命罪责怪他，不要忘记添加-恰好在您来之前，一切正常。和日志谎言，一切正常！



我越来越多地看到，即使在开始阶段，也仅仅是因为政治游戏而使相当有趣和有前途的项目濒临死亡。我与RM进行了沟通，后者已被销售六个月，该产品每年可为该公司带来数十亿卢布的收入，因此已经受阻六个月了，但他们一直在坚持不懈。每个人都在寻找无需花钱就可以进行开发的方法，DevOps方法被越来越多地视为一种将不起作用的产品倾销到生产中，并用容器，平衡器和存根盖住门框的方法，即使这会导致评级较低和大量负面影响，主要的目的是节省成本发展。

如前一篇文章中的调查所示，对于大多数哈伯游客来说，雇主试图用1个人塞几个漏洞。自然，无需补偿这些义务。但是问题是企业本身因此遭受损失。由于与财务和技术支持相关的低工资和高劳动生产率，如果依靠独联体国家的这种管理，他们试图在日本或美国开展业务，该业务将幸免于难。



发达国家提供给我们的许多方法都被完全歪曲了。例如，Agile，Scrum，DevOps-所有这三种方法都需要对业务流程进行重大更改才能工作，但是CIS中的管理人员还没有为此做好准备，他希望将旧习惯和现代方法相结合，我们以旧的方式居于首位，而您以一种现代而有效的方式在下面。从下面实施这3种方法是毫无意义的，因为存在卡片，每日报告，两周的计划以及每行代码的发布并不意味着您已经实现了这些方法，而是意味着您已经引入了其他报告过程，这些过程仅有助于查找罪魁祸首和借口。对于高级管理人员。对于项目和在这种情况下开始工作的人们来说，实施计划只会更加困难，因为报告的数量正大大增加，比他们不是。

现在，有几位奇怪的IT经理发表了很多文章和演讲，他们已经愿意为结果付费，几乎就像以前一样为代码行付费，省去了工作时间来考虑实现，认为这是30到40分钟，然后纯粹编写代码。同时，给我们2-3周的时间来思考和计算管理决策的成本和风险...结果，我们越来越面对这样一个事实，即产品质量不可避免地会下降，这当然不仅是IT行业的问题，而且在我们行业中尤为严重，因为失败被归咎于喜欢“挥霍1.8亿卢布”的程序员，我我已经看过4个项目，这些项目由于无法完成任务而花费了10亿卢布以上，但是结果是，懒惰的IT专家感到内，其更多的报告和监管程序开始纠正这种情况。为了确保监督职能，需要雇用更多的经理，并减少IT专家的薪水。我们自己做出的决定数量正在减少，责任和问责制也在增加，这导致了更大的问题。



您需要明确划分责任界限并将其最小化，否则，您只是成为任何政治游戏的受害者。



在下一篇文章中，我将更多地介绍为什么从底层实现的DevOps和Agile永远不会有用。