Нужно ли разработчику знать DevOps-инструменты? Кейс из практики
Сегодня предлагаем порассуждать на злободневную тему. IT-сфера большая и многогранная. В ней обитают разработчики, сисадмины, инженеры и многие другие. Обычно у каждого специалиста есть чёткая зона ответственности, в рамках которой он действует.
Но сегодня всё чаще встречается мнение, что разработчикам было бы неплохо разбираться в DevOps-инструментах. Хотя бы на базовом уровне, чтобы »понимать, что ещё окружает их кроме кода».
Мы пообщались с тимлидом Coolblue.nl Владиславом Килиным и нашли в его практике как минимум пять кейсов, когда DevOps-экспертиза была на пользу команде разработки. Одним из кейсов делимся с вами.«DevOps заставляет разработчика выбраться из пузыря и найти то, что облегчит жизнь»
Однажды я пришёл в компанию и увидел любопытную картину: разработчики перед запросом в БД ставили таймер, а после записывали в лог, сколько длился запрос. И это несмотря на то, что в мире уже существовал стандарт OTLP.
Стандарт OTLP отвечает за связанные логи, измерение времени активности приложений и другие параметры. Почти все современные системы сбора метрик и логов умеют работать с этим стандартом и поддерживают различные визуализации (Jaeger, Datadog APM, ElasticSearch APM и др).
Я предложил переписать код на сбор диагностики через OTLP-collector. Коллеги поддержали затею, и мы приступили к её реализации. Это заняло одну пятницу, но наша команда получила серьёзный профит:
мы выкинули здоровенные куски ненужного кода, фасады над подключениями к БД и самописные Pipes&Filters для пробрасывания кастомных токенов корреляции;
перешли на общий стандарт, который элементарно поддерживался стандартной библиотекой нашего ЯП;
получили метрики и их удобную визуализацию практически бесплатно.
Причём тут DevOps?
Если разработчик находится в пузыре особенностей языка, платформы или алгоритмов, он читает только связанные с этим новости, узнаёт только о стандартах внутри процесса разработки. И, как следствие, остаётся в неведении о том, насколько развились смежные области. DevOps заставляет выглядывать из этого «пузыря» и обнаруживать, что инструменты эксплуатации тоже могут облегчить жизнь.
Другие кейсы из практики Владислава можно прочитать в этой статье.
Получается, DevOps Tools — must have?
Зависит от компании — где-то это более ценно, где-то менее. Но на собеседованиях часто спрашивают про Docker и контейнеризацию — понимаете ли вы, как писать приложения, которые были бы контейнеризируемыми. С точки зрения ежедневной работы, знание DevOps-инструментов помогает снять с себя головную боль »они там что-то сделали, у меня ничего не работает». Да, и в целом, для карьеры это, скорее, плюс — обычно компании ценят сотрудников, которые разбираются в DevOps-методологиях.
Но где взять эту «DevOps-экспертизу»?
Долгий, но бесплатный путь — погружаться в технологии самостоятельно.
Быстрый — отправиться на наш летний поток «DevOps Tools для разработчиков». Обучение ориентировано на тех, кто работал только на одном стеке или плохо понимает, как архитектурно связаны разные инструменты. Через теорию и практику мы по этапам покажем, что существует вокруг вашего кода, и научим с этим работать.
Вроде интересно, но сомневаюсь
Для тех, кто сомневается, у нас есть крутое предложение — «Подписка Ян» на три месяца. В неё входит «DevOps Tools для разработчиков», а вместе с ним ещё 19 курсов. Совокупная стоимость всех курсов — больше 1 000 000 рублей, но, оформляя подписку, вы платите значительно меньше — 60 000 рублей для тарифа с видеолекциями и практикой и 90 000 рублей для тарифа с видеолекциями, практикой, потоками, интенсивами и поддержкой наставников в закрытом чате.
А ещё подписка — это суперполезно. Сначала вы сможете разобраться в основных эксплуатационных инструментах на «DevOps Tools для разработчиков». А затем при необходимости углубиться в частные кейсы на профильных потоках по Jenkins, RabbitMQ и др.
