🔖 Kafka: архитектура и базовые принципы — Часть 1

Ребята, я решил написать для вас серию статей про Kafka.

Она хорошо зайдет тем, кто пока знает про Kafka только то, что “это какая-то очередь”, но хочет спокойно разобраться без перегруза терминами. Начнём с базовых идей: зачем Kafka нужна, чем она отличается от обычных очередей, что такое broker, topic, producer и consumer.

Дальше постепенно дойдём до partition, offset, репликации, consumer groups и production-паттернов и производительности. Короче, попробуем пройти путь от “ничего не понятно” до “я понял как это работает на самом деле”.

Первая часть Kafka: архитектура и базовые принципы уже опубликована. Остальные 6-7 на подходе и постараюсь доделывать по одной каждый день, чтобы контекст не терялся. Enjoy...

—
Telegram | Github | YouTube | X

Ленту моего твиттера последние 2 дня разрывает от двух вещей - складного айфона и мухи. И если с айфоном всё понятно, то релиз FlyGym 2.0 – действительно интересен.

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

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

Я решил исправить эту несправедливость и заставил ее немного поработать. Представляю вашему вниманию дежурного инженера, который следит за сервисами. А если сервис падает мой мух "бежит" эскалировать в чатик. Правда пока она ходит она как devops после корпората.

В общем, пока все спорят, заменит ли ИИ айтишников, у меня дежурит муха. Главное – не прихлопнуть прод 😆

—
Telegram | Github | YouTube | X

🔖 AI больше не стыдно?

Обратили внимание, как быстро мы прошли фазу от “фууу, это нейрослоп” до состояния, когда уже даже лютые AI-нигилисты сдулись?

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

Нас приучили к тому, что AI теперь с нами везде, надолго и уходить никуда не собирается.

Если ещё полгода назад тебе приносили пуллик со словами “я тут нагенерил нейронкой, можете поревьювить?” – и у тебя от такого полыхало внутри, то теперь зайти с пулликом в вообще незнакомый бизнес-домен не только нормально, но и даже приветствуется.

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

Теперь порог входа почти исчез.

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

И с одной стороны – это офигенно.

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

Но есть и обратная сторона.

AI очень хорошо убирает ощущение собственного незнания.

Раньше ты смотрел на незнакомую кодовую базу и был как Ольга Бузова: я ничего не понимаю вообще. И это было полезное состояние. Оно заставляло тебя задавать вопросы, анализировать и искать решение.

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

А понимание при этом могло вообще не появиться.

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

А в том, чтобы не принять чужую уверенность нейронки за собственное понимание.

Ведь самое главное помнить, что ваш мозг как бюджет – если его не освоить, то в следующий раз он будет меньше.

—
Telegram | Github | YouTube | X

Только что релизнул net-peek v0.1.8. Этот маленький, но классный 🚳 на Go я сделал, когда надо было быстро понять кто поджирает трафика на серваке.

Можно, конечно, расчехлить tcpdump, добавить tshark, немного awk, но богу тулов нужны новые тулы😈.

Он показывает по каждому удалённому IP:
- входящую и исходящую скорость;
- сколько данных уже передано;
- количество активных соединений;
- подробности по каждому соединению.

Можно смотреть конкретный интерфейс или сразу все. Есть поиск, сортировка, пауза и отдельный gateway-режим для анализа трафика на NAT-сервере.

sudo net-peek -i all

В общем, делюсь с вами аккуратным TUI-монитором трафика. Репозиторий и инструкции как установить лежат тут: https://github.com/itcaat/net-peek.

Сохраните на будущее - кто знает когда он может понадобиться 🔫
—
Telegram | Github | YouTube | X

🔖 Наконец-то дождались: git branch --delete-merged

У нас у всех есть куча проектов. Мы работаем над фичами. Каждая фича - отдельная локальная ветка. Мы её делаем, пушим, открываем PR, PR мержат, ветку на сервере удаляют.

А локальная ветка остаётся. И так каждый раз. Через полгода у тебя в git branch тридцать восемь веток:

  feature/login
  feature/login-fix
  fix/typo
  topic/auth
  topic/auth-v2
  ...
  main

И ты такой сидишь и думаешь: “Какая из них ещё живая? Какие уже смержены? Можно ли что-то удалить или я что-то потеряю?”.

И вот ты уже пишешь скрипт на коленке, который тебе должен всё почистить. Запускаешь его и вуаля, ты слегка ошибся и больше в твоей репе нет бранчей, паника и судорожный поиск решения на https://ohshitgit.com/.

В общем, короче. Harald Nordgren походу сам задолбался с этим и ребята только что релизнули Git 2.56, в котором запилили опцию delete-merged.

Самое классное, что команда супер простая и простая как полено (хоспадепрости patch-format с 100500 аргументами).

$ git branch --delete-merged 'origin/*' --dry-run
Would delete branch feature/login (was abc1234).
Would delete branch feature/login-fix (was def5678).
Would delete branch fix/typo (was 9876fed).

Посмотрел. Всё выглядит нормально. Запускаешь без --dry-run:

$ git branch --delete-merged 'origin/*'
Deleted branch feature/login (was abc1234).
Deleted branch feature/login-fix (was def5678).
Deleted branch fix/typo (was 9876fed).

Всё. Ветки, которые уже влиты в свой origin, снесены. Ветки, где есть неотправленная работа, - остались. Ветки с deleteMerged = false - остались. Ветки, которые ты вычеканил в другом worktree, - остались.

