Обновить
128K+

Высоконагруженные системы *

Методы получения высокой производительности систем

190,21
Рейтинг
Сначала показывать
Порог рейтинга

Память VDS. Что стоит за строкой «8 ГБ» в тарифе
Число в тарифе отвечает на один вопрос: сколько памяти увидит гостевая система. Зарезервирован ли объем физически, может ли гипервизор забрать страницы обратно и что будет при пике соседей, оттуда не следует.

Три слова, которые каждый понимает по своему. Dedicated обычно означает объем, постоянно доступный машине по условиям тарифа. Слово «постоянно» стоит уточнить: резервируется ли память на хосте и может ли ballooning ее уменьшить. В burstable часть доступна всегда, остальное при свободном ресурсе узла. Shared значит, что резервирования нет. Даже при dedicated провайдер может разрешать swap на хосте, поэтому гарантия в договоре важнее названия модели.

Ballooning и overcommit. Ballooning работает через драйвер внутри гостя. По команде хоста он занимает страницы, ядро гостя освобождает кеш или уходит в свой swap, а высвобожденную память гипервизор отдает другим машинам. Пока баллон надут, приложения работают с меньшим объемом, чем в тарифе. Overcommit это когда сумма лимитов больше физической RAM узла. Умеренная переподписка работает годами, пока гости используют часть лимитов. Пример: после резерва под системные процессы на узле осталось 120 ГБ, машинам назначено 180. При суммарном рабочем наборе 80 ГБ никто ничего не заметит. При 140 придется забирать страницы через ballooning или уходить в swap хоста. Overselling это тот же overcommit, но с недостаточным запасом: разница не в технологии, а в коэффициенте.

Что видно изнутри, а что нет. Сразу о границе: коэффициент переподписки из гостевой системы не определяется никак, эти данные есть только у провайдера. Изнутри ловится давление на память и его совпадение с замедлением сервиса.

free -m && grep -E "MemAvailable|SwapFree" /proc/meminfo
vmstat -y 1 10
procs ---swap-- -----io---- ---cpu---
 r  b   si   so    bi    bo  us sy id wa st
 1  2  184  412  1240   980  22  6 61 10  1

Смотреть надо на MemAvailable, а не на free: файловый кеш при нужде освобождается. Ненулевые si и so в нескольких интервалах подряд это обмен сейчас, а не след прошлого пика.

cat /proc/pressure/memory
some avg10=14.82 avg60=9.31 avg300=3.07 total=8123441
full avg10=6.55 avg60=4.02 avg300=1.18 total=3910228

PSI это доля времени, потерянного задачами из за нехватки памяти. Строка some означает, что простаивала хотя бы одна задача, full что вставала вся работа. Четырнадцать процентов в avg10 при выросшем времени ответа это разговор, а не шум.

journalctl -k -g "oom|Killed process"

Если процесс убило ядро гостя, запись будет здесь. Отсутствие записи при остановившейся машине это отдельный сюжет: OOM хоста может завершить процесс самой машины, и в журнале гостя причины не будет.

Признаки, которые стоит собрать вместе. Задержка растет в одни и те же часы при сопоставимой нагрузке. Устойчивые si и so без изменения профиля приложения. PSI растет синхронно с замедлением. Машина останавливается без записи об OOM у себя. Один признак ничего не доказывает, три совпавших уже повод писать в поддержку с временем эпизодов и метриками.

Что спросить до заказа. Какой объем зарезервирован, а не просто виден. Допускается ли ballooning и до какого минимума. Разрешен ли swap на хосте для памяти машин. Для burstable отдельно: гарантированная часть и условия доступа к остальному.

Тип гипервизора говорит об архитектуре, а не о гарантиях: overcommit поддерживают и KVM, и VMware, и Xen. SLA обычно описывает доступность и компенсацию за простой, но не производительность.

Теги:
+4
Комментарии1

Всем привет! Хочу представить вам приложение, которое сможет освободить ресурс тестирования - Checkcraft.

На данном этапе ЗБТ, приложение уже показывает невероятные результаты, экономя человекочасы для аналитиков, разработчиков или тестировщиков, что соответственно разгружает команду и дает расслабить глаза.

! Сейчас покажу результат, который изменит процесс в вашей команде:

Проверка с детальным отчетом за секунду
Проверка с детальным отчетом за секунду

Типичная ситуация с проверкой расчетов но это же можно сделать в Postman с помощью JS или же просто в коде написать автотест. (Не нужно)

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

Присоединиться к ЗБТ можно по инструкциям на официально сайте приложения - https://checkcraft.ru

В следующих постах покажу ВСЕ! функции приложения, это только начало...

Теги:
0
Комментарии0

Эксперт «Диасофт» примет участие в круглом столе IT-World «Почему хорошие системы плохо работают вместе?»

6 августа 2026 года в 16:00 IT-World проведет круглый стол «Почему хорошие системы плохо работают вместе?». В нем примет участие Дмитрий Гаврин, заместитель директора департамента «Цифровые решения» и один из авторов блога компании «Диасофт» (Как 30 лет боли в интеграции привели нас к собственной платформе)

О чем будут говорить спикеры:           

  • Почему интеграции остаются одной из самых болезненных зон корпоративного ИТ-ландшафта?

  • Что чаще ломает взаимодействие систем - слабые API, разные модели данных, отсутствие владельца процесса или спешка внедрения?

  • Как оценивать API-зрелость решения до покупки: документация, версионирование, песочница, ограничения, поддержка изменений?

  • Как меняется ответственность поставщика ИТ-решения, если его продукт становится частью большого корпоративного контура?

  • Что должно происходить с интеграциями при обновлении продукта, смене версии или доработке соседней системы?

  • Почему единые справочники и мастер-данные остаются проблемой даже там, где уже есть MDM, НСИ или корпоративная шина?

  • Где проходит граница между быстрой автоматизацией и архитектурным долгом, который потом мешает масштабировать решение?

  • Какие требования к интеграциям, API, данным и поддержке стоит включать в ТЗ, договор и критерии выбора поставщика?

Приглашаем вас стать слушателями, это бесплатно. Вопрос экспертам можно задать в чате во время мероприятия или заранее при регистрации.

Регистрация по ссылке: https://www.it-world.ru/events/or8fe6s830gwswk4o4ks4c0wcw0goos.html

Теги:
+3
Комментарии0

System Design на собеседовании: как не утонуть в требованиях, нагрузках и архитектуре

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

В новом выпуске AvitoCode Саша Кучук, тимлид в Авито, разбирает весь путь от постановки задачи до финальной защиты решения:

  • как собирать требования и не упустить нефункциональные;

  • как быстро прикинуть нагрузку и не закопаться в расчётах;

  • как выстроить домены и API, перейти от high-level к low-level design;

  • как выбирать технологии под конкретные ограничения;

  • как вести себя на защите решения и на что смотрят интервьюеры при оценке.

