Доклады

Архитектура в DevOps, DevOps для CTO

Практические подходы к командным топологиям

Тимур Батыршин

Экспресс 42

На прошлой конференции мы поговорили о том, что современный [[DevOps]] это по сути [[Team Topologies]] (https://youtu.be/8d1I5yEvlgw). Однако скорее всего у слушателей не появилось понимания что конкретно нужно делать для того, чтобы этот подход запустить у себя. Попытаемся с этим разобраться.

Данный доклад представляет из себя компиляцию информации из разных источников, опыта клиентов [[Экспресс 42]] и моих собственных размышлений на эту тему, и является приглашением к обсуждению.

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

Обратная связь

Лайфаки алертинга в мониторинге систем. Или как предотвратить аварию до того как заметили пользователи

Игорь Савилкин

ООО "Т2 Мобайл"

В своем докладе хотел бы поделиться личным опытом решения ряда проблем в эксплуатации, путем проработки комплекса мер по изменению процесса мониторинга и алертинга, в частности:
- добавление прозрачности дашбордам и алертам,
- уход в сторону динамических baseline
- фомирование у инженеров правил хорошего тона по работе с метриками/алертами

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

ChatOps. Как на каждом этапе CI\CD можно помочь командам.

Александр Крылов

Росгосстрах

Казалось бы, ChatOps чаще всего про поддержку, алёртинг и мониторинг, но это не правда. Сказ пойдёт о том, как на каждом этапе CI\CD можно внедрить ChatOps с пользой для каждой из команд - разработка, тестирование, DevOps, Ops.

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

Непрерывная поставка

GitOps: один push, чтобы сделать всё

Kubernetes это хорошо, я их сам очень люблю и использую. Но будем честны друг с другом: сложно научить всех разработчиков грамотно использовать кубы. В докладе я расскажу, как мы уже много лет разварачиваем для наших разработчиков инфраструктуру по деплою кода с помощью git. Кроме обзора доступных нам в 2022 году инструментов я подробно разберу этот своебразный "dogfooding": поддержку GitOps инфраструктуры с помощью инстурментов GitOps, покажу как мы работаем с Cluster API и Crossplane, как можно избавиться от Terraform или Ansible при развертывании кластера для нового проекта.

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

Мониторинг cronjob в kuberenetes

В докладе расскажу, как мы организовали мониторинг Cronjob в Kubernetes на базе готовых решений Prometheus-Thanos-Grafana и kube-state-metrics при наличии давно сформированной инфраструктуры мониторинга. Нашей целью было внедрить новые инструменты с минимальное влияние на разработчиков, но при этом получить максимум с точки зрения мониторинга.

В результате, у нас получился полноценный инструмент мониторинга кронджоб, который предоставляет как базовые алерты и агрегации, так и дает возможность репортить свои метрики. Значительно сократили время реагирования на инциденты, где участвуют Сronjob.

Доклад будет наиболее полезен тем, кто развивает инфраструктуру мониторинга, кто эксплуатирует большое количество объектов в Kubernetes, кто давно мечтал собирать метрики с Cronjob.

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

Glaber - высокопроизводительный мониторинг на основе Zabbix

Михаил Макуров

Интерсвязь

3 года назад я написал первый патч, который давал возможность Zabbix работать с ClickHouse.

За это время случилось много нового – Glaber оформился как отдельный проект, стал еще производительнее, его используют несколько компаний с весьма большой инфраструктурой, у него появились уникальные функции.

Сейчас Glaber это высокопроизводительный мониторинг с возможностью сбора и сохранения любого типа данных, быстрым UI, в то же время сохранивший преемственность с API Zabbix.

В докладе я расскажу про воркеры и про то, как Glaber может работать с любыми типами данных и сохранять в любые системы хранения, о потенциале по скорости обработки имеет, и как решены основные узкие места.

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

Как собирать iOS приложения в облаке

Сергей

Курсон

Сборка iOS приложений является всегда нетривиальным процессом, поскольку требует использование Mac машины для сборки. Часто процесс заканчивается тем, что такие машины стоят в шкафах в офисах. Часто они разных типов, каждый из которых надо поддерживать, настраивать и обновлять. Не говоря о том, когда нужны дополнительные мощности во времена релизов и не нужны потом.
Мы рассмотрим как можно запускать виртуальные машины iOS в облаке, масштабировать под задачи и подключить их в пайплайн сборки ваших приложений в AppStore.

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

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

Зачем нужны "облака" и как их правильно использовать.

В далёком 2006 году Amazon запустила Amazon Web Services. В составе платформы работали три сервиса: EC2, S3 и SQS.
Это событие стало в определённой мере революцией, предложив успешную имплементацию формировавшихся в индустрии с начала 60-х годов идей коммунального использования вычислительных ресурсов.
Фактически, запуск платформы AWS дал толчек к созданию понятия "cloud computing" и в итоге привёл к изменению мировоззрения специалистов IT-индустрии.
Эти изменения часто не тривиальны, и многие не до конца их осознают и принимают. Это приводит к неспецифичным и неэффективным способам использования облаков.
Давайте остановимся на этом подробнее, посмотрим в чем заключались эти изменения и что нужно понимать чтобы быть Cloud Native.

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

IaC на Ansible. Как построить понятную инфраструктуру

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

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

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

Безопасность в контейнерах

Поговорим о том, какие есть проблемы безопасности в стандартном контейнерном приложении. Разберём на примерах, как можно встроить проверки в стандартный pipeline выкладки.

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

DevSecOps или как на Руси жить хорошо ... и безопасно

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

Теоретические ингридиенты:Зачем нужен DevSecOps и что он дает, как построить процессы безопасной разработки в крупной компании (800+ разработчиков), с одной стороны не ломая сложивщиеся процессы, а с другой, - траснформируя сложившуюся культуру разработки, как обеспечить соответствие практик разработки требованиям регуляторов ФСБ ,ФСТЭК для ускорения прохождения сертификации и без большого удорожания процесса.

Практические ингридиенты: реальный опыт использования инструментов DevSecOps, анализ требований регуляторов и ведущих игроков индустрии

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

DevSecOps или темная сторона безопасности Cloud Native

Kirill

SberAuto

Тренды Cloud only и Cloud Native в стартап-среде
Темная сторона безопасности Cloud Native
DevSecOps от принципов к действиям
Безопасный конвеер разработки
SSDLC с чего начать и как начать выстраивать процессы и коммуникации внутри команды
Who is who в процессе SSDLC

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

Как встроить базовый SEC в DEVOPS без безопасников

Финальные тезисы запостим после согласования доклада.

План доклада:
Откуда берутся уязвимости.
С какой вешалки Sec начинается в DevOps
Инструменты Sec в DevOps
Трудности Sec в DevOps
Истории успеха DevOps благодаря Sec

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

Шлагбаум на рельсы DevSecOps

Шлагбаум на рельсы

A: А давай сделаем Quality Gate на основании проверок SAST?
B: И заставим ВСЕХ его проходить!
C: И сделаем его блокирующим... 😈

Увлекательная история о том, как приручить инструменты Application Security в энтерпрайзе, заставить их работать с сотнями миллионов строк кода, поставить блокирующий релизный Quality Gate в производственном процессе и не остановить работу Банка.

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

Gatekeeper или как защитить k8s и не деградировать

В своем докладе я расскажу о том как мы внедряли инструмент DevSecOps в production кластер k8s для контроля параметров ресурсов кластера. Какие вводили политики, чем руководствовались при их создании, и о том, как написали свой инструмент для мониторинга нарушений с функцией оповещения разработчиков и сопровождения при деплое.

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

AWS для разработчиков. Основы безопасности или aws-vault на практике

- как перестать комитить ключи AWS в Git
- как жить без Hashicorp Vault в маленькой компании или собственных проектах
- практические примеры использования aws-vault
- эмуляция AWS для локальной разработки

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

DevOps-трансформация

Мама, а я DevOps?

Поговорим, кто или что такое DevOps, как это устроено в Циан и что делает наша команда. (Тезисы требуют доработки)

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

Обогнать самих себя

Вырости в 5 раз за два года с ограниченными ресурсами.
Путь который прошел GCore Labs, выходя из Wargaming на примере команды оперирования облачными сервисами.
Изменения в процессах, архитектуре продукта и технологическом стеке, которые потребовались команде, для масштабирования ее сервисов.

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

Коллабарация ИТ инженера и бизнеса для реализации бизнес-мониторинга

Игорь Савилкин

ООО "Т2 Мобайл"

Рутина ИТ инженера (ops, devops) обычно заключается в задачах автоматизации, синхронизации этапов создания и выпуска продукта, а также технического мониторинга и хелсчека после запуска
Но что если сделать коллабарацию ИТ инженера и коллег из бизнеса в единую команду? В своем докладе я расскажу о нашем опыте внедрения и развития проекта бизнес-мониторинга продуктов. О том как с помощью знакомых вам инструментов и смене ракурса работы с получаемыми данными можно помочь бизнесу

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

3 буквы, которые должны объединить всех.

Краткая история длинного пути эволюции подходов к осмысленной эксплуатации распределенных систем, состоящих их сотен высоконагруженных микросервисов, которые разрабатывают десятки команд. Поговорим о том, с какими проблемами сталкиваются в IT и бизнесе в вопросах мониторинга, процессов эксплуатации. Обсудим, как мы понимаем для себя SLA и как оно должно синхронизировать контексты разных участников. Расскажем, как мы в Tinkoff научились в реальном времени оценивать уровень доступности клиентских сервисов, построили вокруг этого процессы SRE и как стараемся держать этот уровень под контролем.

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

Чек лист переезда в K8S

В ходе данного доклада разберем чек лист готовности проекта к миграции в k8s, рассмотрим не только технологии, но и процессы внутри команды, необходимые для понимания важности процесса миграции в кубернетис.
Для команд, которые начинают разработку и для команд, разрабатывающих давно свои решения в ходе доклада я помогу ответить на вопросы:
1) Что требуется от команды для переезда
2) Что требуется от проекта для переезда
3) Надо ли вам это и стоит ли вестись на хайповые слова

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

