July 30

Экономные работодатели

Раньше требования к девопс вакансиям занимали два листа А4. Девопсу полагалось знать абсолютно всё - от починки побитых баз до нюансов работы с функциями в GCP. Объяснялись такие требования просто - в вакансию постили всё, что используется в техстеке продукта. В реальности вовсе не обязательно было быть гуру всего, что там написано, потому что некоторые вещи были настроены поверхностно и это было норм, некоторые заюзаны на 1% своего функционала.

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

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

Однако, в 2022 году я пришёл на собес во вроде бы крупную компанию, прошёл технические этапы. И там мне говорят:

— Всё хорошо, но есть нюанс. Ты глубоко работал лишь с ~1/4 того, что у нас есть.

— Что ж, расскажите поподробнее, - говорю я.

— Ну, у нас активный переезд на Kubernetes, но есть много легаси проектов. Их очень много. Часть нагрузок у нас на виртуальных машинах VMWare. Часть нагрузок - на докере в виртуалках. Часть нагрузок также крутятся на виртуалках опенстека, а ещё у нас есть бейр метал сервера. Где-то есть докер-композ, а где-то просто скрипты. Базы данных у нас все на виртуалках в proxmox. Это постгрес, мускл, редис, шмедис, а ещё также есть кафка, пульсар, редпанда. Балансировщики траффиков - нжинкс, а есть аппаратные, и это тоже наша зона ответственности...

— Стоп. "Тоже" - это как и всё вышеперечисленное? - я начинаю сползать под стол.

— Да-да, я же и говорю про 1/4. Всем этим занимается наша команда.

В дальнейшем разговоре выяснилось, что крупноблочное планирование в команде отсутствует как класс - люди не закладываются на большие изменения платформенного характера, они работают точечно - отвалилось-починили, разработка пришла сказала "надо" - взялись за работу. Про процессы и планирование говорили неохотно и мало, а про пожары, аварии, инциденты - много. (При этом, блядь, у меня там была в тех.цикле секция проектирования какого-то прикладного сервиса с т.з. инфраструктурной части.)

Мне пришёл оффер, ну понятно что я его реджектнул.

Что я хочу сказать - устраивайтесь в команду с узкой специализацией. Да, вы будете мучаться и спотыкаться о грабли, расставленные смежными командами, и часть жизни у вас будет проходить в игрищах "кто кому должен", зато вы сэкономите себе нервные клетки и годы жизни по сравнению с жизнью в работе 24/7 и поездками в отпуск с рабочим ноутбуком.