Комментарии 16
Я заметил такую большую проблему в мире, не только в россии, что нехватку хороших специалистов закрывают набором низкоквалифицированных специлиастов. В первую очередь во фронте и девопсе. У бекендером дела получше, но тоже такое есть.
В частности девопсов набирают не из девов, а из опсов, т.е. системных администраторов. Отсюдого и описанные вами проблемы. Сисадминов привыкших работать в концепции "работает не трожь" и "зачем развиваться если и так работает" внедряют в айти где они и продолжают работать в этих концепциях. В то время как айти требует подхода Continius Evolution, т.е. непрерывного развития и прогресса. Не зря в профессии девопс первым идет дев, в первую необходимо уметь собирать софт, его разворачивать, настраивать мониторинг, знать чего собирать в этом мониторинге, настраивать логирование и следить за логами. Всем этим 99% девопсов не занимается. Вместо этого они ставят npm зависимости в проде в контейнер во время запуска и запускают исходники в режиме dev и считают это потрясающе выполненной работой.
Вот благодаря вам и таким комментариям, я верю в то, что не все потерянно. А так все верно, согласен под каждым словом. Да кстати и разработчиков это также касается, выучив фреймворк но не понимая как под капотом это работает, стало нынче модно. Кстати в моем окружении сейчас уже фильтр появился, на тех что делают код с помощью ChatGPT, с такими я перестаю о чем либо общаться)
Вы правы, что наблюдаемость, это метрики, логи, tracing, но кто кроме разработчика напишет loging во всех местах debug, в критических info и error? Кто кроме разработчика сформирует нужные метрики и даст возможность их забирать по пробам? Кто кроме разработчика отправит в коллектор сигналы tracing'а? Разработчикам просто нужно больше учиться, а не валить все на зону ответственности ops. Это же касается и дебага, поиска текущей памяти и т.п.
тут все же нужна совместная работа, по метрикам к примеру. SRE/OPS должны во-первых четко понимать что такое системные метрики и метрики приложения, далее совместно выявляют нужные метрики м правила для них. Хотя из опыта мне приходилось лезть в исходный код и катчить то или иное чтобы помочь команде разработки быстрее исправить приложения. Но опять же, к чему я это, не перекладывание. а общее развитие. А так вся суть методологии коту под вост, те делают это, а те то. Про обучение - это золотые слова
З.Ы. имхо, в термине «девопс» «дев» идёт первым попросту для благозвучности. Эксплуатация есть эксплуатация, разница в мере интеграции её с разработкой.
Нехватку хороших специалистов закрывают более слабыми - это не проблема, но объективный тренд. Так же как нехватку мощных серверов закрывают множеством маленьких. К сожалению, в мире людей нет кубернетеса для автоматического управления начинающими специалистами.
Лол, я то как раз "из сисадминов", но наверное 90% попадавшихся разработчиков как раз и были теми самыми "node_modules в контейнер", и что такое мониторинг не слышал из них никто. Потому что набирали жабаскриптеров из верстаков-фронтендеров.
Я утрирую конечно, но не сказать чтобы очень уж сильно. Экономия помноженная на кучу войтивайти инфоцыганских курсов дает вот такой вот выхлоп.
Так что не нужно обобщать. Везде есть и свои "работает не трогай", и "развиваться не надо раз деньги платят", независимо от профессии и бекграунда.
В девопс первым идёт дев, потому что опсдев произносится сложнее вне зависимости от языка.
Основная беда не в том, что из сисадминов. В конце концов DevOps = Dev + Ops. Т.е. специалистов и в разработке, и в эксплуатации. Просто вы разработчик и смотрите на сисадминов традиционно как на чужих людей и даже врагов.
Беда в том, что из плохих и безграмотных сисадминов, которые не смогли вырасти в Ops, и тем более не смогли вырасти из эксплуатации в дизайн и архитектуру (ЗП сравнимы со средними по девопсерии).
В конечном итоге получается, что эти девопсы не умеют НИ в дев НИ в опс.
Пару лет назад хотел взять себе пару админов в офис на очень хорошие деньги (для админов) на немного хелпдеска, немного того, немного этого - и под руководством работы в ЦОДе и рост во всякое. При очень высокой, повторюсь, для админов зп.
Так то, что ко мне приходило, иногда с 15-20 лет "опыта" сисадмином, я бы отправил двор мести. Ладно студент пришел ничего не знает, дам стипендию для начала и буду учить. Но если ничего не знает человек с 15 лет админства? Если он не знает чем vlan отличается от подсети, а роутер от маршрутизатора - что он в девопсии то сможет?
А меж тем все без исключения говорили, что вот еще полгодика, надо доучиться и пойду в девопсы, там больше платят.
Часто встречаю в организациях отсутсивие devops специалиста и требование к бэк разработчику знаний devops.
Можно сказать,что: Ну а как же? Ты же разработчик, ты отвечаешь за написание и работу кода на всех стендах...
А так же часто встречаю ситуацию, когда нет системного аналитика и его роль тоже на разработчике.
Все таки нюансов много в ИТ и хорошо, когда есть devops специалист на несколько команд, он занимается своей работой, другие участники - своей работой.
>Как мне кажется, ops инженер должен иметь основные знания и представления в области разработки
Как мне кажется, ops инженер должен для начала иметь основные знания и представления в области эксплуатации. Поэтому он называется ops.
И только после получения знания и представлений в области разработки у него есть шанс стать devops - инженером, сочетающем знания и умения эксплуатации и разработки, чтобы создавать неразрывный конвейер.
DevOps и SRE просто модно