Заявки на доклады

Поиск по тегам:
Показать только принятые доклады

Платформа и платформенные команды

Расскажем про то как командой собрали технологическую платформу, и самостоятельно дошли от автоматизаций и IaC до self-service портала для разработчиков. Почему inventory и git-ops не хватало, и мы собрали свой CMDB сетап для сервисов платформы от k8s namespace до топиков Kafka. Как генератор форм на React и консьерж-mvp разогнали наш небольшой эксперимент до полноценного решения. Про то как верхнеуровневый workflow с интеграциями ITSM, Jira и вебсокетами облегчил жизнь дежурным, и улучшил метрики команды. В конце концов зачем ansible и AWX обернули в n8n. А еще как пытаемся и каталог услуг и cloud-like опыт, почему важны мастер-данные по проектам и информационным системам, и как думаем тиражировать на соседей по ИТ.

Программный комитет ещё не принял решения по этому докладу

1) MS Service Fabric - как отказоустойчивая платформа
2) Docker for windows использовать или нет
3) Плюсы и минусы технологии

Программный комитет ещё не принял решения по этому докладу

Всем давно известно, что pod в Kubernetes может включать в себя несколько контейнеров. Например, один для приложения, второй для Service Mesh, третий – журналирование, а еще четвертый, пятый и т.д. В итоге много контейнеров, много вопросов:
* Зачем нужны дополнительные контейнеры, какие задачи они должны решать, а какие нет?
* Как изолировать платформенные контейнеры от пользовательских приложений?
* Как организовать автоматизацию процесса и не сломать кластер Kubernetes?
Давайте поговорим об этом в рамках доклада: обсудим, чем паттерн sidecar отличается от ambassador, узнаем про опыт использования типовых sidecar-инжекторов и универсальный подход к работе с дополнительными контейнерами.

Программный комитет ещё не принял решения по этому докладу

Инфраструктура как код

Инфраструктура как код - новый buzz word
Все хотят, чтобы было просто быстро и дешево - решить сложную и комплексную задачу. Чтобы легко было управлять и передавать из команды в команду на поддержку, модернизацию и обновление. Agile!
Работая с terraform на многих проектах, хотелось найти такой подход к архитектуре кода, чтобы он хорошо подходил сразу по многим требованиям:
подходило для проекта в начальной стадии - общих ресурсов по максимуму
и для проекта в релизной стадии - когда нужна изоляция dev и prod
Давала достаточную безопасность в pipeline и разграничение доступа к управляемым IaC ресурсам.
Cкорость и минимизация времени выполнения pipeline
DRY - как можно меньше повторяющегося кода
Гибкость в использовании такого кода
Минимальный TTM и TCO
Максимальная возможная автоматизация
Простой git flow

Спешу поделиться тем, что в итоге получилось.

Программный комитет ещё не принял решения по этому докладу

За более чем 10 лет DevOps было сформировано много практик, которые помогают ускорять разработку.
Обычно говорят про CI/CD и контейнеры, но это всего лишь одна сторона вопроса.
Другая важная составляющая — изменение модульности и интеграционных паттернов в самих приложениях.
Третья составляющая — описание инфраструктурных компонентов в виде кода.

Встает интересный вопрос — прошли ли практики написания инфраструктурного кода такую же трансформацию разработки какая произошла в разработке?
Или все по прежнему пишут инфраструктурные монолиты, которые запускаются только если всей командой взяться за руки?
Кто на самом деле являлся драйвером DevOps-трансформации?

Поговорим об этом на докладе.

Программный комитет ещё не принял решения по этому докладу

DevOps был призван сломать стену между dev и ops, но оказалось ломать её согласны только «девопс-инженеры» и то только для того чтобы построить себе уютный колодец из её обломков.

В докладе спускаемся на дно колодца и обсуждаем проблему токсичности в DevOps сообществе.

Доклад принят в программу конференции

В своем докладе я раскрою тему создания и использования операторов Kubernetes. Обсудим следующие вопросы:
- Для чего нужны операторы, сценарии использования
- Архитектура и внутреннее устройство оператора
- Создание своего оператора на Go, инструменты и практики
- Тонкости и подводные камни при создании оператора

Доклад принят в программу конференции