LINSTOR — это как Kubernetes, но для блочных устройств

В этом докладе поговорим про LINSTOR — open source-хранилище от компании LINBIT (разработчика DRBD).

Начиная с девятой версии, DRBD сменил курс с «‎одно большое отказоустойчивое устройство на всех»‎ на «‎по отдельному DRBD-устройству на виртуалку»‎, стал поддерживать diskless-реплики, появился оркестратор, поддержка снапшотов, шифрования и много другого.

Тезисы:
* Почему LINSTOR — это не просто хранилище, а, скорее, оркестратор блочных устройств. В чём его схожесть с Kubernetes.
* Выделим преимущества и недостатки DRBD перед Ceph и другими кластерными файловыми системами.
* Копнём чуть глубже и посмотрим, как работает DRBD9, LINSTOR и что находится у него под капотом.
* Разберём сущности LINSTOR и как его правильно настроить.
* Как работают снапшоты, бэкапы, дедупликация, шифрование.
* Почему не рекомендуется использовать опцию allow-two-primaries и зачем, вообще, она нужна.
* Какие есть проблемы. Как устранять неполадки и чинить split-brain, если потребуется.

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

Grafana as code, или как я перестал кликать мышкой в UI и полюбил grafonnet

Когда мы в Tarantool столкнулись с задачей настройки мониторинга для сдачи проекта заказчику, мы решили её с помощью grafonnet. Это библиотека для написания дашбордов Grafana с помощью кода на языке jsonnet, которая заметно облегчила нам жизнь.

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

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

Цена облака. Как научиться определять реальную ценность облачных сервисов и извлекать из них максимальную выгоду?

С приходом облаков, DevOps и IaC (Infrastructure as a Code — инфраструктура как код) технические специалисты начали самостоятельно “заказывать” ИТ-инфраструктуру, а финансы и C-level начали получать счета на круглую сумму. Модель управления ИТ-затратами стала децентрализованной мгновенно, а вот отделы финансов / закупок не успели адаптироваться к новой реальности.

