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.)
Конференцию открыл Тимоти Листер, который ещё в 1987 (!) году написал книгу про DevOps-практики. Тим много говорил о том, что отличает сильную, успешную команду со здоровой и приятной атмосферой внутри от посредственной и токсичной команды. Особенно запомнилась мысль:
«Хорошая компания полна людей, которые говорят “я не знаю”».
Это про открытость и доверие внутри команды. Атмосфера открытости просто необходима, если у вас есть амбициозная цель. Для этого нужно, чтобы каждый в команде чувствовал себя комфортно и свободно. Это не означает, что в случае появления проблемы участник команды сразу же эскалирует её на всех. Важна атмосфера открытости и возможность в любой момент обратиться к кому-то конкретному (вне зависимости от должности) или ко всей команде и озвучить явно, что требуется улучшить или поменять. Подобная культура формирует спокойный фон для работы, когда каждый знает, что в случае появления вопросов его выслушают.
По моему опыту, для продуктивной и стабильной работы этот фактор имеет большое значение. Ведь вопросы, трения и смена направлений будут всегда. А атмосфера открытости — это универсальный инструмент, который позволяет справляться с личными и командными вызовами.
Ещё одна мысль, которая мне мне кажется правильной: не существует единственной верной формулы для построения культуры в компании.
«Ни одну культуру нельзя назвать идеальной. И ни одну культуру нельзя назвать полным провалом».
Тенденция последнего времени: всё больше конференций включают в программу доклады про управление, коммуникацию, построение команды и культуры. DevOops не стал исключением. Я считаю что это позитивный тренд, ведь эти факторы оказывают на конечный результат даже большее влияние, чем технологические сложности.
«Руководитель не управляет командой, а растит её».
Do it in code (not YAML)! Unlock power of Kotlin DSL for Kubernetes (Виктор Гамов, Confluent, и Фёдор Коротков, Cirrus Labs)
Полустёбный доклад, но он в полной степени выражает боль от написания бесконечных YAML-файлов, их поддержки и (о ужас!) дебага в случае ошибки или опечатки. Это даже привело к появлению отдельных позиций YAML Engineer.
Как всё начиналось? Когда-то были скрипты. Потом их стало больше. И ещё больше. Появилась необходимость унифицировать, упрощать и масштабировать решения. Так в DevOps-мире появился формат YAML и стал стандартом во многих инструментах.
Авторы доклада подумали и сказали: «что-то в консерватории не так».
- Непонятно, как тестировать YAML-файлы.
- Легко допустить ошибку. Причём некоторые ошибки почти невозможно отловить и очень больно исправлять. Например, можно легко указать версию зависимости как число, вместо строки. И потом долго выяснять, почему используется не та версия, которая указана в конфиге. А всё дело в приведении типов и округлении.
- Если ошибка синтаксическая, то она будет выявлена достаточно быстро, на CI. Но это не точно.
Фишкой доклада стала заливка в Kubernetes невалидного конфига, на что он невозмутимо ответил: Too many errors.
Виктор и Фёдор предлагают писать конфигурации на Kotlin DSL, что помогает справиться со всеми этими проблемами. Да, решение интересное и удобное, однако не является универсальным и работает только для k8s. Помимо этого, в случае обновления API нужно также обновить библиотеку.
Pipelines & pods: DevOps with Kubernetes (Burr Sutter, Red Hat)
Лёгкий доклад про общую концепцию и основные компоненты Kubernetes, а также другие модные Ops-инструменты и Ops-практики. Для новичка в теме — то что надо. Он отлично вписался бы в программу конференции для разработчиков, но было странно прослушать доклад такого уровня на специализированной конференции по DevOps. Тем не менее, обзор получился хороший, простой и понятный.
А вот формировать из Java-кода JSON, используя StringBuilder, — как-то слишком. Даже учитывая то, что это demo-проект.
Паттерны и антипаттерны непрерывных обновлений в практике DevOps (Барух Садогурский, JFrog)
В докладе Баруха сложно выделить какую-то одну идею или направленность. Скорее это сборник личного опыта, историй из жизни, примеров «как делать хорошо, а как плохо», баек, прочих хиханек да «факапчиков».
Особенно из этого доклада запомнилась история, когда из-за ошибки в процессе деплоя Knight Capital Group потеряла $440 000 000 за 45 минут и обанкротилась.
Под конец Барух рассказал историю про баг в ПО Airbus A350. Из-за этого бага авиакомпании были вынуждены перезагружать самолёт каждые 149 часов, а для этого его нужно было посадить на землю. А если кто-то забудет это сделать — самолёт зависнет. Такой вот неприятный баг. Проблема простая — в коде происходит overflow. Фикс тоже простой. Но предположим, что перезагрузить самолёт всё-таки забыли, он вылетел рейсом Лос-Анджелес → Лондон и за 3 часа до приземления пилоты осознали, что через час самолёт зависнет. «Хьюстон, у нас проблема». «Сейчас пофиксим!» — ответили диспетчеры, собрали программистов AirBus, пофиксили, всё работает. А что делать дальше? Деплоить новую версию на самолёт по воздуху? Или не рисковать? Барух был настроен решительно: «Деплоить. Хуже уже не будет».
День второй
CDK and infrastructure as a code (Сергей Курсон, AWS)
Сергей рассказывал о AWS CDK (Cloud Development Kit). Это набор библиотек, который позволяет управлять инфраструктурой кодом. Решение спорное, поскольку управление инфраструктурой в императивном стиле — это некий откат назад. Все современные средства автоматизации позволяют описывать инфраструктуру в декларативном стиле (т.е. состояние, которое должно получиться в результате). Тем не менее, у такого подхода есть и преимущества. Например, сильно упрощается процесс тестирования развёрнутой инфраструктуры, а процесс деплоя и принятия решения о том, что и как деплоить, становится намного более гибким. Помимо этого, открываются большие возможности для динамического и крайне гибкого управления инфраструктурой по событиям, признакам или метрикам.
Зачем нам сервисное сито? (Антон Вайс, Otomato Software)
Пожалуй, один из самых лучших и глубоких докладов этой конференции. Под «сервисным ситом» спикер подразумевает Service mesh — отдельный слой облачной инфраструктуры, управляющий общением сервисов между собой. Паттерн Service mesh делегирует множество задач с уровня сервиса (т.е. с прикладного разработчика) на собственно уровень сервисного сита (на DevOps):
- управление безопасностью;
- мониторинг трафика;
- управление трафиком.
Хотя Service mesh как технологии уже несколько лет, автор сделал про неё глубокий доклад и проанализировал историю возникновения, как она эволюционировала и как будет развиваться в ближайшие годы.
Доклад особенно полезен разработчикам, поскольку задачи, которые решает Service mesh, сейчас зачастую решаются на уровне сервисов. А это отнимает у разработчиков дополнительное время и мешает сконцентрироваться на решении бизнес-задач.
Ускоряем интернет-запросы и спим спокойно (Сергей Фёдоров, Netflix)
Сергей работает в Netflix над тем, чтобы для конечных пользователей сервис работал максимально быстро. Все запросы в нём делятся на две большие группы:
- запросы к облаку (динамика);
- запросы к CDN (статика).
Во многих случаях необходимо сделать одновременно запросы и к динамической, и к статической части инфраструктуры. Но в такой схеме есть накладные расходы: нужно установить минимум два соединения, два раза провести TLS Handshake и т.д.
Появилась идея, что если делать запрос только к статической инфраструктуре, установить на неё умный proxy и доверить ей от своего имени делать динамические запросы в облако, то это ускорит клиентские запросы. Команда Netflix реализовала такую схему, провела тестирование на реальных пользователях. Однако стало понятно, что она работает не всегда и не для всех, некоторые запросы начинают обрабатываться хуже.
Поэтому команда решила пойти другим путём. Они придумали схему, которая позволяет для каждого клиента индивидуально принимать решение, как выгоднее выполнять динамические запросы: напрямую с клиента или доверить проксирование этого запроса статической части инфраструктуры.
Это хороший пример того, что не нужно отступать от технических вызовов. Нужно набраться смелости и выбрать компромиссный вариант, если он сделает продукт лучше, а жизнь пользователей проще.
Почему IT-индустрия переживает темные времена, как в этом виноват DevOps, и почему «Капитал» может помочь (Роман Шапошник, ZEDEDA Inc.)
Самый «визионерский» доклад этой конференции. В нём Роман много говорил о том, как связаны (и неразделимы) между собой технологии и капитал. Думаю, этот тезис очень важен для инженеров и понимания, что технологии создаются, чтобы решать конкретные проблемы людей и бизнеса. С таким становится проще приоритизировать задачи и понимать, что важно, а что нет. Также Роман рассказывал, почему политика закрытости и корпорации, всё больше увеличивающие своё влияние, могут привести к глобальному кризису в IT-индустрии. А также в целом об истории и философии сферы информационных технологий.
DevOops — это про развитие
Несколько спикеров спрашивали у зала, кто занимается эксплуатацией и инфраструктурой, а кто разработкой. Результаты меня удивили: распределение примерно 50 на 50. Очень здорово, что всё больше разработчиков хотят понимать, что происходит с их кодом после написания, как приложения разворачиваются и общаются друг с другом. С таким пониманием при написании кода сразу думаешь о том, как он будет работать в живых условиях и где можно подстелить соломки.
Автор: Илья
