5 кейсов, как разработчику помогает знание DevOps-инструментов
IT-сфера большая и многогранная. В ней обитают разработчики, сисадмины, инженеры и многие другие. Как правило, каждый специалист имеет конкретную зону ответственности и действует в её рамках. Однако сегодня всё чаще встречается мнение, что разработчикам было бы неплохо хотя бы на базовом уровне разбираться в DevOps-инструментах — »понимать, что окружает их кроме кода».
Мы пообщались с Владиславом Килиным — тимлидом в компании Coolblue.nl — и узнали, как понимание DevOps-инструментов помогает разработчику улучшать рабочие процессы и эффективно справляться с задачами.
Кейс №1: «DevOps заставляет разработчика выбраться из пузыря и найти то, что облегчит жизнь»
Однажды я пришёл в компанию и увидел любопытную картину: разработчики перед запросом в БД ставили таймер, а после записывали в лог, сколько длился запрос. И это несмотря на то, что в мире уже существовал стандарт OTLP (пусть и непродолжительное время).
Стандарт OTLP отвечает за связанные логи, измерение времени активности приложений и другие параметры. Почти все современные системы сбора метрик и логов умеют работать с этим стандартом и поддерживают различные визуализации (Jaeger, Datadog APM, ElasticSearch APM и др).
Я предложил переписать код на сбор диагностики через OTLP-collector. Коллеги поддержали затею, и мы приступили к её реализации. Это заняло у нас одну пятницу. Потом, конечно, пришлось переписывать и то, как деплоятся сервисы, поскольку возникла новая сущность сборщика телеметрии. Но наша команда получила серьёзный профит:
мы выкинули здоровенные куски ненужного кода, фасады над подключениями к БД и самописные Pipes&Filters для пробрасывания кастомных (а значит, принципиально не поддерживаемых внешними вендорами и клиентами) токенов корреляции;
перешли на общий стандарт, который элементарно поддерживался стандартной библиотекой нашего ЯП;
получили метрики и их удобную визуализацию, а вместе с тем — особые алерты (например, если вызов какого-то запроса к БД или обработка сообщения из Kafka стали аномально долгими) практически бесплатно.
Последнее, кстати, полезно и бизнесу, и команде, поскольку позволяет тратить гораздо меньше времени на расследование узких мест.
Причём тут DevOps? Если разработчик находится в пузыре особенностей языка, платформы или алгоритмов, он читает только связанные с этим новости, узнаёт только о стандартах внутри процесса разработки. И, как следствие, остаётся в неведении о том, насколько развились смежные области. DevOps заставляет выглядывать из этого «пузыря» и обнаруживать, что инструменты эксплуатации тоже могут облегчить жизнь.
Кейс №2: «DevOps — это про то, что разработка не только разрабатывает, но и несёт ответственность за эксплуатацию»
Это было время, когда я работал в логистической компании. Мы делали приложение для частных водителей и заказчиков, которым нужно доставить груз из пункта А в пункт Б. Система работала по принципу аукционов, поэтому пользователям было важно получать актуальную информацию по собственным ставкам. И в случае, если их кто-то перебивал, предлагать новую цену.
Мы тогда только переходили на Kubernetes. Система была не супервысоконагруженная, но ресурсоёмкая. Мы пытались придумать, как реализовать уведомления с учётом, что сервис, отвечающий за аукционы, мог быть запущен в нескольких экземплярах. И пользователь, подключавшийся к бэку, мог получить ответ от любого из экземпляров непредсказуемым образом.
При отправке уведомления, мы должны были гарантировать, к какому бы экземпляру кластера ни был подключен клиент, он точно получит уведомление. Рассуждая в этой парадигме, мы пришли к внедрению RabbitMQ.
Наша топология состояла из fanout-exchange и набора эксклюзивных очередей, привязанных к кластеру API. Таким образом, каждое новое уведомление было доступно каждому приложению из кластера и, следовательно, всем пользователям в режиме реального времени. Мы сделали отказоустойчивую систему для отправки уведомлений, которая работала вне зависимости от того, что происходило с балансировкой нагрузки и инстансами сервиса.
Я часто говорю:»DevOps — это про то, что разработка не только разрабатывает, но и несёт ответственность за эксплуатацию». Если бы мы не задумывались о масштабировании или о балансировке нагрузки, то вполне могли бы ограничиться одной очередью, из которой инстансы API читали бы сообщения одновременно. Это бы привело к тому, что пользователь подключается к одному экземлпяру API, его уведомление улетает на другой, а мы оказываемся под завалами жалоб.
Кейс №3: «DevOps-экспертиза даёт свободу и позволяет самостоятельно строить процессы»
Сейчас я работаю в ритейл-компании, которая продаёт бытовую технику и электронику. Одна из наших услуг — доставка с последующей установкой. Внутри много разного софта, почти весь он серверный и централизованный. У моей команды изолированная зона ответственности: мы работаем над мобильным приложением и живём в режиме »рассказать о статусе заказа и помочь курьеру доставить его». Если для других команд такая изолированность часто оказывается проблемой, нам она, наоборот, на руку. Благодаря DevOps-экспертизе мы можем самостоятельно строить свои процессы — накручивать дополнительные автоматизации, работать с мониторингом и др.
Разберём на примере. Мы используем огромное количество фиче-флагов. Когда заканчивается AB-тестирование, в коде остаются артефакты, которые приходится подчищать. Делать это руками неудобно — всё время забываешь. Максимальная автоматизация, которую могут позволить себе другие команды, просто добавить напоминание «Удалить» или завести задачу в Jira. Мы же написали себе шаг в CD, который перед деплоем приложения на прод пробегает по коду и подсказывает, какие фиче-флаги устарели. Пишет нам в Slack набор рекомендаций, иногда даже с кнопкой «завести задачу в Jira».
Обычно команды, которым новый шаг в CI/CD, сталкиваются с двумя проблемами. Первая — дождаться, пока DevOps-ы обработают запрос. Вторая — убедить DevOps-ов, что эта штука действительно нужна. Поддерживать разные пайплайны для разных команд неудобно, поэтому DevOps-ы склонны центрировать вопросы и отвечать что-то в духе:»У нас есть общий подход. Давайте прежде чем что-то внедрять, продадим внутри компании. Тогда это появится у всех сразу».
Нам же нужно »продать» какую-то идею только в пределах своей команды. Если возражений не возникает, идём к DevOps-ам, объясняем, что хотим сделать, и внедряем.
Разумеется, такое стало возможно только благодаря подтверждённой DevOps-экспертизе. Мы на практике доказали, что умеем делать хорошие пайплайны, поэтому обычно не встречаем сопротивления. Но в этом и смысл: без DevOps-экспертизы вы не сможете понять, что в вашем CI/CD-процессе что-то не так, и предложить достойную альтернативу.
Какие плюсы даёт знание DevOps-инструментов?
Независимость. Когда у DevOps-команды происходит затык, «встаёт» вся разработка кроме нас. Мы умеем «сами себя починить» и не зависим от внешней среды. Хотя это и накладывает дополнительную ответственность.
Заботу о будущем. Следующий кусок после DevOps — SRE. Когда вы думаете о том, что ваше приложение может периодически падать, вы начинаете думать, что и чужие приложения тоже могут падать и становиться недоступными. Поэтому когда пишете приложение, вы задумываетесь, как система будет вести себя, если из строя выйдет один из её элементов.
Кейс №4: «Что насчёт локальной разработки?»
В качестве реляционной базы у нас в компании использовалась старая версия MySQL. Нам это не очень нравилось, и мы подумали, что неплохо бы обновиться до Postgres последней версии или перейти на MongoDB. Но чтобы выбрать наиболее подходящее решение, сначала хотели провести proof of concept.
Если бы мы работали исключительно в удалённом окружении, создание экспериментальной базы данных стало бы настоящей проблемой. Сначала пришлось бы идти к DevOps-ам и слёзно умолять, чтобы они согласились развернуть новую БД.
Но мы умеем работать с DevOps-инструментами (Docker Compose, Vagrant и др.), а потому можем легко воспроизвести ситуацию у себя на машине. И для этого не нужно сражаться за ограниченные ресурсы компании — достаточно рабочего ноутбука.
Мы развернули базу данных на локальной машине и проверили основные моменты. В ходе проверки выяснили, что у MongoDB нет блокировок строк в документах. Соответственно, мы не можем гарантировать целостность данных — будет прав тот, кто последним обновил документ. Мы заранее выявили уязвимость решения и поняли, что оно нам не подходит.
Кейс №5: «Пару слов про логи»
И на практике, и в разнообразных DevOps-чатах регулярно слышу ругань в адрес плохих логов. Когда разработчики много и бессмысленно используют логи, но при этом не умеют писать приложения, которые бы конфигурировались под разные режимы для их сбора. Это боль, которая обычно ощущается, когда команда инфраструктуры говорит что-то вроде:»Мы теперь храним логи только неделю/день/полчаса». Когда разработчики не понимают, сколько стоит хранение логов и как организован их сбор, подобные нововведения воспринимаются особенно тяжело, будто отобрали любимую игрушку.
Недавно мы с командой уехали из Splunk в DataDog, где можно посмотреть, в какую сумму обходится хранение логов. Хотя мы не самый нагруженный сервис, оказалось, что мы стоим значительно меньше ещё менее нагруженных систем — как раз за счёт того, что мы думаем о расходах, когда пишем логи. Плюс, стараемся не писать бездумно Info/Error, а держим отдельно Trace/Debug логи, чтобы сделать наши сервисы ещё дешевле.
Вместо заключения: всегда ли DevOps-экспертиза — must have для разработчика
Всегда ли разработчику требуется знание DevOps-инструментов? Зависит от компании — где-то это более ценно, где-то менее. Например, когда я работал в Ozon, мне вообще казалось, что моя DevOps-экспертиза никому не нужна. Но это только потому что местные DevOps-ы оказались настоящими небожителями, которые сделали всё идеально. Согласитесь, такая ситуация скорее исключение, чем правило.
Сейчас на собеседованиях часто спрашивают про Docker и контейнеризацию — понимаете ли вы, как писать приложения, которые были бы контейнеризируемыми. С точки зрения ежедневной работы, знание DevOps-инструментов помогает снять с себя головную боль »они там что-то сделали, у меня ничего не работает». Да, и в целом, для карьеры это, скорее, плюс — компании ценят сотрудников, которые разбираются в DevOps-методологиях.
Приведу пример: я работал в компании из госсектора, там всё было на Kubernetes. И ценилось, если ты разбираешься во всех этих DevOps-штуках — как устроена сеть, как поддерживать сервисную архитектуру и др. Если даже в такой «олдскульный» сектор проникает культура DevOps, вполне вероятно, что в ближайшем будущем она будет везде.
***
Погрузиться в DevOps-инструменты и познакомиться со всем, что окружает разработчика кроме кода, вы можете на практикуме Слёрма «DevOps Tools для разработчиков». Летний поток стартует 1 июля.
«DevOps Tools для разработчиков»