Это безопасно. Свои скрипты можно выкинуть. Также можно точечно чистить категориями topic-*, feature/*, origin/* .

В общем, если git branch уже не помещается в терминал - обновляемся на 2.56 и теперь вы знаете что делать.

—
Telegram | Github | YouTube | X

🔖 Kafka: от первого сообщения до production

Наконец-то закончил писать серию статей про Kafka, которую надо читать вечерочком под пледиком и с чашечкой какао. 🙈

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

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

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

- Kafka: архитектура и базовые принципы — Часть 1
- Kafka: как масштабируются Partitions, Consumer Groups и порядок сообщений — Часть 2
- Kafka: Record, Offset и Append-Only Log — Часть 3
- Kafka: репликация, Leader, Follower и ISR — Часть 4
- Kafka: что делает её производительной — Часть 5
- Kafka: события, команды, Topics и Keys — Часть 6
- Kafka: Retention, Compaction и контракты событий — Часть 7
- Kafka: гарантии доставки, Outbox и идемпотентность — Часть 8
- Kafka: Retry, DLQ и эксплуатация Consumer — Часть 9

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

ЗЫ Отдельное спасибо за ревью статей @denis_kp

—
Telegram | Github | YouTube | X

Интересно, а насколько AI уже успел изменить нашу работу в DevOps и SRE?

Мы всё чаще отдаём нейросетям написание конфигов, разбор логов, генерацию Terraform и даже диагностику инцидентов. Но вот дать AI доступ к проду и разрешить ему самостоятельно что-то чинить – тут, думаю, многие уже задумаются 😁

Ребята из DevCrowd запустили исследование про SRE, DevOps и платформенных инженеров. Лично мне любопытно посмотреть на результаты по AI и дежурствам. И больше всего: действительно ли AI снижает нагрузку на инженеров или просто позволяет навешивать на них ещё больше задач 😁

В этом году там довольно разнообразные темы:
• Насколько мы вообще доверяем AI и готовы ли пускать его в прод?
• Стало ли больше инцидентов из-за сгенерированного кода?
• Какие навыки инженера AI пока не способен заменить?
• Сколько на самом деле стоят дежурства, переработки и постоянная ответственность за прод?
• Как меняются зарплаты, обязанности и требования к инженерам?

Опрос анонимный, занимает 10-12 минут. Результаты будут в начале декабря.

➡️ https://survey.devcrowd.ru/sre-2026

Ну и вопрос к вам: вы бы уже доверили AI самостоятельно устранять инциденты в проде или рано? 🤩

—
Telegram | Github | YouTube | X

🔖 Expr для Go: динамические правила вместо цепочек if

Сегодня я хочу немного отойти от типичных тем канала и поговорить о разработке на Go, а именно о пакете Expr и задачах, которые она решает.

Вы уже наверняка написали какое-то количество сервисов или программ, дополняющих вашу инфраструктуру на GoLang.

Почти у каждого такого сервиса есть конфигурация по типу такой:

min_replicas: 3
max_error_rate: 0.05

Ну и классическая обработка выглядит примерно так:

if readyReplicas >= cfg.MinReplicas && errorRate < cfg.MaxErrorRate {
 // продолжаем операцию
}

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

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

Но что если я вам скажу, что вместо цепочки if и вложенных условий можно хранить в конфигурации само правило. Expr скомпилирует его при загрузке или обновлении конфигурации, а затем приложение будет выполнять готовую программу с актуальными входными данными (вспоминаем alertmanager):

rule: >-
  environment != "production" ||
  maintenanceMode ||
  (readyReplicas >= 3 && errorRate < 0.05)

При компиляции Expr проверит правило по Go-типам, а готовую программу затем можно многократно запускать с разными входными данными.

Давайте опишем структуру, которая одновременно будет служить входными данными и контрактом.

type ServiceState struct {
 Environment     string  `expr:"environment"`
 MaintenanceMode bool    `expr:"maintenanceMode"`
 ReadyReplicas   int     `expr:"readyReplicas"`
 ErrorRate       float64 `expr:"errorRate"`
}

Теперь загрузим строку из конфигурации и скомпилируем её:

program, err := expr.Compile(
 config.Rule,
 expr.Env(ServiceState{}),
 expr.AsBool(),
)
if err != nil {
 return fmt.Errorf("compile rule: %w", err)
}

После этого программу можно выполнить с реальными значениями:

state := ServiceState{
 Environment:     "production",
 MaintenanceMode: false,
 ReadyReplicas:   3,
 ErrorRate:       0.02,
}

result, err := expr.Run(program, state)
if err != nil {
 return err
}

allowed := result.(bool) // true

Приложение ничего не знает о внутреннем устройстве условия. В конфигурации можно изменить порог, добавить исключение или полностью заменить правило – код вокруг expr.Run останется прежним.

Внутри expr.Compile строка сначала превращается в abstract syntax tree. Затем checker связывает имена с полями ServiceState, optimizer упрощает дерево, а compiler создаёт инструкции для stack-based virtual machine. При expr.Run VM выполняет эти инструкции с переданными значениями.

Главный практический выигрыш Expr довольно простой: меняется правило – обновляется конфигурация; меняется набор доступных данных или поведение самого приложения – тогда уже пересобирается Go-код. Эта граница позволяет убрать растущие цепочки if, не превращая конфигурацию в полноценный язык сценариев.

Такое устройство и позволяет крутить правила динамически: дорогостоящую подготовку мы выполняем один раз на reload, а не для каждого запроса.

PS Playground и самая полная документация тут: https://expr-lang.org/

—
Telegram | Github | YouTube | X