Backend Systems | balun.courses

🎙 Что меняется во взгляде на backend-систему, когда отвечаешь за ее надежность

Знакомьтесь: Виталий Лихачёв - SRE-инженер и автор курса Observability. А еще в кадре его кот Маркус 🐱

Виталий рассказывает, как меняется взгляд на production, когда зона ответственности разрастается от нескольких сервисов до целой системы. Почему телеметрию важно продумывать заранее, как связаны надежность и Observability и почему даже AI не поможет разобраться в данных, если они не организованы. Этот системный подход раскрывается и на курсе: через проектирование полезных сигналов, связь метрик, логов и трейсов и анализ деградаций в цепочках сервисов. Есть вопросы об Observability? Задавайте их в комментариях 👇

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

HTTP-запрос → сервис-источник → Kafka-топик → обработчик → следующий сервис или БД

После публикации сообщения исходный HTTP-запрос уже завершился, а обработка продолжится в другом процессе или на другом экземпляре приложения. Без передачи диагностического контекста трейс сервиса-источника закончится на публикации, а работа обработчика отобразится как отдельный трейс. Логи можно попытаться сопоставить по времени, но при параллельной и пакетной обработке, а также повторных попытках такая связь становится ненадёжной. Идентификатор сообщения или бизнес-операции помогает искать события, однако сам по себе не описывает отношения между spans. Чтобы сохранить связь, producer добавляет контекст трассировки в метаданные сообщения - в Kafka для этого можно использовать record headers. Consumer извлекает контекст во время обработки, после чего с ним можно связать spans обработчика, последующие обращения к сервисам и записи в логах. Связь между producer- и consumer-span не всегда выглядит как прямая parent-child цепочка. Например, при пакетном чтении consumer получает сообщения с разными контекстами. В таких случаях причинные связи можно сохранить через Span Links. На курсе Observability этот механизм рассматривается как часть проектирования наблюдаемости системы. В программе связаны Observability асинхронных взаимодействий, работа с OpenTelemetry, корреляция трейсов, логов и метрик, а также поиск высокой latency и ошибок по трейсам. Такой подход помогает исследовать путь операции через несколько компонентов, а не ограничиваться состоянием одного сервиса. При этом даже связный трейс не гарантирует готового ответа о первопричине. Часть пути может отсутствовать из-за семплирования или неполного инструментирования, а продолжительный span показывает место задержки, но не обязательно объясняет, почему она возникла. Зато команда получает данные, по которым можно последовательно сужать область поиска. Как это устроено у вас: контекст передаётся автоматически, добавляется в Kafka headers вручную или трейс обрывается после публикации сообщения?

Почему первый шаг зависит от условий В этом опросе нет одного универсально правильного варианта. Рост p95 latency фиксирует симптом, но сам по себе не показывает его причину. Выбор первой проверки зависит от архитектуры сервиса, доступных сигналов и того, что уже известно к началу расследования. Метрики помогают определить масштаб проблемы: замедлились все эндпоинты или один, все экземпляры или отдельная группа, совпал ли рост задержки с изменением нагрузки или процентом ошибок. При этом агрегированные значения обычно не объясняют, что происходило внутри конкретного запроса. Логи полезны, если по времени, эндпоинту или идентификатору запроса можно найти медленные операции и увидеть зафиксированные события. Их возможности ограничены тем, какие данные приложение записывает и насколько последовательно устроено логирование. Трейсы позволяют сравнить путь медленного и обычного запроса и увидеть, на каком участке выросло время выполнения. Однако длинный span указывает на место задержки, но не обязательно на ее первопричину. Кроме того, нужный запрос может не попасть в выборку, а часть операций - остаться без инструментирования. Проверка зависимостей оправданна, когда устройство сервиса или первые наблюдения указывают на базу данных либо другой компонент. Здесь важны тот же временной интервал и конкретный сценарий: нормальные показатели зависимости в целом не исключают замедления отдельного запроса или операции. Релиз, изменение конфигурации или рост трафика тоже могут дать рабочую гипотезу, если совпадают по времени с началом деградации. Такое совпадение еще не доказывает причинную связь, поэтому его нужно проверить по другим данным. Первым полезно выбирать действие, которое быстрее сузит область поиска или проверит наиболее вероятную гипотезу. Дальше расследование обычно требует сопоставить несколько сигналов по времени, эндпоинту, версии сервиса, request ID или trace ID. Умение выбирать следующий сигнал и последовательно сужать область поиска - одна из базовых задач Observability.