FinOps (управление затратами на облачные технологии) - ответ на этот вызов и новая норма, а компании вроде AirBnB, Lyft, Atlassian, Spotify, EA давно развивают эту функцию внутри. В своем докладе я расскажу о ключевых составляющих FinOps фреймворка: с чего начинать создавая FinOps в компании и с какими сложностями вы можете столкнуться. Поговорим о том, какие технические навыки потребуются, сколько денег можно сэкономить и о том, почему точечные оптимизации не решат проблему.

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

Эксплуатация без k8s.

Обычно мы выбираем решение исходя из наших требований и экономической эффективности, поэтому отказ от Kubernetes - это осознанное решение.

Нам было необходимо:

* создание неизменного образа приложения
* возможность фиксации состояния системы
* возможность отката приложений
* изоляция ресурсов
* безопасность
* распределение нагрузки
* отказоустойчивость
* простое управление конфигурацией
* мониторинг
* централизованный сбор логов

Оказалось, что все это у нас уже есть и без k8s и лишний слой в виде Kubernetes для нас дорогое и неэффективное решение.

Расскажем, что дают современные ОС для эксплуатации приложений. О том как мы собираем, версионируем и мониторим приложения. И о том самом DevOPS как культуре, когда админ не заложник у разработки и наоборот.

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

Организация сложных алертов

Многие сталкиваются со сложными, составными алертами. Когда для принятия решения о том, что произошла ситуация, требующая вашего внимания, вам надо получить данные их разных источников - базы данных, prometheus, стороннее API и т.д. И, разумеется, хочется это автоматизировать.

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

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

Сервис управление периодическими задачами или зачем нам свой крон

В ходе реализации сайта ТАССа мы столкнулись с проблемами:
⁃ Нужно удобно оркестрировать периодические задачи, а также иметь подробный мониторинг и алертинг;
⁃ Было много разрозненных кронов - вывели в единую систему;
⁃ Были сложности с администрированием.

Доклад отвечает на вопрос, почему мы выбрали не кронджобы куб или celery

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

Open Policy Agent - серебряная пуля для Kubernetes. И не только для него

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

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

Но кажется, что сообщество обратило на это внимание и сейчас активно выходят фичи, которые позволяют гибко настроить политики безопасности. И одной из очень перспективных на мой взгляд технологий является Open Policy Agent, который реализован в Kubernetes с помощью Gatekeeper.

В рамках доклада мы с вами разберемся:

- Что такое Open Policy Agent (OPA) и почему за ним будущее?
- Как можно валидировать вообще все объекты, что создаются в Kubernetes, с помощью только одного admission-controller'а?
- Как и чем заменить устаревший PSP, получив при этом кучу дополнительной полезной функциональности?
- Как внедрить Gatekeeper в большой работающий кластер на продакшн и при этом ничего не сломать?
- Какие важные аспекты и подводные камни необходимо учитывать при внедрении у себя OPA/Gatekeeper?

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

Инфраструктурная платформа

Обзор FaaS фреймворков для Kubernetes

Как работают FaaS фреймворки, преимущества и недостатки того или иного дизайна, сценарии использования

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

Конвейер счастья для коллег

Чтобы инженеры могли сразу же приступать к работе, мы делаем для них копию всего нашего зоопарка сервисов и монолитов.
Как это устроено и работает для приложения, где сочетаются kubernetes и виртуалки?
С чего мы начинали и сколько полезного сделали для коллег?
Как поддерживаем 90 окружений и часто ли это ломается?
Куда целимся в 2024 году?

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

Docker Internals

Обсудим, чем контейнеризация отличается от виртуализации, откуда она пошла и зачем нам нужна. Остановимся на трёх китах в Linux: cgroups, namespaces, layerfs; поработаем с ними сначала вне привязки к Docker, а потом проведём эксперименты и над запущенным контейнером; выберем, что же использовать для Python-проектов и какие могут быть подводные камни.

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

Проект "Serenity" - единый мониторинг

Максим Залысин

Ситимобил

- Мониторинг в компании, которая живет духом стартапа, так же подвержен накоплению технического долга. Я расскажу как мы это поняли, приняли и теперь все переделываем.
- Один инструмент мониторинга для всего не будет выполнять все функции хорошо, а так же оставаться прозрачным и легким в поддержке. Много инструментов - точно будет зоопарк. Нужен баланс, а точнее процесс во взаимодействии инструментов.
- Мониторинг продукта выстроенный командой эксплуатации, только эксплуатации и будет помогать, не компании. Так не пойдет, нужен вклад и со стороны разработки.
- Обработка алерта не заканчивается на этапе его передачи ответственной команде. Конец тогда, когда проблема решена и, в идеале, понятна причина.
- Наша цель - реакция на проблемы за считанные минуты. Устранение проблемы по "данным приборов".

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

Как унифицировать деплои на примере travis-ci и gitlab

1. Как написать деплой так, чтобы он был понятен кому угодно
2. Что можно оптимизировать в CD, когда вам нужно поддерживать десятки проектов
3. Почему не стоит использовать Ansible для доставки кода в 2021 году
4. Как найти баланс между сложностью абстракций и увеличением деплоймент скриптов

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

Database-as-a-Service в Kubernetes с GitOps

Database as a service дает возможность разработчикам или клиентам быстро развернуть базу данных без обращения к операционным командам. В этом докладе расскажем как про кубернетес операторы для баз данных, как построить свой DBaaS в Кубернетес и как управлять всем этим с помощью GitOps.

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

Loki: Логгирование для всех

ELK/EFK стек считается стандартом дефакто в on-premise системах логгирования. Но что делать если весь ELK нам не нужен? Splunk это для больших ребят и что тогда использовать начинающим командам? Старый добрый Grep ?
В докладе я расскажу как мы в компании внедряли систему логгирования Loki, с какими подводными камнями столкнулись, какие подчерпнули тонкости в её настройке и что самое сложное как мы все это представили команде разработки.

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

Karpenter умное масштабирование для Kubernetes

