Русский
Русский
English
Статистика
Реклама

DevOps или как мы теряем заработную плату и будущее IT-отрасли, часть вторая

Прошлая статья уже вызвала много возмущений, думаю эта статья многим ещё больше не понравится, в ней я распишу то, как заказчики видят DevOps инженера.

Чем больше идёт времени, тем больше я слушаю о том, что это обязанность девупса, запросы в БД хотят чтобы тюнинговал девупс, догадывался, как и с какими зависимостями собирается у кодера софт девупс, evpn+bgp+ipsec+geo dns+сетевая авторизация по сертификатам девупс, исправлять ошибки архитектуры и придумывать бескровные варианты девупс, превращать обычный pg_dump в синхронную репликацию девупс, быть психоаналитиком для СТО/CEO и команды девупс.

Ещё интересная тенденция это k8s+load balancer на любой чих. Не так давно мне даже предложили поставить load balancer на бд, авось load average понизится и диски меньше нагружены будут. K8s это вообще отдельная тема, про мифы связанные с ним можно написать 2-3 статьи.

Всё чаще от бизнеса можно услышать что разработчики и инженеры зажрались, что сбербанк устроил мыльный пузырь, и вот-вот должно случиться чудо, и мы начнём работать как обычный люд за 60-80к у сеньора. В регионах уже, конечно, такое есть, да там всё и было печально, но тут мечтают уже и за все города кроме Москвы.

Ещё веселее от этого же бизнеса слушать, какие все лентяи, рассказы про то, как бесполезны работники, и что нужно искать способы не планировать работу, архитектуру, думать о будущем, а шлёпать некачественный код со скоростью света, ведь потом девупс его горизонтально масштабирует, да у нас 1 запрос в БД стоит 15% от мощности железа, а 5 запросов коллапс, ну и что с того? Горизонтальное масштабирование без выделения ресурсов нас спасёт!!! правда не уточняется каким образом. Особенно, если БД довольно кривая по архитектуре, например дефолтный PostgreSQL либо Elasticsearch.

Использовать технологии по назначению? Нет, это скучно. Планировать архитектуру, схемы данных и их обработку зачем это дорого и медленно. Но что делать? Решение есть найми девупса и обвини его во всех смертных грехах твоего проекта, не забывая добавлять ровно до твоего прихода всё работало. А логи врут, всё работало!!!

Я всё чаще вижу, как достаточно интересные и перспективные проекты умирают, ещё даже на этапе зарождения, просто из-за политических игр. Я общаюсь с РМ, которому уже полгода мешают реализовывать продукт, который может приносить компании миллиарды рублей в год, но ему ставят палки в колёса постоянно. Все ищут способы как сделать разработку без расходов на неё, а DevOps методология всё чаще воспринимается как способ вывалить нерабочий продукт в прод, а косяки замазать контейнерами, балансирами и заглушками, даже если это приводит к низким рейтингам и большому числу негатива, главное экономия на разработке.
Как показал опрос в предыдущей статье, у большинства посетителей habr работодатели пытаются заткнуть несколько дыр 1 человеком. Естественно, не компенсируя данные обязанности. Но, проблема в том, что страдает в итоге и сам бизнес. За счёт низкой оплаты труда и высокой производительности труда относительно к финансовому и техническому обеспечению, бизнес выживает, если бы с таким управлением, как в СНГ, пытались делать бизнес в Японии или США, он бы давно обанкротился.

Многие методологии пришедшие к нам с развитых стран были исковерканы напрочь. Например Agile, Scrum, DevOps все 3 методологии требуют для работы существенного изменения бизнес-процессов, но менеджмент в СНГ не готов к этому, он надеется совместить старые привычки и современные методологии, мы вверху по-старому, а вы по-современному и эффективному внизу. Все 3 методологии бессмысленно внедрять снизу, наличие карточек, ежедневных отчётностей, планов на 2 недели и релизов на каждую строчку кода не означает что вы внедрили эти методологии, это означает, что вы ввели дополнительные процессы по отчётности, которые просто помогают найти виновных и оправдание для вышестоящего менеджмента. Проекту и людям, которые начинают работать в таких условиях, только сложнее реализовывать задуманное, потому что кол-во отчётности растёт существенно больше, чем если бы их не было.
Сейчас довольно много статей и выступлений странных менеджеров от IT которые уже предлагают платить за результаты, почти как раньше за строчки кода, убирая из работы время на обдумывания реализации, считая, что оно минут 30-40 а дальше чисто написание кода. При этом на управленческие решения дайте нам 2-3 недели подумать и рассчитать стоимости и риски. В результате мы всё чаще сталкиваемся с тем, что качество продуктов неизбежно падает, конечно это проблема не только IT отрасли, но в нашей отрасли она стоит особенно остро, потому что неудачи потом списывают на программистов, которые типа разбазарили 180 млн рублей, я видел уже 4 проекта, которые в результате такого процесса не выполняют свои задачи, но израсходовали по 1 млрд рублей и более, но виновны в итоге стали ленивые айтишники и начинается её большее кол-во отчётности и регулирующих процедур, для исправления ситуации. Для обеспечения надзорных функций нанимаются дополнительные менеджеры, а ФОТ для IT специалистов сокращается. Кол-во решений, которые мы принимаем сами уменьшается, а ответственность и отчётность растёт, что приводит к ещё большим проблемам.

Вам необходимо чётко проводить линии обязанностей, и их минимизировать, в противном случае вы просто становитесь жертвой в любой политической игре.

Следующую статью я напишу подробнее о том, почему DevOps и Agile, внедрённые снизу, никогда не принесут пользы.
Источник: habr.com
К списку статей
Опубликовано: 28.07.2020 14:05:45
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Agile

Devops

Управление проектами

Читальный зал

Обязанности

Права и свободы

Категории

Последние комментарии

© 2006-2021, personeltest.ru