Бэкенд

В прошлой статье про объекты и скорость доступа к известному полю я рассказал про hidden classes, inline cache и форму объекта. Практический совет там был простой: если поле опциональное, создай его сразу и положи null. Тогда экземпляры сохранят одинаковую форму.

Совет рабочий, но неполный. Форма объекта у V8 может остаться прежней, а вот внутренний контракт хранения поля может измениться. Если горячая функция успела прогреться под старый контракт, V8 пометит её на деоптимизацию.

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

Прошло уже 10 лет с публикации моей предыдущей статьи на тему организации проекта на WordPress для удобной работы. Старый текст до сих пор кто-то добавляет в закладки и ставит звезды на Github, хотя многие вещи, актуальные на тот момент, устарели, а задачи поменялись. Если раньше я работал над большим количеством корпоративных сайтов, по принципу «сделал и забыл», то сейчас у меня в работе несколько долгоживущих новостных ресурсов с посещаемостью доходящей до миллиона хостов в сутки. Эти проекты требуют постоянного участия разработчика, и есть большая ответственность перед заказчиком за поломки.

Недавно я писал на Хабре, как собрал каталог MCP-серверов: 80 тысяч записей из девяти источников в одном индексе. В комментариях и в личке быстро всплыл вопрос, который я сам не до конца продумал, когда делал каталог: «нашёл сервер, а запускать его где?»

С MCP-серверами беда в том, что добрая половина живёт не как готовый npm-пакет, а как репозиторий на GitHub. Его надо склонировать, поставить зависимости, собрать, запустить и держать живым. Если сервер stdio (а таких большинство), сверху ещё задача обернуть его в HTTP, иначе к нему не подключится ни claude.ai, ни ChatGPT. Итог: под сервер на 40 строк человек поднимает VPS, пишет Dockerfile, настраивает nginx, выпускает сертификат и вешает вебхук на автодеплой. Дизбаланс усилий чудовищный.

Поэтому я сделал внутри Unyly полноценный раздел деплоя. Подключаешь GitHub-репозиторий, на выходе получаешь работающий проект на slug.unyly.org, пуш в ветку пересобирает его сам. Работает и для сайтов (статика, фронтенд-сборки, Next.js), и для MCP-серверов на Node и Python. Ниже разберу архитектуру по слоям и честно перечислю грабли, на которых потерял время.

При создании отказоустойчивых систем стремятся гарантировать отсутствие потерь транзакций при восстановлении из бэкапов или при переключении на реплику (резервный кластер баз данных). В статье рассматривается, как в коде приложения можно выяснить, была ли потеряна транзакция при переключении на реплику. Вы познакомитесь с техникой (шаблоном написания запросов) Transaction Guard.

Думаю, многие любят послушать музыку во время работы, и я к таким людям отношусь. Так уж получилось, что моя аудио-коллекция находится в VK, по разным причинам, в том числе и по знаменитой причине “так исторически сложилось”. Обычно я просто запускаю на отдельной вкладке музыку и забываю о ней на весь рабочий день. Но последнее время что-то там у VK либо случилось, либо обновилось, но вкладка VK в браузере начала “выедать” всю память от чего прослушивание стало невозможным.

Решил я, значит, написать свой плеер раз такие дела, всегда хотелось что-то поудобнее, а нет ничего удобного чем свои костыли. К тому же, в последних версиях Qt в качестве media backend стал использоваться FFmpeg, хотелось посмотреть как там с этим обстоят дела. Статья не о том, как в принципе получить аудио из VK, а о сетевых проблемах в VK и Qt.

Привет, Хабр! Меня зовут Иван, я DevOps‑инженер в ИТ‑холдинге Т1. В современной разработке автоматизация — это давно не «роскошь», а «базовый минимум». Однако многие команды до сих пор ограничиваются лишь простыми возможностями IDE (Integrated Development Environment), упуская потенциал генерации кода. В прошлом году я выступал с этой темой на конференции Импульс Т1. В статье расскажу подробнее, как перейти к генерации кода в масштабах проекта и зачем разбираться в синтаксических деревьях.

ИИшечка уже пишет приложение за вечер. Но чтобы выложить его в интернет, мы все еще зовем девопсера.

Тут начинаются докерфайлы, CI/CD, DNS, TLS, секреты, логи и контейнер, который десятый раз перезапускается.

В начале лета мы решили проверить: а можно ли научить AI не только писать код, но и самостоятельно доводить его до прода?

Построение HA-кластера в PostgreSQL традиционно требует внешнего стека: Patroni, распределенного хранилища конфигураций и набора вспомогательных утилит. В СУБД Postgres Pro Standard и Enterprise отказоустойчивость реализована на уровне ядра: механизм BiHA берет на себя консенсус Raft, защиту от split-brain и перестроение топологии.

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

На входе у нас вакансия, на выходе — проверенный контакт в одной из трёх кампаний. Между ними: дубли, таймауты, catch-all, неоднозначные SMTP-ответы и окно, в котором процесс может упасть после передачи контакта, но до сохранения статуса. Показываю, как мы расставили дешёвые и дорогие проверки и почему выбрали at-least-once.

Добрый день, я хотел бы поднять крайне недооценённую среди PHP-разработчиков тему e2e-тестов, затронуть бизнес-важность таких тестов, техническую часть и почему их никто не пишет.

Приветствуем, Хабр.