FluxCD v2 это яркий и преданный представитель GitOps принципов.
За несколько лет был проделан путь от просто полезного инструмента до зрелой масштабируемой GitOps платформы.
Материалов о том, как организовать структуру GitOps репозиториев, не хватает, и на старте сложно предсказать с какими ограничениями и сложностями можно столкнуться на крупных масштабах.
В своем докладе я попробую показать FluxCD непредвзято, со всеми плюсами и минусами, расскажу о чем стоит подумать при добавлении инструмента в свою инфраструктуру. В каких случаях он подойдет идеально, а в каких будет лишь модной добавкой, скорее препятствующей эффективности.
Также продемонстрирую возможности модульного подхода к управлению множеством кластеров, по максимуму используя принцип DRY и сохраняя структурность и читаемость кода инфраструктуры.

Программный комитет ещё не принял решения по этому докладу

Мониторинг, метрики, observability

Когда у вас большой сложный продукт, который разрабатывают несколько команд (или даже несколько десятков), трудно избежать ситуации, когда прод лежит, бизнес стоит, а инженеры несколько часов перекидывают стрелки друг на друга, и у каждого "в Багдаде все спокойно".
В такой ситуации жизненно важен не только и не столько подходящий инструмент, сколько общий подход для мониторинга всех кусочков вашего приложения.
В докладе я расскажу, как мы объединили несколько очень разных команд единым Observability, как с помощью исключительно технических метрик отслеживаем здоровье бизнес-процесса, и как все это помогает нам мгновенно находить root cause во время сбоя, если он все же произошел.

Доклад принят в программу конференции

Балансировщик нагрузки - инструмент мощный, но при этом сложный. В своём докладе я расскажу, как можно упростить работу с балансировщиками с помощью веб-интерфейса.
Веб-интерфейс существенно снижает порог вхождения для начинающих пользователей, а тем, у кого же есть опыт работы с балансировщиками через командую строку , очень облегчает работу. Мой продукт — Roxy-WI — практически не имеет аналогов.
Я расскажу, как можно через веб-интерфейс управлять HAProxy, Nginx и KeepAlived.
Покажу, как реализованы следующие функции:
- мониторинг доступности
- сохранение логов, действий
- настройка групп доступа (разрешений, разные роли)
- статистика всех серверов
- создание конфигураций серверов
- просмотр и фильтрация логов в в одном месте
- уведомления о событиях в телеграмм
- установка и настройка кластера высокой доступности.
В заключение разберу несколько практических кейсов и расскажу о планах по дальнейшему развити продукта

Программный комитет ещё не принял решения по этому докладу

Архитектура систем

1. В чем суть zero trust. Как делать развертывание приложений безопасно.
2. Варианты имплементации zero trust в рамках кластера k8s (Service-mesh, CNI).
3. Как сделать безопасно и быстро. Баланс между уровнем безопасности и временем потраченным на его настройку.
4. Использование Calico. Разберем кейсы, посмотрим код.

Программный комитет ещё не принял решения по этому докладу

Построение GEO-распределенной инфраструктуры в быстроменяющихся условиях, в сжатые сроки.

Программный комитет ещё не принял решения по этому докладу

DevOps пришел к нам внезапно:

- глобально накрыл волной всю IT сферу в 2017-18гг (DevOps, GitOps, IaC..)
- изменил подход к разработке во множестве компаний (Kubernetes, OpenShift, CI/CD..)
- показал нам свои преимущества и недостатки (возросший time to market, излишний Agile, error budget..)
- повторно накрыл новыми изменениями всю IT сферу в 2019-21гг (Kubernetes, OpenShift, CI/CD уже везде, активно появляются SaaS, PaaS..)

А что дальше?

В сегодняшнем докладе, мы поговорим о:

- как DevOps менялся из года в год?
- какой DevOps сейчас?
- чем текущие боли DevOps отличаются от прошлых лет?
- куда движется это направление и к чему придет? к чему стоит готовиться? Может быть новое это давно забытое старое?

Программный комитет ещё не принял решения по этому докладу

“То самое мяско, которое нужно про микрофронты”.

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

Я расскажу о том, как мы в Cloud изменили стандартные подходы к проектированию приложения...

Из доклада вы узнаете:
* какие боли несет в себе микросервисный подход;
* как не создать микросервисный монолит;
* оптимизации, оптимизации и еще раз оптимизации;
* как работать с консистентностью и Bus-фактором;
* как следить за качеством;
* …

