Хвост инженера

Автор: Лёша Королёв · Яндекс для разработчиков

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

Дальше он разбирает, как устроен единый дашборд платформы такси и какие требования к нему предъявляет команда. Его задача — не показать всё на одном экране, а помочь ответить на два вопроса: в какой части платформы проблема и как такси чувствует себя прямо сейчас.

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

Из этого можно взять в работу: начните с бизнес-метрик. Если представить путь заказа как…

Автор: Григорий Петров и Никита Соболев · MoscowPython

Python Day Special на Positive Hack Days 2025 — формат живой дискуссии за столом, который Moscow Python проводит как спецвыпуск между конференциями. Ведущие — Григорий Петров (евангелист MoscowPython) и Никита Соболев. Тема — асинхронность в Python: не туториал по asyncio, а честный разговор о том, что эта парадигма даёт и чего стоит.

Разговор идёт по структуре: сначала реальные преимущества (07:43), затем реальные недостатки (19:04), затем то о чём обычно не говорят — сложности асинхронного программирования в целом (22:10). Отдельный блок — несовместимость sync и async миров в библиотеках и фреймворках (28:22, 43:55): когда одна синхронная зависимость блокирует весь event loop.

Кому смотреть: Python-разработчикам, которые используют async на практике или только решают, нужен ли он их проекту — и хотят услышать взвешенную оценку, а не «async — это будущее».

Из этого можно взять в работу: проверить, нет ли в вашем async-коде синхронных вызовов в библиотеках…

Автор: Александр Морозов (co-founder & CTO, Datafold) · Python Channel · Moscow Python Conf++ 2021

Datafold — стартап из YCombinator, платформа мониторинга аналитических данных. Прошли акселератор, писали MVP за 1–2 месяца — за основу взяли Redash (MIT-лицензия, аналитические БД, SPA). Redash целиком построен на Flask: sqlalchemy, alembic, REST, auth, rate-limiters, CSRF, CLI. Через какое-то время решили менять стек.

Название доклада начинается с «Не highload» — и это принципиально. Причина переезда не в том, что Flask медленный. Причина в том, что типичный Flask-хэндлер — это огромный boilerplate для простых вещей: получить данные из тела запроса как JSON, провалидировать, сконвертировать. Хочешь нормальные сообщения об ошибках — boilerplate вырастает ещё в несколько раз. FastAPI решает это через type hints и Pydantic: код становится короче, читаемее и самодокументируемым.

Кому смотреть: разработчикам на Flask, которые думают о переходе на FastAPI — или уже переходят. Морозов рассказывает не то, что написано в…

Автор: Екатерина Давыдова · AvitoTech

Екатерина Давыдова — программный менеджер в Авито, ведёт внутреннюю программу, которая объединяет все GenAI-команды компании. Авито — один из крупнейших классифайдов мира, и в этой связи их опыт выстраивания работу с GenAI отличается от опыта стартапов с «чистым листом».

Доклад начинается с конкретной ситуации: к продуктовой команде приходит CEO и говорит «давайте уже что-нибудь запустим на AI, иначе будет поздно» — и команда не понимает ни где брать идеи, ни какие ресурсы нужны, ни как вообще двигаться. Давыдова прошла через это с десятками команд и рассказывает, что работает на каждом из пяти этапов: от генерации идей до масштабирования.

Формат — не история успеха, а производственный разбор. Что делать на каждом шаге, какие этапы выпадают при планировании и потом больно бьют, и почему «80% компаний сказали что начали что-то внедрять, но только 10% смогли объяснить — что именно».

Кому смотреть: продуктовым лидерам, которым пришла задача «запустить что-то на GenAI» — и…

Автор: Валентин Удальцов (Happy Inc. / Typhoon) · PHP Russia 2021

Валентин Удальцов в Happy Inc. прошёл полный путь от ORM до нативного SQL — и рассказывает об этом не как об отказе от абстракций ради принципа, а как об архитектурном решении, которое «во всех смыслах выгодно». Отправная точка: ORM, QueryBuilder и прочие абстракции связывают руки при попытке использовать базу данных на полную.

Конкретный вопрос, который задаёт Удальцов: какой смысл выбирать между PostgreSQL, MySQL и Oracle, если ваша библиотека всё равно не умеет в upsert, lateral join, returning, json path и оконные функции? Если абстракция закрывает доступ к возможностям СУБД, которую вы выбрали — это уже не абстракция, это ограничение.

Кому смотреть: PHP-разработчикам, которые чувствуют что ORM начинает ограничивать — но не решаются отказаться от него, потому что «так принято».

Из этого можно взять в работу: найти в своём проекте одно место где вы написали сложный raw SQL внутри ORM-контекста (через DB::raw() или аналог). Если такое место есть…

