Hypersphere OS делает ставку на другое: на простую и разнесённую по логическим функциональным слоям структуру, где системные компоненты, библиотеки, окружения и AI-модели работают как части одного набора инструментов и в согласии между собой.

Я — Алексей Веснин, системный архитектор, создатель HyperSphere — децентрализованной экосистемы для безопасного и цензуроустойчивого пространства. В IT с начала 90-х. Занимаюсь системным администрированием с уклоном в сети, безопасность и построение информационных систем, которые управляли собой сами и преподавал собственный курс в ЦКО «Специалист» при МГТУ им. Баумана и в других местах.

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

У аббревиатуры BFF кроме Backend for Frontend есть и другая расшифровка — Best Friends Forever. И в контексте статьи это только отчасти шутка. Общение фронтенда и бэкенда не всегда происходит гладко (опустим тот факт, что существует множество мемов о противостоянии фронтендеров и бекендеров): клиент запрашивает данные, бэкенд отдаёт то, что запросили, но часто данных сильно больше, чем нужно, а это значит, что запрос будет возвращаться дольше, фронтенд будет отрисовываться тоже дольше и всё это отразится на опыте конечного пользователя.

А что если между фронтендом и бэкендом построить мостик, который распределит нагрузку и сделает всех дружелюбнее? Примерно в этом и состоит суть паттерна BBF, а в статье разберём подробнее: зачем его внедрять и какую роль он играет в масштабировании современных сервисов; как мы реализуем этот подход в рамках RUTUBE, какой профит он нам даёт; почему мы отказались от GraphQL; в чём отличия от API Gateway и как вообще проектировать такие сервисы.

Современные ML-системы опираются на CPU и ускорители — тензорные или графические. Но их производительность часто ограничена пропускной способностью шины между CPU и GPU: данные приходится постоянно перегонять туда-сюда, и выигрыш от ускорителя нередко тает.

Что если есть архитектура, где этого узкого места нет? RISC-V предоставляет гетерогенность принципиально нового уровня, объединяя ключевые компоненты устройства на одном кристалле, что снимает одно из главные ограничений производительности в ML. Но одних процессоров здесь мало — нужна еще экосистема библиотек.

Привет, Хабр! Меня зовут Андрей Саранчин, и я разработчик СУБД Tarantool в VK Tech. Вот уже полтора года мы строим MemCS — новый колоночный движок Tarantool для HTAP. И вот парадокс: даже с индексами иногда не уйти от сплошного прохода таблицы. Поделюсь, почему мы не смогли миновать Sequential Scan и как мы смягчили эту проблему с помощью Data Skipping.

Эта статья написана по мотивам доклада для Saint HighLoad++ и отражает одну из проблем, которую мы затрагивали в этом докладе.

Если бы кто-то создал кнопку «Сделать безопасно», то заработал бы миллиарды. Но увы — такой не существует, приходится всё делать вручную.

Привет, Хабр! Меня зовут Анна Лучник. Последние два десятилетия я реализую сложные и безопасные ИТ-проекты.

В этой статье расскажу:

От каких угроз может защитить внедрение Service Mesh в теории и на практике.

Какие конфигурации и решения обесценивают включение mTLS, на какие конфигурации стоит обратить внимание, чтобы всё корректно работало.

Поговорим о том, чем mTLS отличается от обычного TLS.

К каким сбоям и проблемам может привести режим strict mTLS. И что делать, чтобы безопасность на стала причиной того, что у нас ничего не работает. 

Как объединить по сети вычислители? Что происходит при компиляции кода для железа под капотом и какие есть нюансы при работе с AI в пространстве ядра? ИИ с ноги ворвался во все сферы разработки, работы — вагон и маленькая тележка. Но на чём и как она должна ехать? У каждой программы есть свои требования, универсальных советов нет.

О новых решениях можно будет узнать на конференции OS DevConf 25 — там будет целый трек, посвящённый железу для AI. Пул экспертов соберётся, чтобы показать, как устроен современный стек ИИ — от базового железа для инференса до системных рантаймов и объединения ферм GPU, чтобы обучить большие языковые модели. Участники не просто узнают об инструментах, но и ознакомятся с методиками, как программировать это железо до уровня «можно использовать в Pythorch».

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

Привет, Хабр! Я — Таня Дудо, уже очень много лет помогаю людям и командам обмениваться знаниями. Сейчас занимаюсь в VK развитием внутренних профессиональных сообществ, а также обучением, развитием экспертов и культурой HiPro.

В этой статье мы поговорим о том, что такое профессиональные сообщества в VK, кто такие критики, как с ними работать, разберём метрики и один неожиданный инсайт. И конечно, в этом материале по мотивам доклада на KnowledgeConf 2025 будет несколько инструментов от меня.

Какие практики бывают в разработке и эксплуатации, и как их внедрять? И как масштабировать практики и оценивать их с помощью метрик? Какие сложности можно встретить на пути?

Привет, Хабр! Меня зовут Евгений Харченко. Моя роль в Райффайзен Банке — руководитель отдела по развитию практик в разработке и эксплуатации. А еще уже пять лет я — Senior Community Lead DevOps, хотя начинал с роли инженера тех. поддержки ServiceDesk. Еще я — член программного комитета DevOpsConf.

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

Привет, Хабр! Меня зовут Сергей Черкашин, и я — руководитель команды по эксплуатации систем и защиты от DDoS-атак в Wildberries & Russ.

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

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