Приходите, скучно не будет.
Доклад основан на реальных событиях.

Программный комитет ещё не принял решения по этому докладу

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

Для поддержки групповых политик в ОС «Альт» было разработано 2 набора компонентов:
1) средства применения групповых политик в соответствии со спецификациями Microsoft для операционных систем Windows
2) инструменты администрирования объектов групповых политик(GPO) на уровне назначения соответствующих настроек и на уровне редактирования соответствующих шаблонов групповых политик (GPT).

Программный комитет ещё не принял решения по этому докладу

Проблема:
Команде для нормального развития продукта нужны принципы как и что делать и на уровне кода и на уровне решения
Помочь могут арх принципы, но есть две проблемы
1. Команда не понимает что это
2. После написания их никто не применяет
Как собрать архпринципы, в которые команда поверит
Как не оставить их на уровне чекстайла и автоматизировать

Программный комитет ещё не принял решения по этому докладу

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

Действительно, с каждый годом, кол-во javascript кода, который нужно доставить на клиент, только растет, ведь мы пишем фреймворки для фреймворков. Но, действительно ли это проблема?

Разработка приложения на любом фреймворке строится из множетсва этапов, прежде чем пользователь сможет его использовать. И что удивительно, каждый из этих этапов, оказывается, мы можем оптимизировать. В докладе расскажу про современные решения, которые позволяют оптимизировать приложения на уровне фреймворка.

Программный комитет ещё не принял решения по этому докладу

SRE-практики

Как эксплуатировать сервисы в условиях нехватки автоматизации.

Программный комитет ещё не принял решения по этому докладу

В докладе я расскажу как умение погружаться в код и отладку сторонних продуктов помогает нам повышать стабильность и находить исходную причину их отказов на примере реальных сбоев высоконагруженного сервиса мониторинга с входящим потоком 2,5Гбайт/сек, использующего Elasticsearch и VictoriaMetrics под капотом.

Программный комитет ещё не принял решения по этому докладу

Паттерн рейтлимитера кажется одним из самых очевидных паттернов. Так ли он просто на самом деле? Мы посмотрим как паттерн рейт-лимитера эволюционировал с 1994 года, на каком уровне можно применять паттерн, достоинства и недостатки каждого подхода. Не обойдемся без математики и шагнем дальше leaky bucket. Нальем немного философии - возможны ли рейтлиметеры без состояния или нет... И да, мы обсудим не менее 10 точек установки рейт-лимитеров в распределенных приложениях.... Как бонус обещаю роад-мап по устранению техдолга для задач с рейтлимитером и почему идея Сейчас добавим istio и всё заработает само может привести к фиаско в крупных приложениях.

Доклад принят в программу конференции

Безопасность

В случае компрометации учетной записи разработчика от CI/CD системы, у злоумышленника появляется возможность внести несанкционированные изменения в исходный код, а при плохой настройке ролевой модели - поверхность атаки многократно увеличивается. Для мониторинга изменений кода и подтверждение легитимности необходимо использовать сторонний механизм, который никак бы не зависел от CI/CD.
В докладе я предлагаю рассмотреть такой механизм - это git подпись коммитов. Проверка этой подписи и принятие решения о легитимности изменений.

Программный комитет ещё не принял решения по этому докладу

История о том, как мы превратили классический "отдел DevOps" в продуктовую команду с сильным техническим центром. В докладе расскажу:
- Как нам помогла Spotify модель и почему DevOps трансформация лучше ложится на продуктовый подход
- Какие топологии команд попробовали прежде, чем перешли в текущий формат, и с какими болями столкнулись в процессе перехода
- Как трансформация повлияла на ТТМ и отказоустойчивость сервисов
- С какими задачами сталкиваемся сейчас. Как сделать единую систему грейдов для инженеров, находящихся в совершенно разных командах? Как настроить дублирование и дежурства, учитывая часовые пояса?
- Что у нас пока что не получилось, и какие планы на будущее.

Программный комитет ещё не принял решения по этому докладу

Митапы и workshop

Ни один современный проект по разработке программного обеспечения не обходится без инструмента для хранения результатов сборки ПО (артефактов), а также доступа к этим артефактам для их развертывания или сборки других артефактов.

