Я пропустила знаменательный момент для любого канала и блога!

🎉🎉🎉🎉🎉🎉🎉
1️⃣0️⃣0️⃣
🎉🎉🎉🎉🎉🎉🎉

Рубеж в 100 подписчиков пройден! Цифра небольшая по меркам интернета. Но в системном дизайне мы знаем: важен не абсолютный масштаб, а архитектура и качество связей.
Мой канал - не про хайп. Он про вдумчивый разговор о системах.

Спасибо вам за интерес к сложным темам!
Дальше - больше глубины, больше практики. Работаем :)

Недавно большой интерес у коллег SRE вызвала DLQ. Разберем немного подробнее термины, которые упоминались ранее, и посмотрим на DLQ под другим углом.

🔻Механизм изоляции «ядовитых» сообщений

Ядовитым называют то сообщение, которое даже при многократных попытках обработки не может принести пользу Консьюмеру. Например, отсутствие обязательного поля ведет к тому, что будет падать при каждом ретрае и может блокировать очередь.
Лаг растет. Система деградирует. Занавес...

Под механизмом понимается логика: если N попыток обработки стали неуспешными - в DLQ. Проблема локализуется, система не стопорится.

🔻 Инструмент обнаружения регрессий и проблем интеграции

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

И если DLQ разрослась и ошибки однотипные, то DLQ становится первым сигналом нарушения контракта. Поэтому вешайте на DQL анализ типов ошибок и алерт на рост.

DLQ показывает не только технические ошибки.
Он показывает семантические конфликты между командами.

🧲 Как DLQ помогает улучшать схемы?

1. Поможет выявить неоднозначные поля (например, где нет четкого enum-списка или версий)

2. Выявит обязательные поля

3. Ошибки совместимости и версионирования

4. (на мой взгляд самый главный пункт) Дает повод проанализировать и улучшить retry-стратегию

Немного отойду от технической основы и поделюсь с вами своим наблюдением.

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

Вот какой самый главный инсайт я вынесла из ее выступления:
Иногда важно… поскучать.

С моей многоуровневой многозадачностью это утверждение мне очень откликнулось.
Я думаю, все собравшиеся здесь айтишники живут в режиме постоянной загрузки: рабочие задачи, уведомления, встречи по работе и личные, подкасты на фоне, развитие и статьи «впрок».
"Быть занятым" стало синонимом "быть продуктивным".

Но у сознания есть предел пропускной способности. Только в отличие от ИТ-систем здесь нет DLQ или алертов. Наша голова не уходит в отказ.
Просто внимание рассеивается, и мышление перестаёт быть глубоким. Оно становится реактивным.
Мы не думаем. Мы отвечаем.

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

Именно в моменты «ничего не происходит» мозг начинает перерабатывать накопленное. Парадоксально, но без периодов пустоты не появляется глубина.

Постоянная занятость создаёт иллюзию движения.
Скука создаёт пространство для смысла.

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

Иногда лучший способ двигаться вперёд — на время остановиться...
Не забывайте об этом 🧡

Поставьте реакцию, если вам откликнулось

Следующее решение проблемы consumer'ов

✳️Интеллектуальный Retry с экспоненциальной задержкой
Со словом ретрай все понятно - повторы запросов.
А вот с экспоненциальностью разберемся. Действуем от обратного. Простой ретрай с фиксированным повтором (каждые N секунд):
⚛️ Не дает системе восстановиться
⚛️ Создает искусственную нагрузку
⚛️ Не учитывает природу ошибки

Лучше использовать увеличиваемая задержка + случайная добавка
⏺️ Категоризация ошибок: временные vs постоянные. Если временные (моргает сеть), то увеличиваем время ожидания между попытками. Если ошибка постоянная, то сразу отправляем в очередь dead

⏺️ Экспоненциальная задержка: 1s → 2s → 4s → 8s → 16s. позволяет не делать лавину запросов сразу после того,как сервис заработал.

⏺️ Случайная добавка: предотвращает синхронизацию множества consumer'ов, которые сразу набросятся со своими сообщениями, как только сервис восстановится. С добавкой поступление сообщение будет чутьболее равномерным.

⏺️ Максимальный лимит попыток: обычно 3-8 в зависимости от бизнес-логики

