Хабрахабр

DevOops 2019 глазами разработчика

image

В этой статье я поделюсь впечатлениями и инсайтами, а также краткими заметками о прослушанных докладах. 29-30 октября в Санкт-Петербурге прошла конференция DevOops. Небольшой disclaimer: поскольку я разработчик, то некоторые мысли и комментарии могут быть с уклоном в Dev, нежели в Ops, но я постараюсь быть как можно объективнее.

И нужно признать, организация и уровень докладов были на уровне. DevOops входит в число мероприятий, которые проводит JUG Ru Group. Помимо этого, были дискуссионные зоны для общения со спикерами, мастер-классы, а также lightning talks — более лёгкие и короткие доклады, в том числе для тех, кто ранее не выступал и хочет попробовать себя в качестве спикера. Конференция длилась два дня, в три потока.

Бо́льшая часть докладов была прямо или косвенно посвящена облакам. Тематическая канва DevOops 2019 — cloud native. И многие пришли специально, чтобы найти ответы. Тема давно уже не новая, однако есть множество неочевидных сложностей, которые возникают в процессе использования облачных технологий. Спикерам задавали практические вопросы, которые действительно волнуют людей. Это было особенно заметно на QA-сессиях после докладов. Почти на каждый вопрос следовали реплики других участников «У нас такая же проблема!» и начиналась оживлённая дискуссия.
День первый

Characters, community, and culture: Important factors for prosperity (Timothy Lister, The Atlantic Systems Guild Inc.)

image

Тим много говорил о том, что отличает сильную, успешную команду со здоровой и приятной атмосферой внутри от посредственной и токсичной команды. Конференцию открыл Тимоти Листер, который ещё в 1987 (!) году написал книгу про DevOps-практики. Особенно запомнилась мысль:

«Хорошая компания полна людей, которые говорят “я не знаю”».

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

Ведь вопросы, трения и смена направлений будут всегда. По моему опыту, для продуктивной и стабильной работы этот фактор имеет большое значение. А атмосфера открытости — это универсальный инструмент, который позволяет справляться с личными и командными вызовами.

Ещё одна мысль, которая мне мне кажется правильной: не существует единственной верной формулы для построения культуры в компании.

И ни одну культуру нельзя назвать полным провалом». «Ни одну культуру нельзя назвать идеальной.

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

«Руководитель не управляет командой, а растит её».

Do it in code (not YAML)! Unlock power of Kotlin DSL for Kubernetes (Виктор Гамов, Confluent, и Фёдор Коротков, Cirrus Labs)

image

Это даже привело к появлению отдельных позиций YAML Engineer. Полустёбный доклад, но он в полной степени выражает боль от написания бесконечных YAML-файлов, их поддержки и (о ужас!) дебага в случае ошибки или опечатки.

Когда-то были скрипты. Как всё начиналось? И ещё больше. Потом их стало больше. Так в DevOps-мире появился формат YAML и стал стандартом во многих инструментах. Появилась необходимость унифицировать, упрощать и масштабировать решения.

Авторы доклада подумали и сказали: «что-то в консерватории не так».

  • Непонятно, как тестировать YAML-файлы.
  • Легко допустить ошибку. Причём некоторые ошибки почти невозможно отловить и очень больно исправлять. Например, можно легко указать версию зависимости как число, вместо строки. И потом долго выяснять, почему используется не та версия, которая указана в конфиге. А всё дело в приведении типов и округлении.
  • Если ошибка синтаксическая, то она будет выявлена достаточно быстро, на CI. Но это не точно.

Фишкой доклада стала заливка в Kubernetes невалидного конфига, на что он невозмутимо ответил: Too many errors.

Да, решение интересное и удобное, однако не является универсальным и работает только для k8s. Виктор и Фёдор предлагают писать конфигурации на Kotlin DSL, что помогает справиться со всеми этими проблемами. Помимо этого, в случае обновления API нужно также обновить библиотеку.

Pipelines & pods: DevOps with Kubernetes (Burr Sutter, Red Hat)

image

Для новичка в теме — то что надо. Лёгкий доклад про общую концепцию и основные компоненты Kubernetes, а также другие модные Ops-инструменты и Ops-практики. Тем не менее, обзор получился хороший, простой и понятный. Он отлично вписался бы в программу конференции для разработчиков, но было странно прослушать доклад такого уровня на специализированной конференции по DevOps.

Даже учитывая то, что это demo-проект. А вот формировать из Java-кода JSON, используя StringBuilder, — как-то слишком.

Паттерны и антипаттерны непрерывных обновлений в практике DevOps (Барух Садогурский, JFrog)

image

Скорее это сборник личного опыта, историй из жизни, примеров «как делать хорошо, а как плохо», баек, прочих хиханек да «факапчиков». В докладе Баруха сложно выделить какую-то одну идею или направленность.

Особенно из этого доклада запомнилась история, когда из-за ошибки в процессе деплоя Knight Capital Group потеряла $440 000 000 за 45 минут и обанкротилась.

