Всем привет, Хабровчане!
Хочу рассказать про современный мир IT и его подходах. Сегодня каждая компания говорит про DevOps и более чем уверенна, что он у них есть. Читая вакансии на множестве ресурсов, я часто вижу объявления "требуется DevOps инженер" с расписанным стеком тех или иных модных инструментов. Но вот что самое интересное, что больше ничего и не требуется, главное знать как пользоваться теми самими инструментами. То есть "DevOps инженер" - это такой оператор, который знает куда тыкать и где просто нужно описать пайпллайн, не вдаваясь в подробности разработки. Когда эта методология только пришла к нам, порог вхождения был довольно высок, а сегодня пара курсов дают пропуск в этот мир и это грустно.
Ну ладно, к чему я это все, в больших компаниях, а именно "кровавый энтерпрайз" бывают легаси проекты, где нет современных инструментов и переход на них иногда невозможен, или он дороже самой разработки. Вот как раз в этот момент и требуется настоящий подход методологии DevOps, где порой нужно ковыряться как в коде, так и в разработке своих реализаций того, что не предоставляется из коробки. Какими же знаниями и компетенциями должен обладать Ops инженер?
Как мне кажется, ops инженер должен иметь основные знания и представления в области разработки, речь не идет о том что он должен знать полностью ООП. Но уметь понять что написано в программе при ее развертывании и "траблшутинге", а не просто в случае падения бежать к команде разработки со словами - "Все не работает, разбирайтесь и напишите как развертывать". Также помогать команде разработки в принятии архитектурных решений, а не просто выполнять таски в рамках спринта.
Сегодня, пайплайн для CI можно написать вообще без его понимания, роли в ansible также не стоит труда найти на просторах git репозиториев.
Давайте на примере, как-то на одном из проектов был java продукт. Этот сервис время от времени падал, а именно из-за памяти, логи ничего не показывали, мы со стороны SRE команды настроили сброс дампа приложения в случае падения, далее стали разбирать при помощи Eclipse Memory Analyzer (MAT). В итоге, после нашего разбора мы нашли место утечки памяти и посмотрели на отчет потоков, выяснилось что поток замыкался на себе и уходил в вечное ожидание. Суть в том, что мы уже с анализом и указанием места в коде, пришли к команде разработки. Что мы получили вот от таких наших действий? Мы получили быстрый фикс и выкатили это в прод. Мы ускорили процесс! И получили результат. Мы не ждали пока разработчики посмотрят и решат в свободное время проблему и приложение на продакшене будет аффектить клиентов.
Еще из примеров, подхода методологии и концепции. Не так давно я поменял место работы, в новом месте используется TeamCity. Вроде бы ну CI система и что, но вот в компании выкатка происходит в виде релизов, то есть собирается список компонентов, а потом в отведенное время происходит их развертывание на продакшене (continuous delivery) и вот первый релиз, и ребята в UI TeamCity руками тыкают кнопки выбирая ветки и джобы. На один компонент уходило 2/3 минуты, а их было 28 ,то есть минимум 56 минут. Такой подход меня не устроил, я принял решение написать утилиту для ускорения процесса, а также более простого представления самого релиза. Вот тут можно посмотреть на утилиту https://github.com/sergey-show/teamcity-deploy
Суть утилиты в том, что самописный инструмент покрыл то, чего не было из коробки. Теперь описание релиза хранится в репозитории в виде yml файла, далее утилита сверяет его и применяет в TeamCity посредством API, запуская все джобы одновременно (если нет требований по приоритету).
В итоге релиз из 28 компонентов выкатывается в течении 15 минут с последующей проверкой. Получилось 15 минут вместо 56 минут, на сэкономленное время можно пойти почитать, погулять или отдохнуть. То есть это решение нам позволило ускориться и исключить фактор человеческой ошибки.
Еще один из частых примеров, что доводилось встречать, упаковывать в контейнеры и в k8s все без разбора. Внедрять k8s потому-что модно. А многие ли задаются вопросом - "а вот нужно ли?".
Концепция сборки должна быть такой, сам сервис или код должен собираться так, чтобы его можно было упаковать и развернуть где угодно (со схожей архитектурой конечно-же).
И таких примеров у меня много, инструменты меняются и их можно выучить, а вот подход и мышление в этой методологии это основополагающая.
Всем добра и позитива, развивайтесь, обучайтесь и творите :-)
Комментарии (16)
stackjava
00.00.0000 00:00+3Часто встречаю в организациях отсутсивие devops специалиста и требование к бэк разработчику знаний devops.
Можно сказать,что: Ну а как же? Ты же разработчик, ты отвечаешь за написание и работу кода на всех стендах...
А так же часто встречаю ситуацию, когда нет системного аналитика и его роль тоже на разработчике.
Все таки нюансов много в ИТ и хорошо, когда есть devops специалист на несколько команд, он занимается своей работой, другие участники - своей работой.
AntonVirtual
00.00.0000 00:00>Как мне кажется, ops инженер должен иметь основные знания и представления в области разработки
Как мне кажется, ops инженер должен для начала иметь основные знания и представления в области эксплуатации. Поэтому он называется ops.
И только после получения знания и представлений в области разработки у него есть шанс стать devops - инженером, сочетающем знания и умения эксплуатации и разработки, чтобы создавать неразрывный конвейер.
LabEG
Я заметил такую большую проблему в мире, не только в россии, что нехватку хороших специалистов закрывают набором низкоквалифицированных специлиастов. В первую очередь во фронте и девопсе. У бекендером дела получше, но тоже такое есть.
В частности девопсов набирают не из девов, а из опсов, т.е. системных администраторов. Отсюдого и описанные вами проблемы. Сисадминов привыкших работать в концепции "работает не трожь" и "зачем развиваться если и так работает" внедряют в айти где они и продолжают работать в этих концепциях. В то время как айти требует подхода Continius Evolution, т.е. непрерывного развития и прогресса. Не зря в профессии девопс первым идет дев, в первую необходимо уметь собирать софт, его разворачивать, настраивать мониторинг, знать чего собирать в этом мониторинге, настраивать логирование и следить за логами. Всем этим 99% девопсов не занимается. Вместо этого они ставят npm зависимости в проде в контейнер во время запуска и запускают исходники в режиме dev и считают это потрясающе выполненной работой.
encore-show Автор
Вот благодаря вам и таким комментариям, я верю в то, что не все потерянно. А так все верно, согласен под каждым словом. Да кстати и разработчиков это также касается, выучив фреймворк но не понимая как под капотом это работает, стало нынче модно. Кстати в моем окружении сейчас уже фильтр появился, на тех что делают код с помощью ChatGPT, с такими я перестаю о чем либо общаться)
micbal
Вы правы, что наблюдаемость, это метрики, логи, tracing, но кто кроме разработчика напишет loging во всех местах debug, в критических info и error? Кто кроме разработчика сформирует нужные метрики и даст возможность их забирать по пробам? Кто кроме разработчика отправит в коллектор сигналы tracing'а? Разработчикам просто нужно больше учиться, а не валить все на зону ответственности ops. Это же касается и дебага, поиска текущей памяти и т.п.
encore-show Автор
тут все же нужна совместная работа, по метрикам к примеру. SRE/OPS должны во-первых четко понимать что такое системные метрики и метрики приложения, далее совместно выявляют нужные метрики м правила для них. Хотя из опыта мне приходилось лезть в исходный код и катчить то или иное чтобы помочь команде разработки быстрее исправить приложения. Но опять же, к чему я это, не перекладывание. а общее развитие. А так вся суть методологии коту под вост, те делают это, а те то. Про обучение - это золотые слова
micbal
Метрики железа и окружения лучше вообще разделить от метрик самописной части. Только так будет видна полная картина. Но при микросервисной архитектуре без трейсинга часто метрики бесполезны.
encore-show Автор
верно, лишь бы был архитектор и дизайн этого всего, а не так что каждый микросервис разрабатывается в своем мире и понимании. Слаженость
ky0
Спасибо вам за комментарий — он на сто процентов совпадает с моим гротескным примером ощущения эйчарами «девопс vs сисадмин». А, между тем, то, что вы написали — это классический пример фигового админа.
З.Ы. имхо, в термине «девопс» «дев» идёт первым попросту для благозвучности. Эксплуатация есть эксплуатация, разница в мере интеграции её с разработкой.
encore-show Автор
посмотрел на вашу статью, плюсую ) рад что есть единомышленники
awfun
Нехватку хороших специалистов закрывают более слабыми - это не проблема, но объективный тренд. Так же как нехватку мощных серверов закрывают множеством маленьких. К сожалению, в мире людей нет кубернетеса для автоматического управления начинающими специалистами.
citius
Лол, я то как раз "из сисадминов", но наверное 90% попадавшихся разработчиков как раз и были теми самыми "node_modules в контейнер", и что такое мониторинг не слышал из них никто. Потому что набирали жабаскриптеров из верстаков-фронтендеров.
Я утрирую конечно, но не сказать чтобы очень уж сильно. Экономия помноженная на кучу войтивайти инфоцыганских курсов дает вот такой вот выхлоп.
Так что не нужно обобщать. Везде есть и свои "работает не трогай", и "развиваться не надо раз деньги платят", независимо от профессии и бекграунда.
gudvinr
В девопс первым идёт дев, потому что опсдев произносится сложнее вне зависимости от языка.
AntonVirtual
Основная беда не в том, что из сисадминов. В конце концов DevOps = Dev + Ops. Т.е. специалистов и в разработке, и в эксплуатации. Просто вы разработчик и смотрите на сисадминов традиционно как на чужих людей и даже врагов.
Беда в том, что из плохих и безграмотных сисадминов, которые не смогли вырасти в Ops, и тем более не смогли вырасти из эксплуатации в дизайн и архитектуру (ЗП сравнимы со средними по девопсерии).
В конечном итоге получается, что эти девопсы не умеют НИ в дев НИ в опс.
Пару лет назад хотел взять себе пару админов в офис на очень хорошие деньги (для админов) на немного хелпдеска, немного того, немного этого - и под руководством работы в ЦОДе и рост во всякое. При очень высокой, повторюсь, для админов зп.
Так то, что ко мне приходило, иногда с 15-20 лет "опыта" сисадмином, я бы отправил двор мести. Ладно студент пришел ничего не знает, дам стипендию для начала и буду учить. Но если ничего не знает человек с 15 лет админства? Если он не знает чем vlan отличается от подсети, а роутер от маршрутизатора - что он в девопсии то сможет?
А меж тем все без исключения говорили, что вот еще полгодика, надо доучиться и пойду в девопсы, там больше платят.
ky0
И чем же роутер отличается от маршрутизатора?
AntonVirtual
Каких только вариантов я не наслушался. Основной, конечно, что роутер - это домашняя хрень для интернета, а маршрутизатор - это то, что в корпоративе используют.