Следующее решение проблемы consumer'ов
Circuit Breaker (автоматический предохранитель)

Паттерн предотвращает бессмысленные вызовы сломанного сервиса, что спасает от каскадных сбоев. Если один сервис зависает или выдает ошибки, Circuit Breaker (действующий как прокси) перестает отправлять к нему запросы, предотвращая перегрузку всей системы.

Три состояния Circuit Breaker:

❎ Закрыт: Запросы проходят нормально. Если количество ошибок превышает порог, переключается в Open.
⭕️ Открыто: Запросы мгновенно отклоняются с ошибкой (fallback), не доходя до сервиса. Запускается таймер «окна сна».
🆚 Полуоткрыто: По истечении таймера позволяет пройти небольшому количеству тестовых запросов. Если они успешны, переключается в Closed. Если нет — возвращается в Open.

Решение конкретных проблем

🔰 «Зависшие» сообщения

Симптомы:
Сообщение находится в состоянии обработки длительное время, consumer блокируется, остальные сообщения не принимаются к обработке.

Решения:

⚜️Timeout на уровне обработки
Установить таймауты на обработку сообщений. Если обработка длится дольше заданного лимита, прервать её выполнение и вернуть сообщение обратно в очередь с указанием причины отказа.


⚜️Сердцебиение
Периодически отправлять сигналы активности. Если потребитель долго не отправляет сигнал, считать его неактивным и освободить ресурсы.


🔰 Бесконечные retry

Симптомы:
Сообщение постоянно повторяется снова и снова, счётчик попыток растёт, однако прогресса в выполнении операции нет.

Решения

🔸Умный счетчик попыток
Реализовать экспоненциальную стратегию задержки между попытками (backoff). Например, удвоение интервала ожидания перед следующей попыткой. Ограничить максимальное число повторений.


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


🔰 Забитые очереди

Симптомы
Длина очереди быстро возрастает, латентность запросов значительно увеличивается, поступающие сообщения начинают задерживаться или вовсе теряться.

Решения

🔹 Мониторинг
Постоянно мониторить длину очередей и уровень загрузки потребителей. Использовать инструменты мониторинга вроде Prometheus, Grafana или New Relic.


🔹 Автоматическое масштабирование
Автоматизировать процесс добавления новых экземпляров consumers при увеличении нагрузки и удаления их при снижении трафика.


🔹Приоритизация
Ввести приоритетную обработку критичных сообщений. Создавать отдельные очереди для высокоприоритетных сообщений, обеспечивая своевременную доставку наиболее важных данных.

Хочешь прокачать системный анализ и архитектуру не на словах, а на практике? 🚀

Analyst Marathon #17 состоится уже 18 апреля!
Ребята собрали действительно полезный hard skills контент без “общих рассуждений” (впрочем, они всегда делают полезный контент):
🎾 как правильно делать записи архитектурных решений (ADR), чтобы ими реально пользовались
🎾 как создавать AI-ассистента и встроить его в процессы
🎾 как стандартизировать API, чтобы команды не страдали
🎾 и ещё много практики, которую можно применять сразу

Если вам важно не просто “знать”, а делать системы лучше, то вам точно сюда.

🎁 🎁 🎁 🎁
А для тех, кто дочитал до этого момента, ждет приятный сюрприз, и даже не один!

🎀 В эту пятницу 10 апреля в 13.30 я буду проводить розыгрыш бесплатного билета на Analyst Marathon #17

🎀 Организаторы конференции любят мой уютный канал, поэтому согласились в качестве бонуса на 4 дня (до 11 апреля 2026) открыть доступ к моему докладу с Analyst Marathon #16: «Практика гибридных архитектур: руководство для аналитика» Это идеальный «разогрев» перед конфой. Торопитесь его посмотреть: он припрятан в описании программы конференции.
Внутри:
🔹 Конец архитектурным холиварам: конкретная схема для выбора распределенных систем и реальный кейс, чтобы аргументированно защищать свои решения.
🔹 Чек-лист для старта: список вопросов, которые помогут принять верное решение для критических компонентов системы.
🔹 Умная декомпозиция: освоите принцип деления системы по скорости изменений и бизнес-рискам — лучший способ найти узкие места.
🔹 Инструкция к действию: пошаговый список шагов для создания устойчивой и гибкой архитектуры.