Кстати, если тема зашла — Саша также ведёт свой телеграм-канал, где регулярно разбирает похожие кейсы и делится наблюдениями из практики собеседований.

Смотреть:
📺  YouTube
🔵 ВК 
📌 RuTube

Теги:
+25
Комментарии0

Как Купер перенес 100% инфраструктуры в облако, снизил количество инцидентов и сократил время на их устранение

🏭 Что за компания
Купер — онлайн-сервис доставки продуктов, товаров и готовой еды из магазинов и ресторанов. Сервис работает в 360 городах России, ежедневно обрабатывая десятки тысяч запросов в секунду. Ранее Купер уже перенес 40 ТБ аналитических данных в облако и остался доволен результатом, поэтому было принято решение продолжить процесс миграции. 

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

☁️ Что сделали
Команды провайдера и заказчика синхронизировали требования к инфраструктуре и сетевой архитектуре для плавного переезда. Провайдер помог сформировать команду миграции из 12 специалистов, чей онбординг занял две недели. За 10 месяцев Купер и Cloud.ru перенесли 100% ИТ-инфраструктуры в облако, завершив миграцию в конце апреля 2026 года.

Архитектуру разделили на три логически изолированных слоя — внешний периметр (DMZ) с балансировщиком и веб-серверами, демилитаризованную зону для проверки трафика и закрытый контур бэкенда с базами данных и системами обработки заказов. Дополнительно команда провайдера доработала PaaS-сервисы под задачи Купера, внеся более 30 изменений и взяв на себя их дальнейшее сопровождение — обновления, контроль совместимости и проверку работоспособности.

🦾 Что получили в итоге
Число инцидентов, связанных с облачной инфраструктурой, сократилось на 23%, доступность облачных ресурсов выросла, а средняя длительность инцидентов снизилась на 18%. Затраты на устранение технических сбоев уменьшились в 4 раза, а благодаря FinOps-инструментам Cloud.ru Купер получил прозрачный контроль бюджета и автоматические рекомендации по оптимизации расходов. В итоге онлайн-сервис получил масштабируемую платформу, способную стабильно обрабатывать данные любых объемов и выдерживать пиковые нагрузки без сбоев.

Подробнее читайте на сайте. 

Теги:
+3
Комментарии0

Масштабируем ИИ: как эффективно выстроить инфраструктуру в контуре бизнеса

Узнайте, как развернуть ПАК-AI, запустить on-prem агентов и оптимизировать ИТ-бюджет 21 июля на вебинаре К2 НейроТех и Яндекс. 

Спикеры:

▫️ Вячеслав Дегтярев, руководитель по развитию продуктовых решений, К2 НейроТех

▫️ Тарас Юзефович, тимлид по работе с партнерами направления ML&AI, Yandex Cloud

Что в фокусе:

🟢 ИИ-агенты и стратегии 2026: как перевести инициативы из презентаций в работающий продакшн

🟢 Кадровая независимость: способы ускорить запуск проектов, снизив потребность в ML-экспертах

🟢 Борьба с «зоопарком» технологий: как объединить разрозненный стек в единую управляемую систему

🟢 Экономика ПАК–AI: разберем модели поставки и способы оптимизации ИТ-бюджета

🟢 Разберем, как это реализовано на кейсах бьюти-ритейла, а также страховой и финансовой отраслей

21 июля | 11:00–12:30 | Онлайн

Регистрация по ссылке

Теги:
+4
Комментарии0

Почти 10 лет в Авито — это не просто стаж. Это возможность наблюдать, как компания меняется изнутри, и самому влиять на эти изменения.

В этом выпуске «AviTalk» ведущий Виктор Раев, руководитель разработки юнита Services Base, поговорил с Александром Лукьянченко — техническим руководителем кластера Architecture. Саша прошёл путь от разработчика до менеджера высшего звена и видел Авито ещё в 2016-м — когда всё было устроено совсем иначе.

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

Смотреть выпуск:

🔵 VK Видео
📺 YouTube

AviTalk — шоу толковых людей. Гости — сотрудники Авито из разных дирекций и команд, которые делятся своей экспертизой и профессиональным путём.

Теги:
Всего голосов 23: ↑18 и ↓5+15
Комментарии0

Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы

Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML. 

В трёх треках программы обсудим не только ML‑инфраструктуру, но и базы данных, стораджи, инструменты разработки, observability‑решения, SRE и эксплуатацию и управление трафиком. 

Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы: 

  • «Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс) 

  • «ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech) 

  • «Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon) 

  • «Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud) 

  • «ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк) 

  • «Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)

Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.

Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии0

Как запустить игровой маркетплейс на 150 000 пользователей в день и не упасть на пиках: кейс Win Solutions х Cloud.ru

👨‍💻 Что за компания
Win Solutions («Вин Солюшенс») — ИТ-интегратор, который разрабатывает и внедряет решения для компаний в России и СНГ, а также берет на себя эксплуатацию продуктов, когда критичны устойчивость и полный контроль инфраструктуры. Win Solutions сотрудничает с Cloud.ru на проектах, где важны предсказуемость продакшена и стабильная работа под высокой нагрузкой.

🚀 Задача
Крупному клиенту интегратора нужен был маркетплейс цифровых игровых товаров, который:

  • работает без простоев и деградации на пиках (особенно во время маркетинговых активностей);

  • масштабируется по мере роста аудитории;

  • удобен в сопровождении: с мониторингом и понятной эксплуатацией. 

Заказчику Win Solutions было критически важно быстро вывести проект в продакшен и гарантировать возможность масштабирования, поэтому выбор провайдера начался незамедлительно. Решающим доводом в пользу Cloud.ru стала оперативная работа технической поддержки и детальная документация.

☁️ Что сделали
Продуктовую среду развернули на облачной платформе Cloud.ru Evolution на пяти виртуальных машинах, изолировав значимые компоненты и распределив роли для минимизации зависимостей между ними.

Суммарная конфигурация: 120 vCPU, 240 ГБ RAM, ~6 ТБ SSD, на ВМ — Ubuntu 24.04.

Эксплуатацию закрыли мониторингом в Zabbix: команда следит за CPU, RAM, дисками и сетью, контролируя динамику нагрузки и заранее планируя масштабирование. Сейчас запас ресурсов — около 30%, масштабирование выполняется за счет увеличения ресурсов ВМ. На этапе запуска были сбои при развертывании, но команда интегратора вместе со специалистами поддержки Cloud.ru быстро выявили и устранили причины. После отладки работа сервисов стабилизировалась, сбои не повторялись.

🦾 Что получили в итоге
Маркетплейс работает стабильно: за время эксплуатации не было проблем с производительностью и инфраструктурных сбоев.
Площадка выдерживает до 150 000 пользователей в день, а сервис остается доступным и сохраняет высокий уровень клиентского сервиса даже в периоды пиков. 

