Полный справочник settings.json с ранжированием по полезности: от «почему я не знал об этом раньше» до «пригодится раз в год».

Чтение сериализованных данных — это инфраструктурный налог, который платит каждый сервис при получении информации из внешних источников, например по сети или с диска. В индустрии для схематизированных данных стандартом де‑факто стал Protobuf, и чаще всего этот налог выражается в существенных затратах CPU на его парсинг. В продвинутых случаях парсинг пытаются заменить на значительно более дешёвую, но при этом куда менее удобную работу с zero‑copy представлением FlatBuffers.

Мы открыли исходники YaFF (Yet Another Flat Format) — формата, который убирает этот налог, не заставляя отказываться от Protobuf. На масштабе Яндекса это особенно важно, потому что менять такие базовые вещи, как формат, дорого и больно. Поэтому YaFF изначально спроектирован как альтернативный wire format для существующих экосистем Protobuf (и в перспективе FlatBuffers). Это позволяет дёшево и бесшовно встраиваться в существующие проекты, не переписывая десятки тысяч строк кода.

Как это работает на практике, мы покажем на примере Яндекс Рекламы: в рекомендательной системе, где каждый из сотен тысяч запросов обрабатывает десятки тысяч объектов, нужно особое внимание к представлению данных. Благодаря YaFF мы смогли постепенно, шаг за шагом, оптимизировать систему и без дорогих рефакторингов сэкономить 10–20% CPU в масштабах крупных рантаймов.

Два месяца назад я решил больше не платить за VPN и сделать свой.

Вас ждёт пошаговый гайд по сборке связки VLESS + REALITY + XHTTP, которая пережила атаку РКН, а также теоретические основы для понимания VPN.

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

Я настроил прозрачный прокси-шлюз на роутере: VLESS+Reality+XTLS-Vision через TPROXY на OpenWrt. Сплит-роутинг по GeoIP и доменам, автообновление списка серверов из подписки каждые 30 минут, балансировка по задержке, procd с автоперезапуском. В статье — полный путь от коробочного Cudy TR3000 до рабочей системы: nftables, policy routing, base64-декодер на awk и все баги, которые я нашёл по дороге.

Часть 2: https://habr.com/ru/articles/1028954/

Сегодня Kubernetes — одно из наиболее оптимальных решений для работы с микросервисной архитектурой. Но это не традиционная комплексная система PaaS. В ванильный K8s входит несколько стандартных компонентов, которые отвечают только за минимальный набор необходимых функций. Но для эффективной работы приложений и деплоя продуктовой среды необходимо множество дополнений — CNI, СSI, DNS, Ingress контроллер, внешние LB и т. д. Цель нашей команды — готовая для комфортной работы с кластером PaaS‑платформа. В этой статье мы расскажем, как готовим Kubernetes в dBrain.cloud, чтобы ее достичь.

В этой статье будет рассмотрен принцип работы Kata Containers, а также будет практическая часть с их подключением к Docker.

Вот мы и подобрались к самому интересному: запуску Kubernetes в Kubernetes. В этой статье мы поговорим о таких технологиях, как Kamaji и Cluster API, а также о том, как интегрировать их с KubeVirt.

В прошлых статьях мы уже рассказывали, как мы готовим Kubernetes на bare metal, и о том, как превратить Kubernetes в средство запуска виртуальных машин. Эта статья завершает серию, объясняя, как, используя всё вышеперечисленное, можно построить полноценный managed Kubernetes service и запускать виртуальные Kubernetes-кластеры по клику.

И начнём мы, пожалуй с Cluster API.

Продолжение статьи о продуктовой гипотезе и дистрибуции. Здесь — только инженерная часть.

Эта статья — инженерный рассказ о том, как из набора разрозненных back-office продуктов выросла единая B2B SaaS-платформа.

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

Клиенты часто спрашивают, как построить геораспределенный и катастрофоустойчивый Kubernetes. Так, чтобы при отказе целого дата-центра нагрузка переключалась на резервную площадку без смены IP-адресов сервисов.

Можно возразить, что проще изменить DNS-запись и направить трафик на инстанс в другом дата-центр. Но есть риск: кэширование на рекурсорах некоторых провайдеров может негативно повлиять на доступность. Они иногда игнорируют TTL и хранят старые данные неопределенный срок. Поэтому в таких сценариях крайне желательно сохранить IP-адрес.