Кubernetes autoscaler позволяет использовать одну из ключевых особенностей облака, это динамично добавлять убирать вычислительные ресурсы. Но при различных типах нагрузки требуется разные нод-группы, тем самым управление autoscaler-ом будет требовать много усилий. Karpenter подходит к процессу добавления ресурсов иным путем, решая проблему оптимального выбора размера виртуальной машины. Установим, настроим и сравним Karpenter c Кubernetes autoscaler, рассмотрев как все плюсы так и минусы такого решения.

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

PostgreSQL Disaster Recovery in Kubernetes

Расскажем про построение отказоустойчивых PostgreSQL кластеров в Kubernetes, объясним какие варианты Disaster Recovery есть, покажем как минимизировать Recovery Time Objective и Recovery Point Objective используя Kubernetes операторы.

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

Авито: как мы построили alerting as a service

В своём докладе я расскажу о том, как мы развивали нашу систему управления триггерами и нотификациями. Первоначально все операции производились вручную через графический интерфейс, но это было неудобно и плохо масштабировалось. В какой-то момент мы приняли решение изменить подход к управлению триггерами и нотификациями на использование декларативных описаний (.yaml).
Приходите на доклад, и вы узнаете:
— как мы управляем алертингом для более чем 3000 сервисов;
— как мы управляем алертингом для всей инфраструктуры;
— как организован процесс мониторинга 24x7;
— продемонстрирую работу нашего тестового стенда в режиме реального времени;
— расскажу, как этот тестовый стенд вы можете запустить у себя буквально за две минуты.
Все продемонстрированные решения находятся в open source.

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

Мультикластерный масштабируемый Vault на тысячи сервисов – это ОК

HashiCorp Vault - это отличный opensource продукт, который многие используют как есть для управления секретами.
При этом, как это обычно бывает, при внедрении в большой инфраструктуре мы начинаем сталкиваться с рядом ограничений и нехваткой функционала, что не позволяло нам использовать Vault в полной мере в сервисах Одноклассников.
В докладе я расскажу, как мы научили Vault горизонтально масштабироваться, свели к минимуму поддержку и ручные операции, как и для чего пришлось доработать Vault под наши требования.

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

TechTalk

Аутстаффинг, который одинаково приятен и полезен для всех

Юлиан Тырнов

Decart IT-production

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

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

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

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

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

Финализируем: “Биржа аутстаффа”
Почему аутстафф не так ужасен, как о нем многие думают и говорят, в чем его существенные преимущества именно для разработчиков, какие минусы аутстаффинга мы делаем плюсами и как, почему аутстаффинг так востребован сейчас и к чему это может привести, каким мы видим аутстафф мечты и какую роль в этом будет играть наша “Биржа аутстаффа”.

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

Lean подход к тестированию

Управление качеством: опенсорс и самый безопасный банк страны

Антон Кадников

Газпромбанк

Кирилл Гилевич

Газпромбанк

Доклад об истории выстраивания процесса обеспечения качества в Газпромбанке и о сложностях, с которыми столкнулись как с процессной, так и с технических сторон. И, конечно же, о том, как решили эти проблемы.

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

Тестирование умерло. Да здравствует Тестирование!

Тестирование много лет развивалось эволюционно, однако давление тренда тотальной автоматизации добралось и до нас — скоро все изменится кардинально!

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

В этом докладе Артем расскажет о каждом из этапов, через которые придется провести тестирование: поговорим о метриках, инструментах, целях, сложностях перехода и коммуникаций на каждом из них.

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

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

Unit Testing Principles, Practices, and Patterns

Vladimir Khorikov

Enterprise Craftsmanship LLC

В этом докладе мы поговорим про принципы юнит-тестирования, что из себя представляет ценный юнит-тест, и в каких ситуациях следует и не следует использовать моки. А именно:

- Что из себя представляет хороший юнит тест -- параметры, по которым нужно оценивать тесты
- Почему невозможно написать тест, идеальный по всем параметрам, и на какие компромиссы приходится идти при написании тестов
- Где и когда нужно использовать моки, в частности почему нельзя мокировать базу данных
- Паттерн Humble Object и его применение для изоляции бизнес логики от внешнего мира для упрощения тестирования
- DDD трилема и ее применение в юнит-тестировании

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

Нагрузочное тестирование как сервис: минимизация рисков недостаточной производительности в условиях трансформации организации.

Кирилл Борисов

Газпромбанк

· Сервисная модель работы подразделения нагрузочного тестирования. Разные заказчики с разными целями. В чем заключается бизнес-ценность нагрузочного тестирования.
· Разные этапы жизненного цикла сервиса - органичное взаимодействие с каждым этапом жизненного цикла продукта.
· Подход к тестированию систем вместо тестирования задач: плюсы и минусы. Почему тестирование систем при использовании сервисной модели в большинстве случаев эффективнее. Как длина цепочки коммуникаций влияет на эффективность.
· Автоматизация нагрузочного тестирования: дань моде или потребность. Кто выигрывает от применения стратегии EverythingAsCode.

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

Подходы к архитектуре

Фрактальные моно-поли-репозитории

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

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

Толстый или тонкий? Куда движется веб и что с этим делать?

За последние 7 лет мир фронтенд разработки претерпел много изменений. От «толстых» приложений (Thick Clients), написанных на Meteor/Angular/Ember, разработчики стали активно переходить к «тонким» (Thin Clients) и в IT моду вошли такие фреймворки как React, а позже — Vue. Веб-мир стал захватывать все больше сфер влияния: различные движки, библиотеки и браузерные API для компилирования в веб, создания качественной графики, заворачивания сайтов в мобильные приложения и многого другого. Дальнейшее развитие веб-технологий невозможно без развития WASM, WebGPU, Workers, TypedArrays и множества различных WebAPI. А браузер начинает все больше напоминать OS внутри OS.

Несмотря на все изменения и веяния, IT мода, как и любая другая, циклична, а значит, пора начинать готовится к витку популярности толстых клиентов. Чем это черевато?

Архитектура — это не только про бекенд, а многопоточность актуальна не только для мобилок. Уже сейчас для достижения максимальной скорости работы веб-приложения нам нужно использовать новые инструменты и уметь правильно проектировать архитектуру.

О том, чего нам ждать и как быть готовым к новому витку трендов во фронтенд-разработке я расскажу в своем докладе.

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