Подробнее читайте на сайте.

Теги:
Рейтинг0
Комментарии1

Терабайты данных из Teradata в Trino — эффективный способ передачи

В Data Ocean Nova был добавлен новый Trino Teradata Connector, который упрощает ad hoc-доступ к данным из Teradata и позволяет выгружать терабайты данных без кратного роста нагрузки на источник. Коллеги в новой статье объясняют, почему привычная параллельная выгрузка через несколько запросов плохо масштабируется, и показывают более правильный подход: распределять чтение по AMP’ам Teradata так, чтобы каждый из них читался только один раз.

Авторы разбирают архитектуру Teradata, типичные ошибки при многопоточном извлечении данных и принцип работы федеративного доступа через Trino. Отдельно показывают, как коннектор в Data Ocean Nova помогает организовать эффективную многопоточную передачу данных и использовать push-down для фильтрации, агрегаций и join’ов, когда это действительно уменьшает объем выборки.

Как всегда, в статье много полезных советов. Читайте и комментируйте!

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Spark SQL Scripting. Новые возможности для инженеров данных

Коллеги в новой статье «Spark SQL Scripting» представили добротный туториал с практическим разбором возможностей Spark SQL Scripting для инженеров данных.

Spark SQL Scripting, появившийся в 4-й версии, представляет собой процедурное расширение классического Spark SQL. Теперь разработчики могут писать полноценные многошаговые сценарии непосредственно на уровне SQL-артефактов, внедряя в них управляющую логику.

Spark SQL Scripting – это не просто синтаксический сахар, а эволюционный шаг в сторону сближения классического функционала аналитических СУБД (таких как Oracle PL/SQL, MS SQL Server T-SQL) с мощью распределенных вычислений Apache Spark. Использование Scripting позволяет инженерам данных собирать пайплайны обработки на «чистом SQL», не прибегая к сторонним компонентам и языкам разработки, тем самым сокращая кодовую базу и снижая барьер входа для дата-аналитиков.

Как это работает в типовых сценариях применения (пакетные DDL/DML-последовательности обработки, подготовка и расчет витрин данных, проверки качества данных, Runbook-операции), читайте по ссылке. Бонус для дочитавших статью до конца – свод практических рекомендаций и архитектурных паттернов при работе со Spark SQL Scripting.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты

Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.

Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".

Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.

Скрытый налог, о котором не пишут в книжках

Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?

Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.

Вы платите за:

  1. Пересылку данных по сети вместо вызова method() в памяти.

  2. Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.

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

В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.

Опыт Uber

У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.

В 2016 году в компании Uber поймать баг означало пройти по 50 сервисам из 12 разных команд. Инженеры тратили больше времени на синхронизацию в слаке, чем на написание кода.

Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.

Монолит 2.0: как было в Netflix

В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.

В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.

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

  • Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.

  • Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?

  • Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.

Выводов не будет, вы сделаете их сами.
Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.

tg https://t.me/i_am_analyst

Теги:
Всего голосов 24: ↑23 и ↓1+26
Комментарии17

На чем стоит облако? GoCloud 2026: трек «Инфраструктура»

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

А вот что разберут в докладах:

  • Эволюция облачных сетей: обзор новых функций и сервисов — сценарии сетевой архитектуры, защита через Anti-DDoS и анонс новых возможностей.

  • Наблюдаемость продуктов Cloud.ru Evolution — мониторинг, логирование, аудит и дашборды, включая наблюдаемость для частного и гибридного облака.

  • Как легко переехать в Cloud.ru Evolution из других облаков — подходы к миграции, перенос виртуальных машин, хранение и защита данных.

  • Эффективно и сертифицировано: хит-парад гибридных облачных решений — как получить облачные сервисы в своей инфраструктуре, соблюдая требования регуляторов.

  • ИИ-инфраструктура на выделенных серверах: от инференса до обучения на уровне суперкомпьютера — как построить ИИ-платформу полного цикла и объединить GPU-узлы через InfiniBand в кластер.

  • От хаоса в облаке к прозрачности: как управлять расходами и не удивляться счетам — инструменты и практики для контроля затрат в облаке.

Если еще не зарегистрировались, сейчас самое время.

Теги:
Рейтинг0
Комментарии0

Ближайшие события

Принимаем заявки на доклады infra.conf 2026 до 1 апреля 

Команда Yandex Infrastructure приглашает докладчиков на большую конференцию по инфраструктуре — infra.conf 2026. В этом году мы встретимся 4 июня уже в третий раз и обсудим ключевые темы, которые касаются обеспечения высоких нагрузок и не только: 

  • инструменты разработки и практики управления разработкой, 

  • базы данных и стораджи, 

  • принципы и практики обеспечения надёжности и доступности, 

  • управление инцидентами 

  • и многое другое. 

Отдельное внимание уделим построению и особенностям эксплуатации инфраструктуры в эпоху ML.

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

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

Как масштабировать NGFW до сотен Гбит трафика в секунду без потери сессий

Производительность современных NGFW давно перестала измеряться «гигабитами в идеальных условиях». В реальной инфраструктуре устройство одновременно выполняет SSL-инспекцию, IDS/IPS, контроль приложений, антивирусную проверку и другие функции — и всё это под высокой нагрузкой, без потери пакетов и без разрыва пользовательских сессий.

Когда речь идёт о десятках и сотнях Гбит трафика в секунду, вертикальное масштабирование упирается в архитектурные ограничения. Горизонтальный подход выглядит логичным, но на практике поднимает целый ряд инженерных вопросов:

  • как обеспечить симметричную обработку трафика в обоих направлениях;

  • как сохранить пользовательские сессии при изменении состава кластера;

  • как организовать контроль состояния узлов и корректную реакцию на сбои;

  • как избежать появления единой точки отказа;

  • как корректно встроить решение в существующую инфраструктуру.

5 марта в 11:00 совместно с инженерами UserGate обсудим архитектурный подход к масштабированию производительности NGFW, принципы интеграции UserGate NGFW 7 и DS Proxima, а также результаты тестирования и практический опыт внедрения.

Ссылка на регистрацию

Теги:
Рейтинг0
Комментарии0

Экономия памяти со __slots__

В Python атрибуты классов по-умолчанию хранятся в специальном dunder-атрибуте __dict__. В описании класса его задавать не надо, он есть неявно и доступен для просмотра при необходимости. Каждый экземпляр класса также имеет свой __dict__:

class Standard:
	def __init__(self, x, y):
		self.x = x
		self.y = y
		
std = Standard(100, 200)
std.__dict__ # {'x': 100, 'y': 200}

Помимо того, что и класс и экземпляры отдельно занимают своими __dict__ место в памяти, хранение данных в словарях само по себе несет большие накладные расходы. Хеш-таблица в основе словаря хранит служебные структуры и растёт скачками при увеличении числа атрибутов, поэтому на больших количествах объектов затраты памяти ощутимы:

from sys import getsizeof

std_size = getsizeof(std) + getsizeof(std.__dict__)
std_size # 344 байта

Один из эффективных способов сэкономить память, это реализовать в классе специальный атрибут __slots__ и объявить в нем последовательность атрибутов экземпляра. Тогда вместо __dict__, Python будет использовать альтернативную структуру хранения атрибутов с помощью дескрипторов. __slots__ для экземпляров классов отдельно не создается и хранится только на уровне класса:

class Slot:
	__slots__ = ('x', 'y') # Неизменный кортеж из имен атрибутов
	
	def __init__(self, x, y): # Остальное – без изменений
		self.x = x
		self.y = y
		
slt = Slot(100, 200)
slt.__dict__ # **AttributeError**: 'Slot' object has no attribute '__dict__'. Did you mean: '__dir__'?

slt_size = getsizeof(slt)
slt_size # 48 байтов

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

---
Важные ограничения

  1. Стоит отметить, что реализация __slots__ запрещает динамически добавлять экземпляру класса атрибуты, в отличие от __dict__. В ситуациях, где такое необходимо, __slots__ не подойдет.

    std.z = 300
    std.__dict__ # {'x': 100, 'y': 200, 'z': 300}
    
    slt.z = 300 # **AttributeError**: 'Slot' object has no attribute 'z' and no __dict__ for setting new attributes
    
  2. Важно, не забывать расширять слоты, если мы добавляем в код класса новые атрибуты:

    class PartialSlots:
    	__slots__ = ('x', 'y') # Не добавили атрибут экземпляра 'z'
    	
    	def __init__(self, x, y, z):
    		self.x = x
    		self.y = y
    		self.z = z
    
    p = PartialSlots(100, 200, 300) # **AttributeError**: 'PartialSlots' object has no attribute 'z' and no __dict__ for setting new attributes
    
  3. В подклассах от класса со __slots__ наследование этого атрибута проходит лишь частично. Для полноценного использования, его стоит определить еще раз, включив новые атрибуты подкласса:

    # Подкласс без доп. логики
    class InheritSlot(Slot):
        pass
    
    
    inh_slt = InheritSlot(100, 200)
    
    inh_slt.__dict__ # {}, атрибут снова доступен
    inh_slt.z = 300 # Нет ошибок при динамическом расширении атрибутов
    inh_slt.__dict__ # {'z': 300}, словарь подкласса снова занимает память
    
    # Поправим
    class InheritSlot(Slot): 
         __slots__ = ('z', ) # Слоты суперкласса добавятся в начало кортежа. В конце не забываем запятую, так как это кортеж из одного элемента.
    
    
    inh_slt2 = InheritSlot(100, 200, 300)
    inh_slt2.__dict__ # AttributeError ... теперь слоты используются корректно в подклассе
Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Kubernetes: правда такой сложный, каким кажется?

В новом выпуске подкаста «В SREду на кухне» разбираем Kubernetes — честно, по фактам и без лишней теории. Говорим о главном:

  • как выбирать между опенсорсным Kubernetes и вендорскими платформами;

  • из чего складывается реальная стоимость владения;

  • когда команда действительно готова к своим кластерам.

И пытаемся понять, почему Kubernetes постепенно становится стандартом инфраструктуры, но при этом универсального решения до сих пор не существует.

Ведущие:

  • Михаил Савин, SRE Community Lead в Авито;

  • Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

  • Александр Глухих, TeamLead в юните Incident & Problem Managment в Авито.

Гость:

  • Юрий Лосев, технический директор в команде Deckhouse во «Флант».

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
Всего голосов 24: ↑24 и ↓0+24
Комментарии1

Друзья, 12 февраля проведём открытый вебинар по следам нашего ESB-исследования в «Кругах Громова».

Если коротко — за последний год мы оценили 18 российских интеграционных платформ по единой методологии: 12 категорий, 1 000 баллов. Такого раньше на рынке не было. Результаты местами предсказуемые, местами — неожиданные.

На вебинаре поговорим:

— Почему компании до сих пор путают Kafka, ESB и data pipeline — и платят за это дважды
— 5 классов интеграционных решений: когда какой работает, а когда — категорически нет
— Как мы строили матрицу зрелости и кто в итоге получил номинацию
— Что планируем исследовать дальше — и как повлиять на приоритеты

Будет живой эфир с интерактивом, не просто «говорящая голова».

Кто работает с интеграциями, выбирает платформу или просто в теме — приходите, будет интересно.

📅 12 февраля 2026, 11:00 МСК
📍 Онлайн, бесплатно

👉 Нужна регистрация: тут

Теги:
Рейтинг0
Комментарии0

Что с Релизом ?!

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

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

За 15 лет в разработке я участвовал на разных ролях в создании совершенного разного типа продуктов, как по способу запуска(десктоп, веб и тд), типу поставки(desktop, saas, onprem) так и по зрелости продукта(прототип, mvp, плановое развитие зрелого продукта, полное переписывание внутренней системы крупного банка и тд и тп).

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

В этом посте расскажу одну историю. Если тема "зайдет", то подробно систематизирую все известные мне архетипы и напишу уже полноценную статью.

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

Часть, относящаяся к менеджменту релиза также удивляла как ни странно своим отсутствием и незримостью и непрозрачностью для большей части команды разработки.
Все это происходило из за сочетания типа поставки: saas (вернее отсутствия onprem поставки и строгих проверок на стороне клиентов, как говорится "все свое" ) и факта сосредоточения функций релиза в умах 1.5 человек, 0.5 из которых уже давно не относилось к отделу разработки.

Назовем такой тип релиз-менеджмента "one man release managment". Он неплохо работал, пока разработка шла по привычному процессу в рамках небольших изменений логики. Все быстро и удобно. Один человек знает и код и деплой, описывать ничего не надо, планов развертывания строить не надо, планов отката также. И ответственность тоже шарить не надо ;)

Все конечно изменилось по мере роста сложности системы и вызовов перед командой разработки, но это как говорится "уже совсем другая история". Был ли у вас похожий опыт и как вы относитесь к такому устройству процесса релиза? видите ли все таки в нем плюсы или это "не правильно\в книжках пишут не так" ?

Всем добра и тихих релизов !

Теги:
Рейтинг0
Комментарии0

Open Table Formats — Iceberg vs Paimon — практика использования

В блоге партнеров GlowByte вышла новая статья.

Автор рассказывает об опыте работы с новым открытым табличным форматом (OTF) Paimon от разработчиков Apache Flink, представляет практические выводы, которые были сделаны на промышленных средах; а также проводит репрезентативное тестирование, где иллюстрирует ключевые практические сценарии.