Автор: Алексей Фирсов (мейнтейнер aiopg, SoftPro) · MoscowPython

⚠️ Выпуск записан в 2019 году. Детали реализации aiopg и экосистема async-драйверов для PostgreSQL с тех пор изменились (появились asyncpg, sqlalchemy async, psycopg3). Архитектурные решения и вопросы дизайна — актуальны.

Первый выпуск Moscow Python Podcast (переименован из Python Junior Podcast) открылся «хардкором и сеньорностью». Гость: Алексей Фирсов, старший разработчик SoftPro и мейнтейнер библиотеки aiopg. Разговор ведут сооснователь MoscowPython Валентин Домбровский, тимлид NVIDIA Злата Обуховская и Григорий Петров. 44 минуты про то, как устроен асинхронный доступ к PostgreSQL из Python — и зачем вообще нужна отдельная библиотека для этого.

Центральный вопрос выпуска формулируется прямо: так ли уж нужна целая библиотека для взаимодействия асинхронного кода с PostgreSQL (05:32)? Ответ разворачивается через архитектурные детали: aiopg работает поверх psycopg2, который работает поверх написанной на C библиотеки libpq — и при этом сам написан…

Автор: Listen IT · Listen IT

Видео Listen IT, 15 минут. Event Storming — воркшоп-техника, разработанная Альберто Брандолини. Сессия начинается не с рисования схем, а с вопроса: какие события происходят в системе? И именно этот порядок меняет всё.

Типичная архитектурная сессия выглядит так: техлид рисует диаграмму, остальные кивают или спорят о деталях реализации. Знание о домене остаётся в головах у бизнес-экспертов и не попадает в код. Event Storming переворачивает процесс: на стену клеятся оранжевые стикеры с доменными событиями («заказ размещён», «платёж подтверждён», «склад уведомлён»), и сразу становится видно, где у команды нет общего языка — кто-то называет одно и то же по-разному, кто-то предполагает событие, которого на самом деле не существует. Пробелы в знании домена вскрываются за часы, а не за месяцы.

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

Из этого можно взять в…

Автор: Кирилл Мокевнин · TechLead Channel

Кирилл Мокевнин — основатель Hexlet, образовательной платформы для разработчиков. Он не просто учит программировать — он годами наблюдает, где люди застревают, и думает о том, чему именно нужно учить. Доклад на TechLead Conf.

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

Ценный угол: Мокевнин смотрит на обучение не…

Автор: Алексей Мерсон · Код Желтый

Алексей Мерсон работает в Sage — внутренней observability-платформе Т-Банка. Доклад открывает конференцию по надёжности и наблюдаемости, организованную той же командой: это намеренно вводный разговор — синхронизировать понятия, прежде чем идти глубже.

Центральная структура доклада — пирамида качества: в основании надёжность, выше опыт пользователя. Это не абстракция: если система ненадёжна, весь разговор про UX и satisfaction теряет смысл. Надёжность Мерсон определяет через SRE-буки Google — вероятность выполнить требуемые функции без отказов за заданный период. Из этого вырастают SLI (конкретная метрика, связанная с пользовательским опытом), SLO (целевое значение) и бюджет ошибок — то время, которое система может «лечь», не нарушив SLO. Ключевые метрики для оптимизации — MTBF (среднее время между отказами) и MTTR (среднее время восстановления): чем больше первое и меньше второе, тем лучше используется бюджет ошибок. Наблюдаемость нужна именно для того, чтобы обе величины…

Автор: Папочка Разработки · Папочка Разработки

Канал «Папочка Разработки», 20 минут. CQRS (Command Query Responsibility Segregation) — паттерн с устойчивой репутацией «понятного на собесе, но непонятного в коде». Видео разбирает, почему так происходит.

Распространённое понимание CQRS: разделить код на команды (пишут данные) и запросы (читают данные), сложить по разным папкам, добавить Handler для каждого — и считать, что CQRS внедрён. Это не CQRS, это просто именование. Настоящий паттерн — про разделение моделей: модель записи оптимизирована для инвариантов и бизнес-правил, модель чтения — для отображения данных в том виде, в котором их хочет видеть клиент. Когда модели разделены по-настоящему, появляется возможность масштабировать чтение и запись независимо, использовать разные хранилища, денормализовать read-side для производительности. Без разделения моделей это просто организация кода, а не архитектурный паттерн.

Кому смотреть: разработчикам, которые используют или планируют CQRS и хотят убедиться, что…

Автор: Егор Заплатин · Яндекс Вертикали