ИТ-схема. Как не заблудиться в дремучем лесу вашего ИТ-ландшафта.

Доклад об опыте использования "самописной" ИТ-схемы в Lamoda. С чего начинали, какими инструментами пользовались, какая концепция прижилась и что получилось в итоге: как выглядит, из чего состоит. 

ИТ-схему используем уже 1.5 года и можем рассказать:
- какие проблемы схема решила, а какие принесла;
- как схему поддерживаем и развиваем;
- стоит ли делать что-то подобное.

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

Платформа данных в Tinkoff: история развития и архитектура

Расскажу как развивалась платформа данных вместе с компанией, бизнесом, пользователями и технологиями.
Как мы пришли от одного бизнес-домена на 100 Gb и десятка пользователей к сотням доменов, петабайтам данных и более чем 3000 активных бизнес пользователей, ежедневно создающих нагрузку в более сотни тысяч аналитических запросов.
Как и зачем мы пришли от идеи классического DWH к созданию своей платформы данных.
Расскажу про текущую архитектуру платформы и то как высокая нагрузка и масштабы бизнеса приводит к неработоспособности классических подходов и технологий. Что такое Data Mesh и Lake House и почему мы движемся в эту сторону.

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

Документирование архитектуры платежной системы в масштабе десятков команд и многолетнего развития продукта

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

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

Концепция развития легаси системы

Легаси случается со всеми, сначала это незаметно, потом неприятно, а потом больно и приходится что-то с этим делать. С чего начать, как сделать план и оценить его - все это хочется рассказать и показать путь "второго рождения" или окончательной смерти приложения на синтетических примерах, собранных из реальных систем.

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

Как Сойти за Сениора - Тактика Прохождения Архитектурных Собеседований

Эмиль Шарифуллин

Яндекс.Облако

- Как пройти архитектурное собеседование на сениора
- Как выстраивать архитектуру приложений, с чего начать
- Как выбирать технологии для обеспечения высокой доступности приложения

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

Путь приложения от онлайна к оффлайну

Доклад про то, как мы почти год рефакторили ReactNative приложение для фермеров для работы в условиях слабого интернета и оффлайна. Опробовали не один архитектурный подход и набили немало шишек о подводные камни. Расскажу с какими проблемами мы столкнулись, как пытались их решить и на что важно обращать внимание, если вы решили сделать оффлайн режим в своем приложении. Буду много говорить об архитектурных нюансах и ограничениях ReactNative, но общая концепция и решения могут быть полезны и при реализации как на других фреймворках, так и нативных приложений.

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

Инженерные практики, сложности применения

Эволюция DevOps в компании СберМаркете

Тимошенко Эдуард

Сбермаркет

Что такое DevOps? Какие этапы мы, как компания, прошли при росте команды разработки от 30 человек до 500+ за 1 год.
Расскажу про:
- Закон эволюции и DevOps;
- Какие практики DevOps нам помогли увеличить число релизов от 3х в неделю до 15 в день;
- Как менялась структура и состав команд во время роста, и при чём тут PaaS;
- Зачем бизнесу DevOps и какие проблемы он помог нам решить;
- С какими проблемами мы столкнулись и как решали при DevOps трансформации в условиях роста.

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

Code review

- Что смотреть на Code review.
- Психологические аспекты.
- Проблемы и возможные решения.
- Соглашения.
- Особенности OpenSource.

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

Использование инженерных практик в трансформации процессов крупных подразделений

Рассказ о том, как инженерные компетенции могут найти применение за пределами ИТ.
Этот опыт можно использовать для увеличения скорости изменений в своих подразделениях.

Команда agile коучей столкнулась с низкой скоростью изменений в организации.
Используя опыт полученный в разработке ИТ-систем и быстрой поставки, мы начали разрабатывать плагин для Jira, который поддерживал наши изменения.
В результате цикл принятия изменений сократился с кварталов до недель. А все проекты ушли в прод.

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

Модульный монолит вместо микросервисов: как, когда и зачем

Микросервисы сегодня — это хайп, о котором говорят из каждого утюга. Складывается мнение, что старый добрый монолит — это плохо, а микросервисы — таблетка от всех болезней. Но так ли это на самом деле?

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

Еще расскажу когда обычному монолиту пора становиться модульным и как перейти от обычного монолита к модульному. И, конечно, как выделять модули в отдельные сервисы.

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

Собираем конструктор из сторонних и собственных компонентов для регулярного нагрузочного тестирования платформы с 30M+ пользователей

Нагрузочное тестирование (НТ) - неотъемлемая часть процесса обеспечения качества любой системы с большим числом пользователей. Для проведения НТ существует множество инструментов, но многие из них решают относительно узкие задачи, а более сложные комплексы платные и проприетарные и это накладывает свои ограничения. В своём докладе я расскажу о развитии наших инструментов от ручного запуска скриптов через относительно простой консольный скрипт для кластерного запуска тестов с поддержкой нескольких инструментов НТ до целого комплекса из сторонних и собственных компонентов и интеграцией в CI/CD. Этот процесс шёл рядом с переездом с монолита на микросервисы и это создало дополнительные вызовы. Кроме этого, будут освещены организационные вопросы, которые были решены в ходе внедрения описанного процесса.

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

Нужно ли программистам писать UI тесты (рабочее название)

Николай Серов

Почтатех

Проблема:
В командах мобильной разработки при росте численности разработчиков отдел ручного тестирования не справляется с нагрузкой
Компания не всегда может позволить себе отдел мобильных автоматизаторов (нет средств, не найти на рынке, не согласовать с бизнесом)
Разработчики пишут только модульные тесты или не пишут тесты вообще
Модульные тесты часто несостоятельны или бессмысленны
Итог: падает либо time to market, либо качество

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

Дополнительно:
Расскажем про наше решение по интеграции Android UI автотестов в Gitlab CI.

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

Production Machine Learning в Delivery Club

В Delivery Club есть много задач, которые успешно решаются при помощи алгоритмов машинного обучения (например, планирование количества курьеров, которых мы выводим на смены). Эти алгоритмы используются в offline-режиме.

