Всем привет! Давно я ничего не писал на Хабр про WebRTC. Наверное как‑то не было повода, да и WebRTC давно понятен и прост в общих чертах. Пара строк кода с одной стороны, пара строк кода с другой — вот и готово. Наверное. Там дальше есть несколько тонкостей. На самом деле — целое море тонкостей и обстоятельств, которые надо понимать и уметь с ними работать, но такая уж наша инженерная доля — криво неидеально читать и писать стандарты.

Но сегодня я хочу рассказать не столько про WebRTC как таковой, сколько про велосипеды в его использовании в продакшн‑среде и о том, как тихо без помпы растёт новый стандарт для его сигналинга. На написание этой серии статей меня натолкнула активность Sean Dubois, создателя и мейнтейнера Pion — отличной WebRTC‑библиотеки для Golang.

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

Меня зовут Денис Макрушин, и вместе с Андреем Кулешовым @akuleshov7и Алексеем Тройниковым @atroynikov в этом году мы сделали POC платформы для безопасной разработки в рамках команды SourceCraft. Сегодня поговорим о функциональности поиска секретов. Наша appsec‑платформа состоит из двух групп инструментов: анализаторы, которые требуют точной настройки, и слой управления, который отвечает за обработку результатов и интеграцию с инфраструктурой.

В этом материале пройдём стадию discovery для анализатора секретов: посмотрим на актуальные инструменты поиска секретов, их ограничения и определим направления для повышения трёх ключевых параметров Secret Sсanning: точность, полнота и скорость.

С развитием облаков, появлением гибридных инфраструктур и мультиоблачных сред изменился взгляд ИБ на то, что важно защищать: от безопасности периметра фокус сместился к безопасности учётных записей. Злоумышленники меньше занимаются фишингом и перебором паролей, а всё чаще охотятся на забытые API-ключи и неверно сконфигурированные сервисные аккаунты. По данным Google Cloud Threat Horizons Report, эксплуатация злоумышленниками таких непользовательских сущностей (или non‑human identities, NHI) остаётся в топе угроз, при этом тактики атак постоянно усложняются.

В ответ на это некоммерческая организация OWASP в 2025 году выпустила отдельный рейтинг по топ-10 атак для NHI: OWASP Non‑Human Identities Top 10.

Меня зовут Дмитрий Лютов, я занимаюсь продуктами безопасности в Yandex Cloud и в этой статье я пройдусь по основным угрозам из рейтинга OWASP. Покажу, каким образом владельцы облаков могут позаботиться о безопасности инфраструктуры.

За 10 лет, что существует Serverless‑подход, бессерверные функции стали для многих разработчиков чем‑то привычным и удобным. С их помощью можно быстро написать несколько строк кода для реализации конкретной бизнес‑логики и задеплоить, не думая о развёртывании, настройке и обслуживании инфраструктуры. Нужный код запустится автоматически при срабатывании триггера, как это принято в событийно‑ориентированной архитектуре. Но если таких функций в приложении потребуется очень много — что поможет сохранить нужную скорость работы и другие преимущества Serverless?

Меня зовут Сергей Ненашев, последний год я разрабатываю в Yandex Cloud сервис бессерверных функций Cloud Functions. В нашем облаке с ним можно запускать код в виде функции без создания и обслуживания виртуальных машин.

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

Привет, Хабр! На связи Андрей Бородин, в Yandex Cloud я руковожу направлением разработки СУБД с открытым исходным кодом — и я попал в Яндекс через опенсорс. Я уже немного рассказывал, что и зачем мы делаем в опенсорсных БД с точки зрения облачных сервисов, где мы развиваем PostgreSQL, Greenplum, Cloudberry, Valkey и другие решения.

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

На масштабах Яндекса возникают нетривиальные задачи, которые интересно решать. А когда мы делимся решениями с сообществом, то можем получить от них новый взгляд на проблему, и продолжить совместную разработку новой фичи в удобном формате: с кем‑то на условиях независимого сотрудничества, а кого‑то можем позвать в команду (как это было и со мной).

В общем, если придерживаться опенсорс‑философии, может возникнуть ситуация win‑win. Сегодня с коллегами Леонидом Борчуком @leborchuk и Дмитрием Сарафанниковым расскажу пару историй про то, как это бывает с опенсорсными СУБД.

