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

Автор: Listen IT · YouTube · статья Highload Today

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

Ролик Listen IT даёт короткое введение в оба подхода. Реплики можно использовать для резервирования и переноса части чтений с основного узла. Шардинг нужен, когда объём данных или нагрузка перестают помещаться на одном сервере: система выбирает shard key и по нему определяет, где должна находиться каждая запись.

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

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

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

Автор: Кирилл Борисов · PyCon Russia 2016

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

Кирилл Борисов показывает, как sampling profiling превращает работу программы в набор снимков стека. Вместо инструментирования заранее выбранных функций профайлер периодически фиксирует весь текущий путь вызовов. Такой сбор пропускает короткие события и не даёт точной хронологии, зато меньше вмешивается в выполнение программы и сохраняет контекст: не только работающую функцию, но и цепочку, которая к ней привела.

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

Доклад записан в 2016 году: конкретные Python-инструменты и способы их подключения стоит воспринимать как исторический контекст. Сам подход не устарел — flame graph остаётся одним из основных представлений для sampling и continuous profiling.

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

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

Автор: Сергей Петренко · HighLoad++ 2022

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

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

Кому смотреть: инженерам, которые проектируют failover, настраивают кворумы или составляют инструкции на случай потери связи между ЦОДами.

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

Авторы: Ирина Блажина и Николай Зайцев · HighLoad Channel

В X5 Tech несколько продуктов использовали собственные системы аутентификации. Пользователям приходилось заново входить в разные сервисы и получать дополнительные SMS, а команды независимо поддерживали код, связанный с безопасностью. Единый SSO должен был решить обе проблемы.

Основой системы стал Keycloak. Его возможностей хватало для обработки входов, но при росте аудитории команда столкнулась с другим ограничением: время запуска зависело от количества сохранённых сессий. Так задача масштабирования SSO превратилась в разбор кэшей, rolling updates, PostgreSQL и устройства самого Keycloak.

Кому смотреть: командам, которые внедряют централизованную аутентификацию, расширяют Keycloak собственными providers или готовят SSO к большой аудитории.

Из этого можно взять в работу: проверять identity-сервис не только под потоком входов, но и при полном перезапуске кластера с реальным объёмом пользовательских сессий.

Автор: Дмитрий Ходаков · PyCon Russia 2018

В 2015 году команда Авито выбрала Tornado по правильным причинам. Фреймворк был зрелым, выдерживал production-нагрузку и располагал библиотеками для нужных баз данных. На его основе собрали общий шаблон, от которого затем выросли десятки микросервисов.

Через три года сервисы продолжали работать, но изменился сам Python. Нативные async/await и стандартный asyncio сформировали другую модель асинхронного приложения. Tornado тоже развивался, однако за ним тянулись генераторы, глубокие стеки и собственные исторические абстракции. Когда рядом появился aiohttp, прежний разумный выбор начал обходиться дороже нового — хотя формально ничего не сломалось.

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

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

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

Автор: Александр Луценко · HighLoad Channel

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

Александр Луценко рассказывает, как команда перенесла профилирование с dev-окружения в production и превратила его в постоянный observability-сигнал. Мотивация проста: stage отличается от production железом, данными и формой нагрузки. Даже хороший нагрузочный тест не воспроизводит все сочетания условий, которые возникают в реальной системе.

Для сбора команда выбрала sampling profiler в отдельном sidecar-контейнере. Он не требовал менять код приложения или устанавливать расширение внутрь процесса. Профили отправлялись в коллектор, фильтровались, агрегировались и дополнялись метками сервиса, окружения и транзакции. Так отдельный flame graph превращался в историю поведения приложения между релизами.

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

Кому смотреть: backend- и platform-командам, которые хотят профилировать production или уже собирают профили, но рассматривают их отдельно от метрик и distributed tracing.

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

Автор: Eugene Suleimanov · Proselyte

Почти двухчасовой курс от автора Eugene Suleimanov показывает Keycloak не как «готовую страницу входа», а как отдельную платформу, которой приложение передаёт значительную часть работы с аутентификацией и авторизацией.

Полностью пересказать такой материал в одном дайджесте невозможно. Автор последовательно проходит от realm, clients, scopes и roles до OAuth 2.0, OpenID Connect, SAML, федерации пользователей и межсервисного доступа. Затем собирает практическую систему с двумя приложениями, PostgreSQL и Keycloak, подключает внешние Identity Providers и защищает вызовы между сервисами.

Главная мысль курса — у приложения не одна граница входа. Пользователь может приходить напрямую или через GitHub, учётная запись может храниться в LDAP, а один сервис должен обращаться к другому без участия человека. Keycloak даёт общую точку, где эти сценарии можно описывать и контролировать.

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

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

Автор: Юрий Селиванов · PyCon Russia 2018

Создать конкурентную задачу легко. Гораздо труднее определить, кто отвечает за её завершение, куда уйдёт исключение и что произойдёт с остальными операциями после таймаута.

В 2018 году Юрий Селиванов рассказывал не только о новых возможностях Python 3.7, но и о фундаментальном недостатке раннего asyncio: библиотека позволяла запускать задачи почти из любого места, не заставляя связывать их жизненные циклы. В результате задача могла пережить породивший её код, потерять исключение или оставить незакрытые ресурсы. Решение автор искал в идеях Trio: nursery, supervisors и управляемых областях отмены.

Смотреть этот доклад сейчас особенно интересно. Можно сравнить планы автора с тем, что действительно появилось в Python. Конкретные API изменились и пришли позже, но поставленная проблема оказалась точной: современному async-коду понадобились не новые способы запускать корутины, а структурированное управление ими.

Кому смотреть: Python-разработчикам, которые используют фоновые задачи, таймауты и конкурентные запросы, но ещё полагаются преимущественно на create_task() и gather().

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

Автор: Ильяс Салихов · PHP Russia 2022

ORM умеет сгенерировать миграцию, но не знает, выдержит ли её production. На таблице в сто миллионов строк обычный UPDATE, добавление ограничения или перестройка связей могут надолго занять базу блокировками. Формально схема обновляется правильно — а приложение в это время отвечает ошибками.

Ильяс Салихов показывает, как RetailCRM работает с PostgreSQL при постоянной нагрузке около 100 тысяч транзакций в секунду. Самая полезная часть доклада — не отдельные настройки PostgreSQL, а отношение к изменению схемы как к серии совместимых релизов. Новая структура сначала появляется рядом со старой, приложение некоторое время пишет в обе, данные переносятся порциями, чтение переключается отдельно — и только после проверки удаляется прежняя модель.

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

Из этого можно взять в работу: на review следующей большой миграции отдельно проверить, совместим ли каждый её этап и можно ли остановиться или откатиться между этапами.

Автор: Listen IT · YouTube · статья Nixys

При входе через SAML приложение не получает пароль пользователя. Вместо него оно получает XML-документ, в котором Identity Provider утверждает, что пользователь прошёл аутентификацию. Теперь безопасность зависит от того, насколько строго приложение проверяет это утверждение.

Ролик Listen IT объясняет основные роли SAML. Service Provider представляет приложение, Identity Provider проверяет пользователя, а браузер переносит SAML-запросы и ответы между ними. Благодаря установленному доверию один вход у IdP может открыть доступ к нескольким независимым приложениям.

Это хорошее введение в SAML SSO, но реальный протокол сложнее показанной схемы. Недостаточно найти в ответе имя пользователя: Service Provider должен проверить цифровую подпись, отправителя, получателя, срок действия и другие ограничения assertion.

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

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

Автор: Григорий Петров · MoscowPython

О GIL часто говорят как об одном большом запрете: Python якобы не умеет работать с потоками. Из такого объяснения невозможно понять ни то, почему ограничение появилось, ни то, почему сетевые программы всё же получают пользу от потоков, ни то, какие ошибки GIL предотвращает на самом деле.

Григорий Петров начинает с истории процессов и потоков, а затем постепенно подводит к устройству CPython. Потоки делят память одного процесса, поэтому интерпретатор должен сохранять целостность своих внутренних структур, даже если операционная система переключит выполнение в неудобный момент. GIL даёт право исполнять Python bytecode одному потоку за раз и тем самым упрощает защиту состояния интерпретатора.

Но действие этого ограничения уже, чем кажется. Во время многих блокирующих операций ввода-вывода GIL освобождается, поэтому другие потоки могут продолжать работу. Нативные библиотеки также могут выполнять тяжёлые вычисления вне интерпретатора без удержания GIL. Главное историческое ограничение относится к CPU-bound коду, который исполняет Python bytecode и пытается использовать несколько ядер с помощью потоков.

Важно для 2026 года: доклад описывает стандартную модель CPython с GIL, которая по-прежнему используется по умолчанию. В CPython 3.13 появилась экспериментальная free-threaded сборка, а в Python 3.14 она стала официально поддерживаемой, но осталась опциональной. Поэтому ограничение CPU-bound потоков уже не абсолютно, однако совместимость расширений, накладные расходы и корректность многопоточного кода всё ещё требуют отдельной проверки.

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

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

Автор: Антон Титов (SpiralScout) · PHP Russia 2019

Классическая модель PHP начинает каждый запрос почти с чистого состояния: загружает приложение, создаёт контейнер и после отправки ответа освобождает процесс. RoadRunner сохраняет PHP worker между запросами — и тем самым превращает прежнюю гарантию очистки в ответственность разработчика.

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

У производительности есть обратная сторона. Объект, соединение или пользовательский контекст теперь способны пережить запрос, для которого были созданы. PHP-приложение должно работать как настоящий долгоживущий сервис, а не рассчитывать, что процесс автоматически уничтожит всё состояние.

Кому смотреть: PHP-разработчикам, которые рассматривают RoadRunner, FrankenPHP или другую модель долгоживущих workers.

Из этого можно взять в работу: проверить сервисы и singleton-объекты приложения на данные текущего пользователя, запроса или транзакции, которые могут остаться в памяти после ответа.

Автор: Listen IT · YouTube · статья Nixys

Single Sign-On часто объясняют как «один пароль для всех приложений». Но главное изменение происходит не в пароле: приложения перестают самостоятельно проверять учётные данные и начинают доверять результату аутентификации в другой системе.

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

SSO при этом не является отдельным протоколом. Это желаемое поведение системы, которое можно реализовать через SAML или OpenID Connect. LDAP, Active Directory Domain Services и Active Directory Federation Services тоже появляются рядом с SSO, но решают задачи другого уровня: хранят пользователей, предоставляют доступ к каталогу или организуют федерацию.

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

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

Автор: Николай Павлин · «Павлин Шарит — ИТ вместе с Николаем Павлиным»

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

Николай Павлин показывает, как вынести эти правила в конечный автомат с помощью Python-библиотеки python-statemachine. Состояния и переходы объявляются отдельно, недопустимые изменения блокируются библиотекой, а действия и условия можно привязать к конкретным переходам жизненного цикла.

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

Кому смотреть: Python-разработчикам, у которых правила изменения статуса сущности начали повторяться в разных частях приложения.

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

Автор: Ильяс Салихов (retailCRM) · PHP Russia 2019

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

Ильяс Салихов сравнивает PHP и Go на опыте retailCRM. На момент доклада систему обслуживали около тридцати сервисов: примерно 60% были написаны на PHP с Symfony, 30% — на Go. Автор не выбирает победителя, а показывает задачи, для которых в компании использовали каждый стек.

PHP выигрывал в насыщенных бизнес-приложениях. Symfony и Doctrine давали ORM, Unit of Work, миграции, формы и валидацию. Go выбирали для небольших API и сервисов с конкурентной обработкой, где были полезны goroutines, производительность и поставка одним бинарником.

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

Из этого можно взять в работу: сравнивать не только скорость runtime, но и список инфраструктурных и прикладных механизмов, которые команде придётся реализовать или сопровождать самостоятельно.

Автор: Дмитрий Емельянов (Altenar) · Видео с мероприятий {speach!}

В 39-минутном докладе Дмитрий Емельянов, тимлид группы разработки в Altenar, рассказывает об аварии, которая началась почти как анекдот: команда настраивала новый бэкап Kafka — и именно в этот момент потеряла Kafka. Но самое интересное случилось не во время аварии, а после, когда кластер уже удалось восстановить.

В системе Altenar некоторые топики были не просто транспортом между микросервисами, а единственным источником истины. При запуске сервисы перечитывали их, собирали состояние в памяти и затем продолжали работать с ним. Kafka реплицировалась между брокерами, а раз в сутки её файлы дополнительно копировали с одного диска на другой. Восстановление этих копий не проверяли: для этого пришлось бы останавливать stage, мешать работе QA и откладывать бизнес-фичи.

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

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

Из этого можно взять в работу: проверять не только то, поднимается ли Kafka из копии, но и то, сможет ли после отката продолжить работу вся система. Особенно важно заранее понимать, как устранять рассинхронизацию между хранилищами, восстановленными на разные моменты времени.