Из-за этого бага авиакомпании были вынуждены перезагружать самолёт каждые 149 часов, а для этого его нужно было посадить на землю. Под конец Барух рассказал историю про баг в ПО Airbus A350. Такой вот неприятный баг. А если кто-то забудет это сделать — самолёт зависнет. Фикс тоже простой. Проблема простая — в коде происходит overflow. «Хьюстон, у нас проблема». Но предположим, что перезагрузить самолёт всё-таки забыли, он вылетел рейсом Лос-Анджелес → Лондон и за 3 часа до приземления пилоты осознали, что через час самолёт зависнет. А что делать дальше? «Сейчас пофиксим!» — ответили диспетчеры, собрали программистов AirBus, пофиксили, всё работает. Или не рисковать? Деплоить новую версию на самолёт по воздуху? Хуже уже не будет». Барух был настроен решительно: «Деплоить.

День второй

CDK and infrastructure as a code (Сергей Курсон, AWS)

image

Это набор библиотек, который позволяет управлять инфраструктурой кодом. Сергей рассказывал о AWS CDK (Cloud Development Kit). Все современные средства автоматизации позволяют описывать инфраструктуру в декларативном стиле (т.е. Решение спорное, поскольку управление инфраструктурой в императивном стиле — это некий откат назад. Тем не менее, у такого подхода есть и преимущества. состояние, которое должно получиться в результате). Помимо этого, открываются большие возможности для динамического и крайне гибкого управления инфраструктурой по событиям, признакам или метрикам. Например, сильно упрощается процесс тестирования развёрнутой инфраструктуры, а процесс деплоя и принятия решения о том, что и как деплоить, становится намного более гибким.

Зачем нам сервисное сито? (Антон Вайс, Otomato Software)

image

Под «сервисным ситом» спикер подразумевает Service mesh — отдельный слой облачной инфраструктуры, управляющий общением сервисов между собой. Пожалуй, один из самых лучших и глубоких докладов этой конференции. с прикладного разработчика) на собственно уровень сервисного сита (на DevOps):
Паттерн Service mesh делегирует множество задач с уровня сервиса (т.е.

  • управление безопасностью;
  • мониторинг трафика;
  • управление трафиком.

Хотя Service mesh как технологии уже несколько лет, автор сделал про неё глубокий доклад и проанализировал историю возникновения, как она эволюционировала и как будет развиваться в ближайшие годы.

А это отнимает у разработчиков дополнительное время и мешает сконцентрироваться на решении бизнес-задач. Доклад особенно полезен разработчикам, поскольку задачи, которые решает Service mesh, сейчас зачастую решаются на уровне сервисов.

Ускоряем интернет-запросы и спим спокойно (Сергей Фёдоров, Netflix)

image

Все запросы в нём делятся на две большие группы:
Сергей работает в Netflix над тем, чтобы для конечных пользователей сервис работал максимально быстро.

  • запросы к облаку (динамика);
  • запросы к CDN (статика).

Во многих случаях необходимо сделать одновременно запросы и к динамической, и к статической части инфраструктуры. Но в такой схеме есть накладные расходы: нужно установить минимум два соединения, два раза провести TLS Handshake и т.д.

Команда Netflix реализовала такую схему, провела тестирование на реальных пользователях. Появилась идея, что если делать запрос только к статической инфраструктуре, установить на неё умный proxy и доверить ей от своего имени делать динамические запросы в облако, то это ускорит клиентские запросы. Однако стало понятно, что она работает не всегда и не для всех, некоторые запросы начинают обрабатываться хуже.

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

Нужно набраться смелости и выбрать компромиссный вариант, если он сделает продукт лучше, а жизнь пользователей проще. Это хороший пример того, что не нужно отступать от технических вызовов.

Почему IT-индустрия переживает темные времена, как в этом виноват DevOps, и почему «Капитал» может помочь (Роман Шапошник, ZEDEDA Inc.)

image

В нём Роман много говорил о том, как связаны (и неразделимы) между собой технологии и капитал. Самый «визионерский» доклад этой конференции. С таким мышлением становится проще приоритизировать задачи и понимать, что важно, а что нет. Думаю, этот тезис очень важен для инженеров и понимания, что технологии создаются, чтобы решать конкретные проблемы людей и бизнеса. А также в целом об истории и философии сферы информационных технологий. Также Роман рассказывал, почему политика закрытости и корпорации, всё больше увеличивающие своё влияние, могут привести к глобальному кризису в IT-индустрии.

DevOops — это про развитие

Несколько спикеров спрашивали у зала, кто занимается эксплуатацией и инфраструктурой, а кто разработкой. Результаты меня удивили: распределение примерно 50 на 50. Очень здорово, что всё больше разработчиков хотят понимать, что происходит с их кодом после написания, как приложения разворачиваются и общаются друг с другом. С таким пониманием при написании кода сразу думаешь о том, как он будет работать в живых условиях и где можно подстелить соломки.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть