🚀 Мультибилет на две ключевые конференции июня в Санкт-Петербурге — возможность увидеть картину целиком.
Saint HighLoad++ 2026 (22–23 июня) — для тех, кто строит системы, которые держат нагрузку. Глубокие технические доклады, разборы инцидентов, интерактивные форматы и фокус на практические решения.
Saint TeamLead Conf 2026 (25–26 июня) — для тех, кто развивает команды. Управление людьми, процессы, коммуникации и стратегии роста в условиях неопределённости.
⚡Мультибилет объединяет оба события с выгодой до 30%. Это выбор для тех, кто:
•хочет синхронизировать техническое видение с управленческим;
•планирует прокачать экспертизу в обоих направлениях;
•ценит время и предпочитает решать вопросы комплексно.
Четыре дня в Санкт-Петербурге, две сильные программы, одно логичное решение. Участие в обеих конференциях поможет не просто реагировать на вызовы, а формировать подход к ним.
✋ Билеты постепенно дорожают — чем раньше примите решение, тем выгоднее будут условия. Завтра (1 мая) очередное повышение — успейте забронировать билет сегодня по текущей стоимости, оплатить сможете в течение нескольких дней.
Мультибилет — это инвестиция в развитие, которая окупается качеством архитектуры и зрелостью команды.
➡️ Подробности о конференциях и возможность забронировать билет на сайте
До встречи в Санкт-Петербурге 🖐️
Saint HighLoad++ 2026 (22–23 июня) — для тех, кто строит системы, которые держат нагрузку. Глубокие технические доклады, разборы инцидентов, интерактивные форматы и фокус на практические решения.
Saint TeamLead Conf 2026 (25–26 июня) — для тех, кто развивает команды. Управление людьми, процессы, коммуникации и стратегии роста в условиях неопределённости.
⚡Мультибилет объединяет оба события с выгодой до 30%. Это выбор для тех, кто:
•хочет синхронизировать техническое видение с управленческим;
•планирует прокачать экспертизу в обоих направлениях;
•ценит время и предпочитает решать вопросы комплексно.
Четыре дня в Санкт-Петербурге, две сильные программы, одно логичное решение. Участие в обеих конференциях поможет не просто реагировать на вызовы, а формировать подход к ним.
✋ Билеты постепенно дорожают — чем раньше примите решение, тем выгоднее будут условия. Завтра (1 мая) очередное повышение — успейте забронировать билет сегодня по текущей стоимости, оплатить сможете в течение нескольких дней.
Мультибилет — это инвестиция в развитие, которая окупается качеством архитектуры и зрелостью команды.
➡️ Подробности о конференциях и возможность забронировать билет на сайте
До встречи в Санкт-Петербурге 🖐️
🔥2
Пятничная подборка из 6 свежих материалов апреля для SRE, DevOps, backend-разработчиков и архитекторов высоконагруженных систем.
🔴 GitHub ограничивает Copilot: агентные AI-воркфлоу перегружают инфраструктуру.
🔴 PlanetScale: как работает Database Traffic Control под капотом.
🔴 Релиз Kubernetes v1.36 «Haru»: 70 новых улучшений.
🔴 Unit 42: Эволюция атак на npm и червь Shai-Hulud.
🔴 Datadog: Платформа оценки для автономных SRE-агентов.
🔴 Cloudflare: Внутренний AI-инженерный стек на базе собственных продуктов.
Если у вас есть новости по теме — делитесь в комментариях. Давайте вместе строить уютное профессиональное сообщество 🙌
GitHub был вынужден приостановить регистрацию новых пользователей Copilot Pro из-за критической перегрузки инфраструктуры агентными AI-воркфлоу. Параллельные сессии агентов, выполняющих многошаговые задачи, генерируют экспоненциально растущие затраты на токены, которые превышают стоимость месячной подписки. В ответ GitHub внедряет лимиты сессий (аналог circuit breaker) и жесткие недельные квоты на потребление токенов.
Инженерный блог PlanetScale опубликовал глубокий разбор механизма защиты баз данных PostgreSQL от перегрузки «тяжелыми» запросами. Система использует Postgres-хуки (в частности ExecutorRun) для перехвата запросов до их выполнения. Для предсказания стоимости запроса применяется адаптивный коэффициент, связывающий оценку планировщика с реальным CPU-временем, а также алгоритм leaky bucket для лимитирования по бюджетам.
Вышел весенний релиз Kubernetes 1.36, включающий 18 стабильных фич. Среди главных нововведений: переход в GA гранулярной авторизации kubelet API (заменяет избыточные права nodes/proxy), стабильная поддержка User Namespaces и Volume Group Snapshots. В альфа-версии представлен Workload Aware Scheduling с атомарным gang scheduling через новый PodGroup API.
Аналитики Palo Alto Networks опубликовали исследование ландшафта угроз в экосистеме npm. Зафиксирована новая волна атак (группировка TeamPCP) с использованием пакета @bitwarden/cli. Вредонос использует многоступенчатую обфускацию, крадет токены доступа из CI/CD пайплайнов и облачных провайдеров, а затем использует их для самораспространения (wormable propagation) по всем доступным репозиториям.
Команда инженеров Datadog поделилась опытом создания платформы тестирования Bits AI SRE. Главной проблемой разработки AI-агентов стала «проблема регрессии»: улучшение навыков агента в одной области ломало его логику в другой. Для решения была создана система офлайн-эвалюации, использующая «снимки мира» (world snapshots) реальных инцидентов для воспроизводимого тестирования агентов перед деплоем.
Cloudflare рассказала об архитектуре своей внутренней платформы для AI-разработки, которой пользуются 93% инженеров компании. Стек построен на собственных решениях: AI Gateway используется для маршрутизации запросов к LLM и контроля бюджетов, Workers AI — для инференса, а новый Sandbox SDK обеспечивает безопасное изолированное выполнение кода, сгенерированного агентами.
Если у вас есть новости по теме — делитесь в комментариях. Давайте вместе строить уютное профессиональное сообщество 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Вы уверены, что ваша система выживет при отказе? Большинство отвечают «да» — пока не случится первый инцидент.
На Saint HighLoad++ 2026 вас ждет воркшоп «Рождённый устойчивым», в программе которого практика по HA-архитектуре:
✔️ развернете приложение в Yandex Cloud, намеренно сломаете — и почините. Рядом будут инженеры Yandex Cloud, которые видели, как это ломается в реальных системах. Сможете задать вопрос и получить ответ от человека с production-опытом, а не от документации;
✔️ уйдете с Recovery Plan, который сможете адаптировать под свой прод.
🎤 Ведущие:
•Татьяна Сердинова — активный лидер команд,
•Антон Воронцов — Customer Reliability Engineer,
•Антон Егорушков — DevOps 7 лет, спикер, ментор.
👥 Для кого воркшоп: Backend-разработчики, SRE и DevOps-инженеры, которые хотят прокачать навыки обеспечения надежности.
🖐️ Присоединяйтесь к нам на Saint HighLoad++ 2026 и приходите на воркшоп, чтобы обрести уверенность, что ваш сервис выдержит следующий пик нагрузки.
На Saint HighLoad++ 2026 вас ждет воркшоп «Рождённый устойчивым», в программе которого практика по HA-архитектуре:
✔️ развернете приложение в Yandex Cloud, намеренно сломаете — и почините. Рядом будут инженеры Yandex Cloud, которые видели, как это ломается в реальных системах. Сможете задать вопрос и получить ответ от человека с production-опытом, а не от документации;
✔️ уйдете с Recovery Plan, который сможете адаптировать под свой прод.
🎤 Ведущие:
•Татьяна Сердинова — активный лидер команд,
•Антон Воронцов — Customer Reliability Engineer,
•Антон Егорушков — DevOps 7 лет, спикер, ментор.
👥 Для кого воркшоп: Backend-разработчики, SRE и DevOps-инженеры, которые хотят прокачать навыки обеспечения надежности.
🖐️ Присоединяйтесь к нам на Saint HighLoad++ 2026 и приходите на воркшоп, чтобы обрести уверенность, что ваш сервис выдержит следующий пик нагрузки.
👍1
Внезапный вопрос, друзья: как у вас настроен механизм чтения ленты в Телеграм?
Anonymous Poll
26%
Режим real-time. В течение дня периодически открываю и все читаю, никакой буферизации
30%
Пакетная обработка. Коплю, потом читаю все за раз (раз в день/раз в несколько дней)
16%
Фильтр на входе. Только заголовки, вглубь захожу выборочно
28%
Отказоустойчивый режим. Захожу по пушам из приоритетных чатов/каналов. Остальное по ресурсам
Что обычно происходит с каналами, которые когда-то казались вам полезными, а потом интерес к ним снизился?
Anonymous Poll
6%
Попадают в отдельное namespace (папка «прочитать когда-нибудь»)
31%
Уходят в архив. Захожу раз в месяц, если вспомню
39%
Остаются в общей ленте. Создают шум, но отписываться жалко
24%
Безжалостный код-ревью. Если за 2 недели ни разу не открываю, идут в ансабскрайб
Новость-молния⚡
Вы внедряли AI в разработку и есть что рассказать? Особенно о том, что пошло не так? Вот это нам и нужно!
🙌 Мы открыли короткое окно на дополнительный прием заявок для стрима «Внедрение ИИ в цикл разработки». Ищем именно вас: тех, кто уже столкнулся с AI в реальном проекте.
📍Дедлайн подачи заявок — 15 мая
AI в SDLC занимает больше трети программы Saint HighLoad++ 2026. Поэтому мы хотим добрать кейсы про внедрение AI в реальный инженерный цикл: требования, архитектуру, разработку, тестирование, CI/CD, эксплуатацию, безопасность и управление командой. Тема может быть любой точкой SDLC, но не про «AI пишет код».
Мы хотим усилить программу там, где рынок быстро меняется, а аудитории особенно нужны зрелые практики вместо очередной демонстрации промптов.
Нас интересует живой опыт: как AI встретился с legacy, дорогим инференсом, несговорчивым ревью, compliance или командой, которая смотрит на все это скептически. Что сломалось, что пришлось переделать, какие trade-offs вы приняли и почему.
Есть сырая идея, но не знаете, как оформить? Пишите — поможем выбрать формат: доклад, case clinic, постмортем, дискуссия.
🖐️ Пройдите на сайт, чтобы отправить заявку
Вы внедряли AI в разработку и есть что рассказать? Особенно о том, что пошло не так? Вот это нам и нужно!
🙌 Мы открыли короткое окно на дополнительный прием заявок для стрима «Внедрение ИИ в цикл разработки». Ищем именно вас: тех, кто уже столкнулся с AI в реальном проекте.
📍Дедлайн подачи заявок — 15 мая
AI в SDLC занимает больше трети программы Saint HighLoad++ 2026. Поэтому мы хотим добрать кейсы про внедрение AI в реальный инженерный цикл: требования, архитектуру, разработку, тестирование, CI/CD, эксплуатацию, безопасность и управление командой. Тема может быть любой точкой SDLC, но не про «AI пишет код».
Мы хотим усилить программу там, где рынок быстро меняется, а аудитории особенно нужны зрелые практики вместо очередной демонстрации промптов.
Нас интересует живой опыт: как AI встретился с legacy, дорогим инференсом, несговорчивым ревью, compliance или командой, которая смотрит на все это скептически. Что сломалось, что пришлось переделать, какие trade-offs вы приняли и почему.
Есть сырая идея, но не знаете, как оформить? Пишите — поможем выбрать формат: доклад, case clinic, постмортем, дискуссия.
🖐️ Пройдите на сайт, чтобы отправить заявку
🔥2
В сегодняшнем выпуске дайджеста: изменения в управлении трафиком, внутренностях Git и ядре Linux.
🔴 Gateway API v1.5: Стабилизация стандарта маршрутизации
Крупнейший релиз в истории Gateway API, в котором 6 ключевых функций (включая ListenerSet, TLSRoute и CORS Filter) перешли в статус Standard (Stable). Этот релиз окончательно закрепляет Gateway API как современный стандарт управления трафиком в Kubernetes, приходящий на смену устаревающему Ingress (в частности, Ingress-NGINX).
🔴 Что нового в Git 2.54: config-based hooks и команда history
Свежий релиз Git принес несколько архитектурных изменений. Появилась экспериментальная команда
🔴 Ядро Linux 7.1: новый in-kernel NTFS-драйвер и FRED
Завершилось окно слияния для ядра Linux 7.1. Главные инженерные новшества: внедрение нового, более производительного in-kernel драйвера NTFS (на замену ntfs3) и активация по умолчанию технологии FRED (Flexible Return and Event Delivery) на архитектуре x86. Также добавлены улучшения в подсистему amd-pstate и новые хуки безопасности Landlock LSM.
Продуктивного прочтения и делитесь с коллегами 🙌
Еще больше новостей будем обсуждать на Saint HighLoad++ 2026
Крупнейший релиз в истории Gateway API, в котором 6 ключевых функций (включая ListenerSet, TLSRoute и CORS Filter) перешли в статус Standard (Stable). Этот релиз окончательно закрепляет Gateway API как современный стандарт управления трафиком в Kubernetes, приходящий на смену устаревающему Ingress (в частности, Ingress-NGINX).
Свежий релиз Git принес несколько архитектурных изменений. Появилась экспериментальная команда
git history для безопасного переписывания истории (reword, split) без затрагивания working tree. Также внедрены config-based hooks, позволяющие определять хуки прямо в gitconfig (с поддержкой нескольких хуков на одно событие), а геометрическая перепаковка (geometric repacking) стала стратегией обслуживания по умолчанию.Завершилось окно слияния для ядра Linux 7.1. Главные инженерные новшества: внедрение нового, более производительного in-kernel драйвера NTFS (на замену ntfs3) и активация по умолчанию технологии FRED (Flexible Return and Event Delivery) на архитектуре x86. Также добавлены улучшения в подсистему amd-pstate и новые хуки безопасности Landlock LSM.
Продуктивного прочтения и делитесь с коллегами 🙌
Еще больше новостей будем обсуждать на Saint HighLoad++ 2026
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Готовый инструмент не покрывает ваши требования на 30%. Что делаете?
Anonymous Poll
46%
Форкаем и дорабатываем под себя
28%
Пишем свое с нуля
9%
Берем как есть и подстраиваем процессы под инструмент
17%
Заводим тикет «улучшить инструмент» и идем делать фичи
Насколько надежна ваша инфраструктура на самом деле? Между красивыми отчетами и суровой реальностью продакшена часто лежит пропасть.
В Райффайзен Банке решили не просто верить в планы, а регулярно и осознанно «ломать» свои системы, чтобы проверить их на прочность. Это не просто игра, а серьезный подход к обеспечению стабильности и отказоустойчивости. Ведь когда дело доходит до критически важных сервисов, знать о потенциальных сбоях заранее — значит быть готовым к ним.
В статье руководитель команды разработки хаос-платформы рассказывает, как они пришли к хаос-инжинирингу, почему готовые решения не подошли и как за несколько месяцев собрали собственную платформу для проверки отказоустойчивости. Это не только повышает надежность и сокращает время простоя, но и улучшает пользовательский опыт.
➡️ Если вы хотите узнать, как построить систему, которая действительно выдерживает сбои, и почему иногда лучше написать свое решение с нуля, — читайте статью.
В Райффайзен Банке решили не просто верить в планы, а регулярно и осознанно «ломать» свои системы, чтобы проверить их на прочность. Это не просто игра, а серьезный подход к обеспечению стабильности и отказоустойчивости. Ведь когда дело доходит до критически важных сервисов, знать о потенциальных сбоях заранее — значит быть готовым к ним.
В статье руководитель команды разработки хаос-платформы рассказывает, как они пришли к хаос-инжинирингу, почему готовые решения не подошли и как за несколько месяцев собрали собственную платформу для проверки отказоустойчивости. Это не только повышает надежность и сокращает время простоя, но и улучшает пользовательский опыт.
➡️ Если вы хотите узнать, как построить систему, которая действительно выдерживает сбои, и почему иногда лучше написать свое решение с нуля, — читайте статью.
AI Native Call for Papers
Мы открыли короткое окно (до 15 мая) на дополнительный прием докладов для стрима «Внедрение AI в SDLC» на конференцию Saint HighLoad++ (22 и 23 июня, 1500+ участников, Санкт-Петербург).
Ищем докладчиков, кто уже использует AI-инструменты, AI-агенты в реальном проекте - в рамках любой из стадий цикла:
1. Как на этапе сбора и анализа требований AI помогает продуктовым командам и аналитикам быстрее обрабатывать информацию, находить инсайты и формализовать задачи? Например, как использовать AI для автоматического выявления противоречий, логических ошибок и пробелов в объемных технических заданиях?
2. Как на этапе проектирования AI помогает архитекторам в создании архитектуры? Как AI-архитектор может помочь в проектировании схемы базы данных и микросервисных взаимодействий? Как автоматически поддерживать актуальность архитектурной документации (Architecture as Code) при помощи LLM?
3. Этап разработки - самый популярный и противоречивый этап для внедрения AI, обсуждаем кодогенерацию, рефакторинг и безопасность. Как внедрить «агентный» подход в разработку: от Copilot к автономным кодинг-агентам?
Как автоматизировать рефакторинг огромных монолитов и миграцию на новые стеки технологий? Как организовать эффективное Code Review, где AI выступает первым (и самым строгим) проверяющим? Как настроить локальные AI-модели? Как автоматизировать поддержание технической документации в актуальном состоянии прямо в процессе написания кода?
4. Как AI трансформирует QA-процессы: от генерации данных до умного запуска тестов? Как автоматически генерировать Unit- и Integration-тесты на основе исходного кода и бизнес-требований с высоким покрытием?
5. Как на этапе деплоя AI помогает снизить риски, автоматизировать рутину и оптимизировать инфраструктуру? Как AI-модели могут предсказывать риски неудачного релиза? Как внедрить системы автоматического отката деплоя?
6. AI-инструменты для эксплуатации, SRE, DevOps и инженеров техподдержки, направленные на стабильность и быстрое решение инцидентов. Как предсказывать деградацию производительности и потенциальные инциденты?
Подробнее о секции и докладах, которые мы ждём:
https://cfp.highload.ru/
Прямая ссылка на подачу доклада:
https://conf.ontico.ru/lectures/submit/ainative_hl2026-spb
Сама конференция:
https://highload.ru/spb/2026
Целевая аудитория: senior-разработчики, IT-руководители, DevOps-инженеры, QA-инженеры, CTO.
Конференция берёт на себя помощь с подготовкой, проезд до и проживание в Санкт-Петербурге.
Приглашаем выступить :)
👍4
Со временем разработка перестает быть историей только про новые фичи. На первый план выходят ограничения существующей архитектуры, рост нагрузки, сложность интеграций и попытки понять, как применять AI-инструменты в реальных продуктах.
В этой подборке — 5 записей докладов Saint HighLoad++ 2025, где разбираются production-подходы к highload-архитектуре, производительности, distributed systems и AI-интеграциям.
1️⃣ Как выбрать технологии для высоконагруженного проекта и не привлечь внимание санитаров. Дмитрий Кривопальцев, Вадим Клеба.
Доклад о том, как подходить к выбору языков, баз данных и архитектурных решений при проектировании highload-сервисов. Спикеры разбирают стадии выбора технологий и принципы проектирования долгоживущих систем — с акцентом на разницу между теорией из учебников и практикой production-разработки.
2️⃣ Архитектура высоконагруженных RAG-систем: 10 стратегий оптимизации чанкинга и интеграция с Weaviate, Qwen / Llama / Gemma. Андрей Носов.
Доклад посвящен архитектуре RAG-систем и проблемам масштабирования retrieval-пайплайнов. В центре — стратегии чанкинга, работа с большими документами, баланс между latency и recall, интеграция Weaviate, LangChain, LlamaIndex и LLM-моделей. Также разбираются результаты оптимизаций на реальных данных и способы снижения стоимости инференса.
3️⃣ Прикладной консенсус. Какая Станция должна ответить? Павел Корозевцев.
Если вы когда-нибудь задумывались, как работает Станция и, особенно, как несколько Станций договариваются между собой, этот доклад для вас. Архитектура, алгоритмы, технологии.
4️⃣ Тысячи асинхронных задач в секунду в облачных s3 на Rust/Axum/Tokio — шлифуем ржавчину до блеска. Александр Сербул.
Интересное пересечение двух тем — Rust и параллельной работы c разными облачными хранилищами в условиях «догоняющей» консистентности. Узнайте, какие тонкости вас ждут, как можно добиваться значительного рейта команд к S3 максимально дешево и как при этом нарастить экспертизу в инструменте.
5️⃣ Анализ кода: символьная виртуальная машина. Георгий Александрия.
Глубокий доклад про алгоритмы статического анализа безопасности. Будет интересен не только безопасникам, но и тем, кто любит красивые низкоуровневые решения.
Продуктивного просмотра 🙌
В этой подборке — 5 записей докладов Saint HighLoad++ 2025, где разбираются production-подходы к highload-архитектуре, производительности, distributed systems и AI-интеграциям.
1️⃣ Как выбрать технологии для высоконагруженного проекта и не привлечь внимание санитаров. Дмитрий Кривопальцев, Вадим Клеба.
Доклад о том, как подходить к выбору языков, баз данных и архитектурных решений при проектировании highload-сервисов. Спикеры разбирают стадии выбора технологий и принципы проектирования долгоживущих систем — с акцентом на разницу между теорией из учебников и практикой production-разработки.
2️⃣ Архитектура высоконагруженных RAG-систем: 10 стратегий оптимизации чанкинга и интеграция с Weaviate, Qwen / Llama / Gemma. Андрей Носов.
Доклад посвящен архитектуре RAG-систем и проблемам масштабирования retrieval-пайплайнов. В центре — стратегии чанкинга, работа с большими документами, баланс между latency и recall, интеграция Weaviate, LangChain, LlamaIndex и LLM-моделей. Также разбираются результаты оптимизаций на реальных данных и способы снижения стоимости инференса.
3️⃣ Прикладной консенсус. Какая Станция должна ответить? Павел Корозевцев.
Если вы когда-нибудь задумывались, как работает Станция и, особенно, как несколько Станций договариваются между собой, этот доклад для вас. Архитектура, алгоритмы, технологии.
4️⃣ Тысячи асинхронных задач в секунду в облачных s3 на Rust/Axum/Tokio — шлифуем ржавчину до блеска. Александр Сербул.
Интересное пересечение двух тем — Rust и параллельной работы c разными облачными хранилищами в условиях «догоняющей» консистентности. Узнайте, какие тонкости вас ждут, как можно добиваться значительного рейта команд к S3 максимально дешево и как при этом нарастить экспертизу в инструменте.
5️⃣ Анализ кода: символьная виртуальная машина. Георгий Александрия.
Глубокий доклад про алгоритмы статического анализа безопасности. Будет интересен не только безопасникам, но и тем, кто любит красивые низкоуровневые решения.
Продуктивного просмотра 🙌
❤4👍1
This media is not supported in your browser
VIEW IN TELEGRAM
Как устроена программа Saint HighLoad++ 2026, рассказываем ⤵️
В программе есть секции докладов и стримы развития. На первый взгляд разница может быть неочевидна, поэтому рассказываем, в чем идея каждого направления.
🔴 Секции — это привычный способ ходить на конференцию. Находите в программе интересный доклад и идете слушать конкретную тему: кейс, технологию, разбор решения. Это точечный формат — когда хочется закрыть конкретный вопрос или услышать опыт коллег по определенной задаче.
🔴 Стримы развития — это уже маршрут. Не отдельное выступление, а собранная логика вокруг одной инженерной задачи. Несколько форматов: доклады, воркшопы, дискуссии, разборы — все в одной линии, чтобы не просто услышать отдельные истории, а сложить цельную картину. Так можно глубже разобраться в направлении — например, в архитектуре платформ, эксплуатации, data или ML.
И это не два разных сценария участия. Обычно они работают вместе: можно выбрать стрим как основной маршрут, а внутри него идти на конкретные доклады, которые решают ваши текущие задачи. Или пройти весь стрим целиком.
Когда будете смотреть программу, ориентируйтесь так: секции помогают перенять опыт в решении конкретной задачи, стримы — глубоко погрузиться в конкретное направление и собрать развитие на месяцы вперед.
➡️ Программа еще в стадии формирования, но часть уже можно посмотреть на сайте
До встречи 22 и 23 июня в Санкт-Петербурге на Saint HighLoad++ 2026 🖐️
В программе есть секции докладов и стримы развития. На первый взгляд разница может быть неочевидна, поэтому рассказываем, в чем идея каждого направления.
И это не два разных сценария участия. Обычно они работают вместе: можно выбрать стрим как основной маршрут, а внутри него идти на конкретные доклады, которые решают ваши текущие задачи. Или пройти весь стрим целиком.
Когда будете смотреть программу, ориентируйтесь так: секции помогают перенять опыт в решении конкретной задачи, стримы — глубоко погрузиться в конкретное направление и собрать развитие на месяцы вперед.
➡️ Программа еще в стадии формирования, но часть уже можно посмотреть на сайте
До встречи 22 и 23 июня в Санкт-Петербурге на Saint HighLoad++ 2026 🖐️
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤1
Представьте, что ваша модель машинного обучения «запомнила» что-то, что ей не следовало бы хранить — например, персональные данные или конфиденциальную информацию.
Как заставить ее это «забыть» без полного переобучения, которое может занять дни или даже недели? Это не просто академический вопрос, а требование регуляторов и критическая задача для обеспечения приватности и безопасности.
В мире, где модели становятся все более сложными и вездесущими, способность контролируемо удалять информацию из них становится ключевой. Мы говорим о Machine Unlearning — процессе, который позволяет выборочно стирать данные из обученной модели, сохраняя при этом ее общую производительность.
В этой статье глубокое погружение в то, как измерить эффективность такого «забывания» и какие методы позволяют его достичь. От метрик забвения, таких как Unlearn Accuracy и MIA Metrics, до сохранения качества модели и вычислительной эффективности.
Если вы работаете с ML-моделями и сталкиваетесь с вопросами приватности, безопасности данных или просто хотите понять, как работает контролируемое «забывание», эта статья для вас 🙌
Как заставить ее это «забыть» без полного переобучения, которое может занять дни или даже недели? Это не просто академический вопрос, а требование регуляторов и критическая задача для обеспечения приватности и безопасности.
В мире, где модели становятся все более сложными и вездесущими, способность контролируемо удалять информацию из них становится ключевой. Мы говорим о Machine Unlearning — процессе, который позволяет выборочно стирать данные из обученной модели, сохраняя при этом ее общую производительность.
В этой статье глубокое погружение в то, как измерить эффективность такого «забывания» и какие методы позволяют его достичь. От метрик забвения, таких как Unlearn Accuracy и MIA Metrics, до сохранения качества модели и вычислительной эффективности.
Если вы работаете с ML-моделями и сталкиваетесь с вопросами приватности, безопасности данных или просто хотите понять, как работает контролируемое «забывание», эта статья для вас 🙌
👍4
Через 2 дня закроется дополнительный прием докладов для стрима «Внедрение ИИ в цикл разработки» на Saint HighLoad++ 2026.
📍15 мая – последний день
Мы ищем тех, кто уже применяет AI в реальной инженерной работе: в требованиях, архитектуре, разработке, тестировании, CI/CD, эксплуатации, SRE. Не «как AI написал код», а как он встроился в процесс и что из этого вышло.
Особенно интересны кейсы, где было непросто: legacy, compliance, дорогой inference, сложный rollout, конфликт с процессами, скепсис команды. Что не взлетело, что пришлось переделывать, какие компромиссы приняли.
Если у вас был опыт, после которого поменяли подход к AI в продукте или разработке — это именно тот разговор, который нужен рынку сейчас.
Присылайте ваши заявки, мы поможем оформить и собрать в подходящий формат: доклад, case clinic, postmortem.
✅ Подробности и кнопка для отправки заявки на сайте
📍15 мая – последний день
Мы ищем тех, кто уже применяет AI в реальной инженерной работе: в требованиях, архитектуре, разработке, тестировании, CI/CD, эксплуатации, SRE. Не «как AI написал код», а как он встроился в процесс и что из этого вышло.
Особенно интересны кейсы, где было непросто: legacy, compliance, дорогой inference, сложный rollout, конфликт с процессами, скепсис команды. Что не взлетело, что пришлось переделывать, какие компромиссы приняли.
Если у вас был опыт, после которого поменяли подход к AI в продукте или разработке — это именно тот разговор, который нужен рынку сейчас.
Присылайте ваши заявки, мы поможем оформить и собрать в подходящий формат: доклад, case clinic, postmortem.
✅ Подробности и кнопка для отправки заявки на сайте
Пять инженерных разборов и кейсов от команд, которые строили и эксплуатируют описываемые системы сами, — в сегодняшнем новостном дайджесте.
🔴 Rethinking Distributed Systems for Serverless Performance and Reliability
Архитектурный разбор от первого лица — как сделать distributed compute по-настоящему serverless с изоляцией, intelligent routing и автоскейлингом.
🔴 Отключение Full-Page Writes: ускорение записи в 5 раз
Фундаментальная оптимизация PostgreSQL через архитектурное решение — снятие ограничения, существовавшего десятилетиями.
🔴 PGKeeper: Building the Bouncer We Needed for Postgres
Практический кейс замены стандартного connection pooler на кастомное решение с admission control — актуально для любого, кто масштабирует PostgreSQL.
🔴 How Discord Automates ScyllaDB Clusters at Scale
Редкий детальный разбор автоматизации NoSQL-кластеров на масштабе Discord — полезен для SRE и platform engineers.
🔴 Avalon: как построить эффективный Feature Store на YDB
Практический кейс построения Feature Store на distributed database — актуально для команд, работающих с ML-инфраструктурой на масштабе.
Если у вас есть интересная новость по теме, делитесь в комментариях 🙌
Архитектурный разбор от первого лица — как сделать distributed compute по-настоящему serverless с изоляцией, intelligent routing и автоскейлингом.
Фундаментальная оптимизация PostgreSQL через архитектурное решение — снятие ограничения, существовавшего десятилетиями.
Практический кейс замены стандартного connection pooler на кастомное решение с admission control — актуально для любого, кто масштабирует PostgreSQL.
Редкий детальный разбор автоматизации NoSQL-кластеров на масштабе Discord — полезен для SRE и platform engineers.
Практический кейс построения Feature Store на distributed database — актуально для команд, работающих с ML-инфраструктурой на масштабе.
Если у вас есть интересная новость по теме, делитесь в комментариях 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1