Автор: Александр Боргардт (duckstax) · Evrone Development

У питонистов есть простое правило: хочешь сделать быстро — пиши нативный код. Это действительно так, когда нативный код пишут опытные C/C++-разработчики. Но те, кто только начинает погружаться в эту область, часто обнаруживают что стало не быстрее, а медленнее. Боргардт объясняет почему — и как это исправить.

Реальный кейс: ML pipeline с видеопотоком, задача — поиск объектов в кадре в реальном времени. На каком-то этапе всё начало тормозить. Расследование привело не к проблеме в алгоритме, а к проблеме на границе Python–C++: неявные накладные расходы при вызове нативного кода из Python.

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

Из этого можно взять в работу: если пишете C++-модуль для Python и работаете с большими массивами данных — изучите Buffer Protocol (PEP 3118). Это стандартный механизм zero-copy передачи данных между Python и нативным кодом, который поддерживают numpy, bytearray, bytes.

Автор: Даниил Коноваленко (Яндекс Go) · Python Channel · Moscow Python Conf++ 2021

Даниил Коноваленко — backend-разработчик в Яндекс Go. В подразделении несколько сотен микросервисов, треть из них написана на Python. Однажды во время дежурства пришёл алерт: один из сервисов занял 91% памяти. Открыв графики — всё выглядело нормально. Открыв на большем масштабе — характерный паттерн: память растёт линейно и никогда не возвращается. После перезапуска — то же самое. Это и есть утечка.

Доклад — детективная история с реальным production-кейсом. Три акта: как утечка выглядит и как её опознать, откуда они берутся в языке с GC, какие инструменты помогают найти и исправить.

Кому смотреть: backend-разработчикам на Python, которые деплоят сервисы в production и уверены что GC за них всё уберёт. После этого доклада — чуть менее уверены, зато знают что делать.

Из этого можно взять в работу: если у вашего сервиса есть метрика потребления памяти — посмотрите на неё на масштабе нескольких дней. Линейный рост без возврата после GC-цикла — сигнал для расследования, а не повод «накинуть памяти и посмотреть».

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

Асхат Уразбаев — один из наиболее известных Agile-консультантов в России, основатель ScrumTrek, более двадцати лет внедрял Agile в крупнейших российских компаниях. В этом выпуске подкаста «Организованное программирование» (1:53:26) он говорит не о том, как «правильно внедрять Scrum», а о том, что произошло с Agile за двадцать лет — и куда это движение привело.

Центральный вопрос разговора: почему Scrum победил XP? Ответ неочевидный — не потому что лучше технически, а потому что церемонии, роли и сертификации проще продавать. XP требовал технической дисциплины: TDD, парного программирования, непрерывной интеграции. Scrum предлагал процесс, который мог вести не инженер, а специально нанятый Scrum Master. Это решило задачу менеджмента — и убило технические практики.

Кому смотреть: тимлидам и менеджерам, которые работают «по Agile», но чувствуют что что-то не так; разработчикам, которым интересна история методологий — не как мифология, а как реальные организационные и коммерческие решения.

Из этого можно взять в работу: спросить себя — Continuous Delivery в вашей команде есть, или только спринты? По словам Уразбаева, именно отсутствие CD при наличии Scrum-церемоний — самый частый симптом того, что «Agile» внедрён, а ценностей нет.

Автор: Артём Малышев · Moscow Python Conf 2016

⚠️ Материал 2016 года, Django Channels 1.x. Концептуальный разбор «зачем это нужно» остаётся актуальным. Детали API и конкретные паттерны с тех пор существенно изменились (Channels 2.x переписал архитектуру Channel Layer). Сверяйтесь с актуальной документацией.

Классический Django построен на WSGI — стандарте, появившемся в 2003 году. Его базовый контракт прост: принять запрос, вернуть ответ. Никакой асинхронности, никаких долгоживущих соединений. Это сознательный дизайн для эпохи, когда веб состоял из страниц с новостями и гостевых книг.

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

Кому смотреть: Django-разработчикам, которым нужны WebSocket или long-polling, и которые хотят понять как Channels вписывается в Django-архитектуру — особенно где заканчивается синхронный Django и начинается async.

Из этого можно взять в работу: если добавляете real-time функциональность в Django-проект — поймите границу между синхронным Django (models, ORM, middleware) и async Channel Layer до того как начнёте писать код. Смешивать их без понимания этой границы — источник трудноуловимых проблем.