Такие инструменты называются менеджерами бинарных репозиториев (МБР). Наиболее известные из них — JFrog Artifactory и Nexus Repository. Но полноценное использование этих МБР подразумевает покупку лицензий, а это может быть затруднительно сейчас.

Artipie — это бесплатный инструмент для управления артефактами с открытым исходным кодом. Это не просто сервис — это конструктор, который включает в себя множество компонентов для обеспечения поддержки Maven, Docker, Debian, NPM, Go, Helm, Ruby, Python, Anaconda, HexPm, Composer. Также он позволяет использовать различные варианты хранения данных, включая пользовательские. Artipie основан на принципах реактивности и асинхронности.

Доклад будет интересен инженерам, ответственным за CI/CD. Вы узнаете, как с использованием Artipie с нуля создать приватные репозитории Maven и Docker на примере сборки и развертывания простого Java-приложения.

Программный комитет ещё не принял решения по этому докладу

TechLeadы и Синьоры

Коллаборативные практики проникают в IT на всех уровнях разработки: парное программирование, архитектурные комитеты, профессиональные комьюнити. Ex nihilo nihil fit - говорили римляне.

Мы рассмотрим историю становления коллаборативных практик в IT, как одной из образовательных форм деятельности базирующиихся на ценностях: открытости, безопасности и вовлеченности. Образование - базис современного общества и, логично, что паттерны поведения, принятые в образовательной среде непосредственно влияют на высокотехнологические отрасли.

Мы пройдем по пути развития образования - эволюции образовательного процесса, обусловленного гео-политическими и социальными изменениями общества, и увидим, как образовательные стандарты проникли в IT. Обсудим, почему сотрудники стали чаще менять работу, и почему - это тенденция не временная, а - вектор ближайшего десятилетия (а может быть и более долгосрочного периода), мало того, обусловленный Болонским процессом - документом, изменившим международные образовательные стандарты и сделавшим постоянную миграцию учеников между учебными заведениями и обмен знаниями - неизбежной реальностью. Детально рассмотрим несколько коллаборативных практик, которые стали "базовыми" во многих компаниях, с точки зрения ценностного подхода, обсудим, что дает развитие, каждой из них в частности, и их вместе, и какие фокусировки будут способствовать качественному профессиональному росту сотрудников и продуктов.

Гео-политическая ситуация и экологическая дестабилизация в мире заставляют любую индустрию быстро реагировать на изменения, и IT отрасль не исключение. DevOps - это культура, философия направленная на трансформацию за счет принципов совместной работы на достижение общих целей. Коллаборативный подход - основа DevOps и, понимая ценности практик, предпосылки, зародившие их именно в известной нам форме - можно качественнее выстраивать процессы и достигать лучших результатов.

Надеюсь, доклад будет интересен и для С-level, и для руководителей, в чью зону ответственности входит выстраивание коммуникации и корпоративной культуры. А ещё для инженеров, которые понимают, что ценность она всегда в людях и в том, чего можно достичь совместно.

Программный комитет ещё не принял решения по этому докладу

Трансформация

DevOps в глазах многих руководителей стал "серебряной пулей", которая решит многие проблемы и приведет к процветанию компании и поможет в самых запущенных случаях.
Со стороны специалистов, это слово решает финансовые вопросы и поднимает собственную самооценку.
Так что такое DevOps на самом деле ? зачем он нужен в современных процессах компании ?
Как перестать беспокоиться и начать жить.

Программный комитет ещё не принял решения по этому докладу

Разработка в блокчейне отличается от разработки обычного централизованного сервиса. Мы привыкли, что devops в разработке уже не является редкостью и его наличие существенно ускоряет процесс разработки и тестирования.

В мире блокчейна devops тоже есть, но занимаясь им в блокчейне важно учитывать множество особенностей, о которых я хочу рассказать в докладе, в рамках которого раскрою:

- основные особенности и отличия блокчейн-разработки от разработки централизованных сервисов;
- как строится окружение разработчика в блокчейне и из каких элементов оно состоит;
- пример построение непрерывной интеграции и автоматического развертывания в блокчейне;
- как «экономить» газ при деплое и не разориться при обновлении. И почему вообще можно разориться от одного git push в блокчейне

Программный комитет ещё не принял решения по этому докладу

Практики разработки и тестирования