Что вы проверяете первым, когда сервис начинает отвечать медленнее? Условная ситуация: за последние 15 минут у API-сервиса выросла p95 latency. Доля ошибок осталась на обычном уровне, но пользователи подтверждают замедление. Сервис обслуживает несколько эндпоинтов, обращается к базе данных и вызывает другие сервисы. У команды есть метрики, централизованные структурированные логи и распределённый трейсинг. Инцидент только начался, готового сценария диагностики для этого симптома нет.

Всё про Kafka есть бесплатно. Тогда за что вообще платить 52 400 ₽? За саму информацию – наверное, незачем. Документация Kafka открыта. Доклады спикера можно посмотреть бесплатно. Есть книги, статьи, конференции, чужие postmortem'ы. Если есть время и желание, практически во всём из программы курса можно разобраться самостоятельно. Проблема обычно появляется не на этапе «где найти информацию». Допустим, у вас в production растёт consumer lag. Можно открыть документацию и прочитать всё про consumer groups, rebalance, offsets и настройки consumer. Но дальше всё равно придётся самому понять: • что из этого относится именно к вашей проблеме; • в каком порядке проверять гипотезы; • какие рекомендации актуальны для вашей версии и нагрузки; • почему решение из чужой статьи у вас не сработало; • какой компромисс допустим именно в вашей системе. А иногда два вполне компетентных источника вообще советуют противоположные вещи – потому что исходные условия у них разные.

За это и платят на курсе: не за доступ к «секретной информации про Kafka», а за собранную последовательность от задачи к решению.

За 6 недель идём от устройства Kafka к записи, чтению, работе под высокой нагрузкой и стриминговой обработке. Всё это связывается одним проектом – сервисом склада, который усложняется по мере прохождения программы. Плюс каждую неделю есть Q&A, где вопросы можно задать непосредственно Андрею Серебрянскому – человеку, который 8+ лет работает с Kafka, строил streaming-платформы и сейчас разрабатывает YDB Topics в Яндексе. Не куратору, который сверяет ответ с методичкой. Поэтому самостоятельно изучать Kafka – абсолютно нормальный вариант. Курс нужен скорее тогда, когда хочется не просто накопить ещё материалов, а систематизировать знания и научиться применять их к реальным архитектурным задачам. Стартуем 8 сентября. ➡️Посмотреть программу курса

Не 6 уроков про Kafka, а 6 рабочих задач Названия уроков сами по себе мало говорят о том, что потом получится делать в работе. Поэтому на карточках собрали программу иначе – через задачи, которые участники будут учиться решать на курсе❤️

Там: как выбрать брокер под требования системы, настроить запись, найти причину consumer lag, рассчитать кластер под рост нагрузки, выбрать инструмент для стриминговой обработки и разобраться, где новые возможности Kafka уже могут заменить самописные решения.

Все эти темы проходят не отдельно друг от друга. На курсе есть сквозной проект – сервис склада, который постепенно усложняется от занятия к занятию: сначала поднимаем Kafka, затем добавляем запись и чтение, CDC, схемы, безопасность и потоковую обработку. Курс рассчитан на Middle/Senior-разработчиков и архитекторов, которым уже недостаточно просто подключить producer и consumer. 💾Основная задача – научиться принимать решения вокруг Kafka так, чтобы система нормально переживала рост нагрузки и её не приходилось переделывать после первых серьёзных проблем. Старт – 8 сентября. Через 2 дня – финальное повышение цены на курс. Если планировали идти, до повышения можно зафиксировать текущую стоимость. ➡️ИЗУЧИТЬ ПРОГРАММУ КУРСА

Найдите ошибки в этой Kafka-архитектуре На схеме – условная система склада. Что в ней есть: • все события пишутся в один топик; • partition key выбран по типу события; • у топика всего 3 партиции; • данные читают несколько команд, но без Schema Registry; • retention = 1 день; • ошибки обработки бесконечно уходят в retry. Что именно здесь может сломаться или начать дорого обходиться команде?

Сколько клеток закрывается на вашем архитектурном созвоне? 👀 Собрали bingo из фраз, которые подозрительно часто звучат на архитектурных обсуждениях. Отмечайте, что слышали в последнее время) Если собрали bingo – присылайте тому самому коллеге 🙂

Если вы уже работаете backend-разработчиком, знаете любой backend-язык, умеете пользоваться Docker и понимаете базовый Computer Science – этого достаточно, чтобы стартовать) Дальше темп быстро растёт: от базового устройства Kafka переходим к production-задачам – записи, чтению, ребалансам, отказам и работе под высокой нагрузкой. Поэтому отсутствие опыта с Kafka – не проблема. А вот если backend-база пока ещё неуверенная, лучше сначала укрепить её. Старт курса – 8 сентября. ➡️ИЗУЧИТЬ ПРОГРАММУ КУРСА