Появление open table formats исполнило вековую мечту data-инженеров: совместило эффективность хранения и чтения Apache Parquet с возможностью обновления данных без полной их перезаписи. Достигается это за счет парадигмы Merge-On-Read и «отложенного удаления», когда информация об удалении старых версий записи пишется в deletion-файлы. Для фреймворков потоковой обработки, например Flink, это открывает возможности по обновлению данных прямо в Data Lake в режиме, близком к реальному времени, а для движков пакетной обработки — Spark, Impala, Trino, StarRocks — сокращает расход ресурсов на MERGE новых порций данных в витрины.

Читать статью полностью по ссылке.

Теги:
Всего голосов 4: ↑3 и ↓1+4
Комментарии0

Всё зелёное — значит, всё ок?

В новом выпуске подкаста «В SREду на кухне» обсуждаем суть мониторинга и причины его хронических сбоев. В фокусе — метрики и алерты: как не утонуть в потоке предупреждений, отсеять ложные сигналы и выстроить эффективную систему. Говорим о том, как SRE анализируют графики, какие показатели бизнес считает ключевыми, и развенчиваем миф о том, что «зелёный» статус всегда означает успех.

Ведущие:

  • Михаил Савин, SRE Community Lead в Авито;

  • Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито;

  • Евгений Харченко, руководитель отдела по развитию практик в разработке и эксплуатации в Райффайзен Банк.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
Всего голосов 25: ↑25 и ↓0+25
Комментарии0

Процедурное SQL-расширение в Lakehouse-платформе — новые возможности для работы с данными

В блоге технологического партнера GlowByte вышла новая статья. Команда Data Sapience рассказала о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей.

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

Теги:
Всего голосов 4: ↑3 и ↓1+4
Комментарии0

Открываем доступ по запросу к Yandex Managed Service for Sharded PostgreSQL — сервису на базе технологии SPQR для горизонтального масштабирования PostgreSQL

PostgreSQL по умолчанию не имеет нативной поддержки горизонтального масштабирования — и это вызывает сложности при достижении пределов единственного экземпляра Postgres. В качестве решения часто используют разделение таблиц по ключам и установку рядом с приложением координатора, который знает, на какой шард направить запрос. 

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

Сегодня мы открываем доступ по запросу к управляемому сервису Yandex Managed Service for Sharded PostgreSQL. Новый инструмент создан на базе SPQR (Stateless Postgres Query Router) — это опенсорс‑решение для горизонтального масштабирования PostgreSQL, которое разработано инженерами из команды платформы данных Yandex Cloud и оптимизировано под OLTP‑нагрузки и плавные миграции. 

Управляемый сервис на основе SPQR позволит клиентам облачной платформы Yandex Cloud ускорить обработку миллионов транзакций: так, с Sharded PostgreSQL банки и компании из сферы электронной коммерции могут запускать новые ИТ‑продукты в 3–4 раза быстрее. Надёжность технологии шардированного PostgreSQL проверена на проектах Яндекса.

Подробная история о том, что стало отправной точкой для создания SPQR, какие задачи он помогает решать, на чём основано решение и что помогает ему быть довольно простым в эксплуатации — в статье разработчика команды Managed Sharded Postgres Дениса Волкова на Хабре.

Команда активно развивает технологии PostgreSQL: каждый год в релиз базы данных попадает множество доработок от контрибьюторов из Yandex Cloud:

Инкрементальное улучшение любой популярной технологии зачастую имеет негативные последствия. Построить что‑то новое, ничего не сломав, бывает трудно и в чистом поле, а ядро PostgreSQL в этом смысле — лабиринт с граблями.


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

Андрей Бородин, руководитель команды разработки СУБД с открытым исходным кодом Yandex Cloud, Major Contributor PostgreSQL

Читайте статью Андрея о том, как не получилось сделать PostgreSQL лучше (и почему это нормально)

Теги:
Всего голосов 7: ↑7 и ↓0+8
Комментарии0

Пришлось недавно серьёзно повозиться со сложным обновлением, давно такое интересное не попадалось.

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

В семействе ЕРП регулярно случаются длинные обработчики обновления. Например, при переходе с 17 на 22 в регистр сведений "Реестр документов" добавили измерение с уникальным идентификатором, которое обработчик и заполняет - для всех записей. В моём случае записей было 9 млн, и выполнение обработчика занимало больше суток.

Если нужно сделать 1 шаг обновления, то не страшно - в течение этих суток пользователи могут работать. Но, во-первых, бывают обработчики, которые "отключают" отдельные виды документов или целые контуры учёта, вроде взаиморасчётов или резервов. Во-вторых, мне надо в одно технологическое окно обновить на 4 версии, поэтому ждать было нельзя.

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

И случилось чудо - обработчик выполнился часа за 4-5 (вместо 24+). Попробовал с другими обработчиками, которые столь же изолированные - результат по ускорению тот же.