Однако, есть целый класс задач, для которых требуется наличие в production-инфраструктуре сервисов, способных отдавать предсказания ML-моделей в режиме online.

Мы расскажем, как создавали в Delivery Club первые сервисы, использующие под капотом ML-модели, как мы обеспечиваем безопасность деплоя таких сервисов и как оцениваем качество их работы.

Обсудим следующие темы:
1. особенности ML-сервисов в сравнении с обычными микросервисами;
2. построение инфраструктуры для обучения ML-моделей в production;
3. особенности деплоя и тестирования ML-приложений;
4. как организовать процесс совместной работы Data Science и ML-инженеров.

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

Текстовые архитектурные модели - (относительно) простое средство раннего выявления и предупреждения сложных проблем

Все мы много раз слышали, что стоимость исправления ошибки тем выше, чем позже она обнаружена.
Очевидный вывод заключается в том, что исправить серьезные ошибки дешевле всего на самых ранних стадиях создания программного обеспечения, когда программа еще не написана - при анализе потребностей и проектировании. Но именно на этих стадиях ошибки в ПО труднее всего обнаружить, так как очень много всего нужно учесть и сопоставить практически "в уме".
Существующие инструментальные средства моделирования довольно дороги, сложны в освоении и тяжелы в использовании. В докладе будет представлен метод моделирования архитектуры и сценариев использования ПО на основе текстовых нотаций. Для удобного моделирования был разработан DSL на основе plantUML, который позволяет описывать лаконичные текстовые модели, которые автоматически превращаются в информативные диаграммы, которые можно обсуждать с заинтересованными сторонами на стадии проектирования. Это позволяет выявлять архитектурные нестыковки и несоответствие внешним потребностям на самых ранних стадиях, когда ПО еще даже не начали разрабатывать.

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

Как запустиь систему за 4 месяца, если объективно надо 2 года

Архитектура это базис
Немного об ограничениях: 9 беременных женщин не рожают за 1 месяц
Воздушный шар: отсекаем все, что возможно
Кросплатформенная разработка - практика 5 осей
Выключаем мессенджеры / Включаем мессенджер в FullTime или работа в 4 и 6 рук

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

Нативные фреймворки на страже автоматизации

Автоматизация 15 лет назад и сегодня — совершенно разные истории. Разнообразие инструментария радикально изменило масштабы, процессы и задачи автоматизации.

Важно отметить, что все изменилось не сразу. Сначала популярны стали инструменты, разработанные тестерами для тестеров: Selenium, Appium, REST Assures*.* А в последние годы все популярнее становятся инструменты тестирования от разработчиков, двигающиеся в другой парадигме: Playwright, Kaspresso и другие.

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

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

TDD: путь от сказки до рабочей фичи за полтора часа

Злата Занина

Райффайзен Банк

Пробовали ли вы когда-либо внедрять TDD у себя в команде? А на чем вы споткнулись? Мы вот, как и многие, не могли перейти от тренировок про калькуляторы к реальным задачам. Интерес команды угасал, никому не хотелось тратить ограниченное двухнедельным спринтом время на то, что не приносило ощутимой пользы.
Однако мы преодолели этот этап и вовлекли в практику большую часть команды разработки. Наш результат: за полтора часа мы получили выполненную задачу и хорошие юнит-тесты к ней. А изначально эта задача была оценена командой в два дня.
Мы получаем хороший профит от TDD и хотим рассказать, как преодолели барьер между теорией и практикой.

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

Backend for frontend: the complete guide

Вы все еще деплоите фронтенд через докер контейнер? Выкатка фронта занимает больше чем 10 секунд? Тогда этот доклад будет вам полезен, я расскажу что такое BFF и как мы его используем в Толоке. А также расскажу подробно все нюансы разработки.

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

Учимся искать ответы на вопросы о разработке вместе с TDD

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

В процессе поиска ответа на вопрос “Почему у кого-то TDD работает, а у нас нет?”, мы нашли несколько причин. Во-первых, мы неправильно понимали сущность разработки через тестирование. Во-вторых, мы не всегда понимали, для чего мы пишем тесты. В-третьих, наши инструменты не очень помогали нам писать те тесты, которые нам были нужны. Были и другие причины. И тогда мы начали искать ответы на вопрос: как нам всё это исправить?

Небольшой рассказ о том, как в рамках разработки уже существующего проекта с некоторой “историей” начать внедрение элементов разработки через тестирование “снизу вверх” (т.е. силами разработчиков) и о том, как это может повлиять на архитектуру самого приложения и архитектуру тестов.

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

Как запустиь систему за 4 месяца, если объективно надо 2 года

Архитектура это базис
Немного об ограничениях: 9 беременных женщин не рожают за 1 месяц
Воздушный шар: отсекаем все, что возможно
Кросплатформенная разработка - практика 5 осей
Выключаем мессенджеры / Включаем мессенджер в FullTime или работа в 4 и 6 рук

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

<N> стратагем в войне с legacy

Legacy — прискорбная, но неизбежная составляющая любого достаточно крупного (или долгого) проекта. Что-то досталось нам от неведомых предшественников, а что-то породили мы сами. Как быть, когда вы сталкиваетесь с этим чудовищным спрутом, всех щупалец которого даже сразу не разглядишь?

В этом докладе я поделюсь личным опытом, полученным за последние двадцать лет спасения и похорон различных проектов, объясню почему подход "нормально делай — нормально будет" не работает и поделюсь инструментами и подходами для борьбы с тенями прошлого.

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

TDD в мобильной разработке

В Додо Пицце на iOS мы автоматизировали 75% регресс-кейсов и последние два года пишем разные виды тестов: юнит-, скриншот-, компонентных- и UI-тестов. Общее число приближается к 4 тысячам.

За это время мы написали много разных тестов, разделили приложения на модули. Какие-то тесты не падали ни разу, какие-то ни разу не были зелеными. Самым главным вопросом всегда было «как писать полезные тесты». Этим опытом я и поделюсь.

Отвечу на вопросы:
- Как писать по TDD для мобильной разработки.
- Что такое тестируемая архитектура.
- Зачем нужные разные уровни тестов и как не тестировать одно и тоже.
- Где прячутся компонентные тесты
- Как не скатиться в ад с автотестами.

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

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