Один из элементов «мозаики» такой геораспределенной системы — балансировщик нагрузки с возможностью использования адресов из anycast-подсети, которую выделяет поставщик услуг. В этой статье мы не будем затрагивать вопрос передачи данных и их консистентность на двух разных площадках — разберем только сетевую составляющую. Подробности под катом!

Начало всех начальных начал 

Добрый день, уважаемые хабропоселенцы;‑) Сегодня мы будем говорить, снова о хакатонах и разработке RAG‑моделей, вернее моделей с RAG‑подходами и наших попытках выйти за рамки простого векторного поиска. Не так давно мы участвовали на всероссийском хакатоне «Альфа‑Будущее», организованным Альфа‑Банком и посвящённому настройке RAG для вопросно‑ответных систем. 

Нам необходимо было создать интеллектуальный pipeline RAG‑системы, которая по пользовательскому запросу находит релевантные фрагменты в корпусе данных. Вообще, было на выбор две задачи, вторая звучала как «Разработка copilot приложения для клиентов микробизнеса», но нам ближе оказалась вторая задача. И, конечно же, мы «запилили» своё «модное» решение, о котором вам спешим рассказать в этой статье. Мы проиллюстрируем, как выстраивали архитектуру, какие модели тестировали, на чём остановились и почему, именно такой подход оказался для нас наиболее удачным. Покажем, как работает весь пайплайн — от чанкования документов до гибридного поиска и поделимся результатами бенчмарков и планами развития системы в дальнейшем. Всех заинтересованных лиц приглашаю по традиции под кат;-)

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

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

Мы столкнулись с этим в явном виде и сформулировали задачу так: дать разработчикам и системным аналитикам быстрый и актуальный поиск по всей кодовой базе компании с возможностью диалога через универсального агента.

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

Надоели чат‑боты, которые только болтают? Создаём настоящего ИИ‑помощника: читает файлы, ищет в сети, запоминает всё. LangGraph + MCP — пошаговый гайд для Python‑разработчиков. Меньше теории, больше работающего кода.

— Два готовых агента: классификатор вакансий + файловый помощник
— Поддержка Ollama, OpenAI, DeepSeek — выбирайте любую модель
— Асинхронная архитектура с обработкой ошибок
— Полная интеграция в Python‑проекты без no‑code конструкторов
— Код готов к продакшену: логирование, retry‑механизмы, конфигурация

От настройки окружения до рабочего агента за час.

Задумывались ли вы когда-нибудь, как построить самое стабильное приложение в мире? Какими свойствами оно должно обладать и какие архитектурные подходы делают это возможным? Впечатляет, что приложения вроде Discord и WhatsApp выдерживают миллионы одновременных пользователей, тогда как другие задыхаются уже на нескольких тысячах. Сегодня посмотрим, как Erlang позволяет обрабатывать огромную нагрузку и при этом держать систему живой и стабильной.

Это вторая статья - техническо-практический разбор протоколов и интерфейсов автоматизации сети.

Если хочется исторической справки, я отсылаю читателя к статье-спутнику, в которой мы двигаемся от начала времён в будущее человечества. Какую роль сыграли в нашем настоящем IETF, ISO, олдовые и современные вендоры и даже просто люди.
В этой же мы раскрываем дерево XML, пробуем на вкус капабилити NETCONF, шлём первые RPC и наконец уже расставим в правильном порядке буквы YANG, OpenConfig, gNMI.

Практическую пользу вам принесут только обе прочитанные статьи. Вторая без первой будет непонятна. Первая без второй - беллетристика.

Привет, Хабр!

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

Главная задача данной статьи – объяснить начинающим специалистам необходимость виртуализации, указать на точки ее практического применения и дать ключевые понятия для дальнейшего изучения. По этой причине (а еще, безусловно, вследствие недостаточной квалификации автора) теоретический материал достаточно сильно упрощен.

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

В этом техническом разборе рассмотрим, как инженеры Harness обнаружили и исправили критическую утечку памяти в Go: переназначение переменной контекста в циклах воркеров порождало невидимые цепочки, мешавшие сборщику мусора освобождать память в тысячах горутин, из-за чего их сервис-делегат CI/CD в итоге потреблял гигабайты памяти.

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

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

Для деплоя приложений в Kubernetes существует огромное количество различных инструментов. Если посмотреть на соответствующий раздел в CNCF Landscape, то можно потеряться в разнообразии. Поэтому иногда хорошо иметь в своем арсенале «серебряную пулю», которая подойдет для большинства задач. Helmwave вполне может стать именно таким инструментом.