Друзья, привет! Уже на этой неделе встречаемся на 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 не тормозил.

Друзья!
🏆🏆🏆🏆🏆🏆
В четверг в 16.00 начнём розыгрыш билета. (Чтобы сделать вам приятное перед праздниками 😊)

Розыгрыш, как обычно, будет заключаться в правильном ответе на 2 вопроса.
Первый правильно ответивший получает онлайн-билет на конференцию!

Ставьте напоминания и будьте готовы!

Я не буду впаривать вам идеальную архитектуру

Посмотрите это видео от Дарьи Борисовой из ПСБ и узнайте, какую задачу решала ее команда, какие важные вопросы стояли перед ними, и что вы сможете вынести из ее доклада на Saint HighLoad++ 2026 ✅

🏅🏅🏅🏅🏅
🎯🎯🎯🎯🎯🎯🎯
Приступаем к розыгрышу онлайн-билета на конференцию HighLoad в Санкт-Петербурге 22-23 июня.

Победителем будет тот, чей комментарий под этим постом с правильными ответами на оба вопроса будет первым.

1. Вы проектируете отказоустойчивый кластер на 5 нод. Принятие решений требует согласия большинства. Как называется это большинство?

2. Какой паттерн помогает обрабатывать всплески нагрузки, временно возвращая ошибку вместо падения сервиса?

Как давать ссылки на файлы
(и чтобы никто не украл)


🗳 Публичные файлы (аватарка, превью новости)
Любой может посмотреть. Просто ссылка:
https://cdn.myapp.com/assets/12345/avatar.jpg


🗳 Приватные файлы (паспорт, налоговая, личный документ)
Только владелец или кто с правом.


💔 Как не надо делать
Запрос к API: GET /api/get-file?id=123, сервер читает файл с диска и отдает байты.

Почему плохо: Сервер тратит CPU и память, передавая гигабайты файлов. При 1000 пользователей сервер ляжет.

💚 Как надо делать
Предподписанные ссылки (Pre-signed URLs) - это ссылка, которая:
🔸Работает ограниченное время (например, 1 час)
🔸Содержит подпись (шифр), что файл можно забрать

Как работает:
1. Фронтенд просит бэкенд: "Дай ссылку на файл 123"
2. Бэкенд проверяет права пользователя
3. Бэкенд генерирует специальную ссылку на S3 вида:
https://s3.amazonaws.com/bucket/123?signature=abc...&expires=3600
4. Бэкенд отдает ссылку фронтенду
5. Фронтенд идет напрямую в S3 по этой ссылке


Итог:
Сервер не передает файл, а только дает одноразовую ссылку.

⚡️⚡️⚡️🔥🔥🔥
Розыгрыш для очных участников конференции HighLoad.

Чтобы получить мерч от ПСБ, нужно правильно ответить первым на 2 вопроса.

Вопрос 1

Какого вида согласованности не существует в классификации PACELC?

A. Strict consistency
B. Eventual consistency
C. Optimistic consistency
D. Strong consistency


Вопрос 2

Как меняется поведение системы при проверке лимитов во время деградации, согласно PACELC-профилю операции из доклада?

A. Система перестаёт проверять лимиты вообще
B. Система переключается на строгую согласованность
C. Система перестаёт доверять «быстрым» данным из кеша и возвращается к «медленным, но точным»
D. Система начинает проверять лимиты асинхронно после списания денег


Победителя буду ждать у входа в "Башню" после доклада до 13.15

Давно не виделись!
Думали, я забросила? Нет, конечно!

Завершен мой сезон конференций "весна-лето 2026" (да-да, как у коллекций дизайнеров).
В этом сезоне у меня был фокус и на других задачах, поэтому в арсенале всего 2 конференции, зато какие.

Особый шарм конференциям добавил сезон белых ночей Петербурга, пропустить которые было бы преступлением! Поэтому день я проводила на конфе, а ночами любовалась разведением мостов. Выспаться я мечтала дома, но это снова не удалось, потому что в Москве тоже много всего интересного.

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

Не обошлось и без ИИ. В наши дни конфы без них не проходят.Иногда мне кажется, что про него говорят только для хайпа. Но много полезных вещей при этом рассказали.

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

Главный итог: Analyst Days 2026 оставил приятное впечатление. Организаторам — респект, а аналитическому сообществу — пожелание не бояться сложных тем и задавать неудобные вопросы. Именно так мы и растем профессионально.

А вы были на этой конференции? Что запомнилось больше всего? Делитесь в комментариях 👇

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

Что я вынесла из кулуаров?
Превалирование докладов в ИИ-тематику понравился не всем. Люди по-прежнему ждут инженерных решений, но не в формате «как проектировать ракетные двигатели» (из которого в свой проект ничего не утащишь), а чего-то более универсального и прикладного.
Впрочем, звучало и встречное мнение: перекос кажется нам перекосом только потому, что мы пока не доросли до истинной трансформации сознания для качественного использования ИИ. И с этим мне тоже трудно не согласиться. Время покажет.

Что я вынесла из официальной программы?
Очень зашел формат круглых столов и живых рассуждений о процессах. Говорили о процессах на уровне принятия решений руководства, о том, где экономия бюджета стала реальностью, а где её не случилось. Делились опытом внедрения ИИ в разных бигтехах и всей правдой о том, что ожидания часто не оправдались. Было честно, местами больно, но очень полезно.

Что я вынесла из нетворкинга и общения с аудиторией?
Как я и ожидала, аудитория здесь сильно отличается от моих профильных конференций. Мой доклад слушали с хирургической точностью — люди разобрали его буквально по косточкам. И я увидела, что попала в самое сердечко большинства. Не на всё смогла ответить (некоторые вопросы просто не в моем профиле), но это лишь подстегнуло меня залезать еще глубже в смежные области. Ведь именно благодаря этому неуемному интересу к разным техническим деталям я когда-то и зашла на территорию спикерской деятельности. И это ощущение, когда к тебе приходят с конкретными, сложными вопросами — бесценно.

Главный итог: HighLoad++ 2026 — это конференция-маркер. Она показывает, что мы находимся в точке бифуркации. Все понимают: по-старому работать больше не получится. Но как именно будет выглядеть "новое нормальное" — никто не знает. И это тот самый момент, когда аналитики, инженеры и лидеры должны не просто слушать тренды, а сами формировать будущее.