Управление инцидентами

Олег Федоткин

СберМаркет

«Критерий успеха не в том, насколько важные проблемы вы решаете. Важно, чтобы это были не те же самые проблемы, что вы решали в прошлом году.»
Джон Фостер Даллес, гос. секретарь США.

Да,прод падает, но это было бы ещё полбеды. Плохо то, что он иногда внезапно падает, вот в чем фокус!
Вольная интерпретация Булгакова, книга "Мастер и Маргарита"

Представьте: вы только что потушили прод. Кластер живой, трафик ходит, клиенты довольны, разве что некоторые еще пишут гневные тирады в Твиттере. Вы заварили себе кофе и приготовились впервые за несколько часов насладиться тишиной...

Подумали, "это — идеальный окончание инцидента"? У меня есть, что вам рассказать 🙂

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

Горизонтальный рост – возможно ли?

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

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

Оркестрация обработки данных с Apache Airflow: как перестать страдать?

Apache Airflow потихоньку стал самым популярным оркестратором в для Data-* задач. Тем не менее использование его до сих пор приносит боль, заставляет вспоминать неприличные слова, а новичков сбивает с толку кучей непонятных названий и концепций. В докладе мы поспекулируем почему это происходит, я поделюсь советами о том как можно сделать так чтобы ваши дата сайнтисты и дата инженеры писали пайплайны без ощущения что это их убивает, и мы рассмотрим несколько подходов к организации разработки дата-процессов и с их преимуществами и недостатками. Также рассмотрим свежие нововведения в Apache Airflow появившиеся в последних версий которые могли пройти незамеченными, но которые существенно упрощают разработку и тестирование дата-пайплайнов.

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

Еще один способ, сделать разработку в enterprise лучше!

Когда перед вами встает вопрос, как сделать так чтобы более 160 команд разработки следовали определенному уровню качества кода и организации процессов в команде, то вы можете почувствовать, что ситуация оказывается не такой и простой как могло казаться.

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


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

Productive Developer-Driven Testing

Практически все разработчики пишут тесты. Преимущественно, юнит тесты и тесты интеграционные. Но, зачастую, не лучшим образом. Мы посмотрим на аггрегированный 20-летний опыт разных команд в Google в написании тестов, посмотрим, как внутренние guidelines менялись с течением времени, и к чему мы пришли.

Большую часть из того, что будет в этом tech talk можно прочитать в относительно недавно опубликованной https://www.amazon.com/Software-Engineering-Google-Lessons-Programming/dp/1492082791. Но здесь мы в сжатом виде поговорим о главном, расставим акценты и, конечно, немного пофилософствуем в начале :) При этом, с десятком практических примеров.

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

Как защитить чистоту архитектуры

Как говорил герой «Ералаша»: «Мало установить рекорд — его ещё надо удержать». Так вот и хорошую архитектуру проекта нужно не только придумать и реализовать, но и защитить от энтропии и ньюкамеров. Цель — как можно раньше предостеречь разработчика от неправильных действий. Защищаться будем как от неправильных ссылок между компонентами системы, так и от типичных ошибок в дизайне классов и многого другого. А еще посмотрим как с помощью тестов, плагинов к IDE и существующих языковых конструкций реализовать защиту в автоматическом режиме.

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

Как отдавать технический долг

Олег Федоткин

СберМаркет

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

Технический долг это те самые кривые рельсы. Да, мы проехали по ним один раз, но следующие поезда должны идти плавнее, а значит, рельсы надо перекладывать. У меня есть подсказки, как сделать перекладывание проще.

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

Масштабирование

Сообщества практиков: А что так можно было?

Артём Кротов

Мир Plat.form

В многокомандной разработке часто становиться узким местом координация команд, которые работают на одной кодовой базе: Каких стандартов придерживаться? Как выстроить процесс релиза? Как придерживаться архитектурных гайдов? Хочу подробно остановиться на одной из самых интересных техник координации - Community Of Practice (Сообществе Практиков). Этот тот самый горизонтальный клей самоорганизации, который помогает быстрому распространению знаний в продукте, организации и за её пределами.

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

Вырастить команду мечты, или проще ее просто нанять?

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

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

«Метавселенная» нашего ПО или что бывает при взрывном масштабирование

Всегда приятно все строить правильно и хорошо по «канону» на самый последних технологиях итд. Но к сожалении или к счастью законы природы или бизнеса думаю по другому. Сила компании это проявление ее гибкости, способности быстро подстраиваться и изменяться, а не использовать все самое новое везде и сразу. Нет никакого смысла переписывать в одночасье монолит который разрабатывался в течение 10 лет, но при этом нельзя упускать конкурентные преимущества от новых технологий и процессов которые становятся более эффективными и несут пользу.
В своем докладе хочу рассказать про как менялись наше мировоззрение, технологии и процессы когда мы стали рости, у нас не было такого: «есть четкий план и мы по нему идем», у нас были цели и мы пытались адаптироваться в новым для нас реалиям. На своем опыте могу сказать что инструменты меняются во много раз быстрее чем сознание людей и вот это отставание, очень частно начинает портить всю картину. Я расскажу про эволюцию нашего стека и процессов сопровождения, релизов(CI/CD) и безопастности. Итого нам пришлось построить несколько параллельных процессов, где есть ветвления, где то процессы эволюционируют, а где-то это все же разные ветки и никогда не пересекутся межу собой.
Из доклада вы сможете узнать основные этапы эволюции нашей команды и нашего стека и вакцины с помощью чего нам удавалось перейти на новый уровень и при этом сохранить свой разум и спокойный сон)

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

Как мы монолит в kubernetes затолкали

Расскажу историю о том как мы эволюционировали, с какими проблемами сталкивались.

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

Вам нужна core-команда

Мне часто задают вопрос кем и где я работаю. И иногда это сложно объяснить не только людям, не сведущим в IT, но и людям, которые успешно работают в индустрии. Первым сложно объяснить кто такой frontend-разработчик, а вторым в двух словах не объяснить что такое core-команда и чем она занимается.