Diplodoc — опенсорс‑платформа для работы с документацией в парадигме Docs as Code, которая создаётся в Яндексе силами команд Yandex Infrastructure и Yandex Cloud и является частью наших опенсорс‑инструментов. С её помощью мы собираем всю документацию компании. Это суммарно более 300 тысяч статей в более чем 2500 документационных проектов и порядка 6000 запусков Diplodoc CLI каждый день.

На таких объёмах нам важно быть эффективными — умеренно расходовать ресурсы сборочных ферм и при этом собирать проекты как можно быстрее, чтобы документаторы могли увидеть финальный результат без смены контекста на чай.

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

Больше всего от растущего времени сборки страдали технические писатели: для просмотра внесенных изменений им требовалось собирать документацию целиком и на больших проектах это стало приводить к ожиданию более 10 минут. С десятками тысяч правок документации ежедневно эти десятки минут складываются в человеко‑месяцы простоя, которые никому не идут на пользу. Поэтому мы приняли решение всё это основательно причесать.

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

В 2025 году команда НМИЦ онкологии им. Н.Н. Петрова вместе с Центром технологий для общества Yandex Cloud и компанией Raft запустила приложение для быстрой обработки документов клинических исследований. Решение на базе большой языковой модели Яндекса помогает специалистам научного центра классифицировать документы, проверять их оформление и содержание по чек‑листу — и это позволяет сократить цикл согласования с нескольких месяцев до 5–10 дней.

Привет! Это Николай Гриценко, ведущий технический менеджер в Yandex Infrastructure — команде, которая создаёт и развивает внутреннюю инфраструктуру Яндекса, от сетей и дата‑центров до инфраструктуры разработки. Я занимаюсь направлением Internal Developer Platform (IDP). Вместе с коллегами мы много разрабатывали наши собственные инструменты по оркестрации выкладки кода.

В этой статье разберёмся в терминах, попытаемся понять, что же вообще такое инфраструктура как код или IaC, какие бывают инструменты, какие виды и что у нас с этим в Яндексе.

Сегодня мы запускаем Yandex Neurosupport — сервис, который генерирует умные подсказки для операторов контакт‑центра. Он выполняет функции второго пилота: нейросеть анализирует текстовые вопросы клиентов и предлагает оператору вариант ответа. В основе лежат облегчённые модели семейства YandexGPT, дообученные на инструкциях для операторов более чем 50 сервисов Яндекса. Cервис можно внедрить в свой интерфейс через Yandex Cloud по API или же развернуть в on‑premise‑окружении.

Технологическим ядром выступает RAG — звучит просто, но здесь не обошлось без добавления особой яндексовой магии. В этой статье вместе с ребятами из нашей команды ML B2B‑проектов, а также коллегами из команды базовой технологии, Yandex Cloud, «Маркета» и «Еды» расскажем подробнее, как вместе делали этот сервис и каких результатов достигли.

Привет! На связи Евгений Антонов. Я работаю ведущим техническим менеджером проектов в Yandex Infrastructure. А также руковожу парой команд (разработчиков и менеджеров) и факультативно занимаюсь IT‑консалтингом. Ещё я автор телеграм‑канала «Тимлид Очевидность» и ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

Сегодня мне хочется поговорить об очень распространённом паттерне поведения, которого очень многие придерживаются, гордятся этим и даже пишут об этом пожелания в вакансиях.

Как вы, возможно, догадались по названию, речь пойдёт о многозадачности.

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

Меня зовут Виктор Кузённый, и за 15 лет в IT я работал Java‑разработчиком на гособоронзаказ, делал высоконагруженные бэкенды в Кинопоиске, а затем подружился с Serverless в Yandex Cloud, и этот опыт позволил мне познакомиться с разными инструментами разработки, языками программирования, а также инструментами деплоя и управления инфраструктурой.

В статье разберёмся детальнее, что такое IfC, в чём его преимущества и недостатки, а также чем он отличается от IaС и как его дополняет.

Ежегодно в Мировой океан попадает более 11 млн тонн пластика — его накопление в водоёмах угрожает не только отдельным видам птиц и животных, но и целым природным экосистемам. В России эта проблема проявляется не столь остро, как, например, в странах Юго‑Восточной Азии, но тем не менее морской мусор встречается регулярно.

В 2024 году команда специалистов Дальневосточного федерального университета (ДВФУ), Кроноцкого заповедника, Центра технологий для общества Yandex Cloud и Школы анализа данных Яндекса (ШАД) запустила проект «Чистый берег», результатом которого стала разработка нейросети, обученной распознавать определённые виды мусора на побережье, что, в свою очередь, позволяет определить его массу и объём.

