Python-бэкенд в проде: профайлеры, наблюдаемость и дежурство

Твой код уже в проде. Пора научиться отвечать за него целиком В пятницу вечером сервис лёг. Ты сидишь в звонке, смотришь на графики и слушаешь: «упёрлись в пул», «заблокировали loop», «под убил OOM», «реплика отстала». Кто-то чинит. Ты понимаешь примерно половину — и надеешься, что в этот раз будить будут не тебя. Или приходит задача: «Ускорь ручку к релизу». Ты добавляешь индекс, переписываешь код на async, убираешь лишний запрос. Кажется, стало лучше. А насколько? Что именно было узким местом? Не стало ли хуже под нагрузкой? Ответить нечем. Код в проде — твой. Значит, прод не должен оставаться чужой территорией. Этот курс — о том, что происходит с Python-сервисом после мержа: как он исполняется, почему деградирует под нагрузкой, куда утекает память, почему «много async» не гарантирует параллелизм и как действовать, когда алерт пришёл ночью. Здесь не предлагают верить общим словам вроде «GIL мешает многопоточности» или «надо добавить метрик». Ты получаешь доступ к учебному стенду через Telegram-бота, воспроизводишь проблему, снимаешь профиль, трейс или график — и проверяешь гипотезу цифрой. В итоге у тебя будет не сертификат, а доказательства Через весь курс ты собираешь эксплуатационный пакет своего сервиса — документ, который можно принести на работу, прод-ревью или собеседование: бюджет ответа эндпоинта; расчёт воркеров, пулов, таймаутов и лимита памяти — с обоснованием каждого числа; дашборд дежурного и алерты, к которым приложено действие; разделы о хранилищах, зависимостях и сборке; runbook для типовых отказов; план выкатки и отката; постмортем по инциденту без поиска виноватых. Это 16 записей в 6 разделах: не домашка, которую пишут в последний вечер, а рабочий документ, который растёт модуль за модулем. К нему прилагаются твои артефакты: флеймграфы, профили памяти, трейсы, графики, нагрузочные прогоны «до и после». В финале ты проверяешь пакет чек-листом прод-готовности из 19 пунктов, затем сам вносишь отказ в стенд, проходишь по своему runbook и дополняешь его там, где он не сработал. На прод-ревью и собеседовании ты отвечаешь своими цифрами — не пересказом чужой статьи. Не мифы о проде, а его механика Ты не просто услышишь, что GIL «мешает». Разберёшься, что именно удерживает GIL, когда он отпускается и как это меняет поведение твоего сервиса. Не просто прочитаешь об утечках. Увидишь растущий RSS, найдёшь удерживающую ссылку и отличишь утечку от фрагментации памяти. Не просто узнаешь, что event loop можно заблокировать. Сам создашь блокировку, увидишь её в сигналах и уберёшь причину: синхронный вызов, потерянный таймаут, неограниченную конкурентность или фоновые задачи. На стенде можно увидеть всё, что обычно приходится угадывать в рабочем проде: заблокированный event loop; растущую память процесса; очередь, которая не успевает разгребаться; реплику с лагом; выкатку, которая уронила p99; процесс, который был убит по OOM; незаметный CPU-троттлинг в Kubernetes. Числа вместо уверенных догадок В проде очень легко сделать правдоподобный, но неверный вывод. Например, в файле написано: «версии зафиксированы». В нём 17 строк — но реально устанавливается 70 пакетов. Три из них за шесть дней успели сменить версии сами, хотя их имён в файле вообще нет. Или кажется, что многоступенчатая сборка должна радикально облегчить образ. На практике в конкретном сценарии она снимает лишь 4% веса. А лёгкий образ не обязательно стартует быстрее: пустой процесс поднимается за 0,19 с против 0,20 с; ускорить импорт приложения вдвое помогает не вес образа, а байткод, скомпилированный во время сборки. Или сервис говорит, что партнёр отвечает за 2 008 мс, а партнёр у себя видит те же 13 мс. Оба замера честные. Ошибочным оказывается вывод «партнёр тормозит». Ни одну из этих вещей нельзя угадать. Их можно только измерить. На курсе ты учишься выбирать правильный замер, читать его и делать вывод, который выдержит встречные вопросы. Закрытый стенд: ломай, чини, измеряй Практика проходит не в чёрном ящике и не в игрушечной песочнице. У тебя будет доступ к закрытому учебному стенду с Python-сервисом службы доставки на FastAPI, где специально оставлены реальные продовые дефекты. Доступ выдаётся через Telegram-бота. Рядом поднимается полноценное окружение: PostgreSQL с репликой и PgBouncer; Redis; Celery, RabbitMQ и Kafka; метрики, трейсы и централизованные логи; генератор нагрузки; локальный Kubernetes-кластер. Ты меняешь код или конфигурацию и сразу видишь результат на графике. В этом разница между «читал про утечку памяти» и «нашёл утечку, доказал причину и проверил исправление». К финальным модулям в стенде появляется управление сетевыми отказами. Одной командой можно сломать путь к базе, реплике, кэшу, брокеру или партнёру — придушить соединение, закрыть его или начать обрывать запросы. Это 15 сочетаний отказов, которые можно безопасно отработать до того, как они случатся в рабочем проде. Ронять свой сервис по своей команде — лучший способ проверить, работает ли твой runbook. Kubernetes — без ухода в администрирование Курс не учит обслуживать кластер. Он учит понимать, какой контракт Kubernetes предъявляет твоему приложению: как сделать три пробы для трёх разных болезней; что происходит при SIGTERM и как организовать дренаж; как requests и limits связаны с OOMKilled и CPU-троттлингом; почему троттлинг может не быть виден в kubectl top; как вынести конфигурацию и секреты из образа; как безопасно выкатить и откатить изменение. Всё — локально, на своей машине, без доступа к рабочему кластеру. Как устроена программа Диагноз по сигналам → рантайм и GIL → профилирование → память → asyncio в проде → воркеры, пулы и остановка → наблюдаемость → нагрузочные прогоны → очереди и потребитель лога → хранилища глазами дежурного → упаковка и зависимости → CI/CD → Kubernetes глазами разработчика → дежурство и разбор инцидента → финальная защита. Ты работаешь с настоящим продовым стеком: FastAPI, uvicorn, gunicorn, SQLAlchemy, PostgreSQL, PgBouncer, Redis, Celery, RabbitMQ, Kafka, py-spy, memray, OpenTelemetry, Prometheus, Grafana, Loki, Alloy, Docker, uv, GitHub Actions и Kubernetes на k3d. Чего в курсе нет Это не курс по администрированию Kubernetes. Здесь нет сетевой инженерии, Terraform и инфраструктуры как кода: кластер рассматривается только со стороны приложения. Это не курс по архитектурному дизайну. Границы сервисов, саги, CQRS, выбор между очередью и логом, а также выбор брокера подробно разбираются в курсе System design: архитектура бэкенда и межсервисное взаимодействие. Здесь ты не выбираешь брокер — ты учишься эксплуатировать уже выбранный: подтверждения, смещения, ребаланс, дренаж и сигналы. Это не курс по внутреннему устройству PostgreSQL. Планирование запросов, индексы, WAL, Patroni и глубокий тюнинг — в курсе Базы данных для бэкенда: PostgreSQL вглубь и карта хранилищ. Здесь — пул соединений, лаг реплики, бэкапы и сигналы, которые нужны дежурному разработчику. Это не Python с нуля. Предполагается, что ты уже пишешь сервисы. Если нет, начни с Python с нуля и Старта в бэкенде на Python. Один курс не делает синьором — и мы этого не обещаем. Но он закрывает ключевой разрыв между «я пишу Python-код» и «я понимаю, как мой сервис живёт в проде»: рантайм, нагрузка, память, наблюдаемость, выкатывание, инциденты и дежурство. После него прод перестаёт быть территорией, куда тебя однажды позовут в ночь и где придётся надеяться, что справится кто-то другой.