Я думал, проблема в типовом распараллеливании, которое как-то не очень эффективно распределяет задания между потоками. Пошёл смотреть чужой опыт на партнёрке, нашёл относительно свежую тему (https://partners.v8.1c.ru/forum/t/2259464/m/2259464), где автор нашёл больше меня - дело и в распараллеливании, и в записи статистики. Правда, гарантированного и надёжного решения там найти не получилось - ребята из 1С сказали, что могут быть последствия, если просто отключить статистику. Но обещали что-нибудь придумать со скоростью обновлений.

А пока можете пользоваться тем же способом, что и я, коли возникнет схожая проблема.

https://t.me/ywhite

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии1

Нагрузочное тестирование YMatrix

В партнерском материале расширяются результаты нагрузочного тестирования из статьи «Нагрузочное тестирование GP6 vs GP7 vs Cloudberry» и презентуются результаты тестирования YMatrix. Это дополнение к предыдущей статье, призванное сформировать понимание сравнимости результатов различных форков GreenPlum.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Оптимизации функционала Apache Iceberg в задачах real-time загрузки и обработки данных

В блоге Data Sapience, технологического партнера GlowByte, вышла новая статья.

Технические лидеры направления разработки Apache Spark в составе платформы Data Ocean рассказывают:

  • С какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg;

  • Что такое equality delete;

  • Почему они создают нагрузку при чтении таблиц в Apache Iceberg;

  • Как оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.

Теги:
Всего голосов 3: ↑2 и ↓1+3
Комментарии0

Нагрузочное тестирование YMatrix

Привет, друзья! Мой коллега Марк, ведущий архитектор GlowByte, поделился в новой статье результатами тестирования YMatrix.

Сразу оговорюсь, что это дополнение к предыдущей статье, для того, чтобы сформировать понимание сравнимости результатов различных форков GreenPlum, поэтому акцентировать внимание будем только на YMatrix. Детали по методике тестирования и как были получены результаты для GP6, GP7 и Cloudberry 1.6, можно прочитать в предыдущей статье по ссылке выше. 

Добро пожаловать в статью! Комментарии приветствуются.

Теги:
Всего голосов 3: ↑2 и ↓1+1
Комментарии2

Как оптимизировать бюджет на интеграции в 2026 году: практики и инструменты для DATAREON

11 декабря в 12:00 проведём практический вебинар для ИТ-директоров и архитекторов, которые хотят сократить стоимость интеграций на DATAREON и избавиться от рутинных трудозатрат.

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

Однако цена лицензии — лишь часть картины: важную роль играет также стоимость внедрения и дальнейшего сопровождения.

Сколько на самом деле стоит интеграционный проект? 

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

Об этом мы поговорим на вебинаре.

Что покажем на вебинаре

Технический директор ИТ-интегратора «Белый код» Сергей Скирдин разберёт реальные кейсы и продемонстрирует, какие технические решения ускоряют работу и снижают стоимость интеграционного проекта:

  • Использование API DATAREON для создания типов данных. 

  • Генерация обработчиков 1С.

  • Отладка обработчиков и функций без боли.

  • Использование формата Enterprise Data как основы для интеграции типовых объектов 1С

  • Заглянем в будущее — покажем, как с помощью ИИ-агента можно дорабатывать интеграционный проект в DATAREON.

Какой эффект получит бизнес

✔ Снижение стоимости интеграций. Автоматизация процессов уменьшает объём ручной работы и бюджет проекта.
Быстрый запуск интеграций. Готовые инструменты ускоряют разработку и ввод в эксплуатацию.
Масштабируемость интеграций. Единые стандарты позволяют быстро подключать новые системы без усложнения архитектуры.

Кому будет полезно

  • Руководителям, которые выбирают подрядчика для внедрения интеграционной шины и хотят объективно оценить подходы и стоимость.

  • Архитекторам перерабатывающим технологию замены существующего интеграционного решения на DATAREON Platform

  • Компаниям с большим количеством систем на 1С и активными интеграционными задачами, которые хотят выстроить оптимальную архитектуру и ускорить ввод в эксплуатацию новых интеграционных потоков.

Регистрируйтесь и приходите!
Принять участие

Теги:
Рейтинг0
Комментарии0

5 Ошибок Рефакторинга

А ты надел каску перед рефакторингом ?
А ты надел каску перед рефакторингом ?
  1. Добавлять в рефакторинг улучшения
    Строго отделяйте рефакторинг т.е. преобразование кода из одной формы в другую с полным сохранением поведения от любых даже самых незначительных улучшений, оптимизаций, украшательства и тд и тп

  2. Делать один огромный коммит
    Делайте много коммитов, каждый на свой шаг рефакторинга. Рефакторинг это как ходьба по заминированному лабиринту, нужно обязательно записывать все ходы и иногда отступать на шаг или N шагов назад и искать другой путь.

  3. Рефакторить без промежуточных проверок
    Когда вдохновение несет и хочется "прибраться" и тут и там и везде и некогда останавливаться можно "пролететь поворот" и даже не один. Лучше всего делить рефакторинг на логические этапы. "Дешевые" по времени и ресурсу проверки можно и нужно запускать как можно чаще: компиляция, тесты, запуск приложение локально. Между крупными этапами желательно проводить регрессионное тестирование. И самое отличное поэтапный релиз рефакторинга, чтобы провести не только синтетические проверки, но самую важную "проверку продакшеном"

  4. Затягивать и долго не релизить рефакторинг
    Топ выбрасываний рефакторинга на моей практике происходило из за желания довести его до окончательного окончания, всё всё исправить, привести в идеальную симметрию и тд и тп. Чем дольше человек очищает код, пока параллельно идут продуктовые спринты, тем больше он несет накладных расходов(мержить то надо) и тем больше падает вероятность успешной интеграции ветки рефакторинга с основной и его успешного релиза.

  5. Не думать о запасном варианте
    Не смотря на все многоступенчатые системы проверки качества вашего кода всегда есть далеко не нулевая вероятность ошибки, особенно когда "наводишь порядок" в самом ключевом месте системы (а где еще как не в таких местах наводить порядок).
    В таких ситуация очень полезно оставлять запасной вариант, например флаг переключения на "абсолютно старый код", лучше всего налету без рестартов.

    В своем канале о разработке в стартапах делюсь опытом и рассказываю еще больше удачных примеров и факапов. Буду рад видеть каждого! Заходите!

    Всем удачного рефакторинга!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Как нагрузочное тестирование на бою помогает платёжному сервису готовиться к сезону распродаж

День холостяка, Чёрная пятница, предновогодние распродажи — для платёжного сервиса ЮKassa это не просто даты в календаре, а особенно важное время. Тех, кто одновременно нажимает на кнопку «Оплатить» в онлайн-магазинах, становится в разы больше, и за считанные минуты нагрузка на инфраструктуру нашего сервиса многократно увеличивается.

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

Для тестов на продакшене мы используем контролируемое нагрузочное тестирование, при котором синтетические платежи генерируются через боевые API и проходят полный цикл обработки: магазин → наш шлюз → банк → маркетплейс → платёжная система. Весь тестовый трафик маркируется и не подлежит биллингу — это гарантия отсутствия финансовых рисков. Нагрузка наращивается по двум сценариям — сначала ступенчато (step load), а затем резкими краткосрочными пиками (bursts), — чтобы достоверно сымитировать ситуацию в момент старта распродажи.

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

Более подробно о боевых стрельбах рассказываем в большой статье.

Теги:
Рейтинг0
Комментарии0

Бенчмарк бенчмарка Lakehouse-движков, в котором побеждает объективная реальность

В блоге Data Sapience, технологического партнера GlowByte, вышла крутая статья технического идеолога Lakehouse-платформы данных Data Ocean Nova Евгения Вилкова.

Недавно на Хабре вышла статья с громким заголовком “Бенчмарк lakehouse-движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех”. В своей статье авторы из Кверифай Лабс выбрали методику TPC-DS, но вместо 99 запросов остановилась на одном, который к тому же запускается на одной машине. Обосновывается это тем, что на одном конкретном запросе нужно разобрать работу оптимизаторов. По результатам исследования делается вывод, что решение, разработанное авторами, является лучшим, в том числе для запуска одного конкретного запроса на одном узле. Давайте попробуем разобраться, действительно ли это так.

В качестве отступления замечу, что данный эксперимент не имеет ничего общего с массивно-параллельными вычислениями и Lakehouse. Архитектура раздельных вычислений предполагает интенсивный сетевой обмен не только между storage и compute, но и между узлами compute-движка. Как заметили в комментариях к оригинальной статье, с тем же успехом можно было включить в тест и MySQL. Складывается впечатление, что методика тестирования была выбрана исключительно из-за заявленных компетенций в области оптимизатора движка, а запрос – исходя из наличия собственных доработок для обработки схожего случая. Главной же целью было на частном выводе убедить аудиторию в общем выводе. Отдадим должное коллегам – они не скрывают субъективность своего отношения к упражнению.

Заинтригованы? Добро пожаловать в статью Евгения! Комментарии приветствуются.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Как организовать хранение кадровых документов 1,5 млн пользователей в облаке: опыт HRlink 📄

Когда ваш бизнес обслуживает более 6 400 корпоративных клиентов, а платформу используют 1,5 млн человек, вы точно задумаетесь об отказоустойчивости, надежном хранении данных, соответствии 152-ФЗ, да и на вопросы производительности СУБД взглянете по-новому.

С такими задачами столкнулась компания HRlink. Рассказываем, как на IT-инфраструктуре Selectel она:

  • развернула сервис в облаке с возможностью гибкого масштабирования,

  • повысила производительность более 5 000 баз данных,

  • организовала надежное хранение кадровых документов,

  • обеспечила безопасную обработку персональных данных.  

Подробности кейса читайте в Академии Selectel, а также оставляйте заявку на бесплатную миграцию ➡️

Теги:
Всего голосов 7: ↑6 и ↓1+10
Комментарии2

Яндекс снова на обложке, хотя теперь под именем Nebius. После сделки с Microsoft акции в США улетели на +71%. Формально — всё красиво: дата-центр в Нью-Джерси, контракт на $17+ млрд до 2031 года. Но за кулисами это выглядит чуть иначе.

Главная проблема индустрии — NVIDIA ограничивает квоты на свои чипы. Это значит, что даже гиганты вроде Microsoft не могут прийти и сказать: «Дайте нам вагон H100, мы оплатим картой». Карточек тупо нет столько, сколько всем нужно. Поэтому Microsoft вынужден искать партнёров, у которых есть доступ к чипам через свои каналы.

Появляется Nebius. У компании свой лимит на железо, свои отношения с NVIDIA — и теперь кусок этого лимита фактически «арендован» Microsoft. То есть вместо того, чтобы напрямую выбивать квоты, корпорация берёт вычислительные мощности у бывшей «Яндекс N.V.».

Теги:
Всего голосов 2: ↑1 и ↓1+1
Комментарии1

Про сеть и инфраструктуру RUTUBE в подкасте linkmeup

В этом выпуске Эльдар Ниязов, директор департамента развития и эксплуатации ИТ-инфраструктуры RUTUBE, рассказывает об устройстве видеохостинга, ЦОДах, сетях и делится историями, которые не вошли в доклад об архитектуре.

Из видео узнаете:

  • Сколько нужно серверов, чтобы построить национальный видеохостинг.

  • Сколько легаси осталось от прошлых итераций (спойлер: совсем мало).

  • Как пережить взрывной рост и с какими ещё вызовами сталкивается команда.

  • Где живёт RUTUBE.

  • Зачем понадобилось написать собственный S3 (а более подробно о том, как устроено хранилище — в этом видео).

  • Как оптимизируется CDN и многое другое.

Как видно на превью, это интервью было записано на конференции HighLoad++. Следующая встреча разработчиков высоконагруженных систем уже не за горами и там снова выступят специалисты из RUTUBE — в этом году фокус на ML:

  • «Как RAG ускоряет поддержку RUTUBE: от гибридного поиска до мониторинга галлюцинаций». Виктор Леньшин объяснит, как устроена архитектура системы, которая уже в 80% случаев генерирует готовый ответ на запрос в поддержку.

  • «Платформа для создания субтитров на весь UGC в RUTUBE». Дмитрий Лукьянов расскажет, как платформа сейчас обрабатывает новые видео почти без задержек, справляется с экстремально длинными записями и не привирает на музыке, шумах и спецэффектах.

Больше о том, как разрабатывают медиасервисы, читайте в телеграм-канале Смотри за IT. Там делимся опытом и рассказываем о жизни в цифровых активов «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE и Yappy.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Мемо: в ожидании Python 3.14

Финальный релиз Python 3.14 запланирован на 7 октября 2025. Уже вышел RC2 (14 августа), а финальный кандидат RC3 ожидается 16 сентября.
Этот пост — краткая шпаргалка, чтобы помнить, какие изменения стоит протестировать и чего ждать в новой версии.

1. Свободная многопоточность (Free-Threaded Python, без GIL)

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

# Включение free-threaded режима при сборке
# ./configure --disable-gil
import threading

def cpu_bound_task(n):
    return sum(i*i for i in range(n))

threads = [threading.Thread(target=cpu_bound_task, args=(10**6,)) for _ in range(4)]
[t.start() for t in threads]
[t.join() for t in threads]

Free-Threaded Python теперь не будет экспериментальным и будет официально поддерживаться, но пока пока будет являться опциональным, по умолчанию остаётся GIL.

2. Отложенная оценка аннотаций типов

Зачем нужно: ускорение работы и избавление от кавычек при forward references. Появился новый модуль annotationlib для работы с аннотациями.

# from __future__ import annotations
import annotationlib

class Node:
    def __init__(self, value: int, next: Node | None = None):
        self.value = value
        self.next = next

print(annotationlib.get_annotations(Node.__init__))

Аннотации больше не обрабатываются при определении функций, классов и модулей. Они сохраняются в специальных функциях аннотирования и обрабатываются при необходимости.
Импорт from future import annotations можно удалить при поддержке Python 3.14 и новее.

3. Template-строки (t-строки)

Зачем нужно: безопасное форматирование строк, полезное для веба и DSL, расширение возможностей f-строк.

name = "<script>alert('xss')</script>"
age = 25

tpl = t"Hello {name}, you are {age}"
safe = tpl.format(name=escape_html(name), age=age)
print(safe)

4. Zstandard-сжатие

Зачем нужно: современный алгоритм сжатия, быстрее gzip и удобнее для больших блоков данных.

import compression.zstd

data = b"Large dataset" * 1000
compressed = compression.zstd.compress(data, level=3)
decompressed = compression.zstd.decompress(compressed)

print(f"Ratio: {len(data) / len(compressed):.2f}")

5. Удалённая отладка процессов

Зачем нужно: можно подключать отладчик к работающему приложению без перезапуска и накладных расходов.

import sys
import pdb

# Подключение отладчика к работающему процессу
sys.remote_exec("""
import pdb; pdb.set_trace()
""", target_pid=12345)

# Безопасное выполнение кода в удаленном процессе
result = sys.remote_exec("print('Debug info:', some_variable)", target_pid=12345)

6. Экспериментальный JIT-компилятор

Зачем нужно: ускорение выполнения вычислительно интенсивных задач.

# Включается флагом при запуске
# python --jit script.py

def fibonacci(n):
    if n <= 1:
        return n
    return fibonacci(n-1) + fibonacci(n-2)

# JIT автоматически оптимизирует "горячие" функции
result = fibonacci(35)  # Заметно быстрее с JIT

7. REPL с подсветкой синтаксиса

Зачем нужно: удобнее писать и отлаживать код прямо в интерактивной оболочке.

>>> def hello(name: str) -> str:
...     return f"Hello, {name}!"
>>> hello("World")
'Hello, World!'

Что стоит попробовать?

  1. Потестировать free-threaded режим на CPU-нагруженных задачах.

  2. Перейти на новый синтаксис аннотаций без кавычек.

  3. Проверить t-строки в веб-шаблонах и DSL.

  4. Протестировать zstd для больших массивов данных.

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

Подробнее на python.org: What’s new in Python 3.14

Теги:
Всего голосов 3: ↑3 и ↓0+4
Комментарии0

Как построить отказоустойчивую инфраструктуру на базе Bare Metal: кейс компании SEOWORK

SEOWORK — платформа для мониторинга и аналитики поискового маркетинга. Компания развернула IT-инфраструктуру на выделенных серверах Selectel.

  • Основа инфраструктуры — выделенные серверы в дата-центрах уровня Tier III. Они связаны локальной сетью со скоростью до 10 Гбит/с и изолированы от интернета.

  • За производительность отвечают процессоры AMD EPYC™ 7452 (32 ядра), 512 ГБ RAM на сервер и быстрые SSD-диски корпоративного класса в RAID объемом до 20 ТБ.

  • Вся инфраструктура Selectel по умолчанию соответствует требованиям 152-ФЗ и защищена от DDoS-атак на уровнях L3-L4. Независимый трехмесячный пентест выстроенной системы, выполненный по заказу SEOWORK, подтвердил ее защищенность.

Подробнее о том, как компания развернула на Bare Metal производительную и отказоустойчивую инфраструктуру с SLA 99,8%, которая ежедневно обрабатывает более 600 ГБ данных, читайте в Академии Selectel.

Теги:
Всего голосов 4: ↑4 и ↓0+7
Комментарии0

Интеграция VXLAN в архитектуру LBaaS: наш опыт и решения — тема доклада на IT-конференции GoCloud Tech 2025 ☁️

Расскажем про обновленный балансировщик сетевой нагрузки: какие есть отличия от старого, что уже появилось и еще появится в новом. Разберем его архитектуру и способы управления VXLAN в K8s, затронем тему перформанса и дальнейшего увеличения производительности.

Трек: Cloud Infrastructure — про построение устойчивой, масштабируемой и безопасной облачной инфраструктуры.

📅 Когда: 3 сентября в 12:00 мск

👉 Зарегистрироваться

Что еще интересного будет на GoCloud Tech, смотрите в программе конференции.

Теги:
Рейтинг0
Комментарии0

DeepSeek, Qwen, T-lite, T-pro: на чем мы запускаем LLM для своих ИИ-сервисов

До фреймворка vLLM мы использовали NVIDIA Triton в паре с TensorRT LLM бэкендом. Но перешли на vLLM, потому что с ним оказалось намного проще добавлять новые модели. Да и по стабильности vLLM показал себя лучше: нормально работал под нагрузками там, где связка Triton и TensorRT начинала сбоить и падать. К тому же инференс-сервер vLLM изначально предоставляет OpenAI-совместимые REST API, что упрощает его использование в других продуктах. А инференс-сервер Triton работает с более обобщенным KServe REST API, который сложнее интегрировать в другие продукты.

Не обошлось без проблем и с vLLM: на наших валидационных тестах модель давала неконсистентные ответы даже с нулевой температурой. Оказалось, что это известная особенность vLLM, даже упомянутая в документации. Мы нашли несколько советов, как минимизировать этот эффект: отключать prefix caching опцией --no-enable-prefix-caching и фиксировать random seed опцией --seed. Это помогало при одном запущенном инстансе модели, но при нескольких, даже работающих на одном железе и версии софта, проблема всплывала снова. Также неконсистентность ответов возникает при больших нагрузках — например, когда тесты запускаются одновременно с бенчмарком.

Еще один вызов — это накладные расходы от litellm-proxy и его масштабирование под нагрузками. LLM Gateway, в качестве которого мы используем LiteLLM, превращается в боттлнек кластера, так как все другие сервисы взаимодействуют с кластером именно через него. То есть именно на него идет суммарная нагрузка от всех возможных пользователей, которая потом распределяется между разными моделями и их инференс-серверами.

О том, как устроен инференс-кластер YADRO, подробно рассказал Владислав Виноградов. Бонус к разбору программной и аппаратной части кластера — челленджи и бенчмарки!

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Как не потерять важные проверки в долгих тестах: soft-assert на практике

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

Решение — использовать soft-assert, которые не прерывают выполнение. В команде мы используем Pytest плагин pytest-check, которая позволяет писать soft-assert через контекстный менеджер with check. Это дает возможность:

  • продолжить тест даже при частичных ошибках,

  • собрать диагностику по множеству компонентов (например, контроллеры, кэши, пулы),

  • минимизировать потери времени при дорогостоящих прогонах.

Пример soft-assert с pytest-check:

from pytest_check import check


def object_stack():
    pool_stack = ExitStack()
    yield pool_stack
    for host in hosts:
        with check:
             result = None
             try:
                PoolsService.get_pools_info(host)
             except HostUnavailableException as err:
                result = err
             assert not issubclass(type(result), HostUnavailableException), f'Failed to get pool: {result}'

Soft-assert полезен, когда нужно получить статус всех компонентов, несмотря на сбои отдельных, одна ошибка не делает тест недействительным и тест длится часами и его повтор — затратен.

Однако soft-assert не заменяет критические проверки — в местах, где сбой должен останавливать выполнение, следует использовать assert.

О том, как устроен процесс проверки надежности СХД TATLIN.UNIFIED, рассказала Наталья Грязнова, ведущий инженер по разработке ПО в YADRO. В тексте она делится подходами, которые позволяют комплексно проверять работу систем в разных условиях — от сверхнагрузок до нестабильной среды.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Как развернуть сервис для сбора данных с 500 000 транспортных средств

Представьте, что вы собираете данные с полумиллиона автомобилей: скорость, маршрут, расход топлива, маневры — каждую секунду, без сбоев и потерь. А затем превращаете эти данные в понятные отчеты для тысяч компаний. Справитесь?

Компания «ГЛОНАССSoft» справляется — на инфраструктуре Selectel. В Академии Selectel рассказываем, как команда:

  • обрабатывает 25 миллионов запросов в день,

  • держит инфраструктуру стабильной под высокой нагрузкой с SLA 99,995% за счет репликации, облачных балансировщиков и производительного железа,

  • защищает API с помощью файрвола и настроек сети,

  • минимизирует риски потерь данных благодаря S3-хранилищу.

Теги:
Всего голосов 7: ↑7 и ↓0+8
Комментарии0