Привет, Хабр! Меня зовут Дмитрий Буров, я Golang-разработчик, автор Telegram-канала Go Advocate, а также лидер Go-сообщества в Lamoda Tech. В IT свитчнулся из военного дирижера. В коммерческой  разработке — более 10 лет, начинал как фуллстек-разработчик на стеке JS, PHP, CSS, а последние шесть пишу только на Go. В этой статье по мотивам моего доклада для GolangConf расскажу про асинхронность и её роль в современных высоконагруженных системах. Разберём исторический аспект, концепцию и реализацию корутин в разных языках, эволюцию асинхронных подходов, сравним корутины и горутины, выясним, зачем Go добавил в рантайм пакет coro и чем это может обернуться.

Мы в Смартомато — супер продуктовые ребята. Со временем у нас скопились недовольство по поводу работы с Golang, захотелось залезть в технические дебри. Произошла гиперкомпенсация и мы придумали препроцессинг в Go. Да, несмотря на то, что этот язык официально не поддерживает препроцессоры —  мы всё равно сделали. А сейчас делимся результатами этой работы с вами.

Эта статья по мотивам моего доклада на Golang Conf X 2025 о болях шаблонного кода и вариантах их решения с помощью препроцессинга на базе стандартного тулчейна Go. В тексте не будет сравнения с препроцессорами в других языках и морально-этической оценки решения.

Условия работы в IT-отрасли становятся всё более непростыми из-за санкций, сокращения бюджетов и прочих факторов. Рынок технологических продуктов в России откровенно штормит, он переживает сложный и важный этап. Растёт спрос на локальные, контролируемые и легко интегрируемые решения, и вместе с этим появляется всё больше зрелых продуктовых команд, способных не просто писать код, а создавать полноценные B2B и B2C-продукты.

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

Привет, Хабр! Меня зовут Александр Коротков, я — тимлид продуктовой команды в Т-Банк и член программного комитета конференции DevOps Conf. Разрабатывал системы автоматизации тестирования, пять лет посвятил работе над IDP, лидировал разработку бизнесовой платформы. Эта статья родилась из моего доклада для DevOps Conf. Но, если честно, тема давно сидела в голове. Я много раз наблюдал в индустрии один и тот же сценарий: платформы начинают строить с амбициями, но потом что-то ломается — развитие замирает, платформа превращается в тяжёлую обузу или её и вовсе переписывают с нуля. Почему так происходит? Где те самые «невидимые грабли», на которые снова и снова наступают разные команды?

Будет полезно не только тем, кто строит платформы напрямую — CTO, Head of Platform, DevOps-инженерам и разработчикам платформенных решений, но и всем, кто сталкивается с инфраструктурой и хочет заранее видеть потенциальные проблемы.

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

Современный DNS — это не только соответствие доменов IP-адресам, но и целое распределенное хранилище различных метаданных (SVCB-, HTTPS-записи, всевозможные верификации и публичные ключи).

Сегодня расскажем, как проект стал одним из основных DNS-сервисов в мире. Статья написана на основе доклада технического директора AdGuard Андрея Мешкова и директора по инфраструктуре AdGuard Константина Замякина в рамках Профессиональной конференции разработчиков высоконагруженных систем Saint HighLoad++ (июнь-2025).

Снаружи финтех выглядит безупречно: есть подробная документация, надёжные провайдеры, а платёжные интеграции будто можно внедрять «на автопилоте». Но стоит заглянуть внутрь, и вы попадаете в «семь кругов финтеха», где любая мелочь превращается в драму, отнимающую выходные и нервы всей команды.

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

Многие считают ITIL (Information Technology Infrastructure Library) устаревшим набором практик, которые не работают на современных процессах. Опыт «Петрович-ТЕХа» доказывает обратное.

Привет, Хабр! Меня зовут Антон Скутин и я business relationship & service level manager в «Петрович-ТЕХ». Вырос из специалиста техподдержки в лида направления качества и сервиса, в компании уже шесть лет, веду телеграм-канал BRM о своей работе. Расскажу про опыт, как мы в «Петрович-ТЕХ» внедрили ITIL и получили реальный профит. В процессе роста компании мы выделили три временных этапа внедрения ITIL-практик.

Статья написана по мотивам моего доклада для конференции DevOps Conf.

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

Чтобы закрыть эту проблему, в Авиасейлс решили внедрить ML-скоринг и ранжировать билеты по вероятности покупки. На практике задача оказалась гораздо сложнее: разные источники данных у аналитиков и бэкенда, training-inference skew, провалы в нефункциональных требованиях и неожиданный рост latency.

В Райффайзен Банке 14 профессиональных сообществ и 262 Agile-команды. Все эти люди взаимодействуют между собой, создают артефакты и проекты с разной скоростью, качеством и своими решениями. Чтобы все это не превратилось в хаос, в корпорации начали выстраивать инженерные практики — для унификации/стандартизации решений.

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

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

Привет, Хабр! Я Владимир Комаров — программист, администратор, архитектор данных и инфраструктуры, преподаватель и автор. В этой статье по мотивам моего доклада на Highload++ мы посмотрим, как развивались системы управления базами данных: с чего всё начиналось, как система хранения данных СУБД эволюционировала, и в каком состоянии эта область находится сейчас. А заодно узнаем, существует ли идеальная СУБД, и если нет, то как приблизиться к идеалу.