Не секрет, что большие языковые модели и, в частности, трансформеры (GPT) серьезно повлияли на работу программиста, привели к автоматизации многих рутинных задач, значительно удешевили проверку концепций и эксперименты при разработке новых продуктов. Коренные изменения произошли не только в разработке, но и во взаимодействии пользователя с ботами, агентами, поисковыми системами. Промпт-инжиниринг буквально за полтора года превратился из искусства в ремесло, которое способен освоить и подросток. Мы хотим очертить ближайшие перспективы выхода книг из типографии и планы на обозримое будущее — на наших верфях и уже практически на стапелях готовится целый флот литературы, ориентированной на работу с искусственным интеллектом.

Привет, Хабр! Меня зовут Сергей Маркизов и я бэкенд-разработчик в Далее. 

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

Node.js отлично чувствует себя в I/O-bound задачах (API, микросервисы, работа с базами данных и очередями), но как только в приложение попадает тяжелая CPU-bound логика (хеширование больших файлов, обработка изображений, видео, криптография) event loop может стать узким местом.

Один из способов решить эту проблему — вынести тяжелую часть в нативный аддон. В статье разберемся, как делать такие аддоны на Rust с помощью NAPI-RS: посмотрим на базовые типы, классы, асинхронные задачи, работу с JavaScript-объектами и управление ресурсами через Reference и External. 

Материал будет полезен Node.js-разработчикам, backend-инженерам и всем, кто хочет понять, когда Rust можно встроить в JavaScript-проект без боли для пользователей библиотеки.

В старой резервной копии базы данных 0.mk хранится 657 958 ссылок, созданных с 2009 по 2014 год, а также количество нажатий на них. В августе 2026 года мы восстановили 657 607 из этих записей в виде ссылок до 2015 года и прошли по каждой из них. Из 655 178 безопасных записей ссылок с возможностью перехода 76,7% больше не возвращало загружающуюся страницу.

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

Основанный в 2009 году 0.mk был любительским проектом команды из трёх человек. Мы работали над ним в свободное от работы время, обычно по несколько часов в день. Спустя семнадцать лет один из нас нашёл на диске резервную копию базы данных и решил вернуть её к жизни.

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

На примере FastAPI соберём JSON‑логирование, в котором запрос можно проследить целиком, ошибки — фильтровать по типу, а задержки — анализировать по duration_ms.

Документация PostgreSQL по numeric содержит два плохо согласующихся утверждения:

«especially recommended for storing monetary amounts and other quantities where exactness is required» — и сразу же: «calculations on numeric values are very slow compared to the integer types, or to the floating-point types». То есть рекомендуют для хранения денежных величин и тут же признают, что это весьма дорого.

Для меня, как разработчика СУБД это сигнал к действию. Если операции с типом заметно медленнее bigint, возникает соблазн: а нельзя ли хранить денежные величины целым числом копеек и округлять по стандартному правилу? Это бы прилично сэкономило вычислительные ресурсы наших серверов баз данных, разве нет? А что, если вообще использовать double precision?

Стенд: один nginx, одно HTTP/3-соединение, четыре одинаковых запроса подряд. Меряем размер сжатого блока заголовков в обе стороны.

Ответ (nginx → клиент): 131, 131, 131, 131 байт. Запрос (клиент → nginx): 246, 8, 8, 8.

Ответ — константа: сколько запросов ни повтори, столько же байт. Запрос со второго раза схлопывается в тридцать раз. В HTTP/2 к тому же серверу — та же константа.

Между тем динамическая таблица HPACK и QPACK и есть половина смысла обоих протоколов: повторяющийся заголовок отправляется один раз, дальше идут ссылки на номер. Клиент ей пользуется. Сервер не пользуется ни в одном из двух — в HTTP/2 выставляет её размер в ноль, в HTTP/3 не открывает encoder-поток вовсе.

Разбор по фиксированным тегам: nginx 1.31.3, quic-go, Cloudflare quiche, ls-qpack, Google QUICHE. Две реализации из пяти таблицу всё-таки ведут. И приёмная половина — та, которой сервер сам не пользуется, но обязан обслуживать, — в мае принесла nginx use-after-free с оценкой 9.2.

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

Как выбрать правильную платформу, особенно когда у вас нет отдельного штата ИТ‑инженеров и огромного бюджета?

В нашей статье мы разберём ключевые критерии, на которые стоит обратить внимание при выборе системы виртуализации.

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

В Proto Observability Platform уже были дерево, граф, флейм-граф и другие представления трейса. Они продолжали решать инфраструктурные задачи, но ответы о поведении агента приходилось собирать вручную из десятков спанов, транспортных вызовов и повторяющихся тел сообщений. Мы увидели это сначала на OpenTelemetry Demo 3.0, затем при отладке собственного «AI-аналитика» в связке с нашим MCP-сервером.

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

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

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

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

Увеличение количества воркеров с 16 до 32 практически не дало прироста производительности, а при 64 воркерах ситуация стала ещё интереснее: задачи, которые должны были выполняться около 0.5 секунды, начали занимать больше секунды.

Первой моей мыслью было, что я упёрся в PostgreSQL.
Оказалось, что нет.

Отчёт пользователя вскрыл утечку между диалогами в query-провайдере ядра — 6 из 6. Что ещё в 3.6.0: AS2/EDI, общий Kestrel, Camel-паритет.

Год стек рос на наших собственных задачах: мы писали то, что нужно было нам, и проверяли на своей проде. С весны им начали пользоваться посторонние люди — и характер входящих сообщений изменился. Вместо «а поддерживаете ли вы X» приходят разборы: воспроизведение, номера строк в наших исходниках, обходные пути, которые человек уже написал у себя, пока ждал ответа.

Это самое ценное, что может ...