Я Middle-разработчик, но с Kafka почти не работал. Мне подойдёт курс? Курс рассчитан на Middle/Senior, но опыт работы именно с Kafka для входа не обязателен. На первом занятии начинаем с устройства Kafka: разбираем архитектуру, основные термины, отличие от RabbitMQ, поднимаем Kafka и пробуем писать и читать сообщения. То есть Kafka начинаем с основ. Разработку – нет.

DLQ не решает проблему с сообщением. Он просто убирает его с пути consumer Сообщение не обработалось – его отправили в отдельный топик, а consumer пошёл дальше. Для основного потока это удобно, но сама ошибка никуда не исчезает.

Если заранее не определить, кто разбирает DLQ и как сообщения возвращаются в обработку, через несколько месяцев там просто накапливается очередь проблем❗️

Обычно путь в DLQ продуман хорошо: после нескольких неудачных попыток сообщение отправляется в отдельный топик. А вот дальше начинаются вопросы: • почему оно туда попало и устранена ли причина ошибки; • можно ли безопасно обработать его повторно; • не нарушится ли порядок событий; • что произойдёт при повторной обработке: не появится ли дубль в БД, повторный вызов внешнего API или ещё одно изменение состояния. 💾Поэтому одного DLQ недостаточно. Нужен процесс восстановления: мониторинг новых сообщений, alert, понятный owner и инструкция, что делать в каждом сценарии. Иначе сообщения можно месяцами складывать отдельно от основного потока и формально считать, что обработка ошибок в системе есть. На курсе «Kafka для разработчиков: тонкости и нюансы» отдельно разбираем работу с consumer при ошибках: retry, DLQ, offsets и повторную обработку сообщений – в том числе ситуации, когда вернуть сообщение обратно не так просто, как кажется. ➡️ИЗУЧИТЬ ПРОГРАММУ КУРСА 💬А у вас DLQ – рабочий инструмент или топик, в который стараются лишний раз не заглядывать?

Consumer lag растёт. Добавить ещё консюмеров? Это первое решение, которое приходит в голову, когда сервис перестаёт успевать за потоком сообщений. Кажется логичным: было 5 консюмеров – сделаем 10 и будем читать в два раза быстрее. Но Kafka так работает не всегда.

В карточках разобрали, где искать причину растущего consumer lag и почему добавлять новые консюмеры – не всегда первое, что стоит делать

На третьем уроке курса «Kafka для разработчиков: тонкости и нюансы» отдельно разбираем чтение из Kafka: штормы ребалансов и замедление чтения, Schema Registry, DLQ, работу с offsets и другие ситуации, которые возникают уже в production. Начинаем 8 сентября. ➡️ПОСМОТРЕТЬ ПРОГРАММУ КУРСА

⚡️ElasticSearch для разработчиков Привет, на связи Balun.Courses!

Готовим углубленный курс для разработчиков по использованию ElasticSearch. И чтобы не «тыкать пальцем в небо», хотим спросить у вас напрямую: 1) Насколько этот инструмент для вас понятен? 2) Где вы вообще используете эластик? 3) Какие у вас возникают сложности? И есть ли они вообще?

Подготовили небольшой опрос, который займет не больше 10 минут. 🎁 Каждому, кто ответит на вопросы честно и развернуто – дадим промокод на скидку в -15% на любой наш курс или интенсив. В конце попросим поделиться своим Telegram'ом для связи. Индивидуально отсмотрим каждую анкету, и если ответы покажутся нам развернутыми и полезными – отправим промокод в личку! Есть две весомые причины заполнить опрос: 1) получите дополнительную скидку на любую программу. Суммируется с вашей персональной, если уже учились у нас ранее. А если не учились, но планировали – хороший повод сэкономить несколько тысяч за 10 минут 2) по выявленным проблемам напишем практические статьи и запишем несколько бесплатных уроков на ютуб. Закроете часть своих трудностей, не проходя никакие обучения Очень просим вас помочь – сделаете огромный вклад в общее дело🙌🏻 ЗАПОЛНИТЬ ОПРОС

Андрей Серебрянский рассказывает, как бы он изучал Kafka заново в 2026 году☝️ Курс, о котором говорит Андрей, называется «Kafka для разработчиков: тонкости и нюансы» Это глубокий курс про внутреннее устройство, лучшие практики, паттерны и антипаттерны – все для работы в highload-проектах. На примере реальных кейсов ❤️ В рамках курса мы создадим свой pet-проект — сервис склада. На нем же разбираться во всех тонкостях Кафки. Начинаем уже 8 сентября – успевайте занять своё место и за 1,5 месяца изучить всё, что нужно знать про Kafka! ✔️ЗАНЯТЬ МЕСТО НА КУРСЕ