🎀 Конечно, для подписчиков всегда есть промокод на скидку 20%
🎁🎁 DB20_AM17 🎁🎁

Программа и покупка билетов здесь

Ну что, уже посмотрели мой доклад? Вдохновились перед конфой? Тогда переходим к главному: к розыгрышу билета.
🎈 Кто первым ответит на два вопроса - отдам билет
(отвечаем в комментариях к этому посту)

❓Вопросы

1. Если “ничего не сломалось” при дубле - это благодаря чему?
2. К чему может привести коммит offset'а до записи в БД?

Жду ваши ответы в комментарии!

А для тех, кто не успел, всегда есть промокод на скидку 20% 🎁 DB20_AM17 🎁
Программа и покупка билетов здесь

Хочу начать следующую тему, которая давно меня интересует.
🏮 Что такое "девятки" в надежности и почему о них все говорят 🏮

"У нас четыре девятки доступности"
"Мы стремимся к пяти девяткам"
Эти фразы звучат почти в каждом разговоре про инфраструктуру и надежность. Но за ними часто скрывается путаница: кто-то воспринимает это как маркетинговый штамп, кто-то - как строгую инженерную метрику. Я решила погрузиться в тему глубже и разобраться в "магии девяток" и почему вокруг них столько внимания.

Доступность - это процент времени, в течение которого система работает и доступна пользователям.
Как измерить
availability = uptime / (uptime + downtime)
"Девятки" — это просто способ записать доступность:
99% → "две девятки"
99.9% → "три девятки"
99.99% → "четыре девятки"
99.999% → "пять девяток"
Звучит почти одинаково. Но разница - слишком большая.

Переведём это в реальное время простоя за год:
99% → ~3.6 дня
99.9% → ~8.7 часов
99.99% → ~52 минуты
99.999% → ~5 минут

Разница между 99.9% и 99.999% — это не "чуть лучше". Это переход от часов простоя к минутам в год.

🕶 Почему бизнес так любит «девятки»
Потому что простой стоит денег. Чем критичнее продукт, тем дороже каждая минута недоступности:
- онлайн-магазин теряет выручку
- платежная система — транзакции
- B2B-сервис — доверие клиентов и контракты

Поэтому появляются SLA (Service Level Agreement) — обещания доступности:
"99.9% uptime гарантирован"
"99.99% или компенсация"

Девятки становятся языком общения с клиентами и инструментом продаж.
Бизнес видит высокие цифры и чувствует себя спокойнее: Высокая доступность = меньше рисков = конкурентное преимущество.

Канал есть в MAX

♻️ Не вся "доступность" одинакова ♻️
Казалось бы ситуация бинарна: система упала - downtime, работает - uptime. Какие еще есть варианты?

Оказывается, оттенки есть и здесь. Можно считать:
- по времени (сервис не отвечает)
- по ошибкам (часть запросов падает)
- по пользователям (у кого-то работает, у кого-то нет)

Получается, 2 сервиса с 99.9% могут ощущаться совершенно по-разному.


♨️ Частичные сбои часто игнорируются
Система может работать медленно, отдавать ошибки 10% пользователей, ломать отдельные функции
Формально - аптайм есть.
Фактически - пользователь страдает.


⛓️‍💥 Окна обслуживания выпадают из статистики
Иногда плановые downtime не учитывается в SLA и выносится в технические окна
И тогда 99.99% на бумаге не равняются 99.99% в жизни.

🥎 "Пять девяток" — это редко про весь продукт
Часто это про конкретный компонент, отдельный API и вообще про идеальные условия существования сервиса (читай, никогда). Весь пользовательский путь end-to-end обычное не включается в "пять девяток".


Обычно инженеры относятся к "девяткам" осторожно, потому что за каждой дополнительной "девяткой" стоит:
- кратный рост сложности
- рост стоимости инфраструктуры
- рост требований к процессам

Главное, что стоит запомнить, что без контекста девятки превращаются в маркетинг
Хороший вопрос вместо "сколько у нас девяток":
Сколько времени наши пользователи реально не могут пользоваться продуктом, и насколько это критично для бизнеса?
Ответ на него почти всегда важнее любой красивой цифры.