Егор Заплатин — фронтенд тимлид в Яндекс Вертикалях (Путешествия, Аренда, Авто.ру). Доклад на Vertis JS 2026: полгода работы с AI-агентами в реальных задачах, выводы о том, что нужно сделать, чтобы они работали предсказуемо.

AI-агент не замещает инженера — он меняет то, на что инженер тратит время. Заплатин это понимает, хотя в докладе использует популярную аналогию «прокачать до мидла» — скорее как метафору для аудитории, а не буквальное сравнение. Содержательная часть, если убрать маркетинговую рамку, прикладная и по делу.

Центральная мысль: если ваш агент работает — это ещё ничего не значит. Надёжная работа в production требует инженерии. Заплатин разбирает четыре конкретные практики: правильно выстроенный контекст (что агент видит и в каком виде), feedback loop (как агент получает сигнал об ошибке и исправляет курс до конца задачи), MCP-интеграции (реальные инструменты вместо угадывания по обучающим данным), и скиллы — описания того, как решать конкретные задачи в…

Автор: Денис Буздалов · Heisenbug

Денис Буздалов работает в ИСП РАН с 2010 года: верификация авиационной электроники самолётов, тестирование криптопротоколов по формальным моделям, зависимые типы. Человек, который думает о корректности систем профессионально.

8 апреля 2022 года самолёт TAP Air Portugal в Копенгагене ушёл на второй круг в нестандартной ситуации — и левый двигатель не свернул реверс тяги. ПО было корректно сертифицировано. Баг проявился после 95 миллионов посадок и не воспроизводился ни в одной другой конфигурации. Самолёты так и продолжили летать с этим ПО спустя годы — исправление планировалось к 2025 году. Буздалов задаёт с этого вопрос: что вообще значит «хорошо протестировано», если такое возможно?

Его ответ: хорошее тестирование должно ставить систему в ситуации, о которых автор тестов даже не подумал. Property-based testing это умеет — описываешь свойства, а не примеры, фреймворк ищет опровержение на случайном входе. Но есть класс задач, где случайный вход почти всегда бессмысленен:…

Автор: Юрий Самсонов · JUG.ru

Юрий Самсонов — разработчик из Яндекса. Доклад на JPoint 2023 — не обзор GraphQL и не агитация за его повсеместное использование, а конкретный опыт внедрения: что сломалось, что не ожидали, как вышли.

REST-эндпоинты имеют предсказуемую проблему роста: по мере того как клиентов становится больше, у каждого появляются свои требования к форме данных. Один клиент хочет вложенный объект, другой — плоский список. Появляются параметры вроде ?include=user,tags,comments, эндпоинты обрастают опциями, и в какой-то момент backend-разработчик обнаруживает, что его работа — это в основном добавление новых вариаций существующих эндпоинтов под нужды клиентов. GraphQL переворачивает эту ответственность: клиент сам описывает, какие данные ему нужны, и получает ровно их — без over-fetching и under-fetching. Самсонов честно рассказывает о том, что эта свобода стоит: N+1 проблемы, сложность с кешированием, отладка запросов, которые клиент сформировал сам.

Кому смотреть: backend-разработчикам, у которых…

Автор: Александр Макаров · Организованное программирование | Кирилл Мокевнин

Александр Макаров — Lead of Yii Framework, CTO нескольких компаний — пришёл с провокацией: «трофей» вместо «пирамиды тестирования». Идея в том, что классическая пирамида — карго-культ. Она хорошо работает на первом проекте, а потом перестаёт отражать реальную архитектуру системы и реальные риски.

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

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

Из этого можно взять в работу: вместо того чтобы спорить «юниты или интеграционные» — спроси: что ты называешь…

Автор: Иван Ямщиков · Podlodka Podcast

Иван Ямщиков работает в Pleias — компании, которая строит открытые языковые модели. Во время записи выпуска Podlodka #468 вышла новость о партнёрстве Pleias с Nvidia в рамках проекта Nemotron. Это не случайный контекст: Ямщиков находится внутри процесса, а не смотрит на него снаружи.

Центральный вопрос выпуска — не технический, а стратегический: что произойдёт, если весь рынок AI окончательно сконцентрируется вокруг нескольких закрытых облачных провайдеров? Ямщиков формулирует это как инженерную проблему: зависимость от GPT-4 API — это зависимость от одного вендора с непрозрачной политикой изменений, ценообразования и доступа к данным. Маленькие открытые модели — это не «дешёвая альтернатива большим», это инструмент сохранения контроля над инфраструктурой. Модель на 7 миллиардов параметров, которая умещается на одной GPU и работает локально, даёт то, что никакое API не даёт: полную воспроизводимость, отсутствие утечки данных и независимость от апстрима.

