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

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

Симптомы:
Сообщение находится в состоянии обработки длительное время, 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
Секция В

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

📃 Что такое файловый asset?

Аналогия из жизни
Если представить, что система — это офис, то файловый asset - это любая бумажка или предмет, который может понадобиться разным сотрудникам: договор с клиентом, фото товара и тд

📇 Asset (актив) - это не просто файл. Это "файл + паспорт к нему"
В БД мы храним:
- id пользователя, загрузившего файл
- Дата загрузки
- Размер файла
- Права доступа к файлу
- Адрес в хранилище

Но сам файл лежит отдельно!

🔖 Почему это важно?

Новички часто делают так:
кладут файл в папку на сервере и пишут в базе путь C:\files\dog.jpg. А потом сервер ломается, папку переносят, и ссылки в базе становятся невалидными.
Правильно: в базе хранить ID файла (например, ast-123-456), а где он лежит - это решает специальный сервис.

Увидимся на HighLoad в Питере!

Кто хочет получить от меня бесплатный онлайн-билет на конфу?
Скоро буду разыгрывать. Позже выдам подробности.

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

В этом посте — три доклада из программы Saint HighLoad++ 2026 с разбором подходов, которые помогли справиться с такими задачами.

1️⃣ FinOps: Anomaly Management как версия управления инцидентами. Максим Бурцев (Купер.тех).

В рамках развития практик FinOps в Купере столкнулись с необходимостью управления «финансовыми аномалиями» – отклонениями в расходах на облачные ресурсы. Решение оказалось интересным и элегантным: вместо того, чтобы изобретать процесс с нуля, они переиспользовали «кубики» из зрелых и уже показавших свою эффективность процессов управления инцидентами и проблемами. Максим расскажет о том, как это работает, почему это проще, чем кажется на берегу и как это поможет вам перестать переплачивать за облака и сервера, используя уже имеющийся стек технологий и процессов.

2️⃣ Как жить без строгой консистентности и не терять деньги. Дарья Борисова (ПСБ).

Фундаментальный доклад, из которого вы узнаете (или вспомните) что такое CAP и PACELC, зачем нужна Saga и 2PC. А также на реальных примерах убедитесь, что идемпотентность, дедупликация и reconciliation — обязательные механизмы выживания систем.

3️⃣ Как колоночное хранилище может помочь legacy? Михаил Шишкин (ООО Газинформсервис).

В старых нагруженных корпоративных проектах часто можно встретить активное использование временных таблиц в СУБД. Нередко подобные решения оказываются очень чувствительными к росту объема поступающих в систему данных. Чтобы оживить один из таких проектов без его модернизации в ООО Газинформсервис воспользовались одним из ключевых преимуществ колоночных хранилищ и применили его к этому «проблемному» паттерну.

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

До встречи на Saint HighLoad++ 2026 🖐️

Типы хранилищ для файлов
для тех, кто как и я не ночевал в администрировании, но кто хочет знать разницу.

🔹 Тип 1. Файловое хранилище (NAS, NFS, HDFS)
Как работает: Как обычная папка на компьютере, только расшаренная по сети. Есть иерархия: папки → подпапки → файлы.
Пример из жизни: Общая сетевая папка в офисе, куда все скидывают отчеты.
Проблема: Если два человека одновременно редактируют один файл, система ставит lock (блокирует для остальных). При миллионах пользователей это приводит к тормозам.
Когда можно использовать: Во внутренних системах компании с 50 сотрудниками. Не для интернет-магазина.


🔹 Тип 2. Блочное хранилище (EBS, SAN)
Как работает: Представь флешку. Сервер видит её как обычный диск (диск D: или /dev/sda). Форматируешь, создаешь файлы.
Проблема: Этот диск можно «прицепить» только к одному серверу. Другой сервер уже не сможет читать файлы с этого диска одновременно.
Пример: База данных хранит файлы на своем локальном диске.
Когда использовать: Для временных файлов, кеша, логов на одном сервере. Не для общего доступа.


🔹 Тип 3. Объектное хранилище (S3, MinIO)
Как работает: Нет папок, есть объекты. У каждого объекта есть:
-Уникальный ключ (например, user123/avatar/2024/photo.jpg)
-Тело (сами байты файла)
-Метаданные (как паспорт)
Главное отличие: Вы не ходите по папкам. Вы просто говорите: "Дай объект с ключом X".
Почему это стандарт для веба:
Бесконечное масштабирование. Можно хранить миллиарды файлов, в отличие от папок.
HTTP-доступ. файл можно отдать как ссылку https://...
Неизменяемость или версионирование. Вы не меняете файл по тому же адресу, а создаете новую версию.

 Это как огромный склад с ячейками. У каждой ячейки есть номер. Вы не создаете папки, а просто говорите: "Положи в ячейку 123-456". И потом: "Дай содержимое ячейки 123-456".

🙌 Что такое S3?
S3 (Simple Storage Service) - это сервис от Amazon. Самое популярное объектное хранилище в мире.
Большинство других хранилищ (MinIO, Yandex Object Storage, VK Cloud S3) совместимы с S3. Это значит, что код, написанный для Amazon S3, будет работать и у них.

Как выбрать хранилище под задачу?

1. Аватарки, фото товаров, документы пользователей в веб-сервисе -> Объектное (S3/MinIO)

2. Локальный кеш на сервере -> Блочное

3. Внутренний файлопомойка для 10 сотрудников -> Файловое

Как называть файлы в объектном хранилище
(чтоб не было больно)

Допустим, выбрали S3. Теперь вопрос: как придумывать ключи (имена объектов)?

❌ Что нельзя делать
Плохо: Ключ = оригинальное имя файла document.pdf
Пользователь может назвать файл ../../../config.json - жди взлома системы.
Два пользователя загрузят report.pdf — файл перезапишется, данные будут утеряны.

Плохо: Все файлы складывать в одну папку assets/ и туда все подряд.
S3 тормозит, если в одном префиксе больше 100 000 объектов (на самом деле не строго, но для понимания - да).


✅ Что можно делать

📔 Хороший паттерн для старта:

assets/{user_id}/{category}/{uuid}.{ext}

Пример: assets/12345/avatar/a1b2c3d4-5678.jpg
Почему так:
user_id - быстро найти все файлы пользователя
uuid - уникальный идентификатор, никогда не повторяется
Папки на самом деле в S3 виртуальные, но для человека удобно


📔 Продвинутый паттерн (для больших объемов):

{md5_hash[:3]}/{uuid}.{ext}

Пример: a1b/123e4567-e89b-12d3.jpg
Первые 3 символа хэша нужны, чтобы равномерно размазать файлы и S3 не тормозил.