Канал есть в MAX

🕰 Про виды downtime'ов и как с ними жить или почувствуй себя немного SRE

Downtime бывает плановый (релизы) и аварийный.

🧧В понятие доступности нужно включать плановый downtime или нет?
Нужно. Ведь пользователю, который не может достучаться до сервиса неважна причина недоступности: инцидент или релиз.

🧧 Когда допустимо исключать плановый downtime из рассчитанной доступности?
Если предусмотрены строгие SLA-окна и система не обязана работать в указанное время (например, ночные окна обслуживания)

🧧 Где начинается манипуляция?
Там, где аварию можно прикрыть плановым downtime или вообще не считать событие downtime'ом. Т.е. когда релизы влекут за собой деградацию функционала, а оформляется как плановый. Или когда задержки выросли, но downtime не зафиксирован.

💌 Как решать?
1. Сделать 2 метрики: Общая доступность (с учетом всего) Операционная доступность (без плановой)
2. Учитывать деградации отдельно
3. 3. Сделать метрику с влиянием на пользователей

Канал есть в MAX

🧾 Как считать инциденты: время, пользователи или транзакции?

⏰ По времени
сервис был недоступен 30 минут → downtime = 30 минут
Нюансы:
- игнорируется масштаб 
- не учитывается частичная деградация

Пример: 1% запросов падает 24 часа → downtime по времени ≈ 0


🙍‍♂️По пользователям
Формула: доля пользователей, столкнувшихся с ошибками

Плюсы:
- ближе к реальному UX 
- учитывает частичные проблемы

Минусы:
- сложно считать 
- не учитывает интенсивность использования

⛓️ По транзакциям
Формула: Отношение успешных запросов ко всем запросам

Плюсы:
- точная 
- хорошо автоматизируется 
- чувствительна к деградациям

Минусы:
- не различает важность операций 
- может скрывать критические сбои
Главная ловушка: игнорирование частичной деградации


❓И как действовать?
Не можешь выбрать - бери всего по чуть-чуть:

🔑 Доступность (по времени) 
🔑 Показатель успешности (по транзакциям) 
🔑 Влияние (по пользователям)
И отдельно:
🗝 деградации (задержки, частичные сбои)

Главное❗️
не считать доступность "в вакууме", а привязывать её к реальному влиянию на пользователей и бизнес.

Коллеги SRE, что скажете?

Канал есть в MAX

Между праздниками не буду мучить длинными постами, поэтому кратко рассмотрим.

Зачем вообще это всё?
Когда команда говорит "сервис работает нормально", это бессмысленно без измерений. SRE-подход вводит три уровня:

✳️ SLI (Service Level Indicator)
Это метрика качества. Это то, что мы измеряем:
- процент успешных запросов 
- latency (p95, p99) 
- uptime

✳️ SLO (Service Level Objective)
Это цель по метрике. Это то, насколько хорошо должно быть то, что мы измерили:
+ 99.9% успешных запросов за 30 дней 
+ p95 latency < 200ms

✳️ SLA (Service Level Agreement)
Это договор с пользователем о последствиях. Это то, что будет, если мы облажались
если доступность < 99.5% → компенсация

❇️ Error Budget
сколько ошибок допускаем
Например, на 1 млн запросов в месяц допускаем 0.1% = 1000 ошибок

❌ Не делайте SLO = 100%
✅ Связывайте SLO с бизнесом

Канал есть в MAX

Вышла 3я и последняя часть цикла статей про мифы REST

🧮 Как считать доступность в микросервисах

На первый взгляд: берём uptime каждого сервиса и радуемся:
- Service A: 99.9% 
- Service B: 99.9%
"Значит система тоже 99.9%" - скажем мы.
А вот и нет. В композиции сервисов действует другая математика.

🔗 Последовательная цепочка
Если запрос проходит через 3 сервиса (последовательная цепочка Client → API → Auth → DB), у каждого из которых 99.9%, то:

0.999 × 0.999 × 0.999 = 0.997 ≈ 99.7%

Цифра получилась меньше.
Формула для последовательной цепочки:

Availability_total = Π Availability(i)