Кому смотреть: разра…

Автор: Listen IT · Listen IT

Видео Listen IT, 7 минут. BFF (Backend-for-Frontend) и API Gateway — два паттерна, которые часто упоминают вместе и так же часто смешивают в один. Это разные решения разных проблем.

API Gateway — единая точка входа для всех клиентов: аутентификация, rate limiting, роутинг запросов к нужным сервисам. Он не знает о специфике клиента — будь то мобильное приложение, веб или сторонний партнёр, все получают одинаковый интерфейс. BFF — другое: отдельный backend, специально заточенный под нужды конкретного типа клиента. Мобильному приложению нужны агрегированные данные в компактном формате, чтобы не делать десять запросов там, где один. Веб-интерфейсу нужны другие данные в другой структуре. BFF решает это не изменением общего API, а созданием специализированного слоя для каждого клиента. Разделение полезное — пока не начинаешь дублировать логику между BFF для web и BFF для mobile.

Кому смотреть: разработчикам и архитекторам, проектирующим API для нескольких типов клиентов — мобильного…

Автор: Максим Денушев (Точка) · Golang Channel

Максим Денушев работает в банке Точка. Доклад с GolangConf 2024, 31 минута. API Gateway — компонент, через который проходит весь трафик платформы. Переписать его — значит заменить двигатель у летящего самолёта: система должна оставаться доступной, а пользователи не должны заметить, что что-то происходит.

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

Кому смотреть:…

Автор: Дмитрий Самохвалов · HighLoad++ Channel

Доклад с HighLoad++ 2024, 49 минут. Kubernetes великолепно работает внутри себя. Проблемы начинаются на границе: когда поды должны обращаться к legacy-сервисам вне кластера, а legacy-системы — к подам. Эта граница существует у большинства компаний, которые переходят на Kubernetes постепенно, а не заново строят всё с нуля.

Самохвалов разбирает конкретные конфигурации и паттерны: как работает сетевая модель Kubernetes (flat network, каждый под получает IP) и почему она не совпадает с тем, чего ждёт legacy-окружение; как CNI-плагины (Calico, Cilium, Flannel) по-разному решают задачу связности; как настроить BGP-пиринг между кластером и существующей сетевой инфраструктурой; почему NodePort и LoadBalancer — это не решение, а костыль, который работает до определённого масштаба. Это доклад не про «установите Kubernetes», а про то, что происходит когда старая и новая инфраструктура должны сосуществовать в одной сети.

Кому смотреть: DevOps- и SRE-инженерам, занимающимся…

Автор: Listen IT · Listen IT

Видео Listen IT, 9 минут. Canary deployment и Blue-Green — две стратегии выката, которые решают одну задачу разными способами: как выпускать новые версии без того, чтобы весь трафик сразу шёл на непроверенный код.

Canary deployment — это постепенный выкат: сначала 1–5% пользователей получают новую версию, остальные работают со старой. За это время смотрят на метрики: error rate, latency, конверсии. Если всё хорошо — процент растёт. Если что-то ломается — откатить стоит секунд, а не часов. Название идёт от шахтёрской практики: канарейки чувствовали токсичный газ раньше людей. Небольшой процент пользователей — первые, кто обнаруживает проблему, пока большинство ещё на безопасном коде. Это принципиально другой разговор о надёжности: не “как сделать, чтобы не сломалось”, а “как сделать, чтобы поломка затронула минимум людей и откатилась быстро”.

Кому смотреть: разработчикам и DevOps-инженерам, у которых релиз — это страшное событие раз в неделю с ручным smoke-тестингом. И тем, кто хочет…

Автор: Михаил Жилин · HighLoad++ Channel

Доклад с HighLoad++ 2024, 50 минут. PostgreSQL — база, которую хорошо знают и любят. Но поведение под нагрузкой — это другая тема: здесь включаются механизмы, которые в обычной работе не видны и в документации описаны скромно.

Жилин разбирает аномалии, которые проявляются именно под нагрузкой: как MVCC-механизм начинает накапливать мёртвые версии строк быстрее, чем autovacuum успевает их убирать; как это влияет на размер таблиц и производительность запросов; какие блокировки возникают там, где их не ждёшь; как connection pool ведёт себя при спайках и почему «просто увеличить max_connections» решает одну проблему и создаёт две новых. Доклад не обзорный — это конкретный производственный опыт с цифрами и конфигурациями.

Кому смотреть: разработчикам и DBA, которые эксплуатируют PostgreSQL под реальной нагрузкой и хотят понять, почему база «начала тормозить» — и особенно тем, кто ещё не сталкивался с bloat и autovacuum lag, пока они не случились в продакшне.

Из этого можно…