Меня зовут Игорь, я больше двух лет работаю в Tinkoff в core-команде. И в этом докладе я попробую рассказать:
1. Что же все таки такое core-команда
2. Чем она занимается
3. Почему совершенно техническая команда занимается внутренним devrel и технопиаром.
4. Почему мы обсуждаем команды и их процессы на технической конференции

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

Как расти в управлении ресурсами. Опыт Авито.

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

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

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

Продуктовый подход в платформенной разработке

Есть разные подходы организации платформенной разработки в компаниях. Можно часть задач распространять на продуктовые команды и прокачивать экспертизу там, можно делать максимально готовые кубики со стороны платформы, которые уже использовать в продукте, снижая затрачиваемое время на разработку. Поговорим о плюсах и минусах вариантов разделения и придем к важной теме, которая часто остается в серой зоне – платформа это такой же продукт, со своими пользователями, болями и хотелками и он требует подобных подходов как и любой обычный продукт.

В докладе я раскрою те принципы и подходы, которые мы используем при построении PaaS в Авито, какие полезные метрики скорости, качества разработки можно выделить для полноценного продуктового развития. Как принимать решения, когда заказчик – это сразу все команды и потенциально фича интересна всем. Как собирать фидбэк в таком случае. Какие есть готовые инструменты для организации такого подхода: процессы, готовые метрики и механики.

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

Развитие информационной системы от одной пиццерии в подвале до 16 миллионов клиентов

Додо пицца начиналась с одной пиццерии в подвале и 2 разработчиков, а на данный момент у нас уже более 700 точек питания и в IT отделе работает порядка 200 человек.

Система росла вместе с бизнесом и я расскажу о том как это происходило. Мы вместе посмотрим, как решения принятые годы назад или более откликаются в настоящем дне:

* Выбор баз данных
* Разделение по сервисам
* Внутренний дизайн сервисов
* Подходы к тестированию
* Организация взаимодействия между сервисами

Постараюсь подробно рассказать про то с чем мы сейчас огребаем и в чем мы ошибались, а так же какие крутые приемы для себя нашли

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

Мастер-класс

Тяжёлый функциональный рефакторинг: как сделать код лучше и не сойти с ума

Pavel Argentov

Evrone LLC

Общим местом современной разработки RoR является философско-практическая проблема "куда девать бизнес-логику во фреймворке, который "заточен под другое". Лёгкость прототипирования и развитый ООП-инструментарий RoR первоначально не предполагает "обмазываний абстракциями" и "академической нудятины". Вместе с тем, как только сложность проекта превышает пресловутый "бложик за 15 минут", в проекте начинает накапливаться технический долг в виде надобности рефакторинга образовавшейся в результате "гибкой инкрементной разработки" лапши из спутанного (entangled) ОО-кода, god-objects на всех уровнях MVC, бешеных репортов CodeClimate и прочих "благ цивилизации".

Во всех современных языках существует достаточно зрелый ФП-инструментарий, а коммюнити накопило достаточно знаний для его применения. Мы стали более лучше самообразовываться, продвигаться в CS и теории языков. Проблемы DDD требуют уже не столько наработки, сколько деления реальным опытом ФП-архитектуры в DDD. У компании Evrone такой опыт есть.

Предлагаю мастер-класс по ФП-рефакторингу спутанного MVC-кода с применением инструментария Dry-rb, встроенных ФП-примитивов Ruby и функциональных паттернов монадного вычисления, каррирования, инъекции анонимных функций и т.п.

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

TechLead Conf

Story mapping на примерах

Планирование, estimate и deadline - это слова, которые болью отзываются в сердцах многих разработчиков. Вместе с вами мне хотелось бы рассмотреть подход к планированию story mapping. Будут примеры из реальной жизни. Поговорим про то зачем нам всё это надо и какие ошибки совершаются чаще всего. Вспомним что такое agile и взгрустнём во что он превратился. Бонусом будет презентация бота для GitHub, который позволяет использовать story mapping в привычном интерфейсе.

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

Аутстаффинг, который одинаково приятен и полезен для всех

Юлиан Тырнов

Decart IT-production

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

Наводим порядок в умах руководителей и в сердцах подчиненных
Какие действия необходимо предпринять на самых верхах до внедрения какой-либо автоматизации в процессы и вообще перед вмешательством во все эти “и так работает”, на какие существенные моменты прежде всего нужно обратить внимание, с кем подружиться, а с кем расстаться, где брать порох для точечных выстрелов по целям и на какие цели вообще можно и следует ориентироваться (подсказка: кадры решают все).

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

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

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

Финализируем: “Биржа аутстаффа”
Почему аутстафф не так ужасен, как о нем многие думают и говорят, в чем его существенные преимущества именно для разработчиков, какие минусы аутстаффинга мы делаем плюсами и как, почему аутстаффинг так востребован сейчас и к чему это может привести, каким мы видим аутстафф мечты и какую роль в этом будет играть наша “Биржа аутстаффа”.

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

Интеграционные паттерны Domain-Driven Design

Мы снова поговорим про DDD, но только в этот раз речь пойдет про паттерны Domain-Driven Design, и как они помогают при формировании структуры команд и взаимодействию между ними.
Рассмотрим такие понятия как: upstream/downstream контексты продукта, определение Context Map'ы и как команды должны разрабатывать и взаимодействовать с ними, чтобы не мешать друг-друг. Ну и конечно же, мы пробежимся и по базовым паттернам, таким как правильное определение бизнес моделей: value, entity, agregate'ов, ответим на понятие domain-логика и ее место в коде проекта, постараемся рассмотреть все это на примерах.

Доклад будет полезен всем, кто немного знаком с DDD и хочет закрыть пробелы в своих знаниях при использовании этого инструмента в разработке.

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

Как перевести отдел на новый техстек и ничего не сломать

В нашей компании был разработан собственный фреймворк SurfAndroidStandard, который выручал нас годами и позволял переиспользовать лучшие практики разработки. Однако, стараниями Google, большинство наших наработок стали неактуальными, так как теперь существуют гайдлайны и стандартные Jetpack-компоненты. В своем докладе я расскажу, как в нашем отделе происходит переход на новый стек

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