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

Самое печальное в сегодняшней ситуации то, что IT постепенно становится отраслью, где вообще нет слова “стоп” в количестве обязанностей на 1 человека.

Читая вакансии иногда уже даже видишь не 2-3 человека, а целую компанию в 1 лице, все спешат, тех.долг растёт, старое legacy на фоне новых продуктов выглядит совершенством, потому что в нём хотя бы есть дока и комменты в коде, новые продукты пишутся со скоростью света, но в итоге пользоваться ими нельзя ещё год после их написания, и зачастую этот год прибыли не приносит, более того, расходы на “облако” выше, чем продажи сервиса. Деньги инвесторов уходят на содержание ещё не работающего сервиса, но который уже выпустили в сеть как рабочий.
Как пример: известная компания, чей ремастер старой игры получил самые низкие оценки за всю историю индустрии. Я был одним из тех, кто купил данный продукт, но даже сейчас этот продукт работает ужасно, и по идее ещё не должен был в таком виде выходить в продажи. Возвраты денег, падение рейтинга, огромное количество банов пользователей на форумах за жалобы на работу сервисов. Количество патчей не восхищает, а ужасает, но всё равно – продукт не юзабелен. Если этот подход приводит к таким результатам у компании, которая занимается разработкой с 91 года, то у компаний, которые только начинают свою деятельность, ситуация ещё хуже.

Но это мы посмотрели на результаты такого подхода со стороны пользователя сервиса, а теперь посмотрим на проблемы, которые возникли у сотрудников.

Я часто слышу утверждение, что DevOps команд не должно быть, что это методология и т.д., но вот беда, компании почему-то перестали искать ноков, dba, инфруктурщиков и build инженеров – сейчас это всё DevOps инженер в единственном лице. Конечно, в отдельно взятых компаниях такие вакансии ещё есть, но их всё меньше. Многие это назвали развитием, я лично в этом вижу деградацию, невозможно поддерживать по всем направлениям хороший уровень знаний, и при этом успевать работать не более 8 часов. Естественно – это фантазии. В реальности, многие ITшники вынуждены работать и по 12, и по 14 часов, из которых оплачивается 8. А зачастую и без выходных, потому что «мне поставили задачу, доков нет или кривые, да ещё и денег стоит сервис», а за 1 ошибку в облаке можно в принципе не получить з\п за пару месяцев, особенно, если работаешь по ИП. Мы по факту теряем слово в бизнесе, вместе с разделением обязанностей, я всё чаще сталкиваюсь с тем, что менеджеры лезут в процессы разработки, вообще в них ничего не понимая, они путают бизнес-данные и работу приложения, в результате начинается хаос.

Когда начинается хаос, бизнес хочет найти виновного, и тут нужно универсального виновного, повесить вину на 10+ человек сложно, поэтому менеджеры объединяют позиции, ведь чем больше обязанностей у 1 специалиста, тем проще доказать его халатность. А в условиях Agile нахождение «виновного» и порка — это основа данный методологии ведения бизнеса в менеджменте. Agile давно вышел из IT, и основной его концепции стало – требование ежедневных результатов. Проблема в том, что у узкоспециализированного специалиста не всегда будет ежедневный результат, а значит отчитаться будет сложнее, и это ещё одна причина, почему бизнес хочет «специалистов по всему». Но основная причина конечно же, это ФОТ – он основная причина всех изменений, ради надбавки люди соглашались работать за себя и того парня. Но в итоге, как и в других сферах, это просто стало теперь обязанностью, за меньшую оплату большего кол-ва предоставленных услуг.

Сейчас можно часто увидеть даже статьи о том, что уже и разработчики должны уметь деплоить, должны заниматься инфраструктурой рядом с DevOps инженером, но к чему это приводит? Правильно – к падению качества сервисов, к падению качества разработчиков. Вот буквально 2 дня назад я объяснял разработчику, что писать и читать можно из разных хостов, а мне с пеной у рта доказывали, что никогда такого не видели, вот есть в settings orm host, port, db, user, password и всё…. Зато разработчик умеет запускать деплои, писать ямлы…. Но уже забывает про юнит тесты и комменты в коде.

По итогу мы видим следующее – постоянные переработки, поиски решений проблем вне рабочего времени, постоянное обучение в выходные, и не для роста доходов, а для поддержки себя на плаву. Разработчики вынуждены помогать DevOps инженеру с CI/CD, а если у разработчика нет времени, тот начинает зашиваться, и менеджеры начинают компостировать мозги, а, если это не помогает увеличить желание работать сверхурочно, то применять взыскания и штрафы, человек ищет новое место работы, оставляя после себя тех.долг размером с Эверест, в результате долг начинает расти и у разработчиков, т.к. они вынуждены писать код с меньшим его рефакторингом, чтобы успеть помочь либо старому или новому DevOps инженеру, а менеджеров всё вполне устраивает, ведь виновный есть и его видно сразу, а значит основное правило при Agile в менеджменте соблюдено, виновный найден, результаты по его порке видны.

Когда-то на ITGM я выступал с докладом «когда мы научимся говорить «нет»» — его результаты были очень показательными. Огромное число людей считает, что это слово табу, и пока мы не перестанем так считать, проблемы будут только расти.

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