Доклады

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

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

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

- как планировать постепенный рефакторинг;
- как выстроить процесс, чтобы не остановить разработку;
- как мотивировать команду работать с legacy.

Если у вас есть проекты с «тяжёлым» наследием, этот доклад поможет взглянуть на проблему под другим углом.

Всем привет, в этом докладе мы разберём топ 5 инженерных практик, которые важны для внедрения в команду.

В докладе, мы рассмотрим такие инженерные практики как:
- Deployment and Release
- Integration and Build
- Test Automation
- Code Review
- Branching

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

Про техдолг и поддержку (тойл) было сказано уже очень много. Но проблема все еще существует, а значит - актуальна. Продукту Mindbox уже более 15 лет и все это время он активно развивается, сейчас - мы хайлоад с миллионами бизнес-транзакций в минуту. Хочу поделиться нашим опытом и рассказать:
- Почему наш архитектор не дает делать “технические” задачи? И как это помогает побороть техдолг?
- Почему выделения % времени/ресурса на техдолг - недостаточно?
- Как продать техдолг и выпил легаси бизнесу? (c конкретными примерами)
- Что нужно рефакторить, а что нет? На наших кейсах - где отказались инвестить и это было правильным решением.
- Какие еще способы борьбы с техдолгом и тойлом есть помимо “затянуть пояса и пойти отдавать”?

Уже больше 10 лет я занимаюсь системной разработкой. Работал в GridGain над Apache Ignite, теперь продолжаю в СберТехе над ним же и еще несколькими проектами.
За это время мое отношение к ревью радикально изменилось. До системной разработки у меня тоже были ревью в команде, но они, почему-то? не работали, да и вообще всем казались довольно бесполезной и чисто формальной процедурой.
Но, как только я начал писать код которому суждено крутиться в продакшенах огромного числа компаний годами, мое мнение начало резко меняться.

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

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

Несколько лет назад мы решили ещё один продукт компании реализовать с применением Backend Driven UI. До этого у нас уже были подобные архитектуры, которые не выходили за границы одного сервиса. Но в этот раз что-то пошло не так в хорошем смысле слова :) Решение масштабировалось на другие продукты. Появился спрос от бизнеса. Одобрены долгосрочные планы по развитию и поддержке.

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

Почему в этот раз все получилось? Что мы не делали и что делали не так раньше? Разбираем нашу историю и пробуем найти секрет успеха.

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

CQRS довольно популярный архитектурный стиль, что, помимо прочего, формирует ряд мифов. Один из них: CQRS — это best practice, некая архитектурная серебряная пуля. Второй миф крайне вредный: что якобы существует эталонная реализация CQRS, а все остальное неправильно и вообще не CQRS.

В докладе максимально прагматично обсудим CQRS: когда применять, когда нет, каковы минусы, какие задачи решаем. Рассмотрим различные варианты реализации. Поговорим про типовые проблемы и обсудим, как с ними справляться.

В докладе рассматривается подход к автоматизированной проверке архитектуры при ее публикации через Quality Pipeline.
Рассмотрим преимущества такого подхода, и какие метрики можно улучшить таким способом.
На примере компании beeline разберем, как подготовить команды к ведению архитектуры в машиночитаемом виде, какие сложности при построении процессов возникнут, как и какие данные собирать для автоматизированной проверки архитектуры и с помощью каких инструментов можно построить свой архитектурный Quality Pipeline.

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

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

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

Подмена понятий «QA» и «тестирование» – это не просто терминологическая путаница, а серьёзная проблема, мешающая развиваться как конкретным специалистам, так и всей индустрии в целом.
Называя процесс контроля качества – QA, мы обесцениваем важность такого процесса, как обеспечение качества. Мы как бы закрываем глаза на его существование. А между тем, это отдельная большая область знаний, в которой следует разбираться.
В докладе хочу обратиться к авторитетным источникам (ISO, ISTQB) и разобрать определения оттуда, продемонстрировать на конкретных примерах, где проходит разделение между этими процессами, а также объяснить, почему этими процессами зачастую занимаются одни и те же люди (спойлер: это плохо).

В докладе будет подробно рассказано о том, как с помощью AI-агентов можно полностью автоматизировать процесс планирования IT-проектов и заменить рутинные человеческие операции. Мы начнем с анализа проблем традиционного планирования, когда длительный сбор требований, частые контекстные переключения и зависимость от множественных специалистов приводят к задержкам и ошибкам. Затем будет представлено практическое решение – система, в которой специализированные AI-агенты берут на себя функции бизнес-аналитика, продакт-менеджера, системного архитектора и даже проектного менеджера. Эти агенты, используя алгоритмы обработки естественного языка, машинного обучения и интеграцию с инструментами вроде Jira и Confluence, способны автоматически собирать и анализировать входящую информацию, трансформировать бизнес-требования в технические спецификации, генерировать архитектурные артефакты и создавать задачи для разработки. Мы рассмотрим, как данная система сокращает временные и ресурсные затраты, повышает прозрачность процессов и минимизирует ошибки, позволяя человеческим экспертам сосредоточиться на стратегически важных задачах, требующих творческого подхода.