Меня зовут Дмитрий Сошников, и в этом проекте я выступил в качестве научного руководителя студентов ШАД. В статье расскажем, как готовили данные и обучали нейросеть, какие технологии для этого использовали и как приложения на основе ML помогают планировать работу исследователей и волонтёров.

Привет! На связи Ольга Попова, и вместе с Алексеем Гусевым @MAD_GooZe мы работаем в Yandex Infrastructure — это команда, которая создаёт и предоставляет внутреннюю инфраструктуру Яндекса — фундамент из продуктов и технологий, которые помогают разрабатывать, деплоить и эксплуатировать все основные сервисы компании. Наша команда носит название «Видеоплатформа» и занимается созданием инфраструктуры для показа видеоконтента на таких платформах, как Кинопоиск, Яндекс Музыка, Станция, Маркет и других.

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

20 марта мы провели митап для пользователей YTsaurus — главной платформы для хранения и обработки больших данных в Яндексе от разработчиков из Yandex Infrastructure, которая уже успела зарекомендовать себя за пределами компании.

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

Всем привет, меня зовут Юрий Пузыня, я занимаюсь развитием платформы документации Diplodoc в Yandex Infrastructure, которую мы пару лет назад выложили в опенсорс. И сегодня я расскажу лёгкую историю невероятного везения в опенсорсе.

Мой первый коммит как контрибьютора в опенсорс‑проект был смёржен спустя два с половиной года мной же в качестве мейнтейнера этого проекта. И в чём тут история успеха — спросите вы. Но давайте я расскажу всё по порядку.

Это адаптированная для Хабра расшифровка доклада Алексея Дмитриева, директора аналитической платформы YDB DWH, которую создаёт команда Yandex Cloud, — компонента нашей гибридной базы данных YDB для обработки аналитических нагрузок. Когда проект только начинался, у нас было много наработок, которые мы успешно переиспользовали в других проектах. Но оказалось, что OLAP‑нагрузка так сильно отличается от OLTP, что за три года пришлось практически написать по ещё одной реализации многих частей системы. Под катом история о том, почему на рынке так мало гибридных баз данных класса Hybrid Transactional and Analytical Processing (HTAP) и какие сложности стоят на пути их разработки.

30 марта сервисы, размещённые в одном из наших основных дата‑центров, оказались недоступны. К инциденту привела авария на опорной подстанции, которая спровоцировала отказ сразу двух вводов питания и последующий каскадный сбой оборудования.

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

Недавно мы выложили в открытый доступ pretrain-версию модели YandexGPT 5 Lite, обученную нами с помощью технологий Яндекса и без применения каких-либо сторонних моделей. За прошедший месяц в сообществе её скачали более 15 тысяч раз, на её основе создали больше десятка квантизованных моделей и даже дообучили instruct-версии. 

Тем не менее мы видим большой интерес к instruct-версии Яндекса, поэтому сегодня выкладываем её в открытый доступ. В том числе — в совместимом с llama.cpp формате, о чём нас просили на Хабре. Кроме того, мы обновили лицензионное соглашение для обеих моделей так, чтобы применять её стало возможно в ещё большем числе проектов, в том числе во многих коммерческих проектах. 

Для тех, кто хотел бы попробовать новую модель онлайн, она также доступна для выбора в Чате с Алисой и через API в Yandex Cloud.

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

В этой статье я расскажу, как использовать VSCode для разработки прошивок под разные архитектуры и как мне в этом помогает SourceCraft Code Assistant от разработчиков Yandex Cloud & Yandex Infrastructure.

В сентябре 2024 года вышел релиз Valkey 8.0 — это key-value-хранилище также часто называют BSD-клоном Redis. В отличие от Redis, Valkey изначально создавался как опенсорс-проект. У него нет энтерпрайз-версии, а значит, развитие не сдерживается коммерческими ограничениями.

Весной 2024 года, когда началась активная работа над форком, команда разработчиков смогла принять и стабилизировать ряд патчей, которые заметно улучшили производительность по сравнению с Redis 7.2.

В этой статье Евгений Дюков, разработчик Managed Databases в Yandex Cloud, разбирает некоторые из изменений и делится результатами проведённых бенчмарков, которые позволяют оценить, как именно новые патчи повлияли на производительность — и в позитивном, и, в некоторых случаях, в негативном ключе. Особенно интересно будет тем, кто ждёт релиз Valkey 8.1 этой весной.