⛓️ Параллельные запросы
Если запрос обрабатывается параллельными независимыми вызовами сервисов А и В (каждый по 99%), то:

1 - (1 - A)(1 - B) = 99.99%

Общая надежность получилась выше.

Канал есть в MAX

Почему "пять девяток" почти невозможны без деградации UX

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

🎖 Иллюзия непрерывной доступности
Любая распределённая система подвержена сбоям: сетевые задержки, частичные отказы, деградация зависимых сервисов. Стремление к "пяти девяткам" означает, что система должна продолжать отвечать почти всегда, даже если часть компонентов не работает. Но отвечать - не значит работать идеально.
Именно здесь возникает ключевой конфликт: либо пользователь получает быстрый, но неполный или устаревший результат, либо он ждёт (или получает ошибку), пока система восстановит целостность данных и всех зависимостей.

🎖 Контролируемое ухудшение
Один из главных инструментов достижения высокой доступности - мягкая деградация. Система продолжает функционировать, но с урезанным функционалом.
Примеры:
▪️ отключение рекомендаций при недоступности ML-сервиса;
▪️ показ кэшированных данных вместо актуальных;
▪️ упрощённый интерфейс без тяжёлых компонентов.

С точки зрения SLA это победа: сервис доступен.
С точки зрения UX - компромисс: пользователь получает "второсортный" опыт там, где точность данных явно не влияет на финансовые и репутационные потери бизнеса.
Важно, что деградация должна быть предсказуемой и управляемой, иначе она превращается в хаос.

🎖 Запасные пути
Заранее подготовленные сценарии на случай сбоя.
▪️ переход на кэш
▪️ использование реплик или вторичных источников данных
▪️ возврат значений по умолчанию
▪️ очереди и отложенная обработка

Проблема таких сценариев в том, что:
▪️ снижается точность
▪️ устаревшие данные

Например, пользователь видит неполный список заказов. Сервис работает, но доверие к нему может снижаться. Это недопустимо, потому что пользователь начнет делать повторный заказ, а это влечет двойныезаказы и звонки в поддержку. Будет значительно проще показать ошибку вместо неполного заказа и сообщение попробовать заглянуть сюда позднее. Этот функционал критичен, и полумеры здесь не спасут, лучше выбрать полную деградацию. А вот если у каталога отвалился фильтр - это уже не так критично и врят ли потом придется отменять двойные заказы после восстановления, и здесь значения по умолчанию или кеш вполне рабочие варианты.

Канал есть в MAX

🔝 Eventual consistency (моя любимая) и доступность

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

Это напрямую влияет на UX:
🔻 пользователь может не увидеть только что созданный объект;
🔻 разные экраны показывают разные версии данных;
🔻 возможны «скачки» состояния.

В high-load системах только так и выживают, но для пользователя - это источник когнитивного диссонанса.


🔃 Так что же выбрать: точность или доступность?
В основе всей проблемы лежит фундаментальный выбор:
🔸При доступности выигрываем uptime, но проигрываем точность данных
ИЛИ
🔸При согласованности выигрываем точность данных, но проигрываем время отклика.

На практике это проявляется так:
быстрый ответ → возможна неточность
точный ответ → выше риск таймаута или ошибки


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


Поэтому надежность мы рассматриваем под иным углом: про непрерывность взаимодействия любой ценой.


🟪 Как формализовать деградацию?
Всего 3 вопроса для фиксации в требованиях:
1. какие функции отключаются
2. какие данные упрощаются
3. как это отображается в UI
И ваша деградация становится управляемой.

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

Канал есть в MAX

Друзья, привет! Уже на этой неделе встречаемся на Analyst Days в Петербурге.

От меня традиционно немного хардкора 🙂
В прошлый раз разбирали CAP, а в этот раз поговорим про PACELC и то, как этот подход помогает принимать более взвешенные архитектурные решения.

На докладе разберём:

- как структурированный анализ ограничений PACELC в штатных сценариях влияет на требования к согласованности данных;
- как это отражается на выборе архитектурных паттернов и технологических ограничений;
- как заранее оценивать последствия архитектурных решений для бизнеса и сильнее аргументировать проектные компромиссы.

Буду рада увидеться и обсудить всё это вживую!

22 мая, в 10.00
Секция В