Тезисы для публикации
История о том, как начать развивать техническую культуру команд в Enterprise и не сгореть:
- Наш путь в исследовании технической зрелости команд - от опроса и первых проблем до имплементации и результата, или как помочь команде повысить эффективность производственного процесса.
- Какую модель эффективного взаимодействия с командами мы нашли, и как интеграция с соседними ключевыми направлениями помогает нам достичь результата.

Программный комитет ещё не принял решения по этому докладу

Изменять конфигурацию узла Kubernetes нужно не только в момент создания кластера, но и при изменениях в инфраструктуре и при обновлениях кластера. Хорошо, если узлы можно автоматизированно пересоздать или изменения не требуют перезагрузки узла. А что, если нет, и узлов в кластере под сотню?

В докладе будут рассмотрены распространенные варианты реализации с помощью Ansible, Cluster API, OpenShift Machine Config с разбором плюсов и минусов и предложен собственный оператор с описанием основных решений:
1. Элементы конфигурации — чем управляем.
2. Логика контроллеров (как не уронить весь кластер одним движением).
3. Drift prevention & self healing.
4. Как масштабировать решение на сотни узлов.

Доклад принят в программу конференции

В современных реалиях не так просто прийти в бизнес и сказать - "Давайте всё автоматизируем и всё будет хорошо!" Нет, это так не работает, особенно в крупном enterprise. А если у вас ещё и нет единого процесса, по которому будет один понятный путь, то каждый будет, кто в лес по грибы, кто домой за скатертью самобраной приходить со своими идеями по разным путям.
Необходимо выстроить процессы, составить набор базовых требований и договориться со всеми участниками данного процесса, но и это ещё не всё. Для этого должен быть механизм, некий процесс, который позволит выстроить понятный прозрачный путь. Который позволит в явном виде показывать всем участникам цикла разработки, в том числе и бизнесу, с использованием понятных для всех метрик, на основе зрелости систем, полезность автоматизации в компании.
Я расскажу Вам о том, как мы внедряли механизм с процессами матрицы зрелости, сколько внедряли, и к каким результатам это привело за несколько лет. Мы с Вами пройдём путь от идеи внедрения до результатов внедрения с учётом трудностей внедрения, и появления побочных процессов, вроде базовых требований на старт проектов при работе с вендорами.

Доклад принят в программу конференции

Мы расскажем про полостью локальную инфраструктуру для разработки kubernetes-native ПО на примере разработки Luntry. Как купив 2 сервера в самом начале, можно пережить 3х рост количества микросервисов, и трехкратный рост команды. Как при этом минимизировать ручную работу, сделать разработчиков довольными и не платить за облака.

Программный комитет ещё не принял решения по этому докладу

Внедрение Best Practice в деплой In-Memory Tarantool. Основной подход автоматизации деплоя Tarantool-кластера без Enterprise поддержки.

Программный комитет ещё не принял решения по этому докладу

Release Notes – это часть документации, в которой собраны последние изменения продукта. То есть изменения выпускаемой и предыдущими версиями. В этом докладе расскажу о том, как можно автоматизировать систему версионирования, а также генерацию Release Notes, и возможные способы публикации в этой разработке. Данный доклад будет полезен тем, кто занимается мобильной разработкой и хочет облегчить взаимодействие разработчиков с документацией, также данная разработка значительно снизит Time-to-market. Разработка применима для использования в связке с системой управления репозиториями программного кода - GitLab.

Программный комитет ещё не принял решения по этому докладу

Люди и сообщества

Классические вопросы на технических интервью все мы уже знаем наизусть. Многие из них хороши и помогут нам найти классного специалиста в области внутреннего устройства библиотек. А как нам за час-полтора понять, что человек обладает нужным типом мышления, хорошо впишется в продуктовую команду и усилит её? Как построить интервью так, чтобы увидеть реальный уровень кандидата, а не его способность выучить все ответы из статьи "100 популярных вопросов на собеседовании"?
В своём докладе я расскажу, как построено техническое интервью в нашей команде.

Программный комитет ещё не принял решения по этому докладу

TechTalks

Этапы развития ML в компаниях и как они соотносятся с этапами внедрения MLOps,
чем отличается процесс разработки сервиса с ML и почему под него нужен отдельный workflow,
каким образом благодаря ему можно сократить время создания модели и выпуска её как продовый сервис
современные best practice в ML workflow

Программный комитет ещё не принял решения по этому докладу