Рассмотрим тему безопасного исполнения ненадежного кода (untrusted code). Любого программного кода, утилит или скриптов, которые по каким-то причинам не вызывают доверия. Например, из-за ненадежности поставщика или из-за политик безопасности компании.

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

Возможно, вы занимаетесь разработкой CI/CD-системы; sandbox-системы для тестирования; или приложения, в котором пользователи могут писать код для исполнения на сервере. Или, возможно, в целях интеграции со сторонней системой вам нужно запускать какой-то внешний процесс или размещать стороннее ПО. Поговорим о том, как делать это правильно и безопасно.

Как и многие бывшие разработчики, я был большим фанатом agile и противником бюрократии. Делай быстро, релизь еще быстрее, user story просто повод поговорить с владельцем продукта. Хочу рассказать о том, к каким проблемам это привело, как я стал узким местом для команд и как мы вернулись к необходимости письменно проектировать на новом уровне.
Расскажу, какие плюсы я вижу в этой схеме (предсказуемость времени разработки, сокращения переделки задач после ревью, экономия времени лидов и архитекторов, повышение осведомленности команд друг о друге) и какие сложности были при внедрении

OSS дает огромный профит современной разработке, и все мы активно используем эти решения. Существует ли предел полезности? Что может пойти не так? PnL, профиль рисков, плато продуктивности — давайте разбираться с калькулятором.

Когда мир разочаровался в DevOps…
Когда количество задач на одного разработчика улетело в космос…
Да еще и эти постоянные миграции…
Пришли они - платформы для разработчиков!

Что это за очередная менеджерская штука?! И когда это мир разочаровался в DevOps?!

Да и причем тут: «платформа, как продукт?!»

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

Обычно планирование и выполнение задач в команде выглядит как рутинный процесс, знакомый каждому из нас. Есть заказчик, который приносит цели и задачи, есть аналитик, который готовит документацию и тд. У меня ситуация другая. Моя команда состоит из 5 человек и пишет около десятка продуктов для более чем 20 заказчиков. Расскажу, как мы планируем задачи, выбираем приоритет, чтобы никого не обидеть и принести пользу, какими процессами при этом пользуемся.

Когда я пришел в Авиасейлс, нас было 300 человек. Сейчас мы выросли до 1 000 сотрудников. Во время роста мы столкнулись с множеством проблем:
- Разрозненность решений: команды использовали разные версии библиотек в своих сервисах, подходы к логированию, мониторингу, тестированию.
- Любое обновление инфраструктурных решений требовало ручной работы в сотнях репозиториев.
- У нас не было единой точки входа для обсуждения API, стандартов взаимодействия.

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

Внутренние инструменты позволяют сокращать time-to-market в сотни раз, делать разработчиков счастливее и ускорять рост бизнеса. Тем не менее на практике часто сталкиваются с тем, что внутренние инструменты съедают ресурсы и не приносят пользы. Как результат — продать время на разработку таких инструментов не так уж и просто.

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

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

Перед командами поставлена амбициозная задача - за несколько лет полностью сменить ядро банка с вендорского коробочного решения на самописные микросервисы. Тут даже реализация сложной бизнес логики операционного учёта - уже задача со звёздочкой, но есть и другие сложности. Одни системы привыкли использовать старый API коробки и не готовы быстро переходить на новые контракты. Другие системы ходят за данными напрямую в БД коробки. Да ещё постоянно появляются новые нефункциональные требования. Тем не менее у нас получилось для каждой проблемы найти архитектурные и организационные решения и за 3 года незаметно для клиентов смигрировать 12 из 35 продуктов банка.

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

Рассказ является логическим продолжением прошлого выступления SLI/SLO/SLA в микросервисном приложении

Хочу развеять запах кровавого энтерпрайза, который повисает в воздухе от словосочетания «техническая стратегия». Это необязательно термин для крупных компаний и гигантских проектов, и в рамках доклада я на примерах покажу, какой может быть реальность даже небольшой команды в зависимости от того, есть ли у неё понимание планов бизнеса и своё видение развития технического ландшафта.

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

Моя цель — посеять мысль «а и правда, что ждёт нас через пару лет и не придется ли всё переписывать?» и желание найти ответы на эти вопросы вместе со всеми участниками процесса разработки и планирования.

Как мы используем транзактный анализ для:
1. Разрешения конфликта интересов разных департаментов
2. Построения горизонтальных связей
3. Правильного донесение смыслов до сотрудников
4. Принятия сложных управленческих решений в условиях неопределенности

В докладе пойдём от простого к сложному. Сначала разберём ключевые концепции CI/CD и их значение в современной разработке. Как основной инструмент реализации пайплайна будем использовать GitLab CI: познакомимся с его основными возможностями и особенностями с фокусом на поддержке и улучшении процессов разработки и развёртывания.

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

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