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

Трассировка через eBPF снимает налог на ручное инструментирование, но требует ядра не ниже 5.8, несрезанной таблицы символов и знания устройства планировщика Go.

При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов в ядро ежесекундно и потолок расхода в 200–600 мс процессорного времени на ядро.

Медленный запрос это не одна проблема, а пять разных: лишняя работа, борьба за ресурсы, давление среды, деградация плана и патологические шаблоны вроде N+1.

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

Версия браузера, тип навигации, библиотека сбора данных и версия инструментирования входят в определение метрики: смешав их в одном графике, вы увидите изменение измерения вместо изменения продукта.

Слой первый наблюдаемости: собрать данные, не трогая код

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

Альтернатива, ставшая эксплуатационно пригодной за последние пару лет, — подключение зондов eBPF напрямую к символам рантайма и точкам входа библиотек HTTP и gRPC. Трассы восстанавливаются из событий ядра и пользовательского пространства, а файл бинарника на диске не меняется вовсе: правки идут только в памяти работающего процесса, точечно и обратимо.

Почему с Go это сложнее, чем с C

Зонд работает так: в заданное смещение работающего бинарника ставится инструкция прерывания, при попадании в неё ядро останавливает поток, выполняет свою программу и возобновляет исполнение. Для C и Rust это ложится на прологи функций почти без остатка. Go добавляет три осложнения.

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

Соглашение о вызовах. В Go 1.17 аргументы функций переехали со стека в регистры, причём сначала только на amd64; на arm64 и ppc64 это произошло версией позже. Программа зонда, написанная под прежнее соглашение и читающая контекст со смещения от указателя стека, на новых бинарниках прочитает мусор. Значит, трассировщику нужна либо логика зондов под каждую минорную версию языка, либо вычисление места по отладочной информации самого бинарника.

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

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

Главная нерешённая проблема: передача контекста между сервисами

Если нельзя вписать заголовок в коде приложения, как передать идентификатор трассы дальше по цепочке вызовов? Есть три подхода, и практически применим один.

• Писать заголовок прямо в пакет на уровне сетевого интерфейса. Требует расширенных привилегий и работает только для нешифрованного HTTP/1.1: шифрование выполняется выше уровня сокета, и программа видит уже зашифрованные байты.
• Пропускать исходящие вызовы через локальный вспомогательный прокси, который держит соответствие идентификатора горутины и контекста трассы и вставляет заголовки перед пересылкой. Добавляется сетевой переход, зато шифрование не ломается.
• Править карту заголовков прямо в памяти процесса. Соответствующая функция ядра помечена как опасная и действительно способна повредить память: каждая её загрузка пишет предупреждение в журнал ядра, работа требует широкой привилегии CAP_SYS_ADMIN, а в режиме блокировки ядра она запрещена совсем.

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

Что ломается в продакшене

• Идентификаторы горутин переиспользуются. При высокой конкурентности номер может уйти на новую горутину раньше, чем потребитель разобрал события старой.
• Обновление бинарника сдвигает смещения символов. Зонды старого отображения ядро снимает само, и новый бинарник какое-то время работает без трассировки. Слежение за изменением файла сокращает разрыв до секунд, но не убирает его.
• Требования к ядру. Кольцевые буферы нужны ядру от 5.8, а переносимая компиляция зондов требует 5.4 с включённой отладочной информацией о типах. Матрицу ядер стоит проверить до внедрения, а не после.
• Срезанные бинарники. Сборка без таблицы символов и отладочной информации лишает трассировщик возможности сопоставить имена функций со смещениями. Компромисс: оставить хотя бы таблицу символов, заплатив примерно 10–15% размера бинарника.

Сколько это стоит в процессорном времени

Зонды не бесплатны: каждое срабатывание это программное прерывание с входом в ядро. При 50 000 запросах в секунду и четырёх точках съёма на запрос получается 200 000 входов ежесекундно. Опубликованные замеры дают порядка 1–3 мкс на срабатывание на современном оборудовании, то есть верхняя оценка расхода составляет 200–600 мс процессорного времени в секунду на одно ядро.

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

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

Слой второй: превратить трассы в решения

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

«Медленный запрос» это пять разных диагнозов

Прежде чем что-то чинить, стоит понять, чем именно болен запрос. Разбор CNCF раскладывает медленные запросы к базе на пять непохожих причин:

• Лишняя работа. Обычно это полный перебор таблицы из-за отсутствующего или неприменимого индекса. Выборка по идентификатору клиента без индекса растёт с 20 мс на десяти тысячах строк до минут на десяти миллионах. Запрос не менялся, изменился объём данных.
• Борьба за ресурсы. Идеально оптимизированный запрос стоит в ожидании блокировок или свободного соединения. Запрос, проводящий 95% времени в ожидании блокировки, оптимизацией текста не лечится: ему нужна перекройка транзакций.
• Давление среды. Насыщение процессора, узкое место ввода-вывода и нехватка памяти замедляют любой запрос с любым планом: тот же текст запроса и тот же план на нагруженной машине отработает в разы дольше, чем на свободной, и оптимизировать тут нечего.
• Деградация плана. Данные и текст запроса те же, а план исполнения изменился. Устаревшая статистика после массовой загрузки заставляет планировщик выбрать заведомо плохую стратегию.
• Патологические шаблоны. Проблема N+1 выполняет сотню быстрых запросов по две миллисекунды последовательно, добавляя двести миллисекунд задержки на одно только выполнение, не считая сетевых издержек на каждый обмен с базой. Ни один запрос не является медленным, а шаблон катастрофичен и в журнал медленных запросов не попадает вовсе.

Чего не хватает встроенным инструментам базы

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

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

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

Слой третий: не принять смену измерения за изменение продукта

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

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

Общий тренд не объясняет вашу просадку

В июньском наборе данных о реальных пользователях Chrome, опубликованном в середине июля, доля источников с хорошей отрисовкой основного содержимого упала до 67,7%, с хорошей задержкой отклика на взаимодействие до 85,9%, а доля проходящих все три ключевых показателя до 55,3%. Исключением оказалась стабильность вёрстки, поднявшаяся до 81,4%.

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

Гарри Робертс формулирует критерий проверки прямо: если общая доля прошедших упала на 1,2 процентного пункта, а конкретный сайт просел на четыре, широкий тренд разницу не объяснил. Верно и обратное: если сайт почти идеально повторяет рынок по браузерам и устройствам, срочное расследование в коде потратит время всей команды впустую.

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

Изменение методики выглядит как изменение продукта

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

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

Компенсация это не исправление

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

Улучшение реальное, но документ по-прежнему перевёрстывается, если у картинки не заданы размеры или объявление меняет высоту. Браузер убирает одно видимое следствие, а причина остаётся на месте. Проверять после такого изменения стоит липкие шапки, ленты, интерфейс согласия и встроенные блоки, а чинить всё равно вёрстку, а не полагаться на маскировку.

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

Что забрать с собой

Три слоя решают три разные задачи, и провал на любом из них выглядит одинаково: дашборд есть, ответа нет. Без покрытия вы не видите части системы. Без перевода трасс в метрики видите всё и не понимаете ничего. Без дисциплины в чтении принимаете смену методики за регрессию.

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

Материалы разбора: устройство трассировки Go-сервисов через eBPF, перевод медленных запросов в метрики надёжности и разбор того, как метрики вводят в заблуждение.

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

Первым делом уменьшайте размер в пикселях, а не качество: фотография 6000×4000 в карточке шириной 1200 пикселей это чистые потери. Один этот шаг убрал 77% веса тестового снимка.

Формат выбирается под тип картинки: фотографиям WebP или AVIF, скриншотам и интерфейсам сжатие без потерь, логотипам SVG, анимациям анимированный WebP вместо GIF.

AVIF при равном качестве весит вдвое меньше JPEG, но кодируется примерно в пятнадцать раз дольше, поэтому генерировать его нужно на этапе сборки.

Метаданные съёмки занимают от 10 до 30 КБ на файл и в вебе не нужны ни для чего.

Сжатие с потерями на тексте и резких границах даёт видимые артефакты: скриншоты и логотипы жмутся только без потерь, зато на 20–60%.

Шаг, который экономит больше всех остальных

Прежде чем подбирать кодек и качество, посмотрите на фактические размеры. Фотография 6000×4000 в карточке шириной 1200 CSS-пикселей отдаёт браузеру в двадцать пять раз больше пикселей, чем нужно обычному экрану, и вшестеро больше, чем нужно экрану с двойной плотностью.

В замерах автора чеклиста одно только уменьшение до реально отображаемого размера ужало тестовое изображение с 4,7 МБ до 1,1 МБ. Это минус 77% при нулевой потере качества: пиксели, которых не видно, просто перестали передаваться.

Как определить нужный размер:
Отправная точка это ширина контейнера в CSS-пикселях. На обычном экране она же и есть нужная ширина в физических пикселях, на плотных экранах нужно кратно больше: у части ноутбуков это двойка, у большинства современных смартфонов тройка. Поэтому правильный инструмент здесь не фиксированный множитель, а атрибут srcset с несколькими вариантами файла: браузер сам возьмёт тот, что соответствует плотности экрана посетителя.

Формат под тип изображения, а не один на всё

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

• Фотографии — WebP (на 30–50% меньше JPEG) или AVIF (ещё примерно на 30% меньше WebP).
• Скриншоты и элементы интерфейса — PNG или WebP без потерь.
• Логотипы и иконки — SVG: вектор весит копейки и масштабируется без предела.
• Анимации — анимированный WebP вместо GIF, это экономит 60–80% веса.

Отдельно про текст. Сжатие с потерями на буквах и резких границах создаёт заметные ореолы вокруг символов, поэтому скриншоты и логотипы обрабатываются только алгоритмами без потерь. Инструменты вроде oxipng ужимают такие файлы на 20–60%, не меняя при этом ни одного пикселя.

Конвертация и сжатие — это два разных действия

Перевод PNG в JPEG экономит место. Сжатие получившегося JPEG экономит ещё столько же, и про этот второй проход регулярно забывают. Для фотографий рабочий диапазон качества это 75–82%: от стопроцентного такая картинка визуально неотличима, а весит заметно меньше.

Метаданные, которые вы отдаёте бесплатно

В файле с камеры или из редактора лежат EXIF, координаты GPS, модель камеры и метки программы обработки. Для показа в браузере это бесполезный груз весом от 10 до 30 КБ на файл, за одним исключением: тег ориентации. Часть снимков с телефона хранит пиксели неповёрнутыми и полагается на него, поэтому поворот нужно применить к самим пикселям до того, как метаданные срежутся, иначе фотографии лягут набок. На каталоге из тысячи товарных снимков набегает до 30 МБ трафика ни за что, а координаты съёмки вдобавок могут оказаться данными, которые вы не собирались публиковать.

AVIF: что это и почему его нельзя кодировать на лету

AVIF (AV1 Image File Format) выпущен Alliance for Open Media в 2019 году и построен на внутрикадровом кодировании видеокодека AV1. По сути это инструменты сжатия одного кадра AV1, упакованные в самостоятельный контейнер для картинок.

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

Сколько это в килобайтах

В сравнительном тесте брали пейзажный кадр 1920×1080 с градиентами неба, текстурой листвы и границами зданий, исходник в BMP весил 5,93 МБ. Целевое качество задавали по метрике структурного сходства: она сравнивает сжатую картинку с исходной, где единица означает полное совпадение, а 0,92 примерно соответствует порогу, за которым разницу перестают замечать глазом. Результаты:

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

Плата за это — время. Кодирование AVIF примерно в пятнадцать раз дольше JPEG и вчетверо дольше WebP, потому что выбор разбиения и типа преобразования требует перебора с оптимизацией. Зато декодирование медленнее JPEG всего вдвое, и на просмотр это почти не влияет. Практический вывод прямой: генерируйте AVIF заранее, на этапе сборки. Сервисы доставки изображений кодируют его и по запросу, но только с кешированием результата, чтобы платить за кодирование один раз на вариант, а не на каждого посетителя. Чего делать нельзя, так это кодировать заново при каждом обращении.

Как отдавать современный формат и не потерять старые браузеры

Поддержка AVIF в браузерах составляет примерно 96%, но подстраховка всё равно нужна. Делается она тегом <picture>: браузер берёт первый формат, который понимает, и до остальных не доходит.

Атрибуты width и height здесь не декоративные: без них браузер не знает пропорций до загрузки файла и подвёрстывает страницу заново, когда картинка приходит. Это тот самый прыжок содержимого, который портит метрику визуальной стабильности. Атрибут loading=lazy убирает изображения за пределами первого экрана из очереди, конкурирующей за отрисовку главного элемента.

Именно за пределами: на картинку первого экрана его ставить нельзя. Отложенная загрузка задержит ровно тот элемент, скорость появления которого и меряет метрика отрисовки основного содержимого. Там уместен противоположный по смыслу fetchpriority=high.

Сжатие в браузере: почему это вообще возможно

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

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

Автор одного из таких инструментов разобрал устройство своего конвейера, и его опыт пригодится всем, кто выносит тяжёлые вычисления во фронтенд.

Вся тяжёлая работа уходит из главного потока

Перекодирование снимка 4000×4000 нагружает процессор настолько, что в главном потоке интерфейс замирает, а браузер показывает предупреждение о зависшей странице. Поэтому весь конвейер живёт в Web Worker: главный поток отвечает за выбор файлов, превью и состояние, а рабочий поток декодирует через createImageBitmap, применяет преобразования и кодирует через OffscreenCanvas. Именно через него, а не через canvas.toBlob: последний это метод DOM-элемента, а DOM в рабочем потоке отсутствует, и нужный метод там называется convertToBlob.

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

Три ошибки, которые ищутся дольше всего

Рабочий поток не имеет доступа к window. Причём не только напрямую: достаточно подключить библиотеку, которая трогает window на верхнем уровне модуля. В консоли разработчика появляется ошибка обращения к неопределённому объекту, а вот в интерфейсе не появляется ничего: если сбой рабочего потока никак не показан пользователю, тот видит вечный спиннер. Лечится ревизией всех импортов рабочего потока: библиотеки, завязанные на браузерное окружение, остаются в главном потоке и передают в рабочий поток уже готовые данные.

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

Асинхронный обработчик сообщений перепутал порядок. Обработчик стал ждать преобразование уже после кодирования, а асинхронные обработчики порядок не сохраняют: состояние поворота разъехалось с готовым изображением. Полностью синхронным такой обработчик не сделать, декодирование и кодирование асинхронны по своей природе. Работает другое: обрабатывать сообщения строго по одному, не начиная следующее до завершения предыдущего, и хранить состояние вроде угла поворота рядом с данными конкретного сообщения, а не в общей переменной.

Заголовки безопасности ломают рабочие потоки молча:
Блокирует загрузку скрипта заголовок Cross-Origin-Embedder-Policy: он требует, чтобы каждый сторонний ресурс отдавал разрешающий заголовок, иначе браузер молча его отбрасывает. Cross-Origin-Opener-Policy на это не влияет, но включают их обычно парой, поэтому и ломается всё в одном релизе. Любое изменение заголовков безопасности проверяйте на настоящем развёрнутом стенде, а не только на машине разработчика.

Что это даёт в цифрах

Скриншот 1920×1080 проходит такой путь: исходный PNG весит 2,1 МБ, после уменьшения и перевода в WebP с качеством 75% — 186 КБ, то есть минус 91%. Тот же кадр в AVIF занимает 102 КБ, минус 95% от исходного.

Именно эти проценты и отделяют страницу, которая грузится четыре секунды, от страницы, которая укладывается в одну.

Что забрать с собой

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

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

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

Оба симптома дают один и тот же виновник — постраничная выдача через OFFSET. И оба чинятся одним переходом, причём переписывать приходится только слой выдачи.

Пагинация — это способ отдать большую коллекцию по частям. Вариантов ровно два. Offset-пагинация просит базу пропустить N строк и вернуть следующие двадцать. Курсорная (её же называют keyset) запоминает последнюю отданную запись и просит всё, что идёт после неё.

Стоимость OFFSET растёт линейно: на таблице в 1,2 млн строк выборка со смещением в миллион занимает 2,4 с против 3 мс у курсора.

Под параллельными вставками и удалениями OFFSET выдаёт дубликаты и пропуски, потому что нумерация строк сдвигается между запросами.

Курсор не поддерживает переход на произвольную страницу, поэтому для админок и таблиц с кнопкой «страница 47» offset остаётся правильным выбором.

Лимиты запросов на счётчике в памяти инстанса не работают: при десяти инстансах настроенные 100 запросов в минуту превращаются в 1000.

Скользящее окно на сортированном множестве Redis и атомарном Lua-скрипте занимает пятнадцать строк и снимает гонку без распределённых блокировок.

Результат на спокойной базе одинаковый. Поведение под ростом данных и параллельными записями — принципиально разное.

Offset ломается двумя разными способами

Про первый знают почти все, про второй вспоминают уже после инцидента.

Он линейно замедляется

PostgreSQL, MySQL и SQLite не умеют «перепрыгнуть» через строки. При OFFSET 100000 база честно читает сто тысяч строк и выбрасывает их, чтобы отдать следующие двадцать. Стоимость запроса растёт вместе со смещением.

Автор разбора замерил это на таблице в 1,2 млн строк в PostgreSQL 15 с холодным кешем и обычным btree-индексом по id:

Курсорный вариант на той же таблице держал 3 мс на любой глубине. Разница объясняется сложностью: поиск по индексу это O(log n), а большое смещение — O(offset). На пятидесятитысячной странице пользователь ждёт больше двух секунд вместо миллисекунд.

Он врёт, когда в таблицу пишут

Этот сценарий коварнее. Пользователь загрузил первую страницу с двадцатью записями, отсортированными от новых к старым. Пока он читал, в таблицу добавились три новые записи. Запрос второй страницы с OFFSET 20 вернёт часть того, что уже было на первой: всё сдвинулось на три позиции.

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

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

Как выглядит курсор в коде

Простейшая версия работает по первичному ключу и умещается в один обработчик:

Обратите внимание на per_page + 1. Запрашивая на одну запись больше, чем собираетесь отдать, вы узнаёте о существовании следующей страницы без отдельного запроса COUNT. Лишняя запись отбрасывается, а её наличие становится флагом has_more.

Составной курсор: место, где ломается наивная версия

Курсор по одному id корректен, только пока вы сортируете по id. Как только сортировка идёт по created_at, простое условие created_at > X начинает терять записи: два заказа, созданные в одну миллисекунду, дают ничью, и одна из строк молча исчезает из выдачи.

Лечится это составным курсором — ключ сортировки плюс первичный ключ, сравниваемые как кортеж:

Сравнение кортежей разрешает ничьи детерминированно, поэтому ни одна строка не дублируется и не пропадает. Под это нужен составной индекс (created_at DESC, id DESC), иначе выигрыш в скорости пропадёт вместе с планом запроса.

Про формат курсора:
Не отдавайте наружу голый идентификатор, если планируете менять схему. Заверните значения в маленький JSON с полем версии и закодируйте в base64: тогда через год вы поменяете состав курсора, не сломав клиентов, которые прямо сейчас держат страницу открытой.

Когда офсетную пагинацию нужно оставить

Курсор не бесплатный, и подменять им всё подряд не стоит. Есть четыре ситуации, где offset честно лучше:

• Интерфейсу нужен переход на конкретную страницу. У курсора нет номеров страниц, поэтому админки, таблицы и всё с кнопкой «перейти к странице 47» остаются на offset.
• Данных мало и они не меняются. Справочник на пять тысяч строк не выиграет ничего, зато offset проще объяснить и отладить.
• Пагинация идёт по памяти или по кешу, где смещение и так стоит O(1).
• Сортировка задаётся пользователем по произвольной колонке. Курсор тут превращается в кодирование кортежей в непрозрачные строки, и это уже заметная сложность.

Разумное правило: курсор по умолчанию для всего, что может перерасти десять тысяч строк или читается во время записи. Offset — для небольших, статичных и внутренних данных.

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

Вторая половина задачи: кто и сколько может забрать

Правильная пагинация решает, как отдавать данные. Она не решает, сколько их заберут за минуту. Ограничение частоты запросов выглядит тривиально («считай запросы, блокируй сверх N») и превращается в задачу распределённых систем ровно в тот момент, когда серверов становится два.

Сначала ответьте, от чего защищаетесь

От выбранной цели зависит вся конструкция, и целей обычно выделяют четыре:

• Защита от перегрузки — не дать всплеску положить сервис.
• Честное распределение — не дать одному шумному клиенту вытеснить остальных.
• Защита от злоупотреблений — притупить перебор паролей, скрейпинг и подстановку учётных данных.
• Контроль расходов — ограничить дорогие ручки вроде вызова модели или построения отчёта. Тот же принцип со стороны поставщика разбирали на примере лимитов трат в OpenAI API.

Три алгоритма и один, который выбирают почти всегда

Фиксированное окно считает запросы в календарном интервале: сто в минуту со сбросом на начале минуты. Просто и дыряво: клиент отправляет сотню в 12:00:59 и ещё сотню в 12:01:00, то есть двести за одну секунду. Граница окна и есть дыра.

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

Ведро токенов обычно и оказывается верным выбором по умолчанию. В ведре лежит до N токенов, оно пополняется с постоянной скоростью, каждый запрос тратит один токен. Такая схема разрешает контролируемые всплески (молчавший клиент накопил токены и может потратить их разом), но держит среднюю нагрузку в рамках. Родственное «дырявое ведро» выдаёт идеально ровный поток и нужно там, где принимающая сторона всплесков не переносит.

Фиксированное окно пишут первым и потом жалеют. На ведро токенов мигрируют.

Ловушка, из-за которой лимит не работает вообще

Счётчик в памяти процесса живёт до появления второго сервера. После этого «сто запросов в минуту» тихо означает «сто запросов в минуту на инстанс», и при десяти инстансах клиент законно получает тысячу. Ошибку не видно ни в логах, ни в мониторинге: лимит вроде бы работает, просто не тот.

Лечится это переносом счётчика в общее хранилище, обычно в Redis, причём проверка и инкремент обязаны быть атомарными. Последовательность «прочитать, сравнить, увеличить» из кода приложения гоняется между инстансами и недосчитывает запросы ровно под той нагрузкой, ради которой лимит и ставили.

Скользящее окно на Redis: пятнадцать строк Lua

Команда сервиса jo4.io столкнулась с частным случаем этой задачи: ручка подсказки категорий ходит в модель через Groq, каждый вызов стоит денег, а пользователь может дёрнуть её полсотни раз за минуту. Нужны были лимиты на конкретную ручку и на конкретного пользователя, причём в тот же день.

Скользящее окно они собрали на сортированном множестве Redis. Скор записи — временная метка в миллисекундах, а весь алгоритм умещается в один Lua-скрипт, который Redis выполняет атомарно:

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

Две детали, на которых легко ошибиться

Уникальность члена множества. ZADD не добавляет запись, а перезаписывает существующую, если член совпал. Два запроса в одну миллисекунду с одинаковым значением дадут счётчик, который занижен. Авторы склеивают метку времени с восемью символами UUID: метка обеспечивает уникальность почти всегда, а восемь шестнадцатеричных символов дают около четырёх миллиардов вариантов внутри одной миллисекунды.

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

Обошлось это в два часа работы вместе с тестами. Одна запись в сортированном множестве занимает около 50 байт, на пользователя их пять, и даже при десяти тысячах активных пользователей всё хранилище лимитов весит порядка 2,5 МБ. Настроенный лимит составил пять запросов за шестьдесят секунд на пользователя. Первым же уловом стал автоматизированный скрипт, бивший в ручку больше двухсот раз в час.

Честный контракт с клиентом

Ограничение без внятного ответа превращает вежливого клиента в невежливого: не понимая, что происходит, он начинает долбить чаще. Минимальный набор обязательств выглядит так:

• Отдавать 429 Too Many Requests, а не общий 400 или 503. По коду клиент понимает, что делать.
• Присылать заголовок Retry-After, чтобы клиент знал момент следующей попытки, а не подбирал его перебором.
• Показывать остаток бюджета в заголовках вида X-RateLimit-Remaining и X-RateLimit-Reset.

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

Что забрать с собой

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

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

Разборы, на которых основан материал: переход с offset на курсор с замерами, паттерны и алгоритмы ограничения частоты и скользящее окно на Redis и Lua.

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

Кому это важно: тем, кто много лет копил историю перемещений в Google Timeline и после переноса её на устройство ищет, где хранить данные самому. Импорт Google Takeout в Dawarich есть, а с новой отрисовкой многолетний архив перестаёт быть проблемой для интерфейса. Проект написан на Ruby on Rails с PostgreSQL и ставится через Docker; на сайте указано больше 9000 звёзд на GitHub.

• Точки, треки, маршруты и слои «тумана войны» теперь отдаются через map tiles; 957 350 точек за меньше чем секунду, JSON с 590 МБ до 150 КБ.
• Для перетаскивания точек на карте новый режим нужно отключить.
• Определение посещений (visit detection) переписано с нуля; метаданные устройств перенесены в таблицу point_sources.
• OwnTracks в HTTP-режиме показывает членов семьи на карте; перелёты из AirTrail считаются отдельно от треков Dawarich.
• Self-hosting бесплатен со всеми функциями; облако: Lite 59,99 евро в год (12 месяцев истории, 200 запросов API в час), Pro 149,99 евро (бессрочная история, 1000 запросов в час), Family 299,99 евро (до 5 человек).

Почему тайлы решают проблему миллиона точек

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

Автор пишет, что за месяц вышло девять релизов, и называет результат «немного безумным» (перевод редакции). Для админа, который держит Dawarich на маломощном VPS или Raspberry Pi, важно другое: девять релизов за месяц означают частые миграции базы, и перед каждым обновлением нужен бэкап PostgreSQL.

Что ещё изменилось в 1.14.1

• Метаданные устройств перенесены в таблицу point_sources: миграция базы при обновлении обязательна, перед ней нужен бэкап PostgreSQL.
• Импорт OwnTracks исправлен для массивов PostgreSQL; повреждённая или обрезанная загрузка теперь отклоняется без ошибки сервера.
• Расстояние перелётов из AirTrail считается отдельно от расстояния, записанного трекером.
• Интерфейс переведён на шесть языков: английский, немецкий, испанский, французский, польский и каталанский; следующим заявлен упрощённый китайский. Русского перевода нет.

Self-hosting или облако

Self-hosted версия бесплатна и включает всё, что есть в платных тарифах, ограничения только у облачного варианта: Lite за 59,99 евро в год хранит 12 месяцев истории и даёт 200 запросов API в час, Pro за 149,99 евро снимает лимит истории и поднимает потолок до 1000 запросов, Family за 299,99 евро рассчитан максимум на пять участников. Условия оплаты облака по регионам проект не описывает; self-hosting от них не зависит.

Что проверить перед обновлением: сделать дамп базы, обновить образ Docker до 1.14.1, дождаться миграций и убедиться, что карта показывает точки в новом режиме. Кому релиз не нужен: тем, у кого история перемещений измеряется тысячами точек, а не сотнями тысяч; для них разница будет незаметна. О другом свежем self-hosted проекте того же класса мы писали на примере Home Assistant 2026.9; о хранении резервных копий такого рода данных есть разбор про бэкапы в S3.

Источники: Пост разработчика в r/selfhosted, Релиз 1.14.1 на GitHub, Сайт проекта

Практический интерес здесь не в самом Plush, минималистичном динамическом языке на Rust, а в измеренном ответе на старый вопрос: сколько стоит стековая модель байткода. Вывод автора сформулирован жёстко: «вам, вероятно, не стоит писать стековые байткод-интерпретаторы в 2026 году» (перевод редакции). Для тех, кто пишет свои DSL, скриптовые движки или встраиваемые интерпретаторы, это готовый аргумент с цифрами и с честным списком того, что не ускорилось.

• Медианное ускорение 2,07 раза, максимальное 3,37; геометрическое среднее 1,94 раза, из них 1,55 дала сама регистровая модель без оптимизаций, ещё 25% добавили специализированные инструкции.
• Инструкция теперь 64-битное слово вместо enum на 24 байта; трёхадресная форма reg(a) = reg(b) + reg(c), до 64 000 локальных переменных, 76 опкодов.
• Замеры: MacBook Air M5 (10 ядер, arm64), rustc 1.96.0, 11 чередующихся запусков на тест, медиана; повторный прогон дал те же результаты.
• Против Lua 5.5.1: быстрее на 24% в fib и на 55% в binary_tree; сравнение с CPython 3.14.6 и CRuby 4.0.6 автор ограничивает оговорками о разной семантике и составе тестов.
• Тесты сборщика мусора почти не изменились: регистровая модель ускоряет диспетчеризацию, а не аллокацию.

Почему стековая машина медленнее

В стековой VM выражение a + b превращается в три инструкции: положить a, положить b, сложить. Каждая инструкция проходит через диспетчер: прочитать опкод, перейти на обработчик, сдвинуть указатель. В регистровой VM то же выражение записывается одной инструкцией с тремя операндами: куда положить и что сложить. Главный тезис статьи: в интерпретаторе самый большой рычаг производительности это число инструкций, которые нужно продиспетчеризовать, и регистровая модель сокращает его в разы. Автор цитирует это как основной вывод: «снова, в интерпретаторе главный рычаг это уменьшение числа инструкций» (перевод редакции).

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

Как устроен новый байткод

Старая инструкция была Rust-перечислением Insn размером 24 байта. Новая упакована в 64-битное слово: опкод и операнды-регистры. Для сравнения автор приводит Lua: там 32-битное слово с 8-битными полями, отсюда лимит в 255 регистров на фрейм и 200 именованных локальных переменных. У Plush поля шире, до 64 000 локальных переменных, ценой вдвое большего размера инструкции. Всего опкодов 76. Сверху добавлены оптимизации, каждая из которых убирает инструкции: слитые сравнение-и-переход, сдвиги и маски с непосредственными операндами, свёртка констант, устранение лишних пересылок. Инлайн-кэши вынесены в отдельные таблицы, чтобы не раздувать слово инструкции.

Замену enum на 64-битное слово автор описывала неделей раньше, тогда это дало 17% на старой стековой модели; нынешняя статья седьмая в серии о Plush.

Что показали замеры и где их границы

Методика описана подробно: MacBook Air M5, rustc 1.96.0, для каждого сравнения 11 чередующихся запусков старой и новой версии, берётся медиана, весь набор прогнан дважды. Сравнивались конкретные коммиты репозитория. Неоптимизированная регистровая VM дала 1,55 раза по геометрическому среднему, оптимизации добавили ещё 25%, итого 1,94; медиана по отдельным тестам 2,07, максимум 3,37. Тесты, упирающиеся в сборщик мусора, остались на месте: диспетчеризация там не узкое место.

Сравнение с другими языками автор сопровождает оговорками: CPython 3.14.6, CRuby 4.0.6 и Lua 5.5.1 имеют другую семантику, а набор тестов синтетический. Заявлены только два прямых результата против Lua: fib на 24% быстрее, binary_tree на 55%. Отдельная демонстрация: программный рендеринг уровня Quake в 800 на 600 в один поток, около 47 кадров в секунду, с живой кучей до 1 ГБ без заметных пауз GC по оценке автора.

Что из этого забрать в свой интерпретатор

• Если вы проектируете байткод с нуля, начинайте с регистровой модели: выигрыш от неё больше, чем от любой микрооптимизации диспетчера.
• Считайте инструкции, а не такты: слитые инструкции (сравнение плюс переход) и непосредственные операнды окупаются именно сокращением диспетчеризации.
• Не ждите ускорения там, где узкое место в аллокации: GC-тесты Plush не изменились.
• Готовые бинарники Plush есть для Linux и macOS (x86-64 и arm64) и через PowerShell-установщик для Windows x86-64; код под Apache-2.0, примеры под CC0, всё в репозитории.

Кому это не пригодится: тем, кто использует готовые рантаймы и не пишет свои. CPython, к слову, остаётся стековой машиной, и разница подходов хорошо видна на его фоне; о цене операций в самом Python мы недавно писали в связи с новой 3.15.0rc2. Другой свежий пример переписанного интерпретатора с подробным разбором каждой оптимизации: Wasmi 2.0, где тоже сменили промежуточное представление и получили 2,2 раза.

Источники: Pointers Gone Wild: Plush's New Register-Based Interpreter, Репозиторий Plush, Предыдущая статья серии: Replacing a Rust enum with a 64-bit word

Для тех, кто держит Go-сервисы в проде, это закрывает старую дыру в инструментах. Обычный goroutine-профиль показывает, сколько горутин сейчас заблокировано, но не отличает штатное ожидание от горутины, которая уже никогда не проснётся. Раньше такие утечки искали руками по стекам или ловили в тестах пакетом goleak; сам релиз Go 1.27 вышел 19 августа, а разбор механизма команда опубликовала только сейчас.

• Профиль goroutineleak входит в Go 1.27 и доступен через runtime/pprof и net/http/pprof (/debug/pprof/goroutineleak).
• Ловит блокировки на отправке и приёме в канал, блокирующем select, Mutex, RWMutex, WaitGroup и Cond.
• Не считает утечкой ожидание файлового и сетевого ввода-вывода, системных вызовов и самодельных спинлоков.
• По словам команды Go, метод точный и почти не даёт ложных срабатываний; накладные расходы на память названы пренебрежимо малыми, худший случай для одного цикла GC оценён как O(n²).
• В примере из блога профиль нашёл 116 зависших горутин на одной строке с отправкой в небуферизованный канал.

Что такое утечка горутины и почему её было трудно найти

Утечка горутины по определению из блога Go: горутина заблокирована на операции, условие для продолжения которой больше никогда не наступит. Классический пример: воркеры пишут результаты в небуферизованный канал, а читатель вышел из функции по первой ошибке. Каждый следующий воркер зависает на ch <- result навсегда, и чем дольше живёт процесс, тем больше таких горутин копится, растёт потребление памяти и нагрузка на сборщик мусора.

До Go 1.27 инструментов было три, и ни один не решал задачу для продакшена. goleak проверяет, не остались ли горутины после конкретного теста. Пакет synctest, появившийся в стандартной библиотеке Go 1.25, помогает тестировать конкурентный код с виртуальным временем. Обычный goroutine-профиль показывает заблокированные горутины, но не доказывает, что они не проснутся: всплеск нагрузки выглядит в нём так же, как утечка.

Как профиль отличает утечку от штатной блокировки

Идея, которую описывает автор поста Влад Сайок из команды Go, опирается на работу, которую сборщик мусора и так делает. GC вычисляет достижимость памяти от корней. Команда добавила к этому анализу горутины: горутина считается живой, если она не заблокирована на примитиве конкурентности или если примитив, на котором она ждёт, достижим из какой-нибудь живой горутины. Анализ стартует с незаблокированных горутин и распространяется по доступным им каналам и мьютексам. Всё, что осталось недостижимым после этого обхода, никто уже не разблокирует, значит, это утечка.

Команда Go утверждает, что механизм точный и «почти не даёт ложных срабатываний» (перевод редакции). Есть патологический случай: цепочка горутин, где каждая ждёт примитив, доступный только следующей. Для такой «гирлянды» проверка в худшем случае занимает O(n²) шагов за один цикл GC, поэтому в блоге советуют не включать сбор профиля постоянно, а снимать его периодически, например раз в четыре часа. Память на учёт горутин авторы называют пренебрежимо малой, а GC при этом продолжает работать параллельно с пользовательским кодом.

Разработка выросла из совместного исследования Орхусского университета, Университета Вашингтона в Сент-Луисе и Uber; академическую версию представили на конференции ASPLOS 2025.

Что видно в профиле на живом примере

В блоге разобран сервис, который раз в секунду запускает обработку десяти элементов и на пятом получает ошибку. Функция делает ранний return, оставшиеся воркеры зависают на отправке в канал. Программа подключает net/http/pprof и слушает localhost:6060; профиль снимают обычным способом:

Через несколько минут работы pprof показывает Total: 116 заблокированных горутин, и все они стоят на одной операции: отправке в канал ch. Исправление для примера тривиальное: сделать канал буферизованным на число воркеров, make(chan result, len(ws)), тогда воркеры допишут результаты и завершатся, даже если читатель ушёл.

Что профиль не ловит

• Ожидание файлового и сетевого ввода-вывода и системных вызовов утечкой не считается: горутина, зависшая на чтении из сокета, в профиль не попадёт.
• Самодельные спинлоки и другие пользовательские механизмы блокировки не входят в гарантированный набор.
• Горутина, которая по замыслу ждёт вечно на достижимом канале (например, фоновый слушатель), утечкой не считается, потому что канал достижим из живого кода.

Кому новый профиль ничего не даст: сервисам, где горутины блокируются в основном на сети, а не на каналах, и проектам, которые ещё не перешли на Go 1.27. Профиль работает только в рантайме этой версии; для старых сборок остаются goleak и ручной разбор стеков.

Как включить у себя

1. Обновить тулчейн до Go 1.27 (релиз от 19 августа 2026 года, заметки к выпуску) и пересобрать сервис.
2. Если net/http/pprof уже подключён, новый обработчик появится автоматически по пути /debug/pprof/goroutineleak; отдельной настройки не нужно.
3. Снимать профиль периодически, а не постоянно: команда Go предлагает интервал вроде четырёх часов из-за квадратичного худшего случая.
4. Смотреть в первую очередь на места с ранним return при ошибках, таймауты без select с контекстом и воркер-циклы, у которых читатель может уйти раньше писателей.

Схемы GC и полный пример кода лежат в посте команды Go. Из соседних новостей по инфраструктуре Go-сервисов на сайте есть разбор Kubernetes 1.37 и заметка о tailcat от Tailscale, написанном на Go.

Источники: Go Blog: Goroutine leak profiles, Go 1.27 Release Notes, Go Blog: Go 1.27 is released

Изображение на обложке: Go Authors, логотип Go

Автор публикации Ааши Патель из Cloudflare объясняет мотивацию просто: память и диски дорожают, а кэш-серверы Cloudflare хранят огромный объём текста, который origin-серверы отдают без сжатия. Прототип реализован внутри Pingora, прокси-фреймворка компании на Rust.

• На контрольном наборе коэффициент сжатия составил 2,834x при zstd уровня 3.
• Кодирование стоит 4,31 нс на байт (около 232 МБ/с), декодирование 1,56 нс на байт (около 641 МБ/с).
• HTML, JSON, CSS и JavaScript давали 67,3% запросов, но только 22,3% байтов; около 71% таких ответов приходили без Content-Encoding.
• Картинки, видео и шрифты занимали 63,3% байтов при 21,4% запросов; повторно сжимать их невыгодно.
• Порог 4 КиБ отсекает мелкие объекты и теряет около 1% потенциально сжимаемых байтов.

Почему сжимать пришлось именно в кэше

Казалось бы, текст в интернете и так сжат. Но по замерам Cloudflare около 71% текстовых ответов приходят от origin-серверов без заголовка Content-Encoding: сжатие для клиента делает уже edge-сервер, а на диск кэша объект ложится сырым. При этом HTML, JSON, CSS и JavaScript составляли 67,3% запросов и 22,3% байтов, а медиа и шрифты 21,4% запросов и 63,3% байтов. Пересжимать медиа бессмысленно: оно уже сжато своими кодеками. Значит, целевая доля кэша, где сжатие даёт эффект, это примерно пятая часть байтов.

Ключевая фраза публикации: «стоимость кодирования оплачивается один раз, когда объект попадает в кэш» (перевод редакции). Дальше объект читают многократно, а декодирование почти в три раза дешевле кодирования. Между дата-центрами через Tiered Cache объект едет уже сжатым, и это экономит ещё и междатацентровый трафик.

Критерии и цифры

В прототипе сжимались только ответы 200 OK с тремя условиями: заголовок Content-Encoding не задан, тип содержимого сжимаемый, известен Content-Length не меньше 4 КиБ. Range-запросы, уже сжатые ответы, тела неизвестной длины и бинарное содержимое проходят без изменений. Порог 4 КиБ исключил много мелких запросов, но потерял, по расчётам компании, около 1% потенциально сжимаемых байтов: «сжатие всего подходящего текста от 4 КиБ и выше дало почти всю измеренную экономию места».

Замеры производительности проводились на более чем миллионе запросов через 10 кэш-серверов. Коэффициент 2,834x получен на двух тестовых объектах размером около 195 и 272 КиБ, а не на всём кэше сервиса. Кодирование zstd уровня 3 стоило 4,31 нс на байт, декодирование 1,56 нс на байт. Дополнительная нагрузка на CPU при выбранных предположениях, по оценке Cloudflare, составила несколько процентов. Это замер вендора на его трафике; на другом профиле содержимого доля текста и коэффициент будут иными.

Как повторить у себя

Приём применим к любому кэширующему слою, где объекты хранятся на диске и читаются чаще, чем пишутся: nginx с proxy_cache, Varnish, самописные кэши на Pingora или Go. Порядок действий по мотивам публикации:

1. Измерить долю ответов без Content-Encoding и их суммарный объём: если origin уже сжимает всё, выигрыша не будет.
2. Ограничить кандидатов по типу содержимого и размеру; порог 4 КиБ у Cloudflare покрыл почти всю экономию.
3. Сжимать один раз при записи, хранить сжатым, декодировать при выдаче; прототип Cloudflare всегда декодирует объект, а отдачу сжатого представления клиенту напрямую компания называет будущей работой.
4. Считать CPU: при 232 МБ/с на кодирование одно ядро обслуживает ограниченный поток записи, и на серверах с высокой долей промахов кэша это может стать узким местом.

Для российских хостингов и собственных CDN аргумент тот же, что у Cloudflare: диски и память дорожают, а zstd есть в любом дистрибутиве и в библиотеках для всех основных языков. Cloudflare описывает внутренний прототип, а не продукт, поэтому ни включить, ни купить эту функцию нельзя; повторять придётся у себя.

Что осталось проверить

Компания перечисляет открытые вопросы: другие уровни zstd, другие типы объектов, range-запросы и предварительно сжатые ответы. Zstandard, напомним, разработан Янном Колле и открыт в 2016 году; в более раннем тестировании Cloudflare он сжимал на 42% быстрее Brotli и давал файлы на 11,3% меньше gzip при сопоставимой скорости. Редакция проверит, дойдёт ли прототип до боевой сети и появятся ли цифры по общей экономии.

Источник: Блог Cloudflare: Cache Transcoding

Изображение на обложке: Cloudflare

Wasmi написан на Rust и рассчитан на сценарии, где нужен именно интерпретатор: плагины в приложениях, встраиваемые устройства, песочницы, смарт-контракты. Релиз опубликован на GitHub и crates.io; работа над ним заняла восемь месяцев.

• Wasmi 2.0 примерно в 2,2 раза быстрее Wasmi 1.0 по геометрическому среднему; замеры вендора на Apple M2 Pro, AMD EPYC 7763 и Intel Xeon Platinum 8370C.
• Появились четыре режима dispatch; indirect-threaded на 10–15% медленнее direct-threaded, но экономит память под IR.
• Новое промежуточное представление с аккумуляторными регистрами ireg, freg32 и freg64 и 64-битными ячейками стека.
• Fuel metering стал стабильным и привязан к входному Wasm-коду; появился deterministic profile и новый CLI.
• Включение SIMD больше не замедляет обычный код: в 1.0 это стоило около 8%, в 2.0 разница в пределах шума.

Откуда взялись 2,2 раза

Автор подробно разбирает три источника ускорения. Первый: режимы диспетчеризации инструкций. В 1.0 был один switch-loop, теперь их четыре: direct-threaded, indirect-threaded, switch-loop и call-loop. Режим auto-dispatch включён по умолчанию и выбирает threaded-код там, где компилятор и платформа это позволяют. Indirect-threaded вариант примерно на 10–15% медленнее direct-threaded, зато требует меньше памяти на промежуточное представление, что важно для микроконтроллеров.

Второй источник: новое промежуточное представление. В 1.0 операнды адресовались смещениями в стеке; в 2.0 появились аккумуляторные регистры ireg, freg32 и freg64, через которые проходит большая часть значений. Ячейки стека стали всегда 64-битными, а SIMD-значения занимают две соседние ячейки, поэтому поддержка SIMD больше не стоит производительности обычного кода.

Третий: структура CodeMap, в которой хранятся скомпилированные функции. Она стала append-only с раздельными buckets, поэтому вызов внутренней функции на горячем пути не требует ни одного lookup и не берёт блокировок. Доступ к данным экземпляра модуля, по бенчмарку count/globals, улучшился примерно на 35%; таблицы Wasm уменьшились в 2–4 раза за счёт 32-битных ссылок.

Как измеряли и с кем сравнивали

Замеры сделаны на проекте wasmi-benchmarks, который можно запустить самостоятельно, на трёх машинах: Apple M2 Pro, AMD EPYC 7763 и Intel Xeon Platinum 8370C. Кроме Wasmi 1.0 в сравнении участвовали интерпретаторы Wasm3, WAMR в режиме fast-interpreter, Wasmtime Pulley и Stitch. Это замер вендора: набор тестов, машины и конфигурации выбирал сам проект, и автор оговаривает, что цифры зависят от нагрузки.

В посте есть поучительный эпизод про компилятор. Rust 1.92 включил оптимизацию DestinationPropagation, из-за чего CoreMark у интерпретатора Stitch упал с более чем 3000 до примерно 2200 баллов; после исправления результат вернулся выше 3000. Похожая проблема нашлась и в Wasmi: её устранение подняло CoreMark примерно с 2800 до более чем 4200 баллов, то есть примерно на 50%. Вывод для практики: производительность интерпретатора на Rust заметно зависит от версии компилятора, и после обновления toolchain бенчмарки стоит перепрогонять.

Что изменилось кроме скорости

• Fuel metering, то есть учёт «топлива» на выполнение, стал стабильным и считается по входному Wasm-коду, а не по внутренним инструкциям; это важно для смарт-контрактов и лимитов на плагины.
• Deterministic profile гарантирует одинаковый результат на разных платформах.
• Поддержка memory64 стала опциональной; отключение валидации через feature validate уменьшает бинарник примерно на 200–300 КБ.
• Обновлённый CLI и C-API.

Кому обновление ничего не даст: тем, кто запускает Wasm через JIT-рантаймы вроде Wasmtime или V8 на сервере и в браузере. Интерпретатор нужен там, где JIT запрещён (iOS, некоторые блокчейн-среды), где нет памяти под скомпилированный код или где важна предсказуемость времени запуска.

Как попробовать

Wasmi ставится как обычный crate из crates.io; для Rust-проекта достаточно обновить зависимость wasmi до версии 2.0 и прогнать тесты: автор предупреждает о смене внутреннего представления, а значит, поведение при ошибках и лимитах стоит перепроверить. Проект открыт, спонсируется Stellar Development Foundation с октября 2024 года.

В планах на Wasmi 3.0 названы оставшиеся части WebAssembly 3.0: function-references, exception-handling и gc. Сроков автор не называет.

Источники: Блог Wasmi Labs: Wasmi v2.0, Релиз v2.0.0 на GitHub

Изображение на обложке: Wasmi Labs

Zero — иммерсивный лендинг индийского стартапа Zero University, который предлагает альтернативу классическому университетскому пути. Сайт превращает скролл в шестиактную историю: традиционное образование, разбитое стекло, горящие деньги, уничтоженные сертификаты, тоннель из логотипа ZERO и, наконец, интерактивная карта города с офисами реальных компаний. Цель — не просто показать красивую картинку, а провести пользователя через аргумент: диплом перестаёт быть гарантией, а навыки открывают дорогу в индустрию.

Проект разрабатывала студия BUNQ LABS четыре месяца. Исходные ассеты занимали больше гигабайта: несжатые Blender-сцены, 8K-текстуры и запечённые анимации. Финальная сборка уместилась в 10 МБ и держит 60 FPS даже на бюджетном Android. Команда опубликовала технический разбор на Codrops, а мы выделили решения, которые можно перенести в свои WebGL-проекты.

• Первый жест как ворота: распознавание нуля — это простая проверка угла, округлости и замкнутости, а не нейросеть.
• Виртуальный скролл заменяет нативный: одно число управляет загрузкой, анимацией, шейдерами и текстом.
• Ассеты важнее рендера: DRACO, KTX2/ETC1S, атласы и собственный превьювер сжали гигабайты до мегабайтов.
• Текстурные загрузки — главный источник фризов; декодинг в воркере и очередь по requestIdleCallback решают проблему.
• Адаптивное качество по frame time позволяет не гадать о мощности устройства.
• Мобильная точность шейдеров: mediump на Adreno и Mali — это реальный 16-битный float, и его недостаточно для сложных эффектов.

Разбираем, как это устроено изнутри, и что из этого можно взять в свою работу.

Сюжет из шести этапов и пяти ворот

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

От обещания к свободе

Шесть этапов идут от иллюзии контролируемого пути к интерактивной карте, где пользователь сам выбирает, куда смотреть. Финальный экран — город с башней Zero University в центре. Можно приближать, панорамировать и открывать карточки ролей, сценариев и инструментов. Это не просто финал: после того как сайт вёл пользователя за руку, он отдаёт управление обратно.

Архитектура: один скролл управляет всем

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

Проект разбит на девять таких сегментов; загрузчик одновременно выполняет роль первых ворот. Каждый сегмент самодостаточен: у него свой жизненный цикл, свои объекты и своя утилизация. Это упростило поддержку и отладку. Переход к любому этапу воспроизводит жизненные циклы всех предыдущих сегментов, поэтому состояние всегда консистентно — как будто пользователь дошёл до этого места естественным скроллом.

Конвейер 3D-ассетов: как уместить 1 ГБ в 10 МБ

Большую часть четырёх месяцев ушла не на код, а на подготовку ассетов. Исходники пришли из Blender: несжатая геометрия, 8K-текстуры, запечённые анимации — всё вместе больше гигабайта. Первый месяц команда тратила на то, чтобы выбрать формат для каждого типа ресурсов.

DRACO и KTX2

Вся геометрия отправляется со сжатием DRACO, декодеры для которого хостятся локально в public/vendor/. Урок команда усвоила на собственном опыте: замедление на gstatic и unpkg привело к тому, что все сжатые ассеты перестали декодироваться, хотя сами файлы лежали на ихних серверах. Если декодер зависит от чужого CDN, весь пайплайн зависит от него.

Самый большой выигрыш дали текстуры. PNG может быть маленьким на диске, но в видеопамять он загружается распакованным. Текстура 2048² занимает около 16 МБ VRAM независимо от размера файла. Формат KTX2 со сжатием ETC1S остаётся сжатым на GPU, занимает меньше памяти и загружается быстрее.

Собственный превьювер компрессии

С KTX2 есть проблема: ETC1S — lossy, и локально его не посмотреть обычным просмотрщиком. Чтобы не гадать с настройками, команда сделала внутренний дашборд: сжатая и несжатая версия каждой картинки и видео рядом. Так можно было подобрать степень сжатия индивидуально — усилить там, где артефакты не заметны, сохранить качество для ключевых объектов и отключить мипмапы, где они не нужны. Инструмент простой, но редко встречается в WebGL-пайплайнах, хотя экономит огромное количество времени и памяти.

Атласы вместо дюжин картинок

Похожие текстуры собрали в общие атласы. Например, все текстуры рук уместили в один атлас 4×4, а каждая mesh сдвигала UV-координаты, чтобы взять свой кусок. Спрайты текста, сертификаты, бумажные обрывки, облака, монеты и осколки стекла тоже ушли в атласы. Больше 50 отдельных изображений превратились примерно в дюжину атласов, а большинство градиентных фонов заменили несколькими строками GLSL. Ранние сборки весили 35–40 МБ, финальная — меньше 10 МБ. При этом интерактивная карта мира вынесена в отдельную группу загрузки, чтобы не блокировать открытие сайта.

Текстурные загрузки: главный источник фризов

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

• Декодировать вне главного потока — через createImageBitmap(). Тогда во время рендера остаётся только загрузка в GPU.
• Загружать в GPU в простое — декодированные текстуры ставят в очередь и выгружаются по requestIdleCallback, пока есть запас времени.
• Разбивать большие атласы на плитки 256² и загружать по одной на кадр, чтобы не выбиваться из бюджета кадра.

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

Адаптивное качество по реальному frame time

Невозможно заранее знать, на каком устройстве откроется сайт. Рендерер поэтому постоянно измеряет время кадра по скользящему окну и динамически меняет уровень качества. Если рендеринг замедляется — понижается tier. Если производительность стабильно высокая — tier снова растёт. Задержка между переключениями не даёт постоянно метаться у границы.

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

Шейдеры под каждый эффект

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

Постпроцессинг из нескольких проходов

Кадр собирается из цепочки проходов: основная 3D-сцена, процедурный фон, преломление стекла, иней и след от жеста, глубина резкости, foreground с зернистостью и тональной картой, отложенный текст, и в конце — разбитое стекло. Стеклянный, текстовый и шейдер разбития инициализируются лениво и прогреваются в простое, чтобы не попадать на критический путь загрузчика.

Иней из нарисованного нуля

Эффект инея строится на ping-pong-буфере из четырёх проходов: горизонталь, вертикаль и две диагонали. Каждый проход распространяет нарисованный штрих, захватывая самые яркие соседние пиксели и создавая восьмиугольный паттерн роста. Яркость текстуры льда модулирует шаг распространения, край получается кристаллическим. После замыкания контура центр масс штриха становится точкой отсчёта для радиального таяния.

Освещение без источников света

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

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

Горящие деньги

Эффект сгорания использует noise-driven distance field. Фронт горения проходит по купюре, слегка опережая точку дискарда. Перед ним появляется тонкий HDR-ободок углей, затем обугленная поверхность. FBM — самая дорогая часть шейдера, поэтому фрагменты отсекаются как можно раньше, если они ещё не достигли порога горения.

Рвущиеся сертификаты

Каждая вершина хранит индекс полосы, к которой принадлежит фрагмент диплома. Фронт разрыва движется слева направо, и каждая полоса отделяется и падает независимо со своим вращением. Нормали для освещения строятся аналитически из той же волновой функции, которая анимирует меш, поэтому normal map не нужен.

Тоннель ZERO

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

Текст, который приходит в фокус

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

Точность на мобильных

Одна из самых неприятных находок возникла на реальных мобильных GPU. Несколько шейдеров пришлось явно перевести на highp float, потому что на Adreno и Mali mediump — это настоящий 16-битный float. На десктопе ошибок не было, а на телефоне полосы диплома двигались одинаково, а эффект горения покрывался бэндами. Вывод: тестировать на реальных мобильных устройствах нужно с первых дней, а не перед релизом.

Дизайн взаимодействий

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

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

Финальная награда — интерактивный мир

Последняя последовательность запуска выносит пользователя в открытое небо. Облака расступаются, открывая город с башней Zero University в центре, над которой появляется ореол — финальные ворота. Камера приземляется в интерактивную карту, где можно панорамировать, зумить и открывать карточки с ролями, сценариями и инструментами. Плашка Join Beta превращается в форму waitlist. После того как сайт вёл пользователя через историю, он отдаёт ему контроль — и просит остаться.

FAQ

Выводы

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

ИИ генерировала первые версии кода и прототип, который выиграл нам проект, за 48 часов. Но полировка — сотни мелких решений, тестирование на реальных устройствах и инженерная интуиция — осталась за людьми.

Источник: технический разбор команды BUNQ LABS на Codrops.
Попробуйте открыть zero.university на десктопе и на бюджетном смартфоне — и сравните, где заметнее компромиссы качества.

В статье разбираем, почему React.memo сравнивает пропсы по ссылке, как inline-объекты и inline-функции обнуляют эту оптимизацию, и какие два простых приёма действительно возвращают производительность.

React.memo пропускает рендер только тогда, когда все пропсы равны по Object.is. Для объектов и функций это проверка по ссылке.

Inline-объекты и inline-колбэки в JSX создают новую ссылку на каждый рендер родителя, поэтому memo видит «новые» пропсы и снова рисует дочерний компонент.

В эксперименте со 200 memoизированными строками это дало 243,9 мс на один keystroke; после стабилизации ссылок — 6 мс.

Сначала выносите статические объекты за пределы компонента, а useCallback применяйте только там, где колбэк действительно пересекается с memoизированным потомком.

Оптимизировать всё подряд не нужно: измеряйте в Profiler, а не добавляйте хуки «на всякий случай».

Как React решает, рендерить компонент заново или нет

Когда родитель перерисовывается, React не делает послаблений дочерним элементам только потому, что они обёрнуты в React.memo. Он сравнивает новые пропсы со старыми. Если каждый проп проходит проверку Object.is, React может «отказаться» от рендера — bailout. Если хотя бы один проп не равен, компонент рисуется заново.

Для примитивов Object.is работает очевидно: 1 === 1 и 'hello' === 'hello'. А вот для объектов и функций сравнение идёт по ссылке.

Два объекта с одинаковым содержимым — это разные объекты в памяти. То же самое с функциями. Поэтому, когда вы пишете style=\{\{ padding: 16 \}\}, React получает новую ссылку на каждом рендере и считает проп изменившимся.

Почему inline-пропсы — это не микрооптимизация, а поломка контракта

Сам по себе объект в JSX не вреден. Если компонент дешёвый, редко перерисовывается и не обёрнут в memo, inline-пропсы почти не влияют на скорость. Проблема появляется, когда три условия накладываются друг на друга:

• родитель перерисовывается часто — поиск, скролл, фильтры, live-данные;
• дочерний компонент или поддерево достаточно тяжёлые, чтобы лишний рендер был заметен;
• вы уже добавили React.memo и ожидаете, что React будет пропускать работу.

В такой ситуации нестабильные ссылки не просто добавляют накладных расходов — они полностью отменяют ту оптимизацию, ради которой вы взяли React.memo. UI продолжает работать, но лагает ввод, тормозят списки, а в Profiler видно, что дерево горит жёлтым при каждом чихе.

Классический опасный пример

Представьте список товаров из 200 строк. Каждая строка обёрнута в memo, но в месте вызова передаются inline-пропсы:

Здесь style и onAddToCart создаются заново при каждом рендере ProductList. Для memo это сигнал, что у каждой строки изменились пропсы, и все 200 компонентов рисуются снова.

Эксперимент: от 243,9 мс до 6 мс на один keystroke

Автор оригинальной статьи собрал контрольный пример: поисковый интерфейс со 200 memoизированными строками. Все строки получают одинаковые логические значения, но новые ссылки на объекты и функции. Результат после шести введённых символов: каждая видимая строка отрендерилась 14 раз.

В React DevTools Profiler один keystroke дал коммит длительностью 243,9 мс, в котором подсветились все 200 волокон строк. Инструмент @welldone-software/why-did-you-render прямо указал причину: props.style — «different objects that are equal by value», props.onAddToCart — «different functions with the same name».

Почему 14 рендеров?
Каждый ввод в поиск меняет searchTerm, родитель перерисовывается, и inline-пропсы дают строкам новые ссылки. Счётчик рендеров растёт на каждый keystroke, даже если отфильтрованные товары не изменились.

Как починить: два приёма вместо дюжины хуков

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

1. Статические объекты — за пределы компонента

Если объект не зависит от пропсов и состояния, создайте его один раз на уровне модуля. Это дешевле любого хука и не требует dependency-массива.

2. Динамические колбэки — useCallback

Если функция передаётся в memoизированный компонент и не должна меняться без причины, оберните её в useCallback со стабильным массивом зависимостей.

После этих двух изменений в эксперименте время рендера упало с 243,9 мс до 6 мс, счётчики строк застыли на 2, а Why Did You Render замолчал — avoidable re-renders исчезли.

Когда не нужно ничего стабилизировать

Главная ошибка — оборачивать в useCallback каждую функцию и выносить каждый объект за компонент. React сам по себе быстрый, а мемоизация — это контракт, а не стиль кодирования.

• Компонент дёшев и редко перерисовывается — не тратьте когнитивный бюджет команды.
• Дочерний элемент не обёрнут в React.memo — тогда стабильные ссылки ничего не экономят.
• Значение зависит от часто меняющегося состояния — useCallback с нестабильным массивом зависимостей всё равно будет пересоздаваться.
• Вы ещё не замерили в Profiler — оптимизация без измерений почти всегда лишняя работа.

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

Часто задаваемые вопросы

Выводы

Inline-объекты и inline-колбэки в JSX — не антипаттерн сами по себе. Они становятся проблемой только на границе memoизации, где React ожидает стабильные ссылки. Как только вы понимаете это правило, многие «таинственные» лишние рендеры перестают быть таинственными.

1. Профилируйте до оптимизации, а не после.
2. Вынесите статические объекты за компонент — это самый дешёвый способ стабилизации.
3. Применяйте useCallback только для колбэков, которые уходят в memoизированные потомки.
4. Проверяйте себя через React DevTools Profiler и Why Did You Render.
5. Не забывайте про React Compiler, но не полагайтесь на него как на волшебную палочку.

Мемоизация — это контракт. Если потомок рассчитывает на стабильные ссылки, родитель должен их обеспечить. Нарушение этого контракта стоит намного дороже, чем отсутствие мемоизации вовсе.

Источник: LogRocket — The React pattern everyone uses that kills performance.

Проверьте свой текущий проект: откройте React DevTools Profiler, введите что-нибудь в поиск и посмотрите, сколько компонентов подсветится жёлтым только из-за новой ссылки в пропсах.

Речь пойдёт не о теории reconcile-алгоритма, а о практике: что проверять первым делом, как изолировать проблему через Suspense, куда смотреть в production-логах и как писать тесты, которые ловят регрессии до попадания к пользователям.

Что такое hydration mismatch

Гидратация — это процесс, при котором React берёт серверный HTML и навешивает на него обработчики событий, после чего страница становится интерактивной. React ожидает, что дерево, которое он отрендерил на клиенте, точно совпадёт с тем, что пришло с сервера. Если строки, атрибуты или структура различаются, возникает hydration mismatch.

В development-режиме React покажет предупреждение, текст расхождения и стек компонента. В production всё сводится к коротким кодам вроде #418 или #425. Без телеметрии вы не узнаете, на каком маршруте, в каком компоненте и из-за каких данных произошёл сбой.

Почему это больно именно в RSC

В классическом SSR обычно один серверный рендер и один клиентский проход гидратации. App Router добавляет Server Components, Client Components, потоковую передачу, Suspense-границы, динамические данные маршрута и RSC payload, который едет рядом с HTML.

Когда несовпадение происходит вне Suspense-границы, React может отбросить весь серверный HTML и перерендерить дерево на клиенте. Приложение заплатило цену серверного рендера, а пользователь не получил ни производительности, ни преимуществ стриминга. Это не просто предупреждение в консоли, а реальная потеря производительности.

Ключевые выводы

• Hydration mismatch в production без телеметрии почти невозможно локализовать: нужна инструментация на клиенте.
• Основные причины: browser-only API, дата/время/локаль, состояние авторизации, невалидный HTML, расширения браузера, CSS-in-JS.
• Граница 'use client' — это не только маркер сборки, но и граница гидратации: серверный рендер должен быть детерминирован.
• Suspense-границы помогают изолировать сбой и не давать ему сломать всё дерево.
• Проверяйте hydration только на production-сборке: next dev ведёт себя иначе.
• Добавьте Playwright-smoke-тесты на критичные маршруты, чтобы ловить регрессии в CI.

Самые частые причины

Перед тем как копать RSC payload или сравнивать HTML, стоит проверить шесть типовых сценариев. Они покрывают подавляющее большинство production-инцидентов.

• Browser-only API во время рендера: window, document, localStorage, navigator — сервер не знает об этих значениях.
• Дата, время и локаль: Date, Intl.DateTimeFormat, относительное время — сервер обычно в UTC, пользователь в своей зоне.
• Состояние авторизации: сервер рендерит выклогнутый UI, клиент сразу видит авторизованного пользователя.
• Невалидный HTML: браузер чинит DOM до гидратации, а React сравнивает с исходным деревом.
• Расширения и middleware: браузерные плагины и edge-переписывания меняют HTML.
• CSS-in-JS и порядок классов: styled-components и Emotion могут генерировать разные имена классов при стриминге.

Browser-only API и сторонние провайдеры

Самая частая причина — не ваш собственный код, а сторонний провайдер, который читает localStorage, window или navigator при инициализации. Под это попадают аналитика, фичер-флаги, A/B-тесты, session replay и персонализация.

Проблемный вариант: провайдер читает localStorage прямо при рендере.

Исправление: серверные флаги передаются в Client Component, а локальные оверрайды применяются после гидратации.

Принцип: серверный и первый клиентский рендер должны получить одинаковый результат. Браузерные оверрайды включаются в useEffect после монтирования.

Дата, время и локаль

Сервер часто работает в UTC, а пользователь — в своей зоне. Date.toLocaleString(), Intl.DateTimeFormat и функции вроде formatDistanceToNow() дают разные строки в зависимости от часового пояса и времени между рендером и гидратацией.

Проблемный вариант: относительное время считается на сервере.

Исправление: сервер отдаёт стабильную абсолютную дату, клиент заменяет её на относительную после монтирования.

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

Состояние авторизации

Типичный сценарий: сервер рендерит UI для неавторизованного пользователя, потому что маршрут статический или не читает куки, а клиент сразу видит залогиненного пользователя. При каждой загрузке страница перерендеривается.

Решение — читать куки на сервере через cookies() из next/headers.

С cookies() маршрут становится динамическим — это обычно правильный компромисс для UI, зависящего от авторизации. Начиная с Next.js 15, cookies() асинхронный и требует await. В Next.js 16 синхронный доступ к request-time API полностью уходит.

Невалидный HTML

Браузер молча чинит невалидную вёрстку. React же гидратирует не исходную строку, а DOM, который построил браузер. Классический пример — внутри

Браузер превратит это в примерно такую структуру:

Если HTML приходит из CMS или редактора, валидируйте и нормализуйте его на сервере. Для собственных компонентов следите за предупреждениями validateDOMNesting в DevTools.

Расширения браузера и middleware

Менеджеры паролей, переводчики, грамматические плагины и другие расширения могут вставлять или переупорядочивать узлы до гидратации. Edge middleware и CDN-трансформации тоже могут переписывать HTML в пути.

Если несовпадение затрагивает только <html> или <body>, сначала подозревайте расширения. React 19 стал терпимее к инъекциям в head/body, но на старых версиях такие ошибки особенно шумные.

suppressHydrationWarning на корневых элементах — документированный escape hatch, но он работает только на один уровень вглубь и не должен использоваться для сокрытия неизвестных расхождений в продуктовом UI.

CSS-in-JS и порядок классов

В проектах со styled-components или Emotion имена классов могут зависеть от порядка рендера. Стриминг и Suspense меняют этот порядок, поэтому нужен registry с useServerInsertedHTML.

Production workflow для отладки

Не начинайте с diff-а огромных HTML-документов. Работайте по порядку, сужая область поиска.

1. Настройте клиентскую телеметрию: перехватывайте console.error и отправляйте hydration-ошибки на свой endpoint.
2. Воспроизводите баг на production-сборке: next build && next start, а не next dev.
3. Используйте Suspense-границы, чтобы изолировать проблемный участок и понять, в каком поддереве ошибка.
4. Сравнивайте серверный HTML (curl) и клиентский DOM после гидратации.
5. Когда найдёте расходящийся элемент, проверьте: browser-only API, дата/время, авторизацию, HTML-вложенность, расширения, стили.

Инструментация: instrumentation-client.ts

Файл instrumentation-client.ts в Next.js запускается после загрузки документа, но до гидратации React. Это удобная точка для лёгкой клиентской телеметрии.

Если используете LogRocket, Sentry или другой инструмент, прикрепите тот же payload к текущей сессии — тогда можно будет увидеть, как выглядела страница в момент сбоя.

Изоляция через Suspense

Suspense-границы не только показывают fallback при загрузке. Если hydration mismatch случается внутри границы, React может ограничить восстановление этим поддеревом, а не переключать весь root на клиентский рендер.

Оберните поочерёдно основные секции. Если страничная ошибка исчезает после оборачивания конкретной секции, баг почти наверняка внутри неё.

Сравнение HTML и DOM

Получите серверный HTML через curl с нужными куками:

В Chrome DevTools после загрузки страницы скопируйте живой DOM:

Сохраните результат в /tmp/client-render.html и сравните:

Этот метод хорошо ловит HTML-слой, но может пропустить расхождения на уровне reconciler-а и RSC payload. Если raw HTML совпадает, проверяйте Client Components и браузерное состояние.

Профилактика

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

1. Server Component должен быть детерминированным: одни и те же входные данные дают одни и те же выходные HTML и RSC payload.
2. Все browser-only API, куки, заголовки, локаль и время должны оставаться за границей 'use client' или читаться через request-time API на сервере.
3. Для клиентского UI сначала рендерите стабильный baseline, а улучшения добавляйте в useEffect после гидратации.
4. Валидируйте HTML из внешних источников до того, как React его увидит.
5. Тестируйте hydration на production-сборке в CI.

Пример: стабильный baseline + клиентское улучшение

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

Smoke-тесты в CI

Ручное тестирование пропустит регрессии. Добавьте Playwright-тест на критичные маршруты.

Запускайте такой тест только против production-сборки, никогда против next dev. Сделайте его обязательной проверкой для маршрутов, где hydration failure критичен: продуктовые страницы, дашборды, чекаут, личный кабинет.

FAQ

Выводы

Hydration mismatch — не придирка React, а реальный баг производительности и корректности. Каждое несовпадение означает, что приложение могло отбросить серверный HTML, за который уже заплатило ресурсами.

В приложениях с React Server Components, где цель — меньше клиентского JavaScript и более ранний стриминг полезного UI, hydration failures тихо отменяют эти преимущества. Поэтому важно держать браузерную логику за границей 'use client', рендерить стабильные серверные baseline и проверять гидратацию в production-условиях до того, как ошибку найдут пользователи.

Hydration errors should be fixed, not ignored — официальная позиция React.

Источник: LogRocket Blog — How to fix RSC hydration mismatches in Next.js.

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

Речь пойдёт не о сравнении синтаксиса в вакууме, а о бэкенд-сервисах: API, шлюзах, обработке событий, парсинге данных и всём, что работает под нагрузкой. В статье — авторский взгляд на материал блога инженера Pooya Golchian, дополненный российским контекстом и поправками на реальное состояние экосистем.

Go остаётся стандартным выбором для большинства микросервисов: быстрая компиляция, простота найма, огромная экосистема.

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

Zig подходит для узких, критичных к производительности участков и для интеграции с существующим C-кодом, но экосистема пока незрелая.

В больших системах работает гибридный подход: Go для скорости разработки, Rust/Zig для горячих путей.

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

Почему именно эти три языка

В 2026 году для нового backend-проекта по-прежнему можно взять Java, C#, Python или Node.js. Но если речь заходит о высоких нагрузках, низкой задержке и контроле над ресурсами, внимание смещается к трём игрокам.

• Rust — язык с владением и заимствованием, дающий безопасность памяти без сборщика мусора.
• Go — язык с простой моделью конкурентности, статической линковкой и минималистичной философией.
• Zig — язык в духе C, но с современной системой сборки, comptime и явным управлением памятью.

Все трое компилируются в нативный код, дают один бинарник на выходе и не требуют виртуальной машины. Именно это отличает их от Java, C# и Python на старте.

Rust: максимум производительности, максимум сложности

Сильные стороны

• Безопасность памяти на этапе компиляции — нет use-after-free, data races и большинства утечек.
• Нулевая стоимость абстракций: высокоуровневый код часто компилируется так же эффективно, как ручной C.
• Мощная модель конкурентности поверх tokio или async-std.
• Зрелая экосистема: axum, actix-web, serde, sqlx.

Слабые стороны

• Крутая кривая обучения: borrow checker требует перестройки мышления.
• Долгая компиляция: полная пересборка крупного проекта занимает десятки секунд и минуты.
• Меньше кадров на рынке, чем у Go или Java.
• Итерации медленнее: каждая ошибка компилятора — это время на переделку.

Когда выбирать Rust

Rust логичен, если вы строите инфраструктуру — прокси, базы данных, очереди, edge-сервисы — или если профилирование показывает, что горячий путь съедает CPU и память. Примеры из продакшена: Cloudflare использует Rust на edge, Discord переписал на Rust часть read-path сервисов.

Go: скорость разработки в масштабе

Сильные стороны

• Компиляция за секунды и один статический бинарник для деплоя.
• Встроенные горутины и каналы — простая, но мощная конкурентность.
• Отличная стандартная библиотека и быстрое тестирование через go test.
• Большая база инженеров и проверенные практики в крупных компаниях.

Слабые стороны

• Сборщик мусора может давать всплески задержек, хотя в последних версиях паузы сокращаются.
• Меньше контроля над расположением памяти и размером структур.
• Пиковая пропускная способность ниже, чем у Rust и Zig, на CPU-bound задачах.
• Система типов и обработка ошибок минималистичны — кому-то этого достаточно, кому-то не хватает.

Когда выбирать Go

Go — выбор по умолчанию для команд из 5–50 человек, которым нужно быстро запускать CRUD-сервисы, API-шлюзы и data pipeline. Uber, Google и Яндекс активно используют Go в микросервисах. Если главная метрика — time to market, а не последний процент производительности, Go обычно выигрывает.

Zig: новый игрок с C-душой

Сильные стороны

• Производительность уровня C с более современным синтаксисом и системой сборки.
• comptime — выполнение кода на этапе компиляции для генерации оптимизированных структур.
• Прямое взаимодействие с C без FFI-слоёв.
• Маленькие быстрые бинарники и явное управление памятью.

Слабые стороны

• Экосистема backend-фреймворков и библиотек пока существенно меньше, чем у Rust и Go.
• Сообщество и количество инженеров на рынке ограничены.
• Ручное управление памятью перекладывает ответственность на разработчика.
• Некоторые части языка и стандартной библиотеки всё ещё эволюционируют.

Когда выбирать Zig

Zig хорош, когда нужна C-производительность, но с более удобным инструментарием, или когда приходится интегрироваться с существующим C-кодом. Пример из продакшена: финансовая база данных TigerBeetle написана на Zig. Для универсального backend в 2026 году Zig ещё рано называть mainstream-выбором.

Сравнение в цифрах

Ниже — иллюстративные цифры из оригинального материала, полученные на AWS c7g.2xlarge (Graviton3). Относитесь к ним как к точке отсчёта, а не как к гарантии для вашего сервиса: в реальности большее значение имеют I/O, запросы к базе данных и сетевая задержка.

Бенчмарки:
HTTP throughput — Rust 892K req/s, Go 734K req/s, Zig 812K req/s.
JSON-сериализация — Rust 1,2M/s, Go 890K/s, Zig 1,1M/s.
Память на 10K соединений — Rust 45MB, Go 78MB, Zig 38MB.
Размер бинарника — Rust 8,2MB, Go 12,4MB, Zig 6,1MB.
Время компиляции с нуля — Rust 42s, Go 3,2s, Zig 18s.
P99 latency — Rust 2,1ms, Go 3,8ms, Zig 2,4ms.

Реальные истории миграции

Discord: Go → Rust

Discord переводил read-path сервисы с Go на Rust из-за пауз сборщика мусора, которые проявлялись в хвостовых задержках. По данным компании, throughput вырос в несколько раз, а tail latency снизилась. Ключевой вывод: мигрировать стоит только горячие пути, а не весь сервис целиком.

Uber: Python → Go

Uber мигрировал часть микросервисов с Python на Go, чтобы обойти ограничения GIL и упростить масштабирование. Переход занял годы, но зато проходил постепенно: Go-совместимость и простота языка позволяли быстро обучать команду.

TigerBeetle: C++ → Zig

TigerBeetle — финансовая база данных, ориентированная на корректность и производительность. Команда выбрала Zig, отказавшись от сложности C++ и сборщика мусора. comptime позволил генерировать специализированные структуры данных под задачу.

Гибридная архитектура

На практике редко выбирают один язык на весь проект. Гораздо чаще используют гибрид:

• API Gateway и CRUD — Go: быстро писать, просто деплоить, легко искать людей.
• Горячие пути — Rust: низкая задержка и контроль над памятью.
• Специализированные компоненты — Zig: парсинг бинарных форматов, криптография, интеграция с C.

Такая схема позволяет получить скорость разработки в большинстве сервисов и производительность там, где она действительно нужна. Главное — разделять систему по чётким границам и не превращать проект в зоопарк ради самого зоопарка.

Что выбрать в 2026 году

Выбор зависит от приоритетов команды и задачи:

• Нужна скорость разработки и лёгкий найм — Go.
• Нужна максимальная производительность и безопасность памяти — Rust.
• Нужна C-производительность с современной сборкой и интеграцией с legacy на C — Zig.
• Команда маленькая и сроки горят — начинайте с Go, профилируйте, мигрируйте горячие пути при необходимости.
• Строите базу данных, прокси или edge — Rust становится очень сильным кандидатом.

FAQ

Выводы

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

Нет универсального лучшего языка — есть лучший язык для конкретной команды, задачи и бюджета на обучение.

Источник: Pooya Golchian — Rust vs Go vs Zig: High-Performance Backend Services in 2026.

В статье loops определяются просто: агент повторяет циклы работы до тех пор, пока не выполнится условие остановки. Разница между типами циклов Anthropic выводит из четырёх вещей: что запускает цикл, что его останавливает, какая примитивная команда Claude Code используется и для каких задач это подходит.

Что такое loop в Claude Code

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

Для российских разработчиков, которые часто запускают Claude Code на удалённом сервере по SSH, это особенно удобно: можно настроить цикл, который работает, пока вы спите, и присылает отчёт утром в Telegram или Slack. Главное — не забыть про лимиты токенов, потому что неограниченный цикл способен съесть месячный бюджет за одну ночь.

Claude Code предлагает четыре типа loops: turn-based, goal-based, time-based и proactive.

Каждый цикл характеризуется триггером, условием остановки и подходящей командой: ручной prompt, /goal, /loop//schedule или автоматическая рутина.

Качество результата зависит от проверочных навыков (SKILL.md) и чистоты кодовой базы, а не только от самого цикла.

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

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

Четыре типа циклов

Turn-based: ручной цикл

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

По мнению команды Claude Code, здесь ключевой рычаг — не более длинный prompt, а проверочный SKILL.md. Если вы обычно вручную открываете dev-сервер, кликаете по новой кнопке, проверяете консоль и запускаете Lighthouse, эти шаги стоит записать в skill. Чем более количественные проверки вы зададите, тем чаще Claude сможет сам понять, что задача выполнена.

Goal-based: цикл с целью через /goal

Когда задача сложная и одного оборота недостаточно, помогает команда /goal. Вы явно описываете критерий успеха и максимальное число попыток. Каждый раз, когда Claude хочет остановиться, оценочная модель проверяет условие: если цель не достигнута — агент возвращается к работе.

Чем более детерминирован критерий, тем лучше. «Сделай хорошо» — плохая цель. «Добейся Lighthouse Performance ≥ 90, не более 5 попыток» — хорошая. То же самое работает для числа пройденных тестов, покрытия кода или отсутствия ошибок линтера.

Time-based: цикл по расписанию /loop и /schedule

Некоторые задачи не требуют вашего присутствия: утренняя сводка по Slack, проверка PR на ревью, мониторинг CI. Для таких случаев есть /loop: команда повторяет prompt через заданный интервал, пока вы её не отмените или пока работа не закончится.

/loop работает на вашем компьютере, поэтому при выключении терминала цикл остановится. Если нужно, чтобы агент работал в облаке даже с закрытым ноутбуком, используется /schedule — эта команда создаёт рутину, которая запускается по расписанию на серверах Anthropic (research preview).

Proactive: проактивные рутины

Проактивные циклы объединяют всё вышеперечисленное: /schedule для запуска по событию или расписанию, /goal для критерия готовности, skills для проверки, dynamic workflows для параллельной обработки и auto mode, чтобы цикл не останавливался на каждом разрешении.

Типичный сценарий: обработка входящих баг-репортов. Рутина каждый час проверяет канал обратной связи, триажирует каждую заявку, чинит баг, прогоняет тесты и отвечает пользователю. Для сложных случаев можно параллельно исследовать несколько решений в разных worktrees и поручить «судейскому» агенту выбрать лучшее.

Как не потерять качество кода

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

• Чистая кодовая база. Claude копирует паттерны, которые уже есть в проекте. Если в репозитории хаос, агент будет его множить.
• Проверочные skills. SKILL.md должен содержать конкретные шаги, инструменты и критерии, по которым Claude сам оценивает результат.
• Актуальная документация. Фреймворки и библиотеки меняются, и агенту нужны свежие best practices.
• Второй агент для ревью. Проверяющий со свежим контекстом менее предвзят, чем основной агент. Можно использовать встроенный /code-review или Code Review for GitHub.

Важный совет: когда отдельный результат не дотягивает до стандарта, не исправляйте только конкретный случай — закодируйте правило в skill или CLAUDE.md, чтобы все будущие итерации работали лучше.

Как не сжечь бюджет на токенах

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

• Выбирайте подходящий примитив и модель: мелкие задачи не нуждаются в сложных оркестрациях.
• Формулируйте чёткие критерии завершения: конкретнее цель — меньше лишних итераций.
• Запускайте пилот на малой выборке перед массовым прогоном.
• Используйте скрипты для детерминированной работы: запуск готового скрипта дешевле, чем рассуждение модели.
• Не запускайте рутины чаще, чем меняется объект мониторинга.
• Регулярно смотрите /usage, /goal без аргументов и /workflows, чтобы видеть, куда уходят токены.

С чего начать

Авторы гайда предлагают не начинать с proactive-рутин, а посмотреть на свою повседневную работу и найти одно место, где вы сами являетесь узким звеном. Задайте три вопроса:

• Могу ли я описать проверку результата так, чтобы Claude мог сам её выполнить?
• Достаточно ли чётко я понимаю, что значит «готово»?
• Эта работа приходит по расписанию или в ответ на внешние события?

Если ответ на первый вопрос «да» — начните с turn-based цикла и проверочного skill. Если на второй — попробуйте /goal. Если на третий — /loop или /schedule. Запустите цикл, понаблюдайте, где он застревает или перегибает палку, и дорабатывайте harness, а не только prompt.

Сводка: какой цикл когда использовать

FAQ

Выводы

Гайд Anthropic — не просто описание четырёх команд. Это попытка дать разработчикам общий язык для обсуждения того, как ИИ-агенты переходят из разряда «помощников в чате» в разряд «автономных рабочих процессов». Turn-based, goal-based, time-based и proactive loops — это не конкуренты, а ступени одной эволюции: от ручного управления каждым шагом к проектированию систем, которые управляют сами собой.

Главная метафора, которую стоит уносить с собой: ваш вклад перестаёт измеряться качеством очередного prompt, а начинает измеряться качеством harness — системы проверок, остановок и триггеров. Если вы ещё не пробовали /goal или /loop, начните с одной повторяющейся задачи на этой неделе. Скорее всего, вы удивитесь, как много ручной работы можно отдать циклу.

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

Источники:

• Getting started with loops — официальный гайд Anthropic
• @ClaudeDevs on X
• Loop Engineering — Addy Osmani

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

Selectel: серверные платформы с полным циклом разработки

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

Поэтому в Selectel разработка начинается не со сборки серверов под конкретный проект. Команда развивает собственную серверную платформу, которая становится основой для последующих решений: от серверов общего назначения до GPU-систем для задач искусственного интеллекта, высокопроизводительных вычислений и обработки данных.

От эксплуатации к разработке

Требования к новой платформе формируются на основе собственного опыта работы с железом. С 2008 года Selectel накопил большую экспертизу в эксплуатации серверов различных поколений и конфигураций и использует этот опыт при определении требований к новым платформам.

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

Собственная аппаратная архитектура

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

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

Платформа Selectel поддерживает процессоры Intel Xeon 6, память DDR5, интерфейс PCI Express Gen5, модуль доверенной платформы TPM 2.0, а также предусматривает установку современных сетевых адаптеров и ускорителей вычислений.

Для задач искусственного интеллекта и высокопроизводительных вычислений используются серверы форм-фактора 8U с несколькими GPU, тогда как платформы 1U и 2U применяются для виртуализации, корпоративной инфраструктуры, баз данных, облачных сервисов и других сценариев эксплуатации.

BIOS, BMC и управление платформой

Разработка аппаратной части ведется одновременно с развитием встроенного программного обеспечения.

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

Для управления оборудованием Selectel использует собственный интерфейс Selectel Management Interface (SMI), разработанный на базе OpenBMC.

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

Программный уровень платформы

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

От платформы к решению под конкретную задачу

После того как серверная платформа разработана и проверена, она становится основой для инженерной работы с конкретными проектами.

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

Для CPU-интенсивных задач приоритетом становятся вычислительные ресурсы процессора и организация многопоточной нагрузки. Для систем хранения — производительность дисковой подсистемы и сетевых интерфейсов. При работе с GPU оцениваются баланс между центральным и графическими процессорами, пропускная способность PCI Express, требования к питанию и охлаждению. При необходимости проектируются конфигурации под storage- и backup-системы.

На этапе проектирования также анализируются особенности будущей инфраструктуры: тип рабочей нагрузки (CPU-bound, memory-bound, IO-bound или GPU-bound), требования к доступности и SLA, особенности электропитания, тепловыделения, размещения оборудования в стойке и существующей сетевой инфраструктуры.

Проверка гипотез до закупки оборудования

Для проверки используется Proof of Concept (PoC) — инженеры воспроизводят профиль нагрузки клиента на тестовом стенде, сочетая синтетические и прикладные тесты. Это помогает заранее оценить производительность, задержки, температурные режимы и запас вычислительных ресурсов.

Во время таких испытаний анализируются параметры, которые невозможно оценить по спецификации оборудования: NUMA-топология, баланс между CPU и GPU, производительность подсистемы хранения, влияние вариантов конфигурации памяти, пропускная способность сетевых интерфейсов и шин PCI Express.

По итогам команда получает рекомендации по конфигурации с учетом характера нагрузки и ожидаемой производительности.

Проверка совместимости и стабильности

После формирования конфигурации сервер проходит комплексную проверку.

На производственном этапе контролируются комплектность оборудования, версии компонентов и прошивок. BIOS, BMC, сетевые адаптеры, RAID- и HBA-контроллеры приводятся к согласованным версиям, что обеспечивает воспроизводимость конфигурации. Затем проверяется работа памяти, накопителей, сетевых интерфейсов, аппаратных датчиков и других компонентов платформы.

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

После этого выполняется серия нагрузочных испытаний. Для оценки производительности используются бенчмарки процессоров, памяти, подсистем хранения, сетевой инфраструктуры и GPU. Отдельно анализируется поведение системы под длительной максимальной нагрузкой: температурные режимы, эффективность охлаждения, корректировка ошибок ECC, журналы BMC и другие параметры, позволяющие выявить потенциальные проблемы до начала эксплуатации.

Что отличает подход Selectel

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

Доступ к исходным кодам BIOS/BMC дает возможность не только обходить проблемы, а фиксить причины. Оборудование используется в собственных дата-центрах, поэтому требования к стабильности проверены. На базе платформы инженеры проектируют конфигурации под конкретные задачи, проверяют с помощью PoC, нагрузочного и стресс-тестирования, а затем используют полученный опыт для дальнейшего развития продукта.

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

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

Deckhouse: Kubernetes-платформа и экосистема для Cloud Native

Deckhouse — экосистема инструментов для разработки, доставки и эксплуатации Cloud Native-приложений. В основе — Deckhouse Kubernetes Platform (DKP), которая автоматизирует управление кластерами Kubernetes поверх любой инфраструктуры: публичные и частные облака, bare metal, закрытые контуры без доступа в интернет. Вокруг платформы выстроен набор продуктов — управление виртуализацией, хранение секретов, CI/CD, мониторинг — всё в одной экосистеме с общим API и интерфейсом.

Продукты разрабатываются и размещаются на территории РФ. Платформа поддерживает российские ОС: РЕД ОС, Astra Linux, ALT Linux. Deckhouse Kubernetes Platform CSE имеет сертификат ФСТЭК России №4860, платформа внесена в реестр российского ПО.

Что входит в экосистему

Deckhouse Kubernetes Platform (DKP) — ядро. Управляет кластерами Kubernetes, системным ПО на узлах, базовыми компонентами. После установки платформа готова к работе: автомасштабирование, мониторинг, мультитенантность — из коробки, без ручной сборки из отдельных компонентов.

Deckhouse Virtualization Platform (DVP) — управление виртуальными машинами и контейнерами из одного интерфейса. Масштабируется до 1000 серверов и 50 000 виртуальных машин. Поддерживает IaC-подход через открытый API, что позволяет автоматизировать развёртывание и управление средой полностью декларативно.

Deckhouse Stronghold — управление жизненным циклом секретов: пароли, ключи API, сертификаты, SSH-ключи, токены. Совместим с API HashiCorp Vault, что упрощает миграцию с него — без выгрузки секретов наружу через внешние утилиты. Поддерживает двойное шифрование через внешние HSM (AES + ГОСТ, AES + RSA), автоматическое резервное копирование и межкластерную репликацию.

Как устроен процесс работы

Установка и конфигурация

После установки DKP полностью готова к работе. Узлы группируются под разные типы нагрузки, настраиваются политики безопасности, мониторинг, журналирование. Платформа автоматически управляет системным ПО на узлах и базовыми компонентами Kubernetes.

Развёртывание в закрытых контурах

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

DevSecOps-практики

Сквозное применение DevSecOps на всех этапах поставки: управление сетевыми политиками, аутентификация и авторизация, заказ TLS-сертификатов, аудит-логирование, изолированные контейнеры.

Для кого это полезно

• Техлиды и архитекторы получают платформу, которая закрывает инфраструктурный слой: не нужно собирать стек из отдельных компонентов — мониторинг, service mesh, хранение секретов, балансировка уже встроены.
• Разработчики получают сокращение времени подготовки среды разработки до 15 раз, единый UI и API для управления всей инфраструктурой, понятный CI/CD-конвейер. DVP позволяет использовать IaC для управления виртуальными машинами так же, как контейнерами — через манифесты.
• QA-инженеры и SRE работают с уже настроенным мониторингом из коробки, автоматическими алертами и механизмами восстановления.

Что отличает подход

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

Кластеры поддерживают любой тип инфраструктуры без изменения подхода к управлению: одни и те же практики работают в Yandex Cloud, в собственном ЦОД и на bare metal одновременно. В кейсе «Лемана ПРО» именно это позволило объединить кластеры из разных облачных провайдеров и дата-центров в единую инфраструктуру.

Высокая доступность из коробки: SLA 99,99% достигается за счёт отказоустойчивости компонентов платформы, геораспределённых конфигураций (Multicluster на базе Istio, MetroCluster) и fencing-механизмов для безопасного восстановления при сбоях узлов.

Техническая база

• Поддерживаемые ОС (host): Astra Linux SE, РЕД ОС, РОСА Сервер, ALT Linux, CentOS, Debian, Ubuntu
• Поддерживаемые ОС (guest в DVP): любые ОС на x86-64
• Интеграции: LDAP, OIDC, внешние HSM, аппаратные СХД (TATLIN, Huawei, HPE, NetApp), SCSI-протокол, LACP, VLAN
• API: открытый, совместим с HashiCorp Vault API (для Stronghold)
• Форматы дисков ВМ: VMDK, Qcow2, Raw
• Сертификация: ФСТЭК России №4860, реестр российского ПО

Управление и поддержка

Единый канал поддержки покрывает все продукты экосистемы. Для обучения работает Deckhouse Академия с курсами по платформе и инструментам безопасности. Обновления платформы приходят автоматически в выбранное окно обслуживания. Для знакомства с продуктами доступна 30-дневная пробная версия.

ELMA365 BPM: автоматизация бизнес-процессов на Low-code платформе

ELMA365 — Low-code BPM-платформа для оцифровки, автоматизации и оптимизации бизнес-процессов. В основе — процессный движок, который автоматически ставит задачи участникам, маршрутизирует процессы по заданной логике и собирает данные на каждом этапе. Моделирование ведётся в визуальном дизайнере по нотации BPMN 2.0 — без привлечения разработчиков. Сценарии и кастомная бизнес-логика пишутся на TypeScript с подсветкой синтаксиса и автодополнением прямо в интерфейсе.

Платформа разворачивается в облаке на серверах Яндекса — без установки дополнительных компонентов, всё работает через браузер. По данным TAdviser, ELMA BPM — самая внедряемая BPM-система в России и СНГ.

Продукт используют в корпоративной автоматизации: согласование документов, управление задачами и поручениями, электронный документооборот, CRM-процессы, КЭДО.

Как устроен процесс работы

Моделирование процессов

Процесс описывается в графическом дизайнере из готовых блоков: задачи, шлюзы принятия решений, таймеры, уведомления, запуск подпроцессов. Используется нотация BPMN 2.0 — схема понятна как аналитику, так и бизнес-заказчику. Дополнительно доступны готовые активности ECM для работы с документами: подписание, согласование, генерация по шаблону, вебхуки для интеграций.

Формы и данные

Все формы создаются в графическом редакторе. Поля настраиваются под специфику процесса, группируются по вкладкам и панелям, скрываются или отображаются в зависимости от контекста. На этапе моделирования добавляются сценарии на TypeScript: автозаполнение полей, вычисление значений, определение ветки процесса — всё без написания backend-логики.

Запуск и исполнение

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

Отладка и мониторинг

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

Быстрая оптимизация

Процессы редактируются без остановки уже запущенных экземпляров. Изменения вступают в силу сразу после публикации. Платформа поддерживает версионность процессов — можно откатиться к предыдущему состоянию, если что-то пошло не так. Это важно для компаний, у которых одновременно живут десятки «живых» процессов: по оценке ELMA, для компании в 500 человек таких процессов от 50 до 100, и каждый меняется со временем.

Для кого это полезно

• Разработчики и аналитики работают в среде с подсветкой синтаксиса, автодополнением и встроенным отладчиком — TypeScript-сценарии пишутся прямо в интерфейсе. Сторонние библиотеки и внешние системы подключаются через готовые скрипты и вебхуки. Стандартный API открывает возможности для интеграции с любыми внешними сервисами, веб-сайтами и базами данных.
• PM получает полную видимость по задачам и срокам: канбан, мониторинг процессов в реальном времени, автоматические уведомления при просрочке или ошибке. Перераспределение задач при отпусках и болезнях закрывается механизмом замещения — администратор назначает замещающего и выдаёт временные доступы.
• QA-инженеры могут использовать версионность процессов для контроля изменений и отладчик для проверки бизнес-логики до выхода в продакшн.

Что отличает подход

Платформа сочетает Low-code-скорость с гибкостью полноценного кода. Большинство процессов настраивается без программирования, но там, где нужна кастомная логика, TypeScript-сценарии дают полный контроль. Это позволяет аналитикам закрывать задачи самостоятельно, не ставя каждое изменение в очередь к разработчикам.

Версионность и редактирование «на лету» — принципиальная особенность для enterprise: процессы живут годами и постоянно меняются. ELMA365 позволяет управлять этим циклом без остановки операционной работы и без риска сломать уже запущенные экземпляры.

Интеграционная шина покрывает основные корпоративные сценарии: ЭДО через операторов ЮЗДО и Контур.Диадок, CRM с встроенной телефонией и мессенджерами через ChatDesk, КЭДО с электронной подписью, которая полностью легитимна и позволяет убрать бумажные носители.

Техническая база

• Язык сценариев: TypeScript (встроенная IDE с автодополнением и отладчиком)
• Нотация процессов: BPMN 2.0
• API: стандартный REST API для запуска процессов и управления ими из внешних систем
• Интеграции: ЭДО (ЮЗДО, Контур.Диадок), мессенджеры (ChatDesk), телефония, внешние БД и веб-сервисы через вебхуки и скрипты
• Развёртывание: облако (серверы Яндекс), браузерный интерфейс без установки компонентов

Управление и поддержка

Изменения в процессах вносятся аналитиками без привлечения IT-отдела — платформа адаптирована под пользователей без специальных технических навыков. Мониторинг, уведомления и эскалации настраиваются на этапе моделирования. Новые идеи проверяются быстро: смоделировал → отладил → опубликовал → проанализировал в реальном времени.

Т1 Сфера: платформа полного цикла производства ПО

«Сфера» (SFERA — Scaled Framework for Enterprise Resilience and Agility) — платформа для управления разработкой, тестированием, эксплуатацией и поставкой ПО. Более 40 инструментов в одном контуре: таск-трекер, Git-репозиторий, CI/CD-конвейер, хранение артефактов, управление тестированием, мониторинг, документация. Платформа разрабатывается с 2020 года на основе опыта внедрения ИТ-конвейеров в крупнейших российских компаниях, включая банковский сектор.

В реестре российского ПО. Работает на инфраструктуре без выхода в интернет — подходит для закрытых корпоративных контуров. Применяют в enterprise-компаниях с большими ИТ-командами: финансовый сектор, ретейл, телеком, госструктуры. Поддерживает команды от нескольких человек до десятков тысяч специалистов одновременно.​

Как устроена платформа

Управление процессами и задачами

Сфера.Задачи — таск-трекер с настройкой под любую методологию: Agile, Scrum, SAFe, Kanban. Управляет бэклогом, декомпозицией задач, приоритизацией, назначением ответственных и дедлайнов. Закрывает те же сценарии, что Jira, Notion, Trello и Azure DevOps — в одном инструменте.

Сфера.Знания и Сфера.Документы обеспечивают базу знаний и документооборот — аналог связки Confluence + Notion. Здесь хранятся архитектурные решения, регламенты, технические спецификации и всё, что обычно теряется в чатах и почте.​

DevOps-инструментарий

Сфера.DevOps — сквозная автоматизация цикла от написания кода до деплоя. Включает:

• Git-инструмент для хранения, рецензирования и версионирования кода
• CI/CD-конвейер для непрерывной интеграции, тестирования и развёртывания
• Единое хранилище артефактов разработки
• DevOps-сервис самообслуживания для операций первого и второго дня — создание компонентов, сборка, проверка, раскатка

Тестирование

Комплекс инструментов для автоматизированного тестирования встроен в DevOps-конвейер. Поддерживает быстрый и автоматизированный процесс проверки на всех этапах жизненного цикла — от написания тест-кейсов до интеграционного и регрессионного тестирования в пайплайне.​

Мониторинг и эксплуатация

Сфера.Интеллектуальный мониторинг — транзакционный мониторинг бизнес-сервисов в реальном времени. Включает управление ИТ-активами, технологиями, сервисами, автоматизацию первой линии поддержки и управление жизненным циклом инцидентов. Контроль внесения изменений в инфраструктуру фиксируется отдельным инструментом.​

Особенность платформы — 3D-дашборды для контроля всех процессов производства ПО. Верхнеуровневый мониторинг детализируется до уровня отдельной команды или стрима: видно, где тормозит пайплайн, где накапливается технический долг, где горят сроки.​

Для кого это полезно

Техлиды и архитекторы получают единую среду, в которой живут архитектурные схемы, API-документация, код и задачи — всё связано и не расползается по разным системам. Инструмент для проектирования архитектуры на разных уровнях входит в состав платформы отдельным модулем.​

Разработчики работают в знакомом Git-workflow с code review, CI/CD-конвейером и хранилищем артефактов — без необходимости настраивать интеграции между десятком разных инструментов. DevOps-сервис самообслуживания сокращает время на рутинные операции: создание компонентов, настройку сборок, деплой.​

QA-инженеры используют встроенный тест-менеджмент в связке с CI/CD — тест-кейсы, автоматизация, отчётность по покрытию в одном контуре.

Что отличает подход

Платформа строилась не в вакууме, а на основе реального опыта ИТ-конвейеров в крупных корпорациях — в первую очередь банковского сектора. Помимо инструментов, в комплекте идёт методологический фреймворк — пошаговый план выстраивания технологического производства: от формирования команд до вывода продукта в промышленную эксплуатацию. Это снижает порог входа для команд, которые только выстраивают DevOps-культуру.​

Техническая база

• Методологии: Agile, Scrum, SAFe, Kanban​
• Инструменты: таск-трекер, Git, CI/CD, хранилище артефактов, тест-менеджмент, база знаний, документооборот, мониторинг, управление инцидентами​
• Интеграции: существующие системы контроля версий (GitLab и другие), внешние DevOps-инструменты​
• Развёртывание: корпоративный контур без выхода в интернет​
• Реестр: входит в реестр российского ПО​

Управление и поддержка

Платформа разработана совместно с VK, «1С», Лабораторией Касперского и Ростелекомом в рамках дорожной карты «Новое общесистемное ПО». Поддержка охватывает все модули платформы через единый канал. Новые команды могут опираться на встроенный методологический фреймворк для выстраивания процессов производства ПО с нуля.

Comindware Platform: Low-code BPM для автоматизации сложных процессов

Comindware Platform — Low-code BPM-платформа для моделирования, автоматизации и оптимизации бизнес-процессов предприятия. В одной среде работают корпоративная архитектура, процессный движок, кейс-менеджмент, управление данными и интеграции с внешними системами. Процессы описываются в визуальном дизайнере по нотации BPMN, исполняются движком точно в соответствии с моделью — без разночтений при переносе логики из схемы в код.

Среднее время реализации MVP на стороне клиента — 4 недели. Один из подтверждённых кейсов: бизнес-аналитик ABPMP в одиночку автоматизировал процесс обработки заявок за 30 часов, ускорив его в пять раз. Платформа применяется в промышленности, финансовом секторе, ритейле, телекоме, строительстве, медицине и государственных структурах. Среди кейсов нашла проекты для Газпром Авиа, НСПК, UCS, UserGate.

Как устроен процесс работы

Моделирование и автоматизация процессов

Процессы моделируются в BPMN-нотации, движок исполняет их в точности с моделью. Настройка большинства сценариев ведётся без написания кода, для сложной кастомной логики доступны C# и N3.

Управление данными и интерфейсами

Права доступа настраиваются на уровне отдельных кнопок, столбцов, таблиц и полей. Для отображения данных доступны рабочие области, виджеты, карты, графики, QR-коды.

Событийная оркестрация

Самогенерирующийся REST API развивается вместе с платформой и клиентскими приложениями, оставаясь обратно совместимым. Документирование через Swagger/OpenAPI: разработчики получают подробное описание каждого с примерами и возможностью тестирования на реальных данных без сборки приложения.​

Встроенные коннекторы покрывают стандартные корпоративные интеграции: Git, OpenLDAP/Active Directory, SMTP/IMAP, Exchange, OData (ERP), RabbitMQ/MSMQ, MSSQL/MySQL. Для событийных сценариев поддерживаются вебхуки — обмен данными с Telegram, Viber, JivoSite, телефонией (Novofon, Mango Office), почтовыми сервисами и любыми внешними системами через HTTP.

Для кого это полезно

• Архитекторы и аналитики управляют всей картой процессов компании в одной среде — от верхнеуровневой модели до исполняемых процессов. Изменения вносятся без остановки запущенных экземпляров, логика модели напрямую транслируется в поведение системы без ручной интерпретации.​
• Разработчики работают с самогенерирующимся REST API с Swagger-документацией, встроенными коннекторами к популярным сервисам и возможностью подключать кастомную логику на C#.
• PM получает прозрачность по статусу процессов в реальном времени и аналитику по отклонениям.
• QA и аналитики проверяют логику процессов на моделях до выхода в прод. Изменения можно откатить или протестировать на отдельном контуре.

Что отличает подход

Платформа объединяет в одной среде то, что обычно разведено по разным инструментам: архитектурное моделирование, исполнение процессов, кейс-менеджмент, управление данными и интеграции.

Самогенерирующийся API — нестандартное архитектурное решение для enterprise-платформ. Обычно API — это отдельный артефакт, который отстаёт от эволюции продукта. Здесь API генерируется автоматически по мере развития платформы и клиентских приложений, оставаясь обратно совместимым.

Платформа работает на собственном оборудовании, в частных или публичных облаках и по гибридной схеме. Интерфейс — браузерный, как для конечных пользователей, так и для разработчиков, установка ПО на рабочие места не требуется.​

Техническая база

• Нотация процессов: BPMN 2.0
• Языки кастомной логики: C#, N3
• API: самогенерирующийся REST API, документирование через Swagger/OpenAPI​
• Коннекторы: Git, Active Directory/OpenLDAP, Exchange, SMTP/IMAP, OData, RabbitMQ, MSMQ, MSSQL, MySQL​
• Интеграции через вебхуки: Telegram, Viber, JivoSite, Novofon, Mango Office, Unisender, Mailchimp, CRM-системы (Bitrix24, Megaplan, MS Dynamics)​
• Развёртывание: on-premise, частное и публичное облако, гибридная схема​

Управление и поддержка

Настройка большинства сценариев доступна аналитикам без привлечения разработчиков. Партнёрская сеть охватывает задачи внедрения и сопровождения. Для быстрого старта доступен пилотный проект — среднее время реализации MVP составляет 4 недели. Платформа развивается с учётом требований российского рынка и поддерживает работу в закрытых корпоративных контурах.

***

Общая закономерность у всех рассмотренных решений одна: экспертиза видна в глубине проработки конкретного слоя. Selectel копает до уровня BIOS/BMC и изучает, как ведёт себя железо под нагрузкой — потому что сами на нём работают. Чек-лист, который стоит держать в голове при выборе инструментов и подрядчиков для сложных задач:

• Есть ли у команды собственный опыт эксплуатации, а не только внедрения
• Можно ли протестировать решение под свой профиль нагрузки до принятия решения
• Насколько глубоко команда может разобраться в проблеме — до первопричины или только до симптома
• Покрывает ли поддержка весь стек или только отдельные его части
• Как решение ведёт себя при изменениях — масштабировании, миграции, обновлениях

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

Эта статья объясняет, почему классических CI/CD-ворот недостаточно для production-систем на базе ИИ. Автор делится практическим подходом к release gates для LLM-пайплайнов с помощью baseline-оценок, детектирования дрейфа, shadow-проверок и ограничений по стоимости и латентности. Акцент — на профилактике: отлов тихих AI-регрессий до того, как они достигнут пользователей, на основе реальных уроков платформенной инженерии из production-инфраструктуры.

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

В тот момент я перестал доверять зелёному цвету как сигналу к релизу. У нас не было проблемы с деплоем. У нас была проблема с release gates. Классический CI/CD создавался для детерминированного ПО. LLM — вероятностны. Наши ворота тоже должны быть вероятностными.

Классические CI/CD-ворота работают по принципу pass/fail, но LLM поставляют поведение, а не только код, поэтому нужны ворота, отслеживающие дрейф поведения.

Три режима отказа: eval drift (постепенная деградация оценок), distribution shift (реальные запросы отличаются от тестовых) и context poisoning (изменились извлечённые документы, а тесты спрашивают вчерашнее).

Четыре release gates: baseline eval suite, eval drift detection, shadow traffic validation, cost/latency guardrails.

Ворота должны быть простыми и понятными команде, иначе инженеры начнут их обходить.

Eval-датасеты нужно версионировать так же тщательно, как Terraform state: с бэкапами и параноей.

Почему классический CI/CD не справляется с LLM-пайплайнами

В обычной доставке ПО ворота достаточно просты: unit-тесты прошли, интеграционные тесты прошли, проверки безопасности прошли — деплой. Это бинарно. Сборка зелёная или красная. Эта модель ломается, когда вы поставляете не код, а поведение.

Классический CI/CD создавался для детерминированного ПО. LLM — вероятностны. Наши ворота тоже должны быть вероятностными.

Production-система на базе ИИ может сегодня показывать relevance 0,82, завтра 0,79, а на следующей неделе 0,74. Поскольку ни один запуск не пересекает порог отказа, никого не пейджат, хотя пользователи уже получают худшие ответы.

Я больше 20 лет управлял production-инфраструктурой: приватными облаками OpenStack, миграциями баз данных, CI/CD-пайплайнами и mission-critical системами. В классическом DevOps мы усвоили: сервер, который сообщает о 99,9% аптайма при потере 0,1% финансовых транзакций, — не здоров. Он скрывает баг. Оценки LLM работают так же. Агрегированные метрики маскируют локальные отказы.

Первый режим отказа — eval drift: оценки деградируют постепенно, но недостаточно, чтобы упасть по жёсткому порогу. Второй — distribution shift: реальные пользователи задают короткие, беспорядочные, странные вопросы, о которых ваш чистый eval-датасет и не думал. Третий — context poisoning: ваши извлечённые документы изменились, а тесты всё ещё спрашивают вчерашние вопросы.

Традиционный CI/CD gate спрашивает: «Тест прошёл?» LLM release gate спрашивает: «Поведение осталось в допустимом диапазоне?» Обычный gate сравнивает ожидаемый вывод с фактическим. AI CI/CD gate сравнивает кандидатное поведение с историческим и production-поведением, а также со стоимостью, латентностью и риском. Традиционные ворота быстро отсеивают исключения. LLM release gates внимательно отсекают дрейф.

Традиционные ворота быстро отсеивают исключения. LLM release gates внимательно отсекают дрейф.

Это различие важно, потому что production AI-системы гниют, а не взрываются. Я создал llm-eval-drift-release-gates-AGENT, потому что хотел ворота, которые относятся к AI-релизам как к инфраструктурным релизам: измеримым, повторяемым и, по возможности, скучным. Скука недооценена. Она позволяет инженерам спать.

Анатомия LLM release gate

Первое ворото — baseline eval suite. Он прогоняет фиксированный датасет по кандидатному пайплайну и оценивает relevance, faithfulness, safety, groundedness и любые доменные проверки, которые вам важны. Цель не в том, чтобы доказать, что модель идеальна. Цель — поймать регрессии до того, как они станут историями от клиентов.

Вот упрощённая Python-структура из паттерна, который я использую:

Использование StrEnum сохраняет enum в виде строк без множественного наследования. Это важно в релизном инструментарии, потому что значения статусов часто логируются, сериализуются, сравниваются в CI или передаются в дашборды.

Это ловит очевидные отказы: коллапс relevance, падение faithfulness, небезопасные выходы или искажённые результаты оценщика. Если отказ жёсткий, пайплайн блокируется немедленно; если срабатывает предупреждение, требуется ручное одобрение. Мне не нравятся тихие предупреждения: это будущие инциденты в хорошей рубашке.

Второе ворото: детектирование дрейфа оценок

Второе ворото — детектирование дрейфа оценок. Фиксированного порога недостаточно. Если relevance падает с 0,91 до 0,86, ваш порог 0,80 говорит, что всё в порядке. Ваши пользователи могут не согласиться.

Поэтому я сравниваю текущие оценки с rolling baseline из недавних деплоев:

Eval suite обнаружил 6% падение relevance в 23:00 в четверг. Без него это падение достигло бы 200 пользователей к понедельнику. Ворото не знало бизнес-контекста. Ему это и не нужно. Оно знало, что кандидат хуже последнего известного хорошего релиза.

Третье ворото: shadow traffic validation

Третье ворото — shadow traffic validation. Перед полным раскатом я направляю небольшой процент реального трафика на кандидатный пайплайн. Пользователи всё ещё получают production-ответ, но система записывает кандидатный вывод для сравнения.

Это canary-deployment, применённый к ИИ. Я использовал тот же паттерн в инфраструктурных раскатах, включая идеи из моего репозитория eks-canary-deployment-pipeline. Разница в том, что для LLM вы сравниваете не только HTTP 200. Вы сравниваете качество ответа, извлечённый контекст, латентность и причины, по которым кандидат расходится с production подозрительным образом.

Judge-модель может быть полезна, но я не даю ей быть единственным авторитетом. Она даёт сигнал. Release policy принимает решение.

Четвёртое ворото: стоимость и латентность

Четвёртое ворото — стоимость и латентность. Модель, которая идеально оценивается, но стоит в 3 раза дороже, — не валидный релиз. RAG-пайплайн, который добавляет две секунды латентности, тоже не готов. Эта же логика легла в основу моей работы enterprise-rag-guardrails-costops.

Когда это ворото не проходит, система блокирует релиз или направляет его на ручное одобрение. Я научился не торговаться о латентности во время деплоя. Она всегда побеждает позже.

Эти четыре ворота не делают деплой LLM идеальным. Они делают сложнее поставку бессмыслицы под зелёным бейджем.

Как встроить это в существующий CI/CD

Release gate не должен быть отдельным научным проектом. Если ваша платформенная команда уже использует GitHub Actions или GitLab CI, LLM-пайплайн деплоя должен вписаться в этот workflow.

Паттерн намеренно скучный:

Такую форму я расширил из своей работы devsecops-pipeline-github-actions. Соберите приложение. Запустите детерминированные тесты. Запустите baseline eval suite. Сравните с rolling baselines. Провалидируйте на shadow-трафике. Проверьте бюджеты стоимости и латентности. Деплойте, только когда все ворота согласны.

Здесь guardrails MLOps становятся полезны платформенным инженерам. Вам не нужна отдельная религия деплоя. Вам нужен один дополнительный набор проверок внутри пайплайна, которому команда уже доверяет.

Вот небольшая Python-точка входа, которую можно вызывать из CI. Важная деталь: она падает аккуратно, когда нужные отчёты отсутствуют или искажены, потому что сырые stack trace — не стратегия релиза.

Лучший release gate — тот, которым команда реально пользуется. Если для настройки нужна PhD по ML, это не ворота. Это стена. Я сейчас получаю степень PhD в области безопасности облачных вычислений, и даже я не хочу процесс деплоя, которому каждую пятницу нужна диссертация. Ворота должны быть достаточно простыми, чтобы запускаться в CI, достаточно строгими, чтобы блокировать плохие релизы, и достаточно гибкими, чтобы не стать офисным украшением.

Последняя часть далась мне дольше, чем хотелось бы признать.

Ошибки, которые я совершил, и что бы сделал иначе

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

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

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

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

Оценки выглядели отлично. Production — нет.

Моя третья ошибка — не версионировал eval-датасет. Когда я добавлял новые крайние случаи, я терял возможность сравнивать старые релизы с новыми baselines. Теперь я версионирую eval-наборы так же, как версионирую Terraform state: внимательно, с бэкапами и с лёгкой паранойей.

Строить это из Кочабамбы, Боливия, тоже повлияло на дизайн. У меня не было неограниченных облачных кредитов на огромные eval-прогоны. Это заставило оптимизировать сэмплирование, кешировать вызовы judge-модели и разделять быстрые PR-проверки от более тяжёлых ночных.

Ограничения рождают лучшую инженерию. Раздражает, но правда.

Отправляйте уверенность, а не только код

В классическом ПО мы поставляем код и проверяем поведение. В ИИ мы поставляем поведение и проверяем соответствие. Release gates — это то, как мы закрываем этот разрыв.

LLM release gates не уберут неопределённость из production AI-систем. Ничто не уберёт. Но они дают платформенным командам практический способ поймать eval drift, distribution shift, context poisoning, скачки стоимости и регрессии латентности до пользователей.

Это важно для надёжности агентных workflow. Это важно для AI CI/CD. Это важно, потому что «все тесты прошли» больше не достаточно.

Я создал llm-eval-drift-release-gates-AGENT, потому что устал от зелёных пайплайнов, которые мне лгали. Репозиторий — open-source, offline-first референсная реализация этого паттерна release gates. Он намеренно достаточно мал, чтобы изучить, запустить, сломать и ужесточить в своём CI/CD.

Репозиторий: https://github.com/fdaniel-alvarez-dev/llm-eval-drift-release-gates-AGENT. Форкайте, ломайте, улучшайте. Худший release gate — тот, который вы никогда не построили.

Выводы

Классический CI/CD создавался для детерминированного ПО, а LLM — вероятностны. Поэтому release gates для ИИ должны отслеживать не только прохождение тестов, но и дрейф поведения: baseline-оценки, детектирование дрейфа, shadow-трафик, стоимость и латентность.

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

В своей колонке Daily Drivers редактор Hackaday Дженни Лист скачала ISO-образ, запустила KolibriOS на современном ThinkPad и удивилась: система выглядит зрелой, стабильной и по-настоящему быстрой. Разбираем, что это за проект, откуда он взялся и кому пригодится сегодня.

Что такое KolibriOS

KolibriOS — российский форк MenuetOS, созданный в 2004 году. В то время как автор оригинального MenuetOS Вилле Турьянмаа переключился на закрытую 64-битную версию, сообщество вокруг русскоязычного порта сохранило код открытым и продолжило развивать 32-битную ветку. Название «Колибри» выбрано неслучайно: система маленькая и быстрая, как птица-колибри.

Проект поддерживается преимущественно разработчиками из России, Казахстана, Украины и Германии. Код распространяется под открытой лицензией, а сборки регулярно публикуются на официальном сайте и зеркалах сообщества.

Версия 0.7.7

Версия 0.7.7 продолжает философию предельного минимализма. Минимальные системные требования смехотворны по нынешним меркам: 1 МБ места на диске, 8 МБ оперативной памяти и процессор класса i586. При этом система выдаёт графический интерфейс, многозадачность и набор встроенных программ.

Дженни Лист отмечает, что на ThinkPad 2020-х годов KolibriOS загружается «в мгновение ока» и сразу показывает рабочий стол. Интерфейс выглядит пиксельным, как в 1990-х: нет сглаживания, есть ощущение ретро. Но при этом всё работает — без синих экранов и зависаний.

• KolibriOS 0.7.7 — 32-битная ОС с ядром на ассемблере, базовый образ весит около 1 МБ.
• Минимальные требования: i586, 8 МБ ОЗУ, 1 МБ на диске.
• В комплекте браузеры, игры, эмуляторы, графические редакторы и среда разработки.
• Главное ограничение для повседневного использования — отсутствие поддержки HTTPS.
• Лучше всего подходит для старого железа, тонких клиентов, обучения и ретрокомпьютинга.

Как устроена система

Ядро на ассемблере

Большая часть KolibriOS написана на FASM — плоском ассемблере. Это объясняет крошечный размер исполняемых файлов и молниеносную загрузку: система не тратит время на инициализацию абстракций, слоёв совместимости и десятков фоновых служб.

Важная оговорка: несмотря на миф «всё на ассемблере», часть приложений и драйверов портирована или написана на C, Free Pascal, Oberon и даже Python. Но ядро, графическая подсистема и системные вызовы остаются ассемблерными.

Файловые системы и загрузка

KolibriOS умеет загружаться с CD/DVD, USB, жёстких дисков и даже с классической дискеты 1,44 МБ. Поддерживаются файловые системы FAT12/16/32, exFAT, NTFS и ext2/3/4. Есть варианты для Coreboot и загрузка прямо из Windows.

Что внутри: программы и игры

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

Из игр и развлечений — порты эмуляторов, DOSBox, а также shareware-версии классики вроде DOOM и Wolfenstein 3D на полноценном CD-образе. Есть поддержка SDL, что позволяет переносить проекты с «больших» систем.

Something this polished deserves a while to play around.

Главное ограничение: интернет без HTTPS

Дженни Лист называет именно этот момент решающим: встроенные браузеры KolibriOS, включая Netsurf и Webview, не поддерживают HTTPS. Без этого современный веб практически закрыт: большинство сайтов, включая сам Hackaday, просто не откроются.

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

Почему HTTPS сложно:
Современный TLS требует большой криптографической библиотеки, регулярных обновлений корневых сертификатов и поддержки множества алгоритмов. В условиях ОС размером в мегабайт это серьёзный архитектурный вызов, который сообщество пока не взяло в штатный комплект.

Кому и где пригодится KolibriOS

С учётом ограничений у KolibriOS остаётся несколько чётких сценариев применения. В России и соседних странах это особенно актуально: парки старого офисного и школьного оборудования часто содержат машины, которые официально «не тянут» современные ОС.

• Воскрешение старого железа. Pentium- и ранние Core-машины получают рабочий стол, браузер для локальных страниц и офисные утилиты.
• Тонкие клиенты. Низкие требования к RAM и CPU делают KolibriOS кандидатом для терминалов с удалённым рабочим столом.
• Обучение. Ядро на ассемблере, простые системные вызовы и небольшой кодовой базы — отличная площадка для изучения устройства ОС.
• Ретрокомпьютинг. Запуск DOS-игр через эмулятор, классические 2D-игры и ностальгический интерфейс 1990-х.
• Встроенные системы. Сборка Kolibri-A ориентирована на специализированное железо и железные проекты.

Как попробовать KolibriOS

Попробовать систему проще всего в виртуальной машине. Скачайте ISO-образ с официального сайта, создайте VM с 64 МБ ОЗУ и загрузитесь с образа. Для реального железа подойдёт запись образа на USB-флешку или CD.

• Скачайте ISO или образ дискеты с официального сайта KolibriOS.
• Для VM: создайте 32-битную машину с 64 МБ RAM и VESA-видео.
• Для железа: запишите ISO на CD или USB через обычную утилиту.
• Загрузитесь и выберите разрешение экрана из меню загрузчика.
• Исследуйте меню «Пуск»: игры, утилиты, терминал и браузер.

Если планируете использовать сетевые функции, проверьте совместимость сетевой карты по списку оборудования. Поддерживаются многие чипы Realtek, Intel и 3Com.

Выводы

KolibriOS 0.7.7 — это не замена Windows или Linux, а демонстрация того, какой отклик может давать компьютер, когда софт пишут под железо, а не под абстракции. В эпоху, когда операционки растут гигабайтами, проект напоминает: минимализм ещё жив.

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

Главный вопрос — нужна ли вам такая система прямо сейчас. Если у вас есть старый 32-битный ноутбук, интерес к ассемблеру или просто ностальгия по быстрым ОС — попробуйте. А для повседневной работы с интернетом пока придётся держать под рукой что-то посовременнее.

Источники:

• Jenny’s Daily Drivers: KolibriOS 0.7.7 — Hackaday
• KolibriOS на DistroWatch
• Официальная вики KolibriOS

Тема получила новый импульс после серии публикаций Диона Доктера (Dion Dokter) из голландской компании Tweede golf. Во второй части он заглядывает внутрь rustc и утверждает: async Rust так и не вышел из состояния MVP. Я не буду дословно переводить его рассуждения, а переосмыслю их с упором на практику: как понять, платите ли вы за async-удобство лишними байтами, и как снизить налог, пока компилятор не научился делать это сам.

• Асинхронный Rust компилируется в state machine: на каждую await-точку приходится отдельное состояние плюс служебные Unresumed, Returned и Panicked.
• Простая функция с двумя await-точками даёт 360 строк MIR против 23 у синхронного кода. Часть излишков LLVM убирает, но не все, особенно при оптимизации по размеру.
• Компилятор не схлопывает идентичные состояния, не инлайнит futures через await, генерирует state machine даже для async-блоков без await и оставляет panic-путь в состоянии Returned.
• В release-сборках замена panic в Returned на возврат Pending может сократить прошивку на 2–5%. Убирание state machine у пустых async-блоков — ещё около 0,2%.
• Пока rustc не исправлен, можно вручную: возвращать impl Future из «прозрачных» функций, использовать std::future::ready, схлопывать await-точки через match и передавать большие данные по ссылке.

Почему async-функция — это всегда state machine

Когда вы пишете async fn, компилятор не просто оборачивает тело в callback. Он строит конечный автомат: enum, где каждый вариант — состояние между await-точками. Это называется coroutine desugaring и происходит на уровне MIR (Mid-level IR) — до того, как код попадает в LLVM.

Рассмотрим минимальный пример. Есть две функции, каждая из которых просто возвращает число, и третья складывает результаты:

У bar две await-точки, поэтому минимум два пользовательских состояния. Но если сдампить MIR после прохода coroutine_resume, картина шире:

Три служебных состояния добавляются всегда. Они нужны, чтобы соблюсти контракт Future::poll: опрос завершённой future не должен приводить к неопределённому поведению. Поэтому после первого Ready future переходит в Returned, а повторный poll паникует. Аналогично Panicked блокирует future после пойманного panic — похоже на poisoning мьютекса.

Логика корректная, но цена высокая: bar порождает 360 строк MIR, а эквивалентный синхронный код — 23. В 15 с лишним раз больше. LLVM часть этого выбросит, но на opt-level = "z" или в толстых async-графах вызовов он быстро сдаётся.

Четыре места, где компилятор работает вхолостую

1. Panic в состоянии Returned

Контракт future требует только отсутствия UB. Паниковать при повторном poll — не обязательно. Можно просто вернуть Pending снова: ничего опасного не произойдёт, а ветка panic — это лишний побочный эффект, который плохо оптимизируется.

Дион сделал экспериментальный патч rustc: в release-режиме Returned больше не паникует. На embedded-прошивках это дало 2–5% экономии бинарного размера. В debug-сборках панику можно оставить, чтобы быстро ловить ошибочный повторный poll, — по аналогии с overflow-checks.

2. State machine без await

Взгляните на функцию без единой await-точки:

Идеальная реализация — всегда возвращать Poll::Ready(5) безо всякого enum. А rustc генерирует полноценный CoroutineLayout с тремя служебными состояниями и switch по дискриминанту. Такие функции часто появляются в трейтах, где один интерфейс должен быть async, но конкретная реализация ничего не ждёт. Патч, убирающий state machine у async-блоков без await, даёт ещё 0,2% размера — мало, но правка тривиальная.

3. Futures не инлайнятся через await

Классический шаблон: адаптер просто пересылает вызов вниз.

Сейчас bar получает собственный state machine, который вызывает state machine foo. Вручную мы бы написали fn bar(blah) -> impl Future { foo(blah) } и избавились бы от лишнего enum. Аналогично с преамбулой и постамбулой: их можно перенести на FutureExt::map из крейта futures.

4. Одинаковые состояния не схлопываются

Если в async-функции несколько веток match ведут к одинаковому await, компилятор создаёт отдельное состояние на каждую ветку:

Здесь send_response вызывается с разными аргументами, но структура состояний дублируется. Если вынести выбор аргумента за await, получится одно состояние вместо двух:

В одном примере из статьи MIR сокращается с 456 до 302 строк, а ассемблер — примерно на 11%. Оптимизации stack, поэтому выигрыш в реальном коде может быть заметнее.

Что делать сегодня, не дожидаясь rustc

Всё перечисленное выше — это работа для команды компилятора. Но релиз с этими патчами может занять месяцы, а то и годы. Пока он не вышел, можно снизить async-bloat в своём коде.

Главный принцип: каждый лишний async fn — это лишний state machine. Если функция не содержит await, не делайте её async.

Заменяйте async-пустышки на impl Future

Типичный случай — трейт, где одна реализация реально ждёт ввода-вывода, а другая просто возвращает значение.

Вместо полноценного state machine получается готовая future, которая сразу возвращает Ready. Это особенно полезно в embedded-HAL, где трейты часто async, но конкретный драйвер может делать только прямой доступ к регистрам.

Прозрачные обёртки без await

Если функция только пересылает await вниз, уберите await:

Схлопывайте await-точки

Если несколько веток match заканчиваются одним и тем же await, вынесите выбор аргументов наружу. Это уменьшает число состояний state machine и облегчает жизнь LLVM.

Передавайте большие данные по ссылке

Async-функция захватывает в state machine всё, что живёт через await. Если передать массив по значению, он окажется внутри future целиком:

Разница в 52 раза по размеру future — и это без учёта memcpy, который компилятор вынужден вставлять при перемещении больших значений.

Перспективы: Project Goal и финансирование

Дион оформил эти идеи как Rust Project Goal — формальный механизм, через который команды заявляют цели на полугодие. По его оценке, работа требует порядка €30 000 финансирования. Для компиляторного проекта это скромная сумма: речь идёт о 2–5% размера прошивки практически в любом async-проекте.

Есть и другой подход к той же проблеме: не убирать state machine на входе, а научить LLVM лучше их оптимизировать на выходе. Дион считает, что оба направления дополняют друг друга. Чем проще state machine попадает в LLVM, тем эффективнее её можно проинлайнить и упростить на поздних проходах.

Выводы

Async Rust never left the MVP state. The compiler generates state machines with a lot of unnecessary baggage. With a few targeted optimizations in rustc we can get smaller binaries and better performance for everyone.

Утверждение «async Rust так и не вышел из MVP» звучит резко, но поясняет, почему наши «zero-cost» абстракции иногда всё-таки стоят дорого. Компилятор делает корректный, но не оптимальный код: лишние panic-ветки, неинлайненные futures, дублирующиеся состояния и state machine там, где они не нужны.

Для embedded и WASM это не абстрактная проблема, а конкретные килобайты прошивки. Пока rustc учится, разработчик может снизить налог вручную: убирать async у функций без await, возвращать impl Future из прозрачных обёрток, схлопывать await-точки и не передавать большие структуры по значению.

Если ваш проект на Rust бьётся о лимит flash, имеет смысл посмотреть на async-граф вызовов свежим взглядом. Часто проще убрать одну лишнюю async-обёртку, чем месяцами ждать патч в компиляторе.

Источники:
— Dion Dokter, «Async Rust never left the MVP state»;
— Dion Dokter, «Debloat your async Rust»;
— Rust Project Goal: Async state machine optimisation.

В Linux 7.2 код расширяемого планировщика sched_ext изначально появился в виде файлов ext_arena.c, ext_cid.c, ext_types.h и других прямо в kernel/sched.

Линус Торвальдс слил изменения «под протестом», указав, что префиксы вместо директорий — это неправильный способ группировки.

Новый pull request перенёс файлы в kernel/sched/ext/; Торвальдс уже принял эту реструктуризацию.

Что случилось

На прошлой неделе в основную ветку Linux 7.2 попал основной набор изменений sched_ext — фреймворка, который позволяет реализовывать политики планирования в пользовательских программах BPF. К патчам не было претензий по функциональности, но Торвальдса возмутила организация файлов.

Вместо того чтобы создать поддиректорию kernel/sched/ext/, авторы добавили в kernel/sched несколько файлов с префиксом ext_: ext_arena.c, ext_arena.h, ext_cid.c, ext_cid.h и ext_types.h.

Please don't do this disgusting thing. There's a reason we have subdirectories: it's to group files together and separate them out. Using name prefixing instead of directories is disgusting and wrong. If you have this many random sched-ext files, it damn well should be cleaned up and not be this kind of mess. I've pulled this, but under protest. Proper hierarchical filesystems have been available since 1965.

Как исправили

В ответ разработчики отправили новый pull request, который перекладывает все sched_ext-файлы в отдельную директорию kernel/sched/ext/. Торвальдс уже принял реструктуризацию.

Почему это важно

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

Выводы

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

Источники

• Phoronix: "Disgusting" Linux sched_ext Source Code Restructured
• Письмо Линуса Торвальдса в lkml
• Коммит реструктуризации в git.kernel.org

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

ТОП-15 зарубежных хостингов в 2026 году

1. Timeweb — дата-центры в Казахстане для легального размещения сайтов на доменах .kz с соблюдением местных требований.
2. Fornex — доступно семь стран, серверы работают на мощных процессорах AMD EPYC, а в каждый тариф уже встроена фильтрация DDoS-трафика.
3. Beget — геораспределенная инфраструктура по РФ и СНГ с панелью управления собственной разработки и бесплатной миграцией под ключ.
4. AdminVPS — бесплатное администрирование для всех клиентов и моментальный запуск сервера через минуту после оплаты.
5. WebHOST1 — десять стран для размещения VDS, включая Израиль, Турцию и Гонконг, плюс кэшбэк 20% на лицензии 1С-Битрикс.
6. SmartApe — VPS на NVMe со скоростью чтения до 8 тыс. МБ/с и тройное резервирование данных в европейских дата-центрах Tier IV.
7. Евробайт — виртуальный хостинг в Амстердаме от 159 руб./мес. с бесплатным переносом и месяцем теста за 50 руб.
8. Макхост — своя система управления, завязанная на голландский дата-центр и оплата картой «Мир» без привязки к валютному курсу.
9. HandyHost — дата-центр расположен в столице Финляндии, дисковое хранилище построено на быстрых NVMe, а опробовать услугу можно бесплатно.
10. XLGAMES — игровые серверы на процессорах Intel Core i7/i9.
11. Pterohost — AMD Ryzen 9 7950X3D с разгоном до 5.9 ГГц и AI-ассистент, обученный на тикетах поддержки.
12. RU VDS — 23 дата-центра по миру (включая Антарктиду!) и кэшбэк баллами до 5% за каждое пополнение.
13. Maze Host — бюджетные тарифы от 0.66 USD с DDoS-защитой и серверами во Франции.
14. ggsel — маркетплейс с десятками продавцов VPS в разных странах, где можно сравнить цены за пару кликов.
15. Hostinger — встроенный AI-конструктор сайтов и 30-дневная гарантия возврата без лишних вопросов.

1. Timeweb

Платформа работает с 2006 года и входит в число заметных игроков на российском рынке. Главная фишка — физическое присутствие серверов в Казахстане. В линейке услуг есть привычный shared-хостинг, виртуальные серверы с гарантией ресурсов, а также полноценные физические стойки под крупные проекты.

• Стоимость: от 180 руб./мес. (тариф Year при оплате на год)
• География покрытия: Россия (Санкт-Петербург) и Казахстан (Алма-Ата)

Преимущества

• Дата-центр класса Tier III.
• Переезжать от другого провайдера не больно: помогут бесплатно.
• Доступность ресурса — 99.98% плюс ежедневное создание резервных копий данных.

Что стоит учесть

• Не поддерживаются Ruby on Rails и Node.js на обычном хостинге (требуется VDS).

2. Fornex

Первый сервер подняли 16 лет назад, и с тех пор клиентская база разрослась по всем часовым поясам — от Нью-Йорка до Токио. Оборудование размещено в европейских и американских дата-центрах. В линейке услуг — классический веб-хостинг на скоростных NVMe, виртуальные серверы с посекундной тарификацией и полноценные выделенные машины.

• Стоимость: от 390 руб./мес. (виртуальный хостинг)
• География покрытия: Германия, Нидерланды, Швеция, Швейцария, Испания, США

Преимущества

• Обещают стабильную работу 99.99% времени, плюс есть встроенная фильтрация входящих атак.
• Быстрая техподдержка 24/7: отвечает за несколько минут.
• VPS с гибкой настройкой и оплатой по часам, полный root-доступ.

Что стоит учесть

• Виртуальный хостинг дороже российских аналогов.

3. Beget

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

• Стоимость: от 420 руб./мес. (виртуальный хостинг при помесячной оплате)
• Доступные регионы: Россия, Европа, СНГ

Преимущества

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

Что стоит учесть

• Стоимость виртуального хостинга выше среднерыночной.

4. AdminVPS

Это провайдер, который делает ставку на гибкость и географическое разнообразие. Взять виртуальную машину можно в Европе или в любом уголке СНГ. Компания предлагает две линейки VPS: на процессорах с частотой до 3,6 ГГц и на мощных чипах до 5,0 ГГц.

• Стоимость: от 299 руб./мес. (VPS Lite на процессорах 3,6 ГГц)
• География покрытия: Россия, Беларусь, Казахстан, Нидерланды, Германия, Финляндия, Польша

Преимущества

• Широкий выбор локаций: семь стран.
• Мгновенный запуск сервера через минуту после оплаты.
• Бесплатное администрирование по системе «все включено».

Что стоит учесть

• Трафик на начальных тарифах ограничен 1–5 ТБ в месяц (не безлимитный).

5. WebHOST1

Сервис работает с 2008 года и за это время разместил более 150 тысяч проектов. География присутствия охватывает сразу десять стран. В портфеле не только классический веб-хостинг и VPS, но и аренда целых серверов, защищенные SSL-сертификаты, а также официальные лицензии на программное обеспечение.

• Стоимость: от 225 руб./мес.
• Доступные регионы: Россия, Нидерланды, США, Израиль, Гонконг, Молдова, Франция, Турция, Армения, Германия

Преимущества

• Бесплатный перенос сайтов и 30 дней хостинга в подарок для тестирования.
• Защита от DDoS-атак включена в базовые тарифы.
• Партнерская программа с выплатой до 40% от платежей приведенных клиентов.

Что стоит учесть

• В пиковые часы возможны задержки в работе сайтов и нестабильность.

6. SmartApe

Платформа предоставляет VPS на европейских серверах. Серверное железо стоит в дата-центрах класса Tier IV. Это высшая категория отказоустойчивости, таких объектов в мире единицы. В отличие от виртуального хостинга того же провайдера, где серверы есть и в России, линейка VPS четко ориентирована на Европу.

• Стоимость: от 330 руб./мес.
• География покрытия: дата-центры Tier III и Tier IV в Европе

Преимущества

• Производительность NVMe-накопителей по паспорту доходит до 8 тыс. Мб/сек.
• Выбор более 20 ОС, включая Windows Server и Astra Linux CE.
• Договор-оферта и возможность заключения двустороннего договора.

Что стоит учесть

• Канал ограничен 200 Мбит/с (у зарубежных конкурентов часто 1 Гбит/с).

7. Евробайт

Эта компания предлагает обычный виртуальный хостинг в Амстердаме. Никаких прав root и возни с командной строкой — привычная панель ISPmanager, где сайт разворачивается за пару кликов. Серверы собственные, стоят в голландском дата-центре, а не сняты в аренду.

• Стоимость: от 159 руб./мес. (тариф 3 ГБ SSD)
• Доступные регионы: Амстердам, Нидерланды (дата-центр Tier III)

Преимущества

• Управление сайтами — через знакомую многим панель ISPmanager.
• Даже на самом дешевом тарифе нет ограничений ни на число проектов, ни на количество баз данных.
• Новый клиент получает бесплатный переезд от старого хостера и сертификат шифрования Let‘s Encrypt без доплат.

Что стоит учесть

• Дисковое пространство скромное — максимум 15 ГБ на старших тарифах.

8. Макхост

Компания работает с 2000-х годов и обслуживает более 60 000 клиентов. Серверы находятся в Нидерландах — стране с либеральным законодательством в отношении контента. Провайдер использует панель управления собственной разработки, а не привычный ISPmanager.

• Стоимость: от 232 руб./мес. (тариф 3 ГБ SSD при оплате за год)
• География покрытия: Нидерланды

Преимущества

• При смене провайдера ваши сайты перевезут без оплаты.
• Оплата рублями через систему «Мир» без привязки к курсу валют.
• Возможность собрать тариф через конструктор (1 ГБ SSD, гибкая настройка).

Что стоит учесть

• Собственная панель управления — потребуется время на привыкание, если раньше работали только с ISPmanager или cPanel.

9. HandyHost

Хостинг с зарубежными серверами в Финляндии работает на NVMe-дисках — современный стандарт, который заметно быстрее обычных SSD. При этом панель управления остается привычной ISPmanager 6, а поддержка — русскоязычной.

• Стоимость: от 129 руб./мес. (тариф vHOST-0 при оплате за 2 года)
• География покрытия: Москва, Санкт-Петербург, Хельсинки (Финляндия)

Преимущества

• Тестовый период 30 дней — без активационных платежей и скрытых условий.
• NVMe-диски вместо обычных SSD — выше скорость чтения и записи.
• При оплате на год дают домен .ru в подарок.

Что стоит учесть

• Оперативная память на аккаунт небольшая — от 600 МБ до 2,7 ГБ на максимальном тарифе.

10. XLGAMES

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

• Стоимость: уточняется при выборе тарифа
• Доступные регионы: Европа, США

Преимущества

• Процессоры Intel Core i7 и i9, SSD-диски, канал 1 Гбит/с.
• Возврат средств за 5 дней, если услуга не устроила.
• Техподдержка работает 24/7.

Что стоит учесть

• Веб-хостинг для сайтов еще не запущен.

11. Pterohost

Это игровой хостинг, который делает ставку на топовое железо и собственную панель управления YourControl. Серверы работают на AMD Ryzen 9 7950X3D с разгоном до 5.9 ГГц, оперативной памятью DDR5 ECC и NVMe Gen4. Это одни из самых мощных конфигураций на рынке игрового хостинга. Провайдер поддерживает более 15 игр, включая Minecraft, Rust, CS2, Garry‘s Mod и Project Zomboid.

• Стоимость: уточняется при выборе игры и тарифа
• География покрытия: Европа

Преимущества

• Для клиентов доступен AI-ассистент, обученный на тикетах поддержки.
• Автоматические бэкапы на удаленном S3-хранилище, изолированном от основного сервера.
• Собственная панель YourControl с терминалом и файловым менеджером.

Что стоит учесть

• Специализация только на играх — для обычных сайтов не подходит.

12. RU VDS

Это полноценный конструктор виртуальных серверов с десятками параметров на выбор. Провайдер предлагает VPS в 23 локациях по всему миру. Здесь можно собрать сервер под себя: выбрать процессор (обычный, мощный или AMD EPYC), тип диска (HDD, SSD, NVMe), объем RAM и даже видеопамять.

• Стоимость: от 139 руб./мес. (VPS на SSD)
• Доступные регионы: Армения, Беларусь, Казахстан, Лондон, Турция, Амстердам, Цюрих, Франкфурт

Преимущества

• Гибкий конфигуратор: меняйте параметры сервера онлайн без потери данных.
• Панель ISPmanager бесплатно до конца 2026 года.
• 23 дата-центра по всему миру.

Что стоит учесть

• Тестовый период всего 3 дня (меньше, чем у многих конкурентов).

13. Maze Host

Одна площадка закрывает две задачи: сюда идут и за обычным хостингом для сайта, и за арендой игрового сервера. Ключевая особенность для зарубежного размещения — наличие серверов во Франции. Это европейская локация с хорошей связностью внутри ЕС и низким пингом для западноевропейской аудитории.

• Стоимость: от 0.66 USD/мес. (тариф Lite)
• География покрытия: Россия и Франция

Преимущества

• Цены в USD — удобно для международных расчетов и зарубежных клиентов.
• DDoS-защита включена во все тарифы без доплат
• Самый дешевый тариф — всего 0.66 USD в месяц.

Что стоит учесть

• При оплате из России возможны дополнительные комиссии.

14. ggsel

Это цифровой маркетплейс, где десятки продавцов предлагают свои услуги. Здесь можно найти VPS в Великобритании, Франции, США, а также специализированный хостинг для OpenAI, n8n и игр. Плюс подхода — возможность сравнить цены и условия от разных арендодателей в одном месте.

• Стоимость: от 650 руб./мес.
• Доступные регионы: зависит от продавца

Преимущества

• Можно найти VPS в разных странах (Великобритания, Франция, США) без регистрации на десятке сайтов.
• Цены иногда ниже, чем у крупных провайдеров.
• Есть редкие ниши: хостинг для OpenAI, n8n, игровых серверов Minecraft.

Что стоит учесть

• За качество сервера и поддержку отвечает конкретный продавец, а не платформа.

15. Hostinger

Один из крупнейших международных хостинг-провайдеров, работающий с 2004 года. Компания предлагает широкий спектр услуг: от простого виртуального хостинга до мощных VPS и облачных решений.

• Стоимость: от 1.99 $
• География покрытия: Европа, Азия, Северная и Южная Америка

Преимущества

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

Что стоит учесть

• Панель управления собственная, а не привычная cPanel или ISPmanager — потребуется привыкание.

Еще 10 хостингов с зарубежными серверами

• Asura Hosting — выбор между cPanel и DirectAdmin, плюс аккаунт прокачивается через три уровня с пожизненными скидками.
• Hawk Host — шесть дата-центров на трех континентах (Америка, Европа, Азия) с возможностью протестировать пинг до каждого перед покупкой.
• IONOS — 30 лет на рынке и ISO-сертифицированные дата-центры с геоизбыточностью.
• FirstVDS — процессоры с водяным охлаждением и частотой до 5.7 ГГц.
• AccuWeb Hosting — специализированные Windows VPS для Forex-трейдинга с нулевой задержкой и полным RDP-доступом.
• SpaceWeb — 25 лет на рынке, три дата-центра (включая Амстердам) и бесплатный перенос сайтов еще до оплаты.
• CastleHOST — покупаете игровой PRO-сервер — получаете бесплатный веб-хостинг в подарок плюс заработок на модах.
• CloudVPS — активация сервера за 5 минут, семь премиальных локаций и минималистичный подход без перегруза.
• VDSina — собираете сервер как конструктор и получаете до 50% партнерских отчислений.
• Fozzy — стоимость видна сразу на 10 лет вперед, плюс круглосуточная поддержка из разных часовых поясов.

Когда сайту нужен «паспорт» из другой страны

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

Законы

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

Аудитория за границей

География сервера напрямую влияет на скорость загрузки. Если ваши посетители сидят в Берлине или Лионе, а хостинг стоит во Владивостоке — задержки в 150–200 мс неизбежны. Для интернет-магазина или онлайн-сервиса каждая миллисекунда простоя бьет по конверсии. Вплоть до того, что Google понижает в выдаче медленные ресурсы. Выгоднее оплачивать VPS в Нидерландах или Франкфурте — и получить пинг 20–30 мс.

Свобода контента и изоляция

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

Как выбрать лучший зарубежный хостинг

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

• География. Смотрите, есть ли дата-центр в стране вашей целевой аудитории. Чем ближе сервер к пользователям, тем ниже пинг и быстрее загрузка сайта.
• Производительность. NVMe-диски вместо обычных SSD, процессоры не старше Intel Xeon Gold или AMD EPYC, выделенный канал от 100 Мбит/с — три главных маркера.
• Надежность. Ищите открытый SLA с гарантией аптайма 99,9% и выше, а также информацию о резервном копировании (ежедневные бэкапы — хороший тон).
• Безопасность. Бесплатный SSL-сертификат, защита от DDoS и изоляция аккаунтов через CloudLinux — минимальный набор для спокойствия.
• Удобство управления. Панель должна быть понятной без курсов администрирования. ISPmanager или cPanel подойдут новичкам, собственная разработка провайдера — тоже вариант, если она интуитивная.
• Поддержка и сервис. Круглосуточный чат на русском или английском языке с живым ответом за 5–10 минут. Проверьте перед оплатой — напишите тестовый вопрос.
• Оплата. Узнайте, принимают ли карты российских банков, есть ли PayPal или криптовалюта. И обратите внимание: выгодные цены часто указаны при оплате на год вперед, а помесячный тариф может быть в 1,5-2 раза дороже.

Для каких задач подходит зарубежный хостинг

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

WordPress сайты и блоги

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

Интернет-магазины

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

Лендинги и маркетинговые страницы

Задача одностраничного сайта — быстро загрузиться и не отвлекать пользователя. География сервера здесь критична меньше, чем настройки кеширования и сжатия. Но если рекламная кампания идет на зарубежную аудиторию, хостинг с CDN и сервером в регионе показа объявлений даст фору любому локальному провайдеру. Важна также совместимость с западными аналитическими системами и пикселями соцсетей.

SaaS и веб-приложения

Серьезные проекты, которым нужны стабильная работа CPU, большие объемы оперативной памяти и контроль над окружением. Зарубежные VPS и облачные решения предлагают понятные API для автоматизации развертывания, возможность масштабирования в пару кликов и дата-центры в разных часовых поясах. Если ваше приложение используют клиенты из Нью-Йорка и Сан-Франциско, сервер на восточном и западном побережье США станет правильной архитектурой.

Технические проекты, включая VPN-инфраструктуру

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

Тестовые и учебные серверы

Для экспериментов, обучения или временных проектов жалко платить много. И здесь европейские провайдеры с их минимальными тарифами по 1–3 евро в месяц оказываются вне конкуренции. Вы получаете полноценную среду с root-доступом или готовой панелью, которую после завершения работы просто удаляете без потери значительной суммы.

Международные проекты с аудиторией в ЕС, США или Азии

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

FAQ

Чем сервер за границей отличается от локального?

Главное различие — юрисдикция и география. Отечественный провайдер физически находится в вашей стране, подчиняется ее законам и обычно быстрее работает для местной аудитории. Размещение на европейских или американских мощностях дает возможность выбрать сервер в ЕС, США или Азии, соблюдать требования GDPR и других международных норм, но иногда требует оплаты в валюте.

Какую иностранную площадку лучше выбрать для сайта?

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

Подходит ли иностранный сервер для WordPress?

Да, и очень хорошо. Большинство зарубежных провайдеров предлагают специализированные WordPress-тарифы с предустановкой, автоматическими обновлениями и кэшированием на уровне сервера. CMS одинаково стабильно работает на мощностях в США, Нидерландах или Германии — география не влияет на совместимость.

Влияет ли расположение сервера на скорость сайта?

Напрямую. Чем дальше вычислительные мощности от посетителя, тем выше задержка (пинг). Разница в 100–200 миллисекунд может быть критичной для интернет-магазина или онлайн-сервиса, но почти незаметна для блога. Оптимальный вариант — выбрать дата-центр в той же стране или регионе, где живет большинство ваших пользователей.

Какие риски есть при использовании зарубежных провайдеров?

Три основных момента: языковой барьер в поддержке (не везде есть русскоязычные операторы), возможные сложности с возвратом средств по законам другой страны (всегда проверяйте условия moneyback заранее) и риск блокировки сайта на территории РФ, если контент попадает под локальные ограничения. Оплата в валюте может быть неудобной.

Можно ли перенести сайт с одного иностранного хостинга на другой?

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

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

Service Topology — это не статическая схема из вики, а динамическая карта связей между сервисами. Она обновляется по мере того, как меняется трафик, появляются новые зависимости или старые исчезают. Карта показывает не только «кто с кем говорит», но и контекст: уровень доступности, бизнес-домен, владельца и текущее состояние здоровья.

Если тема микросервисов для вас новая, начните с базового разбора «Что такое микросервисы», а если выбираете архитектуру для проекта — сравните варианты в материале «Монолит или микросервисы». Авторский разбор внутреннего устройства Netflix читайте в статье «Разработчик изучал систему рекомендаций Netflix месяцами».

• Netflix объединила три источника данных: eBPF-сетевые потоки, IPC-метрики и распределённые трейсы.
• Каждый источник строит свой граф; общий вид получается параллельным слиянием слоёв.
• Карта обновляется почти в реальном времени и отвечает на запросы быстрее секунды.
• Инженеры используют её для поиска причин сбоев, оценки зоны поражения и планирования изменений.
• Подход можно перенести в любую распределённую систему, где нужно понимать зависимости.

Почему обычной наблюдаемости мало

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

Инженеру в три часа ночи приходится мысленно склеивать данные из разных источников. Это медленно, чревато ошибками и добавляет стресса. Netflix проанализировала тысячи обращений в поддержку за четыре года и увидела повторяющиеся вопросы: кто мои upstream и downstream, что упадёт вместе со мной, почему сервис отображается в панели мониторинга как Unknown (неизвестный сервис). Ответы на них требовали единого представления о зависимостях.

Три источника данных Service Topology

Главный вывод Netflix: ни один источник не рассказывает всю историю. Поэтому система строит три независимых графа и объединяет их по запросу.

Сетевые потоки eBPF

На сетевом уровне Netflix собирает потоки ядра через eBPF. Это даёт полноту: сюда попадают все соединения, независимо от того, инструментирован сервис или нет. Слой показывает связи между кластерами и приложениями такими, какими они есть на самом деле. Недостаток — не хватает прикладного контекста: видно, что сервис А достучался до IP-адреса сервиса Б, но неизвестно, какой конкретно endpoint вызывался.

IPC-метрики

На прикладном уровне собираются метрики межпроцессного взаимодействия. Когда сервис обращается к другому через gRPC, GraphQL или REST, он фиксирует endpoint, ошибки, задержки и протокол. Этот слой даёт детали, которых нет у сетевого: какой именно путь вызывается и с какой вероятностью ошибки. Ограничение очевидно: если сервис не отправляет метрики, его вызовов здесь не будет.

Распределённые трейсы

Третий слой — трейсинг запросов от начала до конца. Он показывает не «может ли сервис А позвонить сервису Б», а «звонил ли он в рамках этого конкретного пользовательского запроса». Это помогает увидеть поведение во время выполнения, ветвления, фича-флаги и редкие пути. Поскольку трейсы собирают выборочно, редкие сценарии могут не попасть в агрегированный вид.

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

Как собирают Service Topology

Приём и обработка потоков

За кулисами работает конвейер, который держит миллионы событий в секунду. Потоки сетевых логов читаются из Kafka в нескольких регионах AWS. Для обработки Netflix использует Apache Pekko Streams — форк Akka, который разбивает нагрузку по группам автомасштабирования и сам управляет обратным давлением.

Восстановление прямых связей

Сетевой лог показывает отдельные сетевые прыжки: например, приложение → балансировщик → приложение или приложение → NAT-шлюз → приложение. Чтобы получить настоящие связи, запускается трёхступенчатая агрегация. Первая стадия забирает сырые записи, вторая распознаёт посредников и восстанавливает прямые пути между приложениями, третья финализирует агрегаты и добавляет статус здоровья. Такой градуированный подход раскидывает нагрузку и не даёт горячим узлам уронить весь конвейер.

Готовая топология хранится в графовой базе Netflix — абстракции поверх распределённого хранилища «ключ — значение». Она заточена под быстрый обход графа в несколько хопов. Поверх базы — gRPC-API с фильтрами по уровню доступности и домену, постраничным выводом больших выборок и ответом менее чем за секунду.

Хранение и API

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

Что даёт инженерам

Интерфейс и API дают инженерам несколько рабочих сценариев — от ручного расследования до автоматических проверок.

• Видеть upstream и downstream для любого сервиса с фильтрами по уровню доступности и домену.
• Переключаться между единым видом и отдельными слоями: только сеть, только IPC или только трейсы.
• Одним кликом переходить от узла топологии к логам, трейсам и детальным метрикам.
• Оценивать зону поражения перед отключением сервиса на обслуживание и понимать, кого уведомлять.
• Накладывать статус здоровья на граф и быстро понимать, локальная ли это проблема или каскадный сбой.
• Обращаться к топологии программно — например, чтобы автоматически проверять классификацию доступности критичных сервисов.
• Смотреть историю зависимостей и находить, что изменилось перед инцидентом.

Как перенести в свою систему

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

Чек-лист для первых шагов:
1. Выберите один настоящий источник связей: логи балансировщика, агент на хосте или метрики вызовов.
2. Не пытайтесь сразу построить идеальную модель — начните с автоматически обнаруженных рёбер.
3. Добавьте контекст: владельца сервиса, уровень критичности и домен.
4. Сделайте карту доступной программно, а не только в интерфейсе — инцидент-боты и скрипты будут благодарны.
5. Проверяйте актуальность: в динамичной среде карты, устаревшие на несколько часов, быстро теряют ценность.

Для иллюстрации вот минимальный скрипт, который строит рёбра графа из логов балансировщика:

Часто задаваемые вопросы

Выводы

Service Topology — не просто красивая картинка для панели мониторинга. Это операционная основа, которая ускоряет расследования, снижает риск изменений и даёт автоматическим системам общую картину инфраструктуры. Netflix называет её knowledge graph foundation — фундаментом для интеллектуальной автоматизации, в том числе для автоматического поиска первопричины сбоев.

Service topology provides the knowledge graph foundation that makes this kind of intelligent automation possible.

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

Источники

• From Silos to Service Topology: Why Netflix Built a Real-Time Service Map

Git worktrees позволяют держать несколько рабочих копий одного репозитория на разных ветках — и сейчас эта возможность в тренде. Забавно, что в Git она появилась ещё в 2015 году. Но worktrees действительно удобны, и в этой статье разберёмся, зачем они нужны, чем отличаются от обычных веток и почему внезапно стали популярны.

worktree — это дополнительная рабочая копия репозитория на другой ветке, привязанная к тому же .git.

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

Они особенно полезны при параллельной работе с ИИ-агентами и в приложении GitHub Copilot.

У worktrees есть ограничения: раздувание зависимостей, необходимость убирать папки, правила .gitignore и запрет на одновременный checkout одной ветки в нескольких worktrees.

Переключение контекста через ветки и stash

Представьте: вы работаете над задачей и вдруг получаете срочный баг. Нужно срочно переключить контекст.

Сначала, скорее всего, спрячете текущие изменения в stash:

Потом перейдёте на main и обновите её:

Затем создадите ветку с хотфиксом:

Пофиксите, закоммитите и запушите ветку:

После слияния pull request вы вернётесь к компьютеру, подтянете main и удалите ветку с багфиксом:

А потом сможете вернуться к задаче, над которой работали:

Фух. На чём мы остановились?

Переключение туда-сюда, перезагрузка файлов, переустановка node_modules в зависимости от того, что изменилось, — всё это отнимает много сил. Нагрузка от смены контекста серьёзная.

Это базовый пример, но иногда разработчики справлялись с таким хаосом сложными командами git stash или даже несколькими клонами одного репозитория (я сама грешила этим).

А потом появились… worktrees!

Переключение контекста через worktrees

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

Эта команда мгновенно создаёт соседнюю папку hotfix-workspace, базирует её на main и создаёт новую ветку hotfix-bug.

Теперь можно открыть эту папку в новом окне редактора (или перейти в неё через cd) и чинить баг. Исходное окно редактора остаётся в том же состоянии, в котором вы его оставили.

Pull request сливаете онлайн, как обычно, а после слияния можно просто удалить временную папку.

Гораздо плавнее! Нет риска конфликтов stash, редактор не перезагружается, и вы действительно можете работать параллельно.

Так почему же сейчас?

Долгое время worktrees были относительно неизвестны. Большинство разработчиков никогда о них не слышали, потому что либо Git GUI не поддерживали их (или относились как к второсортной функции), либо все привыкли к знакомой схеме: feature-ветка, работа, PR, merge и повтор.

Сейчас наша работа изменилась. ИИ заставляет нас работать параллельно больше, чем когда-либо в истории разработки ПО. Разработчики запускают множество сессий одновременно, а «культура код-ревью» растёт быстрее, чем «культура написания кода».

Агенты и люди могут делать больше параллельно с помощью worktrees. Это режим по умолчанию в приложении GitHub Copilot и во многих других современных инструментах.

Агенты и люди могут делать больше параллельно с помощью worktrees.

В чём подвох?

Worktrees решают кучу проблем, но есть нюансы, на которые стоит обращать внимание.

• Раздувание зависимостей: каждая папка worktree требует собственную копию зависимостей проекта. Если запускать npm install или pip install в нескольких worktrees, диск может быстро закончиться.
• Управление папками: нужно удалять папки worktree, чтобы со временем не засорять родительский каталог. Приложение GitHub Copilot часто делает это за вас, но если вы работаете в терминале, придётся следить самостоятельно.
• Требования к глобальному .gitignore: если создавать worktree внутри основного репозитория, их нужно вручную добавить в .gitignore, чтобы случайно не закоммитить. Можно создавать worktree за пределами основного репозитория (GitHub Copilot делает это по умолчанию), но это стоит учитывать.
• Ограничение «одна ветка»: Git не позволяет одновременно checkout’ить одну и ту же ветку в двух разных worktrees, чтобы избежать повреждения данных.

Как использовать git worktrees в приложении GitHub Copilot?

Отличный вопрос! Здорово, что там всё работает «из коробки». Когда вы открываете приложение, на главном экране есть выпадающий список, который спрашивает, где запускать новую сессию. По умолчанию выбран новый worktree.

Когда вы запускаете новую сессию, можно нажать на имя сессии вверху приложения и увидеть (забавное!) сгенерированное имя вашего worktree, а также путь, где он находится, проект, для которого он создан, и сведения о внесённых изменениях.

Проще простого!

Стоит ли использовать worktrees?

Я дам вам самый senior-ответ, который только можно: зависит от ситуации! Вам может быть удобнее работать по-другому. Возможно, вы не так много работаете параллельно и привыкли к ментальной модели веток и stash. Возможно, теперь вы будете использовать только worktrees. А может, захотите и то, и другое!

Мир у ваших ног, и попробовать всё это можно уже сегодня в приложении GitHub Copilot.

Об авторе. Cassidy Williams — старший директор по адвокации разработчиков в GitHub. Она создаёт ПО, консультирует стартапы и учит разработчиков строить лучше. Подписаться на её еженедельную рассылку можно на cassidoo.co/newsletter.

Выводы

Git worktrees — способ работать с несколькими ветками одновременно, не прерывая текущую задачу и не рискуя запутаться в stash. Они особенно удобны при параллельной работе с ИИ-агентами и встроены в приложение GitHub Copilot по умолчанию. Попробуйте — возможно, именно они упростят ваш рабочий процесс.

EchoBird — это open-source настольный лаунчер для ИИ-агентов и локальных больших языковых моделей (LLM). Написан на Rust + Tauri, работает на Windows, macOS и Linux. Автор, разработчик с ником edison7009, собрал его после того, как друзья не раз просили помочь «поставить этот ваш ИИ» на новой машине. Сейчас проект насчитывает 2200 звёзд на GitHub, 162 ответвления и 112 релизов; актуальная версия — v5.2.7.

Идея простая: вместо того чтобы запускать терминал для каждого инструмента, вбивать команды установки и копаться в переменных окружения, вы открываете одно окно. Там устанавливаются агенты, подключаются API-ключи, запускаются локальные модели и управляются собственные ИИ-проекты. В российских условиях локальные LLM и альтернативные поставщики часто воспринимаются не как эксперимент, а как рабочая необходимость: ограничения на доступ к западным сервисам и требования к данным делают собственное железо привлекательнее облака.

• EchoBird — это open-source менеджер ИИ-инструментов на Rust + Tauri для Windows, macOS и Linux.
• Четыре сценария: установка и починка агентов, локальные LLM, личные ИИ-проекты и единое средство запуска приложений.
• Model Nexus объединяет API-ключи, модели и протоколы OpenAI / Anthropic в одном центре конфигурации.
• Локальные модели запускаются через llama.cpp, vLLM или SGLang с автоподбором под железо.
• Расширяется через plugin.json: новый инструмент можно добавить без изменения кода приложения.

Четыре сценария, которые покрывает EchoBird

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

Установка и починка агентов

EchoBird сканирует систему, находит уже установленные инструменты и проверяет зависимости. Если чего-то не хватает, ведёт установку в режиме диалога. Если что-то сломалось — запускает починку. Поддерживаются Claude Code, Codex CLI, OpenCode, Aider, Hermes Agent, MiMo Code от Xiaomi и собственная линейка агентов автора — OpenClaw, ZeroClaw, NanoBot и PicoClaw. Новый инструмент добавляется через файл plugin.json, поэтому сообщество может расширять список без запросов на слияние в основной репозиторий.

Локальные LLM в один клик

Встроены три runtime'а под разное железо: llama.cpp для CPU и слабых машин, vLLM для серверных GPU NVIDIA на Linux и SGLang для агентских сценариев с жёстко заданным выводом — например, когда модель должна вернуть JSON строго по схеме. EchoBird сам определяет наличие видеокарты NVIDIA и предлагает runtime с подходящими параметрами — например, размер батча и offloading слоёв на GPU. После запуска модель отдаёт совместимые с OpenAI и Anthropic endpoints — остальные инструменты не замечают подмены. Про локальный запуск LLM через Ollama у нас есть пошаговый гайд.

Мои ИИ-проекты

Раздел для утилит, демок, игр и скриптов, созданных в режиме vibe coding (импровизационной разработки с ИИ), которые рождаются за один вечер с ИИ-помощником. Вместо того чтобы искать директорию и вспоминать команду запуска, проект живёт в едином списке с кнопкой «старт».

Менеджер приложений

Центральная панель запуска для всего, что уже установлено. Можно запустить Claude Code, Codex CLI или локальную модель из одного списка, не открывая отдельные терминалы и окна.

Model Nexus: единая точка входа для моделей

Главная архитектурная идея — Model Nexus. Это прослойка между приложением и поставщиками моделей, которая хранит API-ключи, проверяет задержки, транслирует OpenAI- и Anthropic-совместимые протоколы.

Без него каждый инструмент требует своей конфигурации: Claude Code требует свой API-ключ, Codex CLI — свой .env, Hermes Agent — свой config.toml, а локальный vLLM — свой путь к модели. Model Nexus заменяет это на «ввёл один раз, используешь везде».

Поддерживаются 14+ поставщиков: Anthropic, OpenAI, Gemini, xAI Grok, Mistral, Together AI, DeepSeek, MiniMax, GLM, SiliconFlow, а также Ollama, llama.cpp, vLLM, SGLang, OpenRouter и любой OpenAI-совместимый endpoint. Каждому агенту можно назначить свой протокол независимо от остальных.

Почему Tauri + Rust, а не Electron

Выбор стека для менеджера, который управляет чужими тяжёлыми моделями, логичен. Tauri даёт бинарник менее 10 МБ против типичных 100+ МБ у Electron. Rust напрямую дёргает системные API, работает с файловой системой, процессами и детекцией GPU без лишних мостов. Для инструмента, который постоянно запускает подпроцессы и читает конфигурации, это надёжнее и предсказуемее.

Сравнение: классическая установка Claude Code и EchoBird

Традиционный путь — пять шагов, каждый из которых может обломаться:

1. Проверить версию Node.js (нужен 18+).
2. Убедиться, что права npm настроены правильно.
3. Выполнить npm install -g @anthropic-ai/claude-code.
4. Прописать переменную окружения ANTHROPIC_API_KEY.
5. Проверить: claude --version. При смене машины — повторить.

Путь через EchoBird — короче в разы:

1. Открыть EchoBird.
2. Install & Repair → Claude Code → установить в один клик.
3. Model Nexus → ввести API-ключ один раз для всех инструментов.

Расширение через plugin.json

Новый инструмент описывается JSON-файлом с командами установки, проверки, починки и запуска. Пример минимального плагина:

Такой подход отделяет ядро приложения от рецептов установки. Теоретически сообщество может добавить плагины для российских моделей — например, GigaChat, YandexGPT или локальных сборок на базе Saiga — без необходимости ждать официальных обновлений.

Что нового в ветке v5.x

Релизы выходят активно. Несколько примечательных изменений последних недель:

• v5.2.4 — зеркала для установки из Китая (Tsinghua, Alibaba, Huawei), чтобы зависимости качались без VPN.
• v5.2.0 — переключатель Responses-протокола OpenAI для моделей, которые говорят на нём нативно, например MiniMax-M3 и Qwen3.7.
• v5.2.6 — поддержка MiMo Code от Xiaomi и починка автоуплотнения контекста в Codex V2, из-за которого разговоры обрывались.
• v5.2.4 — нативные элементы управления окном и стандартные горячие клавиши macOS (⌘W, ⌘M, ⌘,).

Как попробовать

Безопасность:
Перед запуском любого установочного скрипта из интерната рекомендуем открыть его в редакторе или скачать официальный инсталлятор из GitHub Releases.

После установки: открываете Model Nexus, добавляете ключи; переходите в Install & Repair, выбираете инструменты; запускаете их из App Manager. Для локальных моделей — Local LLM → runtime → модель.

Кому пригодится

• Тимлидам и DevRel'ам, которым часто нужно «поднять окружение» на новой машине коллеги.
• Разработчикам, кто переключается между рабочими и личными ПК и устал от повторяющегося адаптации.
• Энтузиастам локальных LLM, которым надоело вручную ставить CUDA, vLLM и искать пути к моделям.
• Авторам плагинов, которые хотят добавить поддержку отечественных или нишевых ИИ-сервисов.

Выводы

EchoBird не изобретает ИИ-инструменты заново — он убирает трение на границе между «хочу попробовать» и «уже работает». Model Nexus решает проблему разрозненных конфигураций, встроенные runtime'ы — проблему локальных моделей, а плагины — проблему поддержки новых сервисов. Выбор Rust + Tauri выглядит обоснованным: приложение остаётся лёгким, хотя самые тяжёлые модели грузятся вне его.

EchoBird родился из собственной боли: друзья постоянно просили меня установить Claude Code на их машины. Я хотел, чтобы любой мог нажать одну кнопку и получить рабочее окружение, не разбираясь в Node.js, npm и переменных окружения.

Если в вашем рабочем процессе регулярно фигурируют Claude Code, Codex CLI, Aider или локальные LLM, стоит потратить несколько минут на установку и посмотреть, сколько ручных шагов отпадёт.

Источники

Оригинальный материал: Open Source Project of the Day (#97): EchoBird — DEV Community. Дополнительно: репозиторий EchoBird на GitHub, официальный сайт.

Что значит «правильный фундамент сайта»

Под фундаментом я понимаю не только сервер и домен, а совокупность факторов: производительность, надёжность инфраструктуры, структурированные данные, качество контента, доступность и удобство использования. Фреймворк — это инструмент; фундамент — это то, ради чего инструмент используется. Плохо оптимизированный сайт на передовом стеке часто проигрывает хорошо сделанному сайту на классическом стеке. Подробнее про метрики скорости — в материале о Core Web Vitals на Tproger.

• Выбор фреймворка перестал быть решающим фактором: зрелые инструменты дают схожие возможности.
• Производительность, хостинг, домен и CDN (сеть доставки контента) напрямую влияют на трафик и конверсию.
• Структурированные данные (Schema.org / JSON-LD) помогают поисковикам и ИИ правильно понимать контент.
• ИИ-поиск и ответные системы меняют правила видимости: важны ясность, авторитетность и точные ответы.
• Качественный контент и UX становятся главным конкурентным преимуществом.

Технологический стек стал товаром

За последнее десятилетие экосистема веб-разработки выросла настолько, что большинство популярных фреймворков предлагают примерно одно и то же: компонентную архитектуру, серверный рендеринг, интеграции с API, аутентификацию и инструменты оптимизации. Разрыв между React, Vue, Svelte, Next.js, Nuxt, Laravel или Django в типичных задачах сократился до предпочтений команды, а не до объективных преимуществ.

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

Сигнал проверить себя: если команда обсуждает миграцию фреймворка, но у сайта LCP выше 2,5 с, нет CDN и картинки весят по 400 КБ — стоит сначала закрыть очевидные дыры в фундаменте.

Производительность всё ещё решает

Многочисленные исследования показывают, что задержка загрузки влияет на отказы и конверсию. Даже небольшое увеличение времени ответа заметно снижает вероятность, что пользователь дождётся контента.

Что именно оптимизировать

Современная оптимизация выходит далеко за «сожми JS». Нужно думать о форматах изображений (WebP, AVIF), ленивой загрузке, кешировании на граничных серверах, CDN, оптимизации шрифтов и времени ответа сервера. Интернет-магазин, который перевёл каталог на WebP, включил lazy loading и раздал статику через CDN, зачастую получит больше прироста, чем если бы переписал витрину с нуля.

• Измеряйте LCP (Largest Contentful Paint — отрисовку крупного контента), INP (Interaction to Next Paint — время реакции на взаимодействие) и CLS (Cumulative Layout Shift — визуальную стабильность) в PageSpeed Insights или Lighthouse.
• Переводите изображения в современные форматы и используйте адаптивные размеры.
• Включайте кеширование статики на CDN (сети доставки контента) как минимум на год.
• Убирайте неиспользуемый CSS и JS: в российских сетях каждый лишний мегабайт бьёт по скорости и по бюджету пользователя.

Домены и инфраструктура не теряют значения

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

В российском контексте стоит обращать внимание на локальных регистраторов — например, Reg.ru или RU-CENTER. Важны двухфакторная аутентификация в личном кабинете, блокировка переноса домена (domain lock), корректные NS-записи и резервные DNS-серверы. Если ваш бизнес зависит от сайта, отказоустойчивость DNS может спасти репутацию в момент DDoS или аварии хостинга.

• Проверьте срок действия домена и включите автообновление.
• Включите 2FA у регистратора и запретите неавторизованный трансфер.
• Используйте минимум два независимых NS-сервера в разных сетях.
• Мониторьте время отклика DNS: оно влияет на TTFB (Time to First Byte — время до первого байта ответа сервера).

Хостинг — это уже не просто сервер

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

Что спрашивать у провайдера

В России это может быть Selectel, Timeweb, Beget, Yandex Cloud или VK Cloud. Выбирая провайдера, смотрите не только на цену CPU/RAM, но и на SLA по доступности, географию CDN-точек, скорость развёртывания, поддержку HTTP/2 и HTTP/3, а также простоту мониторинга. Сайт, который остаётся доступным во время вирального всплеска трафика, приносит больше пользы, чем идеально написанный, но упавший сервис.

Практический контрольный список: есть ли у провайдера CDN (сеть доставки контента) в России, автомасштабирование, бэкапы и DDoS-защита? Если нет — вы платите не за хостинг, а за аренду сервера с самообслуживанием.

Структурированные данные перешли из «можно» в «нужно»

Поисковые системы и ИИ всё чаще не просто индексируют текст, а пытаются понять смысл страницы. Schema.org / JSON-LD помогает явно указать: это статья, товар, отзыв, событие, организация или рецепт.

Без микроразметки поисковику приходится догадываться из неструктурированного текста, что повышает риск ошибок. С микроразметкой контент чаще попадает в расширенные сниппеты, карточки знаний и rich results. Для русскоязычных проектов это особенно важно в Яндексе и Google: оба поисковика поддерживают Schema.org.

Пример разметки статьи на базе Schema.org — в гайде «Добавляем Schema.org в Docusaurus для GEO».

• Для статей используйте тип Article с headline, author и datePublished.
• Для товаров — Product с offers, aggregateRating и availability.
• Проверяйте разметку через валидаторы Google Rich Results Test и Яндекс.Вебмастер.
• Добавляйте FAQ и HowTo только там, где они реально отвечают на вопросы пользователей.

ИИ-поиск и Answer Engine Optimization

Пользователи всё чаще задают вопросы нейросетям и ассистентам вместо того, чтобы вбивать ключевые слова в поисковик. ChatGPT, Perplexity, ЯндексGPT, Google AI Overviews собирают ответы из множества источников и показывают их в диалоговом формате.

Как стать источником для ИИ

Это меняет правила видимости. Цель уже не только попасть на первую страницу Google, но и стать источником, который ИИ цитирует. Answer Engine Optimization (AEO) — подход, при котором контент структурируется так, чтобы давать прямые, авторитетные и легко извлекаемые ответы.

• Формулируйте ключевые тезисы в первых 100-150 словах статьи.
• Используйте чёткие заголовки H2/H3 с вопросами («Что такое...», «Как проверить...»).
• Добавляйте блоки FAQ и Ключевые выводы: ИИ-системы часто цитируют именно их.
• Подкрепляйте утверждения ссылками на первоисточники и данные.

Контент остаётся главной причиной визита

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

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

Поисковые системы всё лучше распознают контент, который действительно отвечает на вопросы пользователей. Техническая оптимизация открывает дверь, но экспертиза заставляет людей возвращаться.

Пользовательский опыт — новый дифференциатор

С чего начать проверку

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

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

• Проверьте сайт с клавиатуры: можно ли дойти до всех интерактивных элементов?
• Запустите Lighthouse в мобильном режиме и исправьте критичные замечания по доступности.
• Тестируйте на реальных устройствах, а не только в десктопном браузере.
• Собирайте обратную связь от реальных пользователей, а не только метрики.

Подробнее про инструменты и приёмы проверки доступности — в материале «Что такое доступность сайта и как её проверить».

Будущее — за результатами, а не фреймворками

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

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

FAQ

Выводы

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

Если вы планируете запуск или редизайн, начните не со споров о стеке, а с аудита скорости, инфраструктуры и контента. Это даст больше реальной пользы, чем очередная миграция «на что-то более современное».

Источник: Manish Shivanandhan, freeCodeCamp — Building a Website in 2026: What Matters More Than Your Tech Stack. Материал подготовлен как авторская переработка идеи с добавлением российского контекста и практических рекомендаций.

Индекс в базе данных — это вспомогательная структура (чаще всего B-дерево; хеш-индексы, GiST, GIN и другие типы применяются в узких специфических сценариях), которая ускоряет выборку строк по заданным колонкам. По аналогии с оглавлением книги: вместо перелистывания всех страниц СУБД сразу переходит к нужной главе. Но если оглавление построено плохо, пользы от него нет — а вот накладные расходы на поддержку остаются.

В этой статье разберём семь самых разрушительных ошибок индексации в production-SaaS: от параноидального создания индексов «на всякий случай» до игнорирования раздутия и особенностей мультитенантных схем. Каждая ошибка — с примерами SQL, метриками и конкретным фиксом.

Индексы — это налог на запись: каждый INSERT, UPDATE и DELETE обновляет все индексы таблицы.

Индекс на колонке с низкой селективностью (boolean, статус) почти бесполезен — используйте частичные (partial) индексы.

В составном индексе порядок колонок критичен: PostgreSQL может использовать (a, b, c) только если условие начинается с a.

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

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

Внешние ключи в PostgreSQL не индексируются автоматически — после каждого FOREIGN KEY создавайте индекс вручную.

Без EXPLAIN ANALYZE индексы создаются вслепую. Проверяйте реальный план выполнения перед деплоем.

Ошибка 1. Индексировать всё подряд «на всякий случай»

Самая распространённая ошибка — не недостаток индексов, а их избыток из тревожности. Особенно часто в неё попадают junior-разработчики: добавляют индекс на каждую колонку, которая встречается в WHERE, «на всякий случай». Кажется ответственным, но на самом деле вредно.

Каждый индекс — это налог на запись. При INSERT, UPDATE и DELETE PostgreSQL (или MySQL) вынуждена обновлять все индексы таблицы. На таблице с 8 индексами каждая запись трогает 8 структур данных. При низкой нагрузке это невидимо, но при 10 000 записей в минуту это становится узким местом.

Аудит неиспользуемых индексов в PostgreSQL:
Запрос к pg_stat_user_indexes покажет, сколько раз каждый индекс применялся с момента сброса статистики. Если idx_scan = 0 — индекс кандидат на удаление.

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

Ошибка 2. Не понимать селективность

Индекс на булеву колонку — почти всегда бесполезен. Селективность измеряет, сколько различных значений содержится относительно общего числа строк. У boolean всего два значения. Если 95% строк имеют is_active = true, планировщик запросов проигнорирует индекс и сделает Seq Scan — и будет прав.

Правило большого пальца: если у колонки меньше 10–20 уникальных значений относительно размера таблицы, простой индекс по ней один не справится. Используйте частичные или составные индексы.

Ошибка 3. Неверный порядок колонок в составном индексе

Составные индексы мощны, но часто неправильно понимаются. PostgreSQL может использовать индекс (a, b, c) для фильтрации по a, a и b, a, b и c. Но не может эффективно использовать его, если запрос фильтрует только по b или c — ведущая колонка пропущена.

Решение: первыми ставьте колонки с equality-условиями, затем — по селективности, и проектируйте индексы вокруг реальных паттернов запросов, а не вокруг схемы таблицы. Также учитывайте ORDER BY и необходимость покрывающего индекса. Перед созданием обязательно запускайте EXPLAIN ANALYZE.

Ошибка 4. Игнорировать раздутие индексов

Индексы деградируют со временем. Многие инженеры воспринимают их как «поставил и забыл», но это заблуждение. В PostgreSQL при обновлении или удалении строки старые записи в индексе устаревают и накапливаются как раздутие (bloat); их физическое удаление происходит при выполнении VACUUM. На высокоизменяемых таблицах (заказы, события, логи, сессии) раздутие накапливается стремительно.

Таблица с 1 млн живых строк может иметь индекс, раздутый до размеров 8 млн записей. Каждый запрос через такой индекс делает в 8 раз больше работы, чем должен.

REINDEX CONCURRENTLY — ключевое слово. Обычный REINDEX блокирует таблицу, а в production-SaaS это прямой путь к инциденту. CONCURRENTLY перестраивает индекс без блокировок, хотя и медленнее.

Также убедитесь, что autovacuum настроен под вашу реальную нагрузку на запись. Значения по умолчанию в PostgreSQL консервативны и часто недостаточны для SaaS с высокой интенсивностью записи.

Ошибка 5. Индексы на колонках с малым числом уникальных значений в мультитенантных системах

В мультитенантной архитектуре почти каждый запрос фильтрует по tenant_id. Естественное желание — проиндексировать эту колонку. Но для крупных тенантов индекс по tenant_id вернёт слишком много строк, и планировщик предпочтёт Seq Scan. Для маленьких тенантов отдельный индекс по tenant_id может быть полезен.

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

Ошибка 6. Не индексировать внешние ключи

В PostgreSQL внешние ключи не индексируются автоматически. При удалении родительской строки СУБД должна проверить все дочерние таблицы на наличие ссылающихся записей — и без индекса на внешнем ключе это Seq Scan по каждой дочерней таблице. На таблице orders с 50 млн строк удаление пользователя вызывает полное сканирование.

Сделайте это командным соглашением: в чек-листе миграций обязательный пункт «после каждого FOREIGN KEY — CREATE INDEX».

Ошибка 7. Не использовать EXPLAIN ANALYZE перед деплоем

Большинство решений об индексах принимаются интуитивно. Интуиция ошибается достаточно часто, чтобы это стало проблемой. EXPLAIN ANALYZE показывает, что именно делает планировщик: какие индексы использует, какие игнорирует, сколько строк реально прочитал против оценки, где тратится время.

На что обращать внимание:
• Seq Scan на большой таблице при выборке малой доли строк — возможно, пропущен индекс или планировщик не может использовать существующий индекс.
• Rows Removed by Filter в десятки тысяч — индекс есть, но неправильные колонки или низкая селективность.
• Buffers: shared hit=0 read=45000 — данные не закэшированы (cold cache), страницы читаются с диска. Для диагностики раздутия смотрите общее число буферов и сравнивайте размер индекса с ожидаемым.
• Высокое actual time — проверьте раздутие, актуальность статистики, количество буферов, дисковую подсистему и наличие блокировок. Запустите ANALYZE tablename, чтобы обновить статистику планировщика.

Чек-лист индексации для SaaS

• У каждой колонки внешнего ключа есть индекс?
• Составные индексы упорядочены по селективности, а не по удобству?
• Булевы и низкокардинальные фильтры используют частичные индексы вместо полных?
• Вы запускали EXPLAIN ANALYZE на 10 самых медленных запросов за неделю?
• Есть процесс поиска и удаления неиспользуемых индексов?
• Высокоизменяемые таблицы регулярно проходят REINDEX CONCURRENTLY?
• Autovacuum настроен под реальный объём записи, а не под значения по умолчанию PostgreSQL?
• В мультитенантных таблицах индексы начинаются с tenant_id и включают диапазон времени?

Выводы

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

База данных, которая быстра на 10 000 строках и быстра на 50 миллионах, — не случайность. Это результат того, что кто-то считал планирование запросов первоклассной инженерной задачей, а не рутинным дополнением.

Проверьте свои самые медленные запросы этой недели — возможно, одна из этих семи ошибок уже сидит в вашей production-базе.

Источник и материалы:
• Database Indexing Mistakes That Kill SaaS Performance at Scale — оригинальная статья OutworkTech
• PostgreSQL Index Types — официальная документация
• REINDEX — документация по перестроению индексов

Что такое Agentic SRE

Agentic SRE — это практика, в которой автономные ИИ-агенты помогают наблюдать за системами, анализировать телеметрию (метрики, логи, трейсы) и выполнять ограниченные операционные действия при заданных человеком guardrails (правил безопасности). Агент не заменяет SRE-инженера, а работает как цифровой напарник: собирает контекст, предлагает гипотезы и выполняет только те действия, которые одобрены политикой.

Ключевое отличие от классической автоматизации — способность к рассуждению. Традиционные скрипты реагируют на жёсткие триггеры («если CPU > 90%, то перезапустить»). Агент же может связать всплеск ошибок с недавним развёртыванием, проверить корреляцию по трейсам и предложить конкретный план действий — всё до того, как инженер откроет ноутбук.

Agentic SRE — это ИИ-агенты, которые помогают инженерам наблюдать, диагностировать и реагировать на инциденты.

Основная цель — сократить рутину и ускорить принятие решений, а не заменить человека.

Ключевые сценарии: триаж алертов, инцидент-копилот, автоматический RCA, безопасное исправление, обучение на инцидентах.

Безопасность превыше всего: агенты работают с allowlists, approval gates и полным аудитом.

Российские команды могут строить стек на OpenTelemetry, Prometheus/Grafana, собственных LLM и PagerDuty/Opsgenie.

Почему это важно именно сейчас

Сегодняшние системы стали слишком распределёнными, шумными и динамичными, чтобы человек успевал за ними вручную. Микросервисы, Kubernetes, feature flags и канареечные развёртывания создали ландшафт, где одно изменение может затронуть десятки сервисов, а сигналы о проблемах разбросаны по десяткам дашбордов.

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

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

Из чего строится стек

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

• Телеметрия: OpenTelemetry — стандарт сбора телеметрии — для сбора логов, метрик и трейсов в едином формате.
• Наблюдаемость: Prometheus, Grafana, Datadog, New Relic, Elastic или облачные системы — хранилище и визуализация.
• Оркестрация: MCP-серверы (Model Context Protocol от Anthropic), внутренние API или системы рабочих процессов, которые предоставляют агенту безопасные инструменты.
• Среда выполнения агента: LLM-фреймворки с function calling, планированием и работой с инструментами.
• Рабочий процесс при инцидентах: PagerDuty, Opsgenie, Slack, Jira, ServiceNow — куда агент пишет отчёты и запрашивает подтверждения.
• Safety Layer: RBAC, approval gates, audit logs, allowlists и пути отката — неотъемлемая часть, а не дополнение.

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

Пять сценариев, которые уже работают

1. Триаж алертов: от шума к сути за секунды

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

2. Инцидент-копилот: второй мозг в канале

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

3. Автоматический черновик RCA (Root Cause Analysis)

После инцидента агент сравнивает таймлайн с недавними изменениями (развёртывания, конфиги, фичер-флаги), находит корреляции и генерирует первый черновик отчёта RCA с ссылками на доказательства. Инженер остаётся владельцем выводов, но экономит значительное время на подготовку документации.

4. Безопасное исправление под контролем

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

5. Обучение на инцидентах: от пожаротушения к профилактике

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

Guardrails: почему доверие важнее интеллекта

Главный риск агентного SRE не в том, что агент слишком умен, а в том, что он может быть слишком уверен в себе. LLM способны генерировать правдоподобные, но неверные объяснения. Поэтому каждая рекомендация должна быть прослежена до реальной телеметрии, а каждое действие — ограничено явными правами.

• Action allowlists: агент может делать только то, что в белом списке.
• Approval gates: рискованные изменения требуют подтверждения.
• Полный audit log: каждое действие агента записывается.
• Read-only mode на этапе внедрения: сначала наблюдаем, потом действуем.
• Разграничение прав по сервисам и командам.
• Human override на каждом шаге: человек всегда может взять управление.

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

Выводы

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

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

Источник: Agentic SRE: The Next Frontier of Reliability — DevOps.com (Neel Shah, 2026).

Flatten — операция приведения вложенной структуры к одномерной. Самый распространённый кейс: матрица представлена как список списков, а вам нужен плоский список всех значений, чтобы передать в алгоритм или ML-модель. В отличие от других языков, в Python нет встроенного .flatten() у списков — поэтому стандартное «как это сделать?» имеет несколько ответов разной степени читаемости и эффективности.

Пусть у нас есть матрица 4×4:

Цель — получить:

• Быстрее всего работает обычный цикл с in-place мутацией: += или .extend(). Время — около 5–7 мс.
• itertools.chain() — около 16 мс, но в 3 раза экономнее по памяти; подходит, когда финальный список не нужен полностью.
• List comprehension — около 24 мс. Читаемо и без побочных эффектов, но создаёт промежуточные объекты.
• functools.reduce() + lambda и sum() — от 2,6 секунд. Это в 400–500 раз медленнее за счёт постоянного создания новых промежуточных списков.
• Для произвольной вложенности — рекурсия или итеративный обход со стеком.
• В data-science для NumPy-массивов используйте np.ndarray.flatten() — он быстрее любого варианта на чистых списках.

Способ 1. Цикл for + .extend()

Самый прямолинейный и читаемый вариант: проходим по каждой подсписку и добавляем её элементы к итоговому списку через .extend().

.extend() принимает любой iterable и поэлементно добавляет его в конец списка. Альтернативно можно использовать augmented-concatenation +=:

Обе функции делают одно и то же. Real Python отмечает: flatten_extend читается чуть лучше, потому что метод named — намекает на смысл операции. По скорости варианты идут в первой тройке.

Способ 2. List comprehension

Pythonic-альтернатива однострочнику. Двойной for внутри comprehension перебирает сначала строки, потом элементы строк:

Подход компактнее цикла и не плодит промежуточных переменных. Скорость — заметно медленнее .extend() из-за двух вложенных циклов на уровне comprehension, но всё ещё в диапазоне десятков миллисекунд.

Способ 3. itertools.chain() — экономно по памяти

chain() возвращает итератор, а не список. Это значит, что вы можете обходить элементы потокового, не материализуя весь массив в памяти — полезно, когда матрица большая и хранить полный flat-список нерационально.

На большой матрице chain.from_iterable примерно в три раза медленнее цикла .extend(): накладные расходы на материализацию через list(). Но если итоговый список как таковой не нужен — можно отдать сам итератор потребителю и сэкономить и время, и память.

Способ 4. functools.reduce() и sum() — почему так медленно

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

iconcat мутирует аккумулятор и держится в топ-3 по скорости. А вот вариант с lambda и оператором + на каждом шаге копирует обе стороны — отсюда и взрывной рост времени на больших данных.

С sum() ситуация ровно такая же:

sum() работает на любых сложениях, но для списков это О(n²) по аллокациям. На матрице 1000×1000 он в ~500 раз медленнее цикла с .extend().

Способ 5. Произвольная вложенность — рекурсия и стек

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

Рекурсия удобна, пока глубина не упирается в sys.getrecursionlimit() (по умолчанию 1000). Для очень глубоких структур стоит переписать через итеративный обход со стеком:

Способ 6. NumPy для data-science

Если вы работаете с матрицами в data-science, у numpy.ndarray есть готовый метод .flatten(). Он быстрее любого варианта на чистых Python-списках, потому что под капотом работает с непрерывным блоком памяти.

Замер производительности

Real Python прогнали все варианты на матрице 1000×1000 через timeit. Результаты, отсортированные по времени:

Между первыми тремя и последними четырьмя — пропасть в 400–500 раз. Причина: топовые функции мутируют существующий список, а reduce(+), reduce(operator.add), reduce(lambda x, y: x + y) и sum() на каждой итерации создают копии.

FAQ

Выводы

Если вам нужен один-в-один поведенческий рецепт: for row in matrix: flat.extend(row). Этот код понятен любому, кто знает Python, и упирается в производительность только когда матрица переваливает за миллионы элементов. Если объёмы такие, что нужна потоковая обработка — переключитесь на itertools.chain. Если данные numerical — используйте NumPy.

Главное, чего стоит избегать — sum(matrix, []) и reduce с + или lambda. Они смотрятся изящно в туториалах, но превращают O(n) в O(n²) и ставят вас в первую же боттлнек-историю на проде.

Оригинальный туториал с пошаговыми объяснениями и сравнением — на Real Python, автор — Leodanis Pozo Ramos.

В материале на блоге LogRocket разобран один из самых частых React-паттернов, который в неподходящем контексте оказывается одним из самых дорогих, — передача inline-объектов, массивов и колбэков прямо в месте вызова компонента. Контролируемый эксперимент с 200 memoized строк показывает, как это превращает один keystroke в коммит на 243,9 мс — и как простой рефактор возвращает время до 6 мс.

React.memo сравнивает по ссылке. Внутри React работает Object.is: {padding:16} и {padding:16} — это разные ссылки, значит «изменилось».

Inline-объекты в JSX обнуляют memo. Каждый рендер родителя создаёт новый объект/функцию, мемоизированный дочерний компонент видит «новые пропсы» и перерисовывается заново. Оптимизация, которую вы планировали, не срабатывает.

Цена в живом коде. Эксперимент: 200 memoized строк, поиск, inline style и onAddToCart. После 6 нажатий — счётчик рендеров каждой строки = 14, на keystroke коммит 243,9 мс.

Фикс простой. Статичный объект — в module scope. Динамический колбэк — в useCallback с пустыми зависимостями. После: коммит 6 мс, счётчик рендеров = 2, Why Did You Render молчит.

React Compiler не отменяет понимания. Он автоматизирует много memoization, но useMemo/useCallback остаются escape hatch для случаев, когда нужен точный контроль (например, dependency для Effect).

Как работает bailout у React

React.memo оборачивает компонент в memoization-границу. Когда родитель ререндерится, React не пропускает дочерний автоматически только потому, что он мемоизирован. Вместо этого сравниваются новые пропсы со старыми. Если каждый пропс считается равным — bail out, переиспользуем предыдущий результат. Если хотя бы один не равен — рендер. По умолчанию React сравнивает попропсово через Object.is.

Эта деталь критична, потому что для объектов и функций Object.is — это, по сути, проверка по ссылке:

Содержимое выглядит идентичным, но ссылки разные. React поэтому считает их изменёнными. Именно по этой причине inline-объекты и колбэки оказываются скрытой причиной того, что мемоизированный дочерний компонент продолжает ререндериться.

Та же логика объясняет, зачем нужны useCallback и useMemo. По документации React, useCallback кеширует определение функции между рендерами, а useMemo — результат вычисления. Оба помогают только тогда, когда зависимости остаются достаточно стабильными, чтобы React переиспользовал предыдущее значение. Если положить в массив зависимостей нестабильный объект, React видит новую зависимость на каждом рендере и пересчитывает заново.

Это и объясняет, почему баг ощущается запутанным в реальном приложении. Значения «выглядят» неизменными для человека: у style-объекта те же ключи, тело колбэка идентично, config всё ещё говорит то же самое. Но React не сравнивает намерение или структуру — он сравнивает идентичность.

Когда inline-пропсы реально становятся проблемой

Стоит провести границу между теоретической и практической ценой. Inline-колбэк сам по себе — не баг производительности. Если ребёнок дешёвый, частота рендера низкая и memoization-границы вокруг нет, измеримого отрицательного эффекта может вообще не быть. И в документации React, и в гайдах LogRocket по производительности — общее место: оптимизация работает там, где есть реальные узкие места, а не гипотетические.

Проблема начинается, когда сходятся три условия одновременно:

• Родитель ререндерится часто (поиск, скролл, фильтры, анимация, live data).
• Дочерний компонент или поддерево большое — лишняя работа заметна.
• Вы уже добавили memoization и ждёте, что React пропустит работу, когда «ничего важного не изменилось».

В такой связке нестабильные inline-ссылки не просто добавляют немного оверхеда — они обнуляют ту оптимизацию, которую вы намеренно ввели. И этот паттерн коварен в продакшене: он не объявляет себя багом. UI работает, исключений нет, предупреждений нет, и без профилировщика часто нет очевидного запаха. Цена проявляется иначе: тормозящая фильтрация списков, лаг ввода, шумные flame-графы и компонентные деревья, которые продолжают перерисовываться, даже когда осмысленные данные не менялись.

Контролируемый эксперимент: 200 memoized строк

Чтобы не спорить «плохо или нормально», автор поста собрал контролируемый тест: поисковый список товаров с 200 memoized строками, где каждая строка получает одинаковые логические значения, но новые ссылки на объект и функцию на каждом рендере родителя. Это позволяет напрямую увидеть, делает ли React.memo bail out или всё поддерево ререндерится на каждое нажатие клавиши.

Представьте storefront UI с 200 memoized ProductRow. Родитель — ProductList — хранит searchTerm в state. Каждое нажатие апдейтит state, ререндерит ProductList и снова прогоняет JSX, который мапает отфильтрованные товары. В эксперименте каждая ProductRow обёрнута в memo и помечена whyDidYouRender = true, но получает два inline-пропса в месте вызова:

Это ровно тот случай, о котором React предупреждает при передаче функций в memoized-компоненты: свежая функция или объект, созданные во время рендера, не пройдут сравнение пропсов, если ссылку не стабилизировать.

В эксперименте эффект становится виден почти мгновенно. Объект style и колбэк onAddToCart пересоздаются каждый раз, когда ререндерится ProductList, поэтому memo-обёртка видит изменённые пропсы для каждой строки на каждом нажатии. Счётчик рендеров делает это конкретным: после шести нажатий каждая видимая строка показывает Renders: 14. React Profiler затем показывает рантайм-цену ошибки: одно нажатие порождает коммит, в котором ProductList занимает 243,9 мс и все 200 row-fibers светятся в flame-графе.

Здесь React Developer Tools отрабатывают по полной. По официальной документации, React DevTools позволяют инспектировать компоненты, редактировать пропсы и state, а также находить проблемы производительности. Профайлер также доступен программно через <Profiler>, но интерактивный вид DevTools обычно используется командами для отладки.

Why Did You Render делает корневую причину ещё нагляднее. Пакет модифицирует React и сообщает о потенциально избегаемых ререндерах. В этом примере он рапортует props.style как «different objects that are equal by value» и props.onAddToCart как «different functions with the same name» — ровно тот референциальный мисматч, который мы и ожидаем. Это диагностический инструмент только для разработки, не для прода, но крайне эффективный для выявления этого класса багов.

Рефакторинг, который реально решает проблему

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

Вынос ROW_STYLE в module scope решает проблему на самом дешёвом уровне: React никогда не видит новую ссылку на объект, потому что он создаётся один раз вне компонента. Использование useCallback для handleAddToCart даёт ребёнку стабильную ссылку на функцию между рендерами, пока массив зависимостей не меняется. Это и есть тот случай, для которого React документирует useCallback при передаче функций в мемоизированных детей.

В эксперименте стабилизация ссылок восстанавливает bail-out. Измеренный результат впечатляет: ProductList падает с 243,9 мс до 6 мс, бейджи рендеров остаются на 2 сколько ни печатай, и Why Did You Render замолкает — избегаемых референциальных мисматчей больше нет.

Когда стабилизировать ссылки, а когда — нет

Это часть, которая часто теряется в дискуссиях про производительность. Урок не «никогда не используй inline-объекты» и не «оборачивай всё в useCallback». Урок: memoization — это контракт. Если ребёнок полагается на референциальное равенство, чтобы пропустить работу, родитель обязан этот контракт уважать и передавать стабильные ссылки.

Но это не значит, что каждому компоненту нужна агрессивная мемоизация. Современные рекомендации React всё ещё трактуют memoization как точечную оптимизацию, а не дефолтный стиль. Если рендер дешёвый, поддерево маленькое или ребёнок не memoized, стабилизация ссылок может добавить сложности без реальной выгоды. Поэтому большинство гайдов по React performance, включая обзоры LogRocket, акцентируют профилировку прежде, чем механически оптимизировать.

Полезное правило большого пальца: сначала перенеси, потом мемоизируй. Если значение статично — вынеси его за пределы тела компонента, прежде чем тянуться к хукам. Это даёт референциальную стабильность почти без когнитивной или рантайм-нагрузки. useCallback и useMemo — только когда значение реально динамическое и ребёнок выигрывает от стабильной идентичности.

Меняет ли это React Compiler

Один актуальный нюанс — React Compiler. Документация описывает его как стабильный билд-тайм инструмент, который автоматически оптимизирует React-приложения и по умолчанию мемоизирует код на основе анализа и эвристик. Это уменьшает потребность в ручных useMemo, useCallback и React.memo, особенно в новом коде.

Но это не делает референциальную стабильность нерелевантной. Документация также отмечает, что useMemo и useCallback остаются полезными как escape hatch для случаев, когда разработчику нужен точный контроль — например, чтобы держать memoized-значение стабильным как зависимость для Effect. Так что даже в кодовых базах, переходящих на React Compiler, всё равно полезно понимать, как нестабильные ссылки влияют на ререндеры, результаты профайлера и кейсы, где ручной контроль ещё нужен.

Итог

Inline-объекты и inline-колбэки — не плохой React-код по умолчанию. Чаще всего это просто обычные JavaScript-выражения внутри JSX. Проблема появляется, когда они пересекают memoization-границу и вы ждёте, что React воспримет «то же значение» как «тот же пропс». По умолчанию React сравнивает пропсы и зависимости хуков через Object.is, поэтому для объектов и функций новой ссылки достаточно, чтобы React счёл значение изменившимся.

Этот паттерн заслуживает большего внимания, чем обычно получает. Это не пустяковая микрооптимизация. Это один из самых простых способов случайно обнулить React.memo — особенно в фильтруемых списках, дашбордах, search-heavy UI и компонентных деревьях с дорогими потомками. Код выглядит чистым, приложение работает, но оптимизация, на которую вы рассчитывали, исчезает.

Практический вывод для команд, строящих быстрые React-интерфейсы: профилируй сначала. Если memoized поддерево всё ещё ререндерится слишком часто — проверь пропсы прежде, чем винить React. Перенеси статичные объекты из render-пути. Мемоизируйте колбэки только тогда, когда ребёнок реально выигрывает. Используй React DevTools и Why Did You Render, чтобы подтвердить, что именно изменилось и почему. Делай это последовательно — и React.memo перестанет быть декоративным куском кода и начнёт делать свою работу.

Источник: The React pattern everyone uses that quietly kills performance — LogRocket Blog.

Разбираем главные события апреля 2026 — что меняется для тех, кто пишет на Python, мейнтейнит библиотеки или поддерживает прод-инфраструктуру.

PEP 772 принят. Python получил избранный Packaging Council из пяти человек с двухлетними сроками — теперь у решений про pip, setuptools и PyPI есть формальный орган, не зависящий от PyPA.

Инкрементальный GC откатывают. В 3.14.5 и 3.15 вернётся старый поколенческий сборщик. Память на проде росла до 5×, а паузы 26 мс vs 1,3 мс этого не оправдывали.

OpenAI приобрёл Astral. Создатели uv, Ruff и type-checker ty теперь под OpenAI. Лицензии открытые — форк остаётся страховочным механизмом.

PEP 803 принят. Появится abi3t — стабильный ABI для free-threaded билдов, цель Python 3.15. Решает «wheel-explosion» для Cryptography, SciPy, Pydantic.

Python 3.15.0 beta 1. Первая бета и feature-freeze назначены на 5 мая. После этой даты в 3.15 уже не попадут новые PEP-ы.

PEP 772: у Python появился Packaging Council

16 апреля Python Software Foundation и Steering Council одобрили PEP 772 — учреждение Packaging Council из пяти человек, выбираемых голосующими членами PSF. Полномочия совета сравнимы со Steering Council, но узкоспециализированы: стандарты упаковки, инструменты вроде pip и setuptools, эксплуатация PyPI.

До этого момента Python Packaging Authority (PyPA) координировала упаковочные решения неформально, через делегирование от Steering Council по PEP 609. На практике это значило, что любое крупное изменение в pip или PyPI требовало согласования через несколько групп без чёткого мандата. Совет получает прямые полномочия и работает на двухлетних сроках с шахматным переизбранием — две и три позиции ротируются в разных циклах, чтобы сохранять преемственность.

Главное последствие — упаковочные вопросы перестают зависать в комитете. По формулировке PEP, решения принимаются консенсусом, как и в Steering Council, но при необходимости совет может действовать голосованием. На повестке у нового органа уже стоят темы вроде упаковки в эпоху LLM-зависимостей и стандартизации lockfile-формата.

Реверт инкрементального GC в Python 3.14.5

В тот же день, 16 апреля, релиз-менеджер Hugo van Kemenade предложил откатить инкрементальный сборщик мусора, дебютировавший в Python 3.14, и core-команда согласилась. Реверт войдёт в 3.14.5 и 3.15 до feature-freeze.

Тестирование на продакшене у Neil Schemenauer показало интересную картину. Максимальные паузы инкрементального коллектора действительно упали с 26 мс до 1,3 мс — то самое, ради чего его и вводили. Но пиковое потребление памяти выросло до 5× baseline, а суммарное время выполнения задач увеличилось из-за дополнительной бухгалтерии. Для веб-приложений, дата-пайплайнов и батч-задач длинные паузы — не главная проблема. Память — главная.

Необычная часть истории — что ревёрт идёт в патч-релизе 3.14.5. На цикле релиза 3.14 предположение было, что инкрементальный GC обоснован. Откат показывает, что «прошёл бенчмарк-сьют» и «работает в проде» — это не одно и то же. Если ваши деплои на 3.14 жгут заметно больше памяти, чем на 3.13, теперь понятно почему. Core-команда не закрывает инкрементальный подход насовсем — вернуться к нему могут в 3.16, но через полноценный PEP-процесс, который оригинальная реализация пропустила.

OpenAI приобрёл Astral — uv, Ruff и ty переходят к ChatGPT-вендору

В конце марта OpenAI объявил о покупке Astral — компании-разработчика uv, Ruff и type-checker ty. Новость прокатилась по сообществу в апреле, когда разработчики начали считать масштаб сделки. uv в начале года перешагнул отметку в 126 миллионов скачиваний в месяц, Ruff давно стал линтером по умолчанию для существенной доли современных Python-проектов. Перенос обоих инструментов под OpenAI — ощутимый сдвиг в том, кто контролирует критическую инфраструктуру Python.

Реакция Simon Willison — «осторожно-оптимистичная»: команде Astral можно доверять прямо сейчас, но «product+talent acquisition может со временем превратиться в чисто talent-only». Структурная страховка — открытые лицензии: форк остаётся жизнеспособным запасным вариантом, если будущие владельцы решат развернуть стратегию.

Первый полный месяц после поглощения прошёл «скучно в хорошем смысле»: uv выпустил патчи 0.11.3–0.11.7, Ruff — 0.15.9–0.15.11, ни один проект курса не сменил. Если кто-то опасался резкого крена в сторону интеграции только с Codex — этого не произошло. На tproger мы писали ранее о том, как Astral в начале апреля запустила направление безопасности — теперь это инициатива внутри OpenAI.

PEP 803: стабильный ABI для free-threaded Python

PEP 803 приняли 30 марта, цель — Python 3.15. Документ определяет abi3t — отдельный вариант стабильного ABI для free-threaded билдов. Это закрывает «wheel-explosion problem», на которую Cryptography, SciPy и Pydantic жалуются уже больше года.

Сейчас, чтобы расширение работало на free-threaded Python, мейнтейнерам приходится собирать отдельный wheel для каждой минорной версии каждого Python-релиза. Контракт обычного abi3 (собрал один раз — работает на любой 3.x) для free-threaded не работает: у этих билдов разные инварианты по потокобезопасности.

Цена стабильности — PyObject становится непрозрачным под abi3t. Расширения, которые сейчас лезут в поля PyObject напрямую, должны мигрировать на новые accessor-API из PEP 697 и PEP 793. Это реальный рефакторинг, но взамен — один wheel на много версий Python. Картинку дополняет FastAPI 0.136.0 от 16 апреля: теперь у фреймворка есть официальная поддержка Python 3.14t. Инфраструктурный слой для GIL-free Python зреет быстро.

Что ещё стоило бы заметить

• Python 3.15.0 beta 1 — 5 мая. Альфа 8 от 7 апреля стала последней. Бета означает feature-freeze: новые PEP-ы в 3.15 после 5 мая уже не попадут.
• JIT в 3.15 быстрее. На x86-64 Linux замеры показывают +6–7%, на AArch64 macOS — +12–13% по сравнению с tail-calling-интерпретатором из 3.14.
• PEP 829 (черновик). Barry Warsaw предложил .start-файлы как замену .pth для startup-хуков пакетов. Старый формат позволяет произвольное исполнение кода при импорте — известный supply-chain-вектор.
• Polars 1.40.0 (18 апреля). Streaming-движок дотянули до групповых AsOf-join, статистики (cov, corr, skew, kurtosis, entropy) и strptime; добавили lock-free memory manager со spill-to-disk.
• Starlette 1.0 (22 марта). ASGI-фундамент FastAPI наконец стабилен: API теперь не сломается без мажорного релиза.
• Gemma 4 day-one в Python. 2 апреля Google открыл веса (2B/4B/31B + 26B MoE). Transformers 5.5.0, vLLM 0.19, Ollama 0.21 — всё с поддержкой в день релиза.
• Jazzband сворачивается. Площадка коллективного мейнтейнинга 84 проектов закрывается до конца 2026 года. Причины — «slopocalypse» (поток AI-сгенерированных PR-ов) и выгорание единственного админа.

Выводы

Апрель 2026 ощутимо сдвинул сразу два слоя Python-экосистемы. Управленческий — у языка появился второй формальный орган, конкретно отвечающий за упаковку, что давно просили десятки участников. Техническая прод-сторона — команда призналась, что инкрементальный GC из 3.14 не проходит проверку реальностью, и откатила его. На фоне этого поглощение Astral смотрится как индустриальный сигнал: ключевая Python-инфраструктура мигрирует в орбиту крупных AI-вендоров, и сообществу остаётся следить, не превратится ли «product+talent» в «talent-only».

Если поддерживаете C-расширение — следите за abi3t и API-миграцией под PEP 697/793. Если деплоите на 3.14 — планируйте обновление до 3.14.5, как только она выйдет. И если вы в принципе следите за Python — стоит разово посмотреть на состав будущего Packaging Council: пять человек впервые получают мандат принимать решения за всех нас.

Источник: Python News — Real Python.

MTP (Multi Token Prediction) — техника, предложенная исследователями Meta в апреле 2024: рядом с основной языковой моделью обучаются дополнительные головы, предсказывающие следующие 1–3 токена напрямую. Широкое применение в production-LLM пришло с DeepSeek-V3, а Qwen3.6 поддерживает архитектуру из коробки. До PR #22673 при экспорте в GGUF эти головы терялись. Теперь они подтягиваются как отдельная под-модель внутри того же файла и работают как драфтер для спекулятивного декодинга.

Что добавили. Поддержку Multi Token Prediction в llama.cpp — флаг --spec-type mtp запускает спекулятивный декодинг через MTP-головы модели.

Скорость. Qwen3.6 27B Q8_0 — 16–22 ток/с против 7 ток/с baseline. Ускорение в 2,2–2,4 раза в зависимости от типа задачи.

Accept rate. При --spec-draft-n-max 3 — 72,2% угаданных токенов в среднем; при n-max 2 — 82,6% (короче драфт, выше попадание).

Совместимость. Подтверждены Qwen3.6 27B и Qwen3.6 35BA3B; по заявлению автора, режим работает на любой модели с MTP-головами.

Где взять. Готовый GGUF с MTP-головой для Qwen3.6 27B автор приложил к PR — отдельный файл скачивать не нужно, всё в одном.

Что такое Multi Token Prediction

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

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

MTP идёт дальше: вместо двух разных моделей (большая + черновая) одна и та же модель обучается предсказывать сразу несколько следующих токенов через дополнительные параллельные головы. Концепция вышла из статьи Meta «Better & Faster Large Language Models via Multi-token Prediction» (Gloeckle и соавторы, апрель 2024), массовое применение в production-LLM пришло с DeepSeek-V3. Главное преимущество — не нужно держать в памяти отдельную draft-модель.

Бенчмарки am17an на Qwen3.6 27B

Автор PR прогнал девять синтетических задач — генерация Python-кода, C++-кода, объяснение концепций, суммаризация, факто-QA, перевод, креативные тексты, пошаговая математика и длинный код-ревью. Замеры с одной моделью и одним GPU (см. gist с бенчмарком):

• Baseline без спекулятивного декодинга: 7,0–7,7 ток/с, агрегат 201 секунда на 1404 токена.
• MTP, n-max 3 (3 драфт-токена за шаг): 13,9–21,6 ток/с, accept rate 72,2%, 83,8 с — ускорение в 2,4 раза.
• MTP, n-max 2: 15,2–18,2 ток/с, accept rate 82,6%, 90,4 с — короче драфт, но выше доля принятых.
• Draft-модель Qwen3.5 0.8B, n-max 16: для сравнения с классическим speculative decoding — 12,7–47,7 ток/с, accept rate 67,7%, 81,4 с.

На фактической QA («ответь точно») draft-модель догоняет MTP по скорости — accept rate подскакивает до 99,4%, — но на креативных и аналитических задачах MTP стабильнее: меньше провалов на нестандартных формулировках.

Как запустить

После сборки llama.cpp из ветки PR запуск сервера с MTP выглядит так:

Ключевой флаг — --spec-type mtp. --spec-draft-n-max 3 задаёт длину драфта; для большинства моделей оптимум — 2 или 3.

Готовый GGUF с MTP-головами для Qwen3.6 27B автор приложил к PR. Конвертация других MTP-моделей идёт через обновлённый convert_hf_to_gguf.py из той же ветки.

MTP против обычного спекулятивного декодинга

Классическая схема speculative decoding в llama.cpp требует двух GGUF-файлов: основной модели и небольшой черновой (например, Qwen3.5 0.8B как драфт для Qwen3.6 27B). Это удваивает требования к памяти и усложняет деплой — нужно следить, чтобы токенизаторы у обеих моделей совпадали. MTP убирает оба ограничения: дополнительные головы лежат в том же GGUF-файле, что и основная модель, токенизация заведомо одна. По бенчмаркам автора MTP-режим стабильнее по задержке, а draft-модель может выстрелить выше пика на специфичных задачах вроде QA, где её предсказания проще.

В обсуждении PR мейнтейнер ngxson отметил, что предыдущие попытки добавить MTP опирались на постоянное копирование данных между host и device — основной автор am17an обошёл это через отдельный hook для распространения скрытых признаков между ubatch-ами.

Свежий старт лучше моего WIP #18886 — другие попытки добавить MTP сильно полагались на копирование данных host ↔ device. Похоже, у тебя это решено?

Чек-лист для тех, кто хочет попробовать

1. Склонировать репозиторий llama.cpp и переключиться на ветку PR #22673 (или дождаться мерджа в master).
2. Собрать с CUDA или Metal-бэкендом — режимы для CPU работают, но без значимого ускорения.
3. Скачать GGUF с MTP-головой: qwen3.6-q8_0-mtp.gguf, ссылка приложена в PR.
4. Запустить llama-server с флагами --spec-type mtp --spec-draft-n-max 3.
5. Сравнить токены в секунду с baseline (без флагов спекулятивного декодинга) — на Qwen3.6 ожидается рост в 2–2,5 раза.

Выводы

После мерджа PR локальный запуск Qwen3.6 27B приближается по задержке к облачным API: разница в ответе на коде и аналитике сокращается с десятков секунд до считанных. Для MoE-вариантов вроде Qwen3.6 35BA3B экономия видеопамяти от MTP особенно полезна — ту же скорость теперь можно получить на одной серверной карте, не запуская параллельно отдельную draft-модель.

Если пишете инструменты вокруг локальных LLM — обновитесь после мерджа PR в master. Тем, кто использует облачные модели только из-за скорости, имеет смысл проверить, не закрывает ли Qwen3.6 + MTP их сценарий. У нас уже выходил отдельный гайд по запуску LLM локально через Ollama — он пригодится, если вы только подбираете инструменты.

Источники: PR #22673 в llama.cpp, бенчмарки am17an.

Альтернативой выступают гибридные архитектуры, в которых традиционное внимание чередуется с более экономичными механизмами: Mamba‑2, Gated DeltaNet. Разработчики этих моделей заявляют о радикальном снижении потребления памяти и повышении пропускной способности без потери качества. В данном материале рассматриваются три открытые гибридные модели — NVIDIA Nemotron‑Nano‑9B‑v2, Bamba‑9B‑v2 (IBM) и Qwen3.5‑9B (Alibaba) — и сравниваются с референсной плотной моделью Llama 3.1 8B.

Методика моделирования

Моделирование проводилось для одного ускорителя NVIDIA H200 с 141 ГБ видеопамяти при типичной нагрузке: 4096 входных токенов и до 256 выходных. Рассчитывались следующие метрики: память на один экземпляр с учётом весов, оверхеда и KV‑кеша (Instance VRAM); полное время ответа (E2E Latency); пропускная способность одного экземпляра в запросах в секунду (RPS per replica); требуемый объём памяти на единицу пропускной способности (VRAM/RPS); максимальное число параллельных запросов, ограниченное исключительно памятью. Расчёты верифицировались с помощью расширенного симулятора InferSim и по данным публичных бенчмарков.

Результаты

Особенности производительности моделей

Разница на порядок по KV-cashe у Nemotron обусловлена архитектурой. Модель содержит 56 слоёв, из которых лишь четыре используют полноценное внимание с KV‑кешем, а остальные 52 — сверхбыстрые Mamba‑2‑блоки. Mamba‑2 работает как рекуррентная сеть: вместо хранения растущей таблицы ключей и значений для каждого токена она обновляет компактное скрытое состояние фиксированного размера. В результате для запроса длиной 4096 + 256 токенов KV‑кеш Nemotron занимает около 68 МБ — примерно в восемь раз меньше, чем у Llama. Именно поэтому модель способна удерживать в памяти почти 2000 одновременных запросов; узким местом становится не память, а вычислительная мощность GPU.

Архитектура Qwen3.5 построена на чередовании Gated DeltaNet и Gated Attention. Большинство слоёв использует механизм линейного внимания, который подобно Mamba‑2 оперирует скрытым состоянием постоянного размера, не порождая тяжёлого KV‑кеша. Однако у этого подхода есть обратная сторона: Gated DeltaNet работает последовательно, послойно обновляя внутреннее состояние, и плохо утилизирует матричные вычисления GPU. На коротких дистанциях классический Attention с его эффективным матричным умножением способен загрузить видеокарту почти полностью, тогда как GDN‑слои проигрывают в чистой скорости. В результате TTFT у Qwen3.5 для 4096 токенов составляет 1.86 с против 1.32 с у Llama. На очень длинных контекстах (100K токенов и выше) ситуация меняется: классический KV‑кеш становится тормозом, а Gated DeltaNet продолжает работать с прежней эффективностью.

О качестве и специализации моделей

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

Llama 3.1 8B — референсная плотная модель. Показывает 69.4% на MMLU и 72.6% на HumanEval. Это проверенный универсал для задач, где важна предсказуемость и стабильность, а не максимальная производительность.

Nemotron‑Nano‑9B‑v2 позиционируется как математик и кодер. По данным NVIDIA, модель достигает 72.1% на AIME25, 97.8% на MATH500, 64.0% на GPQA Diamond и 71.1% на LiveCodeBench. Эти результаты делают её сильнейшим вариантом для задач, требующих точных вычислений и генерации корректного кода.

Qwen3.5‑9B является универсальным «эрудитом». Модель превосходит GPT‑OSS‑120B по MMLU‑Pro (82.5%) и GPQA Diamond (81.7%), а также показывает 83.2% на HMMT. Высокое качество на широком спектре тестов позволяет использовать её в сценариях, где важны широкий кругозор и точность ответов.

Bamba‑9B‑v2 — быстрый универсал, превосходящий Llama 3.1 8B по среднему баллу OpenLLM v2. Она не специализируется на одной задаче, но обеспечивает хорошее качество при заметно более высокой скорости.

Рекомендации

• Для чат-ботов и потоковой обработки с высокой пропускной способностью оптимален Nemotron‑Nano‑9B‑v2 — он в полтора раза быстрее Llama и примерно на 30% эффективнее использует память (VRAM/RPS 45.8 против 65.0 ГБ·с).
• Для саммаризации, аналитики документов и агентных систем, где во главе угла широкий кругозор и качество ответа, лучше подходит Qwen3.5‑9B.
• Bamba‑9B‑v2 занимает промежуточную позицию: она даёт заметный прирост скорости при сопоставимом с Llama объёме памяти и может использоваться как универсальный инструмент.

Заключение

Большие языковые модели по‑прежнему требуют значительных вычислительных ресурсов. Однако прогресс в архитектурах — Mamba‑2, Gated DeltaNet — шаг за шагом снижает стоимость владения: на одном H200 теперь можно обслужить заметно больше клиентов, чем год назад. Выбор модели перестаёт быть гаданием по маркетинговым обещаниям и превращается в инженерную задачу с чёткими метриками.

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

Главная идея: в Rust поле типа Option<BigStruct> занимает столько же, сколько BigStruct — даже когда оно None. Чтобы пустое поле «весило одно слово», нужно обернуть значение в Box. Компилятор тогда применяет niche-оптимизацию (использует нулевой указатель как маркер None) — Option<Box<T>> весит ровно как один указатель. На задачах с массой опциональных полей это даёт двукратное сокращение памяти.

• Кейс: десериализация всех JSON-моделей AWS SDK (Smithy Shapes) через serde в Rust
• Было: 895 МБ. Стало: 420 МБ. Экономия 475 МБ (-53%)
• Изменения: только layout структур + кастомный Deserializer для пустых полей
• Ключевая мысль: Option<Big> ≠ Option<Box<Big>> по памяти
• Niche-оптимизация компилятора: Option<Box<T>> весит как один указатель
• Verification: jemalloc через feature-флаг profile, замер до/после загрузки
• Цена: десериализация чуть дороже по CPU (значение всё равно создаётся, потом отбрасывается)

Реальный кейс

Программа автора десериализует все JSON-файлы из репозитория awslabs/aws-sdk-rust/aws-models в структуры «Smithy Shape». Эти файлы содержат тысячи объявлений вроде такого:

Как принято в Rust-коде, для разбора используется serde. Соответствующие структуры выглядят естественно — это обычная вложенность структур со множеством опциональных полей и serde-атрибутов. Не нужно вчитываться в код: обратите внимание только на сами имена полей и на россыпь Option<...>:

Это типичный для Rust код. Но именно такой layout приводит к тому, что после десериализации структуры занимают 895 МБ. При этом анализ показывает: большинство опциональных строк отсутствуют — это и стало рычагом для радикального сокращения объёма. Чтобы понять механизм, нужен короткий теоретический отступ.

Как устроены структуры в памяти Rust

На 64-битной платформе одно «слово» — это 8 байт. Например, столько занимает usize.

Тип String занимает 3 слова: указатель на буфер, длину и ёмкость (capacity). Это 24 байта на сам тип String (проверить можно через dbg!(std::mem::size_of::<String>())) — не считая место под содержимое строки на heap. Подробности в документации Rust.

Существует niche-оптимизация компилятора: Option<String> весит столько же, сколько String. Дополнительный байт под пометку «это None» не нужен — пустое значение определяется по нулевому указателю.

Поэтому такая структура, когда все строки None, занимает ровно 120 байт (5 × 24):

Композиция структур

Дальше — самое важное. Что будет, если такая структура встроена в другую? Пусть это будет Container1, у которой одно поле Option<String> и одно — SmithyServiceTrait:

Размер Container1 — 24 + 120 = 144 байта: 24 под Option<String> и 120 под SmithyServiceTrait. А что, если поле trait сделать опциональным — на случай, когда trait отсутствует?

Сколько занимает Container2, когда оба поля None? Те же 144 байта. Опциональность ничего не сэкономила: место под структуру уже зарезервировано в layout родителя, и компилятор всё равно держит его готовым. Везёт ещё, что внутри SmithyServiceTrait только поля Option<String> — это позволяет компилятору не добавлять дополнительный байт-discriminant для внешнего Option.

Применив эту арифметику к SmithyTraits, видно, почему наивная реализация так разбухает в памяти.

Почему в Java и других языках с GC такой проблемы нет

В языках с reference-семантикой полей композиция работает иначе. Когда у класса Container есть поле-объект, это поле — указатель на heap. Если поле null, оно занимает только одно слово.

Чтобы добиться того же поведения в Rust — то есть чтобы пустое поле занимало одно слово, — нужно явно вынести содержимое на heap, обернув в Box:

Теперь, когда оба поля None, Container3 занимает всего 32 байта: 3 слова под Option<String> и одно слово под Option<Box<...>>. Та же niche-оптимизация работает и здесь: Option<Box<...>> весит столько же, сколько голый Box<...>.

Что именно поменялось

Изменение свелось к трём шагам:

1. Найти структуры, которые часто оказываются «пустыми» (все поля — None).
2. Сделать их опциональными в родительской структуре, переместив на heap через Box.
3. Написать кастомный Deserializer, чтобы пустые структуры вообще не попадали в результат.

Было:

Стало:

Аналогично, в SmithyShape все поля Option<SmithyReference> заменены на Option<Box<SmithyReference>>. Местами пришлось поправить акцессоры, потому что путь к данным удлинился на одну разыменовку. И всё — память на хранение десериализованных AWS-shape снизилась вдвое, экономия 475 МБ.

Подводные камни

• CPU чуть дороже. Десериализация полного объекта всё равно происходит — а потом он отбрасывается, если оказался пустым. Парадокс: суммарно задача стала быстрее, потому что меньше памяти = меньше работы аллокатора, меньше TLB-промахов, лучше попадания в L2/L3-кеш. На больших объёмах эти эффекты перевешивают накладные расходы на лишний разбор.
• Фрагментация heap. Много мелких Box ведёт к фрагментированной куче. В авторском случае это не было проблемой, но в долгоживущих сервисах — стоит держать в уме.

Как проверить, что экономия реальная

Чутьё подсказывает, где можно сэкономить и сколько примерно. Но без замеров — не работа. В Rust нет простого способа узнать, сколько весит композитный объект со всеми полями и аллокациями за указателями. Решение автора — использовать аллокатор, умеющий отдавать статистику. В стандартной поставке такие данные ограничены, поэтому подключается jemalloc:

В Cargo.toml объявляется feature-флаг profile, чтобы не таскать jemalloc в обычные сборки:

В main.rs аллокатор подключается под этим же флагом:

И в самой функции загрузки структур делается замер: до и после.

Совет автора: tikv_jemalloc_ctl отдаёт ещё кучу деталей, которые полезно мониторить в серверных приложениях.

Что запомнить из статьи

• Применяйте Option<Box<T>> только там, где поле пусто в большинстве случаев — иначе heap-fragmentation и разыменовка перевесят выигрыш.
• Размер типа узнать просто: std::mem::size_of::<T>(). Реальное потребление с heap — только через jemalloc-ctl, dhat-rs или heaptrack.
• Niche-оптимизация работает не для всего: String, Box, Vec, &T — да; кастомный enum без явных #[repr] — обычно нет.
• При desered-через-serde: голая замена типа на Option<Box> не даёт выигрыша — нужен кастомный Deserializer, который вернёт None для «пустых» структур.
• Перед оптимизацией — всегда замер. После оптимизации — снова замер. Без цифр это карго-культ.

От редакции

Один практический совет от редакции: чтобы быстро найти кандидатов на оптимизацию в большом проекте, прогоните код через dhat-rs — это профайлер аллокаций от автора «Rust Performance Book». Он покажет, какие типы съедают больше всего heap. Альтернатива Option<Box<T>> — arena-аллокаторы вроде bumpalo: если вся группа объектов живёт один пакетный жизненный цикл, разовый bump-аллокатор может оказаться эффективнее множества мелких Box.

Если интересна тема Rust в крупных продакшенах, у Tproger есть свежий материал про то, как WhatsApp переписал медиадвижок на Rust и выкинул 160 тысяч строк C++ — там тоже про экономию памяти и скорость, только в другом масштабе.

Источник: «Box to save memory» — dystroy.org/blog. Автор оригинала — Дени «Canop» де Майе, разработчик файлового менеджера broot и других open-source утилит на Rust.

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

Хорошая новость заключается в том, что российский рынок систем управления разработкой совершил качественный скачок. Если несколько лет назад российский аналог Jira часто представлял собой базовую канбан-доску, то сегодня заказчикам доступны зрелые платформы. Современные решения способны справляться с Enterprise-нагрузками, поддерживать масштабируемые фреймворки (такие как SAFe или LeSS) и оркестрировать сложные процессы CI/CD.

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

Почему команды ищут замену Jira в 2026 году

Помимо очевидных ограничений, связанных с доступом к сервисам Atlassian из России, существуют и глубокие архитектурные причины, побуждающие ИТ-директоров рассматривать альтернативные решения:

1. Перегруженность системы. Инструмент, созданный 20 лет назад как баг-трекер, оброс таким количеством плагинов и настроек, что для управления им нужен отдельный штат администраторов.
2. Зависимость от плагинов (Франкенштейн-архитектура). Чтобы настроить нормальный учет времени (Tempo), диаграммы Ганта (Structure) или управление тестовыми сценариями (Zephyr), нужны сторонние плагины. Они стоят денег, часто конфликтуют друг с другом после обновлений и не всегда дружат между собой.
3. Слабый фокус на продуктовый подход. В Jira вы живете в парадигме «Проектов». Если над одним большим продуктом работает 10 команд, вам придется городить сложную иерархию проектов и эпиков, чтобы просто понять, кто что делает.
4. Требования информационной безопасности. Для государственного сектора, финансовой отрасли и промышленных предприятий критически важно размещать данные внутри собственного защищенного контура (On-premise) и использовать программное обеспечение из Реестра отечественного ПО.

Таким образом, альтернативы Jira сегодня выбирают не только из соображений импортонезависимости, но и ради получения более современного пользовательского опыта (UX), монолитной архитектуры без избытка плагинов и наличия необходимого функционала «из коробки».

Топ-10 аналогов Jira для российского рынка

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

1. SimpleOne SDLC

SimpleOne SDLC — это аналог Jira для команд разработки. Комплексная Enterprise-платформа для управления всем жизненным циклом разработки ПО (Software Development Life Cycle), а не просто трекер задач. Решение изначально спроектировано под потребности крупного бизнеса и продуктовой разработки. В основе архитектуры платформы лежит «Продукт», что позволяет эффективно выстраивать работу множества команд.

Для кого: средний и крупный бизнес, корпорации, банки, финтех, а также компании, внедряющие масштабируемые Agile-фреймворки (например, SAFe).

Соответствие Jira

• Полная поддержка продуктовой иерархии: Портфель -> Продукт -> Модуль -> Эпик -> Фича -> История -> Дефект/Задача;
• Нативные Agile-инструменты (Scrum, Kanban), управление спринтами и бэклогом;
• Возможность настройки сложных рабочих процессов (workflow) визуальными средствами;
• Наличие встроенного функционала, который в Jira требует плагинов: учет трудозатрат, ресурсное планирование, готовые дашборды (Burndown, CFD, Velocity).

Миграция из Jira

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

Плюсы

• Low-code платформа: в отличие от жесткой архитектуры классических трекеров, в SimpleOne бизнес-аналитики могут изменять логику, формы и интерфейсы с помощью визуальных конструкторов;
• Глубокая интеграция с ITSM: процессы разработки и технической поддержки (Service Desk) функционируют в единой среде. Инцидент, зарегистрированный в поддержке, конвертируется в задачу для разработчиков в один клик;
• Продуктовый подход: структура платформы оптимальна для управления сложными продуктами, над которыми работают десятки кросс-функциональных команд;
• Соответствие требованиям РФ: включено в реестр отечественного ПО.

Минусы

• Избыточный функционал и высокий порог входа для небольших стартапов (до 15 человек);
• Для получения максимальной отдачи от системы требуется определенный уровень зрелости процессов разработки в компании.

Тарифы

Стоимость рассчитывается индивидуально в зависимости от масштаба внедрения (Enterprise-модель лицензирования, On-premise или SaaS).

2. Kaiten

Один из ведущих российских визуальных трекеров задач. Kaiten делает ставку на обеспечение максимальной прозрачности процессов с помощью продвинутых Канбан-досок и системы рабочих пространств.

Для кого: Agile-команды, продуктовые студии, ИТ-компании среднего размера, маркетинговые подразделения.

Соответствие Jira

• Полноценная поддержка Scrum (спринты, бэклог, оценка в Story Points) и Kanban (WIP-лимиты, классы обслуживания);
• Иерархия задач реализуется через гибкие связи между карточками (эпики, истории);
• Встроенный модуль работы с документами (альтернатива Confluence).

Миграция из Jira

Реализован автоматизированный импорт данных из Jira, включая задачи, комментарии и структуру досок.

Плюсы

• Уникальная система пространств: на один экран можно вывести доски нескольких смежных команд, что идеально для выявления узких мест в общем потоке создания ценности;
• Современный UX/UI: интуитивно понятный и «легкий» интерфейс, в котором приятно работать;
• Быстрый старт: минимальное время на обучение сотрудников, команда может начать работу в первый же день;
• Импортонезависимость: система включена в реестр ПО РФ.

Минусы

• Ограниченные возможности для построения сложной, нестандартной бизнес-логики (workflow) по сравнению с Enterprise-платформами;
• Отсутствие глубокого функционала для финансового и ресурсного управления сложными портфелями проектов.

Тарифы

От 185 руб./пользователь/мес (до 15 пользователей). Тариф стандарт (до 250 пользователей) — 430 руб./пользователь/мес. Доступен бесплатный тариф с базовыми функциями и On-premise версия для корпоративных заказчиков.

3. YouGile

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

Для кого: небольшие и средние ИТ-команды, digital-агентства, студии веб-разработки, где критически важна скорость коммуникации.

Соответствие Jira

• Базовый функционал представлен Agile-досками (колонки и стикеры);
• Присутствуют инструменты учета времени, контроля дедлайнов и базовой отчетности;
• Отсутствует строгая иерархия эпиков и продвинутое управление спринтами «из коробки» (реализуется преимущественно через систему тегов).

Миграция из Jira

Доступен базовый импорт (задачи, исполнители), однако перенос сложной структуры и кастомных полей потребует ручной настройки.

Плюсы:

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

Минусы

• Не подходит для управления сложной продуктовой разработкой (отсутствуют модули управления релизами, CI/CD интеграции, учет технического долга);
• Слабые возможности для автоматизации бизнес-процессов.

Тарифы

Облачная версия — бесплатно до 10 пользователей, далее от 594 руб./мес за пользователя. Доступна коробочная версия (On-premise).

4. ПланФикс

Гибкая платформа-конструктор для настройки рабочих процессов. ПланФикс позволяет бизнес-пользователям самостоятельно смоделировать необходимую среду: от простой CRM до аналога сложного ИТ-трекера.

Для кого: команды и компании любого масштаба, располагающие ресурсами бизнес-аналитиков, готовых инвестировать время в детальную настройку системы под уникальные процессы.

Соответствие Jira

• Изначально система не специализируется на разработке ПО, но ее гибкость позволяет настроить Scrum-доски, спринты и бэклоги;
• Поддержка любых кастомных полей, статусов и сложных сценариев автоматизации;
• Наличие учета времени и диаграмм Ганта.

Миграция из Jira

Реализуется через импорт CSV-файлов или настройку интеграции через открытый API. Готового автоматизированного коннектора для миграции не предусмотрено.

Плюсы

• Исключительная гибкость: платформа-конструктор позволяет настроить автоматизацию любой сложности без использования программного кода;
• Единое цифровое пространство: возможность органично объединить управление разработкой, CRM и Service Desk в одном интерфейсе;
• Экономичность: конкурентоспособная и прозрачная ценовая политика.

Минусы

• Высокий порог входа: система представляет собой «чистый лист», требующий вдумчивого проектирования и длительной настройки;
• Интерфейс может восприниматься как перегруженный;
• Отсутствие готовых нативных интеграций с репозиториями кода (требуется настройка через webhook).

Тарифы

Поставляется по модели SaaS. Стоимость от 366 руб./пользователь/мес (при годовой оплате). Доступна бесплатная версия для микро-команд (до 5 человек).

5. TeamStorm

TeamStorm — это российская система управления разработкой, позиционируемая как наиболее близкая по логике работы и интерфейсу замена Jira.

Для кого: ИТ-подразделения и команды разработки, ищущие прямую альтернативу продуктам Atlassian с минимальным периодом адаптации сотрудников.

Соответствие Jira

• Поддержка классической иерархии: Эпик, История, Задача, Дефект, Подзадача;
• Организация рабочего пространства через «Пространства» и «Папки»;
• Управление спринтами, бэклогами, поддержка оценки задач в Story Points;
• Встроенный модуль базы знаний (аналог Confluence).

Миграция из Jira

Вендор предоставляет специализированные инструменты для бесшовного переноса данных из Jira.

Плюсы

• Привычный пользовательский опыт (UX): интерфейс и логика работы максимально приближены к связке Jira + Notion, что снижает затраты на переобучение ИТ-команд;
• Производительность: высокая скорость отклика интерфейса даже при работе с большими массивами данных;
• Безопасность: наличие в реестре отечественного ПО и возможность установки в закрытый контур.

Минусы

• Экосистема готовых интеграций со сторонними DevOps-сервисами пока уступает зарубежным аналогам;
• Ограниченный функционал для управления портфелями проектов на уровне Enterprise.

Тарифы

Облачная (SaaS) и On-premise версии. Стоимость от 500 руб./пользователь/мес.

6. Comindware

Comindware — это платформа для управления бизнес-процессами (BPMS) на базе Low-code архитектуры. Предназначена для комплексной цифровой трансформации крупных предприятий.

Для кого: средний и крупный бизнес (Enterprise), где процессы разработки ПО необходимо интегрировать с другими сложными корпоративными процедурами (закупки, документооборот, согласования).

Соответствие Jira

• Возможность настройки трекинга задач любой степени сложности;
• Гибкое управление маршрутами (workflow) и использование графовой базы данных для построения сложных связей между объектами;
• Управление неструктурированными процессами (Case Management).

Миграция из Jira

Осуществляется через API или путем импорта/экспорта данных в рамках комплексного проекта внедрения.

Плюсы

• Максимальная адаптивность (Low-code): бизнес-процессы можно модифицировать и перестраивать прямо «на лету» без остановки работы системы и кодинга;
• Масштаб автоматизации: возможность построения единой платформы для оцифровки процессов всей компании, а не только ИТ-отдела;
• Корпоративная безопасность: полноценное развертывание на серверах заказчика (On-premise).

Минусы

• Не является специализированным трекером для ИТ-команд (отсутствуют нативные интеграции с CI/CD);
• Интерфейс требует адаптации пользователей;
• Внедрение представляет собой масштабный ИТ-проект, требующий участия квалифицированных аналитиков.

Тарифы

Лицензирование по количеству пользователей, расчет стоимости владения (TCO) предоставляется по запросу.

7. Битрикс24 (Scrum/Задачи)

Битрикс 24 — это популярный корпоративный портал, объединяющий инструменты коммуникации, CRM и модуль управления задачами с поддержкой методологии Scrum.

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

Соответствие Jira

• Наличие инструмента «Скрам»: бэклог, управление спринтами, оценка в Story Points, эпики, диаграмма сгорания задач;
• Поддержка Канбан-досок, диаграмм Ганта, учета времени;
• Инструменты автоматизации (роботы) для изменения статусов задач.

Миграция из Jira

Реализуется с помощью специализированных приложений из встроенного маркетплейса.

Плюсы

• Комплексный подход (Всё-в-одном): чаты, видеозвонки, задачи, документы, календарь и CRM доступны в едином, привычном интерфейсе;
• Доступность и поддержка: систему можно развернуть за один день, а на рынке присутствует широкая сеть партнеров-интеграторов для любой доработки;
• Гибкое ценообразование: оптимальное соотношение цены и функциональности, особенно для небольших команд.

Минусы

• Модуль Scrum не обладает достаточной глубиной для сложной Enterprise-разработки (управление релизами, техническим долгом, глубокая интеграция с репозиториями);
• Многообразие не-ИТ функций портала может перегружать интерфейс для профильных разработчиков.

Тарифы

Гибкая линейка: от бесплатных облачных тарифов до коробочных версий (On-premise) для корпоративного сектора. Стандартный облачный тариф (до 50 пользователей) — 4893 руб./мес за всех пользователей.

8. WEEEK

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

Для кого: продуктовые команды, стартапы, маркетинговые агентства, отдающие предпочтение современному дизайну и удобству использования (в стиле Notion).

Соответствие Jira

• Управление задачами в форматах списков, Канбан-досок и календаря;
• Встроенная база знаний для ведения документации;
• Отсутствует поддержка сложных JQL-запросов и многоуровневых кастомных workflow.

Миграция из Jira

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

Плюсы

• Эстетика и современный UX/UI: продуманный дизайн, в котором командам действительно приятно и комфортно работать ежедневно;
• Универсальность: платформа успешно заменяет сразу несколько узкоспециализированных сервисов (например, связку Trello + Notion + простую CRM);
• Доступность: наличие полнофункционального бесплатного тарифа для микро-команд.

Минусы

• Не ориентирован на сложную инженерную разработку (отсутствуют глубокие аналитические отчеты по релизам и интеграции с Git);
• Функционал находится в стадии активного развития.

Тарифы

Облачная версия от 199 ₽/мес за пользователя. Доступна бесплатная версия для команд до 5 человек.

9. Directum Projects

Directum Projects — это корпоративная система управления проектами, исторически развившаяся из мощной платформы электронного документооборота (СЭД).

Для кого: крупный бизнес, государственный сектор и промышленные предприятия, где проектное управление тесно связано с формализованным документооборотом и строгими регламентами.

Соответствие Jira

• Поддерживает визуализацию на Agile-досках (Scrum/Kanban);
• Основной упор сделан на классическое каскадное управление (Waterfall), мощные диаграммы Ганта, ресурсное планирование и работу с проектной документацией.

Миграция из Jira

Выполняется проектной командой в рамках внедрения системы.

Плюсы

• Синергия с документооборотом: глубокая, нативная интеграция с системами электронного документооборота (СЭД Directum);
• Управление по PMBOK: профессиональный инструмент для проектных офисов (PMO), обеспечивающий контроль сроков, вех и бюджетов.

Минусы

• «Корпоративный» интерфейс может потребовать адаптации со стороны Agile-команд разработчиков;
• Система менее сфокусирована на специфике гибкой продуктовой разработки ПО.

Тарифы

Преимущественно On-premise поставки. Корпоративное лицензирование (ориентировочно от 7400 ₽ за пользователя в год).

10. Мегаплан

Мегаплан — это широко известная на российском рынке CRM-система, оснащенная развитым модулем управления задачами и поручениями.

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

Соответствие Jira

• Иерархия: задачи, подзадачи, чек-листы;
• Диаграммы Ганта для визуального планирования сроков;
• Инструменты учета рабочего времени и планирования загрузки сотрудников;
• Отсутствует специализированный ИТ-инструментарий (спринты, эпики, интеграции с репозиториями кода).

Миграция из Jira

Доступен базовый перенос данных через экспорт/импорт CSV-файлов.

Плюсы

• Стабильность и простота: легкость внедрения, простота освоения пользователями и высокая стабильность работы;
• Связка процессов: возможность в одном окне интегрировать процессное управление с продажами (CRM) и финансами;
• Мобильность: качественное и полнофункциональное мобильное приложение.

Минусы

• Не является профильным инструментом для разработчиков ПО; не подходит в качестве полноценной замены Jira для ИТ-подразделений;
• Сложности при масштабировании на крупные кросс-функциональные ИТ-проекты.

Тарифы

Доступны облачная (SaaS) и коробочная версии. Базовый тариф — 315 руб./мес за пользователя при покупке на год. Расширенный тариф (с бо́льшим функционалом) — 630 руб./мес за пользователя.

Сравнительная таблица: Jira vs российские аналоги

Мы свели ключевые функции для ИТ-разработки в единую таблицу. Вместо простых галочек «есть/нет», мы описали уровень реализации каждой функции, чтобы вы могли наглядно оценить, какие аналоги Jira лучше всего закроют ваши потребности.

Таблица наглядно демонстрирует: для гибких Agile-команд отлично подходят легкие решения вроде Kaiten, но если вам нужна полноценная замена Jira для Enterprise-разработки с жесткими воркфлоу, глубокой интеграцией с кодом и продуктовой иерархией, ближе всего к оригиналу стоят специализированные системы — SimpleOne SDLC и TeamStorm.

Балльная оценка готовности систем заменить Jira (для ИТ-разработки)

Чтобы дать вам быстрый срез, мы оценили системы по 10-балльной шкале именно в контексте разработки программного обеспечения и близости к методологии Jira.

Примечание: Низкий балл не означает, что система плохая. Он лишь показывает, что решение (например, YouGile, WEEEK или Мегаплан) сфокусировано на других задачах (коммуникация, продажи, универсальный трекинг) и не является прямым аналогом Jira для хардкорной инженерной разработки и управления релизами.

Критерии выбора аналога Jira в 2026 году

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

1. Масштаб и поддерживаемая методология. Для небольших команд (до 10-15 человек), работающих над внутренними проектами, оптимально подойдут легкие решения вроде Kaiten или YouGile. Для крупных ИТ-департаментов (от 100 разработчиков), создающих сложные продукты и применяющих фреймворки масштабирования (SAFe), необходимы платформы Enterprise-уровня (например, SimpleOne SDLC), поддерживающие сложную продуктовую иерархию «из коробки».
2. Глубина кастомизации процессов. Если ваши процессы требуют сложной логики переходов статусов (например, задача переходит в тестирование только после согласования техлидом и заполнения обязательных полей), выбирайте платформы на базе Low-code, позволяющие настраивать workflow без программирования.
3. Интеграция с процессом разработки. Полноценный аналог Jira должен бесшовно интегрироваться с вашими репозиториями (GitLab, GitHub). Автоматическая смена статусов задач на основе коммитов существенно повышает прозрачность разработки.
4. Безопасность и варианты развертывания. Для компаний финансового сектора и организаций с государственным участием обязательным требованием является наличие On-premise версии и включение продукта в Реестр отечественного ПО.

Как мигрировать с Jira на российский аналог: пошаговый план

Процесс миграции с Jira требует тщательного планирования. Рекомендуем придерживаться следующего алгоритма:

Шаг 1: Аудит текущей конфигурации Jira.

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

Шаг 2: Маппинг сущностей.

Составьте таблицу соответствия терминологии. Например, тип задачи Issue Type «Bug» в Jira должен соответствовать типу «Дефект» в новой системе.

Шаг 3: Тестовый перенос (Пилотный запуск).

Выберите один репрезентативный проект и осуществите его перенос в новую систему (используя встроенные инструменты импорта или API). Проверьте корректность переноса вложений, комментариев, авторов задач и связей между ними (например, blocks/depends on).

Шаг 4: Настройка ролей и бизнес-логики.

Воспроизведите утвержденные маршруты движения задач (workflow) и настройте ролевую модель доступа в выбранной платформе.

Шаг 5: Обучение проектных команд.

Проведите установочные сессии для разработчиков и менеджеров продуктов, продемонстрировав принципы работы с бэклогом и создания дефектов в новом интерфейсе. Подготовьте краткие памятки (Cheatsheets).

Шаг 6: Финальная миграция и заморозка Jira.

Переведите Jira в режим «только чтение» (Read-only) перед выходными. За выходные выгрузите «дельту» (изменения, произошедшие с момента тестового переноса) и импортируйте ее в новую систему. В понедельник утром команда начинает работать в новом трекере.

Чек-лист: 10 вопросов перед заменой Jira

Перед тем как подписать договор с новым вендором, задайте эти вопросы себе и интегратору:

1. Какие функции и плагины Jira мы используем реально, а какие были установлены «на всякий случай»?
2. Обладает ли предлагаемый аналог готовым инструментом (скриптом или коннектором) для импорта данных из Jira (пользователи, история статусов, вложения)?
3. Насколько прозрачна модель ценообразования: оплата взимается за пользователей, проекты или отдельные модули? Предусмотрены ли скрытые платежи?
4. Способна ли новая система обрабатывать наши объемы данных (десятки тысяч задач) без деградации производительности?
5. Включает ли стоимость лицензии базовую техническую поддержку и помощь в процессе миграции?
6. Сможем ли мы беспрепятственно экспортировать свои данные (например, в форматах CSV/JSON) при необходимости смены системы в будущем?
7. Имеет ли вендор подтвержденные кейсы миграции с Jira в компаниях сопоставимого с нами масштаба?
8. Поддерживает ли система «из коробки» нативные интеграции с нашим ИТ-стеком (Git, системы CI/CD, корпоративные мессенджеры)?
9. Соответствует ли архитектура решения требованиям безопасности (ФЗ-152, Реестр Минцифры, возможность On-premise)?
10. Каков реалистичный срок внедрения системы «под ключ» для команды нашего размера?

Заключение

Поиск ответа на вопрос «чем заменить Jira» в 2026 году — это не проблема дефицита, это проблема выбора. Российский рынок предлагает отличные альтернативы, которые давно переросли стадию «импортозамещения ради галочки».

Если вам нужен просто наглядный и быстрый инструмент для Agile-команды, смело смотрите в сторону Kaiten. Если ваша разработка тесно завязана на другие бизнес-процессы компании — вам помогут ПланФикс или ELMA365.

Но если вы крупная продуктовая компания, где сотни разработчиков пишут код, а ИТ-директору нужна прозрачная связь между техдолгом, релизами и инцидентами из техподдержки — вам нужны Enterprise-решения. Платформы вроде SimpleOne SDLC предлагают не просто трекер, а архитектуру, изначально заточенную под масштаб, продуктовый подход и гибкость Low-code настройки, что делает их, пожалуй, наиболее полноценной заменой Jira для серьезного бизнеса на сегодняшний день.

FAQ

Какие российские аналоги полностью заменяют Jira?

Полностью (со всеми тысячами плагинов) скопировать Jira невозможно и не нужно. Но по покрытию базового и продвинутого функционала для разработки (Scrum, Kanban, бэклог, релизы, Git) лучшими российскими аналогами Jira считаются SimpleOne SDLC, TeamStorm и Kaiten.

Сложно ли перенести данные из Jira в российский аналог?

Большинство зрелых российских трекеров уже разработали встроенные утилиты или API-скрипты для миграции. Перенос базовых задач (названия, описания, статусы) обычно проходит гладко. Сложности могут возникнуть при миграции специфических кастомных полей, скриптов автоматизации (ScriptRunner) и данных из редких плагинов.

Сколько стоит переход с Jira на российский аналог?

Совокупная стоимость складывается из двух составляющих: стоимости лицензий на новое ПО (от 400-500 руб/мес за пользователя в облачных версиях до миллионов рублей за Enterprise On-premise решения) и стоимости самого проекта миграции (услуги бизнес-аналитиков и системных интеграторов по настройке процессов и переносу данных).

Какой аналог Jira лучше для скрам-команд?

Для небольших скрам-команд (до 30 человек), которым нужна максимальная визуализация досок и быстрый старт, отлично подойдет Kaiten или YouGile. Для крупных кросс-функциональных скрам-команд в Enterprise-сегменте, работающих над сложными продуктами (например, по SAFe), более мощной альтернативой станет SimpleOne SDLC, так как он поддерживает сложную продуктовую иерархию и связку с ITSM.

Сколько времени занимает миграция с Jira на российский аналог?

Для небольшой команды (до 50 человек) с простыми процессами переезд можно осуществить за 1-2 недели. Для корпорации (500+ пользователей), где нужно перенести сложные воркфлоу, обучить сотрудников и провести интеграции с внутренними системами, проект миграции может занять от 2 до 6 месяцев.

Есть ли альтернативы Jira с хорошими AI-функциями?

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

Реклама. Рекламодатель: ООО «СИМПЛ 1», ИНН 9725013892, erid: 2W5zFFxmVEH

Пизло — человек, от которого обычно ждут постов про «как мы выкрутили очередной трюк в JIT JavaScriptCore». Его прошлые тексты — это FTL JIT, B3, Riptide GC и другие вещи, которые требуют двух лет опыта в компиляторах. Но этот текст — принципиально другой. Он показывает ровно то, о чём обычно не пишут: что делать, когда у вас ещё нет JIT, а GC ещё не является главной болью.

Стартовая версия интерпретатора Zef была в 35 раз медленнее CPython 3.10, в 80 раз медленнее Lua 5.4.7 и в 23 раза медленнее QuickJS-ng 0.14.0. После 21 оптимизации (ни одной из которых не требует SSA-преобразований (static single assignment), переделки сборщика мусора, байткода или машинного кода) тот же интерпретатор проигрывает CPython всего в 2,1 раза, Lua — в 4,8 раза, QuickJS — в 1,35 раза. Если же собрать тем же обычным C++ без Fil-C — Zef становится быстрее CPython в 1,9 раза и быстрее QuickJS в 3 раза.

Представление значений: tagged 64-битные значения с NaN-boxing (упаковка целых и указателей в неиспользуемые биты double) позволяют держать числа на стеке и отличать их от указателей по битам.

Symbols вместо строк: один раз интернировать все имена методов и переменных в Symbol*, потом сравнивать указатели — даёт +18%.

Object Model + Inline Caches + Watchpoints: самый большой прирост (+355%, 4,55x) — одна мегакоммит-оптимизация, без которой остальное не работает.

Специализация мелочей: выделенный AST-узел для a + b вместо строкового a.add(b), Getter/Setter-инференс, специализированные ZeroArguments/OneArgument/TwoArguments.

Штраф Fil-C — 4x: memory-safe C, в котором автор пишет, даёт GC бесплатно, но накладывает штраф; итоговый буст после перехода на обычный C++ — 67x.

О каком интерпретаторе речь

Zef — это учебный динамический язык, который Пизло написал для удовольствия. В нём есть классы с наследованием, приватные поля (по умолчанию), замыкания, кастомные операторы, getter'ы и setter'ы. На уровне идиом он похож на Ruby и тихую версию JavaScript. Исходный интерпретатор — наивный AST-walker, в котором каждая нода — это C++-объект с виртуальным методом Node::evaluate, а все переменные живут в std::unordered_map<std::string, Value>.

Весь исходный код интерпретатора, diff-просмотрщики для каждой оптимизации и бенчмарки выложены на zef-lang.dev/implementation. Бенчмарки — набор ScriptBench1: Richards (OS scheduler), DeltaBlue (constraint solver), N-Body (физика) и Splay (самобалансирующееся двоичное дерево). Все портированы на Zef, Lua, Python и JavaScript.

Одна деталь про измерения: Пизло собирает свой интерпретатор компилятором Fil-C++ — это его собственный memory-safe C, который даёт сборщик мусора из коробки, но платит за это примерно 4x производительности. То есть когда в тексте написано «в 35 раз медленнее CPython», держите в голове, что 4x из этого — стоимость безопасности памяти, а остальные ~9x — это то, что будем выжимать.

Исходная точка: в 35 раз медленнее Python

В базовом варианте Пизло сделал два единственных осознанных про производительность выбора:

• 64-битное tagged-представление значений. Значение может быть int32, double или Object*. Double'ы сдвигаются на 0x1000000000000 — техника из JavaScriptCore, которую в литературе зовут NaN-boxing. Целые и указатели лежат как есть. Это позволяет определить тип значения битовой проверкой и не выделять int'ы в куче.
• Язык — C++. Пизло обосновывает: «Java — потолок низкоуровневых оптимизаций слишком низкий, Rust — сборщик мусора требует глобального изменяемого состояния и циклических ссылок, с этим придётся драться или писать много unsafe».

Всё остальное — сознательные «плохие» решения ради скорости разработки:

• Fil-C++ — штраф 4x, но GC бесплатно.
• Рекурсивный AST-интерпретатор через виртуальные вызовы.
• std::string везде — для имён переменных, методов, полей.
• std::unordered_map везде — на каждый Get переменной идёт хеш-лукап по строке.
• Цепочки рекурсивных вызовов по scope chain: класс внутри функции внутри класса внутри функции — каждый доступ проходит через несколько уровней вызовов.

Результат — 35x медленнее CPython, 80x медленнее Lua, 23x медленнее QuickJS. Дальше — что с этим можно сделать, не переписывая интерпретатор на JIT.

#1–2: Прямой вызов операторов и RMW

В Zef выражение a + b эквивалентно a.add(b). Наивный парсер делает одну и ту же AST-ноду для обоих случаев — DotCall(a, "add", [b]). Каждый плюс превращается в лукап строки "add" в Value::callMethod, который каскадом сравнивает её со всеми возможными именами операторов.

Первая оптимизация — парсер генерирует отдельные ноды Binary<> и Unary<>, каждая со своим виртуальным evaluate, который сразу зовёт Value::add, Value::sub и так далее. Без строковых сравнений на каждый плюс.

+17,5%. Вторая оптимизация делает то же самое для += и аналогов — отдельные ноды SetRMW, DotSetRMW, SubscriptRMW. +3,7%. Итог: 1,22x быстрее старта.

#3: Убрать проверку IntObject из быстрого пути

В базовой версии Value различал четыре случая: tagged int32, tagged double, IntObject (для int64, не влезающих в 32 бита) и всё остальное. Фастпас вызывал isInt(), который через виртуальный вызов спрашивал Object::isInt() — на случай, если под обложкой лежит IntObject.

Правка — пусть Value работает только с int32 и double, а весь int64-код уезжает внутрь IntObject. +1%. Мелочь, но копеечка.

#4: Symbols вместо std::string

Это первый по-настоящему большой прирост. В исходном интерпретаторе std::string — это ключ везде, где есть хеш-лукап: локальные переменные, dot-доступ, имена операторов, имена методов. То есть на каждый x + 1 идут хеширование строки "x", strcmp на каждой коллизии, ещё раз для "+".

Оптимизация — классический interning. Новый класс Symbol. Строки превращаются в Symbol* через глобальный hash-consing — одна строка = один указатель. Равенство Symbol* теперь проверяется сравнением указателей, а хеш-таблицы ключуются по Symbol*, а не по std::string.

Правка большая по количеству затронутых файлов, но по сути тривиальная — меняются сигнатуры функций с const std::string& на Symbol*. +18%. Суммарно: 1,46x быстрее старта.

#5: Value Inline

Простая техника: вынести часть методов Value в отдельный заголовочник valueinlines.h, чтобы они видели типы, которые нельзя было включить в value.h из-за циркулярных зависимостей. Компилятор теперь может их инлайнить в горячих местах. +2,8%.

#6: Объектная модель + inline caches + watchpoints — 4,55x одним махом

Самая большая оптимизация в статье, и единственная, которую Пизло специально защищает:

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

Патч объединяет три независимо бесполезных вещи:

Новая объектная модель: Storage + Offsets

В исходной версии каждый lexical scope выделял объект Context, а внутри Context жил hashmap с «полями» — локальными переменными. Объекты пользовательских классов были хуже: каждый объект содержал hashmap «класс → Context», потому что если Bar наследует Foo, поля у них приватные и могут иметь одинаковые имена — нужно различать, к какому классу относится поле.

Новая идея — Storage, который держит данные по Offsets, вычисленным на этапе resolve AST. Context всё ещё существует, но создаётся заранее, а объекты на рантайме просто выделяют Storage размера, который Context уже посчитал. Доступ к полю становится индексом по offset'у, а не лукапом в хеш-таблице.

Inline caches

Классическая техника — обычно её описывают в контексте JIT-компиляторов. Но здесь Пизло применяет её в интерпретаторе: для каждой AST-ноды типа expr.name запоминается тип, который expr имел в прошлый раз, и offset, куда резолвилось name. Запоминание — через placement-new на месте старой ноды: под той же памятью лежит новая специализированная нода, которая умеет быстрый путь.

Специализация может быть: «прямой load из Storage» (для локальной переменной), «проверка класса + direct call в функцию, которую видели в прошлый раз» (для метода). Плюс chain steps и watchpoints, если access требовал обхода scope chain.

Watchpoints

Представим: класс Foo внутри lexical scope, в котором есть переменная x. Метод Foo обращается к x. Внутри Foo имени x нет. Казалось бы, можно делать доступ без проверок. Но кто-то может унаследовать Foo и добавить геттер с именем x — тогда доступ должен пойти в геттер.

Watchpoint — это пассивный охранник: «если кто-то переопределил имя x в подклассе, инвалидируй мой inline cache». Пока имя не переопределяли, доступ работает на минимальных циклах.

Почему всё вместе

Пизло объясняет, почему эти три вещи не разделить:

• Новая объектная модель без inline caches не даёт никакого прироста.
• Inline caches без watchpoints не могут кешировать большинство интересных случаев — слишком много условий.
• И объектная модель, и watchpoints должны работать вместе с самого начала.

+355% — 4,55x быстрее. После этого Zef в 5,2 раза медленнее CPython, в 11,7 раза медленнее Lua, в 3,3 раза медленнее QuickJS. То есть накладные расходы Fil-C++ (примерно 4x) — это уже почти вся разница. Суммарно: 6,8x быстрее старта.

#7: Arguments — свой тип вместо std::vector

Раньше аргументы функций передавались как const std::optional<std::vector<Value>>&. optional нужен, чтобы отличать геттер-вызов o.getter от функции без аргументов o.function() — в Zef это разные вещи для некоторых типов. То есть каждый вызов аллоцировал std::vector, копировал его, и ещё раз копировал в scope функции.

Правка — новый тип Arguments, физически совпадающий с layout scope, который callee создаст. Caller выделяет его напрямую, callee не копирует. Плюс в Fil-C++ std::optional всегда живёт в куче из-за специфики invisicaps — это отдельный штраф. +33%.

#8–10: Специализация геттеров, сеттеров и callMethod

Много методов в Zef устроены тривиально:

Это запись readable f. Метод fn f f — просто чтение переменной. Гонять это через полноценный eval AST'а расточительно. Оптимизация #8 — инференс: если тело функции — это просто Get, заменяем UserFunction на специализированный GetterFunction, делающий load по известному offset'у. +5,6%.

Оптимизация #9 — то же самое для сеттеров (fn set_x(v) x = v). Инференс сложнее — нужно матчить параметр сеттера как источник присваивания. +3,4%. Оптимизация #10 — тривиальная однострочная: inline-инг callMethod в заголовочник. +3,2%. Суммарно: 10,2x быстрее старта.

#11: Глобальная hashtable для method dispatch

Когда inline cache промахивается, старый путь лез через ClassObject::tryCallMethod и tryCallMethodDirect, которые делают два хеш-лукапа на каждый уровень иерархии наследования: «есть ли метод в этом классе» и «есть ли вложенный класс с этим именем». O(depth × 2).

Правка — глобальный hashmap (ClassObject*, Symbol*) → callee, который запоминает все успешные резолвы. Промах по IC теперь — один лукап в эту таблицу, и только если её нет — полный медленный путь. +15%. Суммарно: 11,8x.

#12: Избавиться от std::optional на горячем пути

В Fil-C++ std::optional почти всегда аллоцируется в куче — из-за особенностей union-типов и invisicaps. LLVM может непредсказуемо потерять capabilities указателей внутри union'ов; Fil-C++ компилятор страхуется и вставляет интринсики, которые заставляют всё, что выглядит как union, аллоцировать на heap.

Правка — обход кода, ведущего к std::optional на горячем пути. +1,7%. Важный сайд-эффект для тех, кто пишет на Fil-C++: избегайте union-типов в горячем коде.

#13: ZeroArguments, OneArgument, TwoArguments

Большинство встроенных функций Zef берут 0, 1 или 2 аргумента. Им не нужен полноценный Arguments-объект — он просто занимает память. Три новых типа: ZeroArguments, OneArgument, TwoArguments. Функции шаблонизируются и инстанцируются отдельно для каждого.

ZeroArguments нужен отдельно, потому что (Arguments*)nullptr уже используется для геттер-вызова. Теперь ZeroArguments означает «функция без аргументов». +3,8%.

#14: Slow paths Value через static + by value

Раньше медленные пути Value были member-функциями и принимали неявный const Value*. Значит, caller должен был stack-аллоцировать Value. В Fil-C++ любая stack-аллокация это heap-аллокация.

Правка — сделать эти методы static и принимать Value по значению. Аллокации не нужны. +10%. Суммарно: 13,6x. Это ещё одна «специфичная для Fil-C++» оптимизация, которая в Yolo-C++ (обычный C++) была бы бесплатной по умолчанию.

#15–17: Дедупликация, быстрый sqrt и toString

#15 — «оптимизация» в кавычках: убрать дублированный код в DotSetRMW. Пизло надеялся на прирост от уменьшения кода. Прироста нет — но код чище.

#16 — специализация Dot-ноды для value.sqrt. Inline caches хороши для объектов, но для числовых примитивов они не работают — там фастпас другой, через Binary<>/Unary<>. sqrt в базовом варианте летел через общий путь. Теперь — свой специализированный код. +1,6%.

#17 — то же самое для toString. Плюс чуть меньше аллокаций при конвертации int → string. +2,7%. Суммарно: 14,2x.

#18: Специализация литералов массивов

Код вроде my whatever = [1, 2, 3] по-старому каждый раз спускался в AST и вычислял 1, 2, 3. Но если литерал константный — результат известен на парсинге.

Оптимизация — специализированная ArrayLiteral-нода, которая при вычислении просто копирует заготовленный массив значений. +8,1%. Суммарно: 15,35x.

#19: Value::callOperator по значению

Та же идея, что в #14 — не передавать Value по ссылке в медленный путь callOperator, а принимать его по значению. Ещё одна Fil-C++-специфичная аллокация убирается. +6,5%. Суммарно: 16,3x.

#20–21: Настройки компилятора и отключение ассертов

#20 — билд-система: отключить RTTI и libc++ hardening, потому что Fil-C++ их всё равно перекрывает. Ни одного изменения в C++-коде, только флаги сборки. +1,8%.

#21 — отключить по умолчанию ассерты. Код использовал макрос ZASSERT (всегда проверяет). Замена на ASSERT (только если ASSERTS_ENABLED) должна была дать прирост, но — не дала. Зато готовит код к сборке в обычном C++.

После 21 оптимизации: 16,6x быстрее старта. Zef в 2,1x медленнее CPython, в 4,8x медленнее Lua, в 1,35x медленнее QuickJS. Стартовали с 35x, 80x и 23x разрывов — оказались в окрестностях конкурентов, без строчки JIT.

Переход на обычный C++ — ещё 4x

Финальный эксперимент — собрать тот же код обычным C++ (GCC 11.4.0) вместо Fil-C++. Пизло называет это Yolo-C++ — без гарантий безопасности памяти. Получается ещё 4x. Суммарно: 67x быстрее базовой версии. Zef в 1,9x быстрее CPython 3.10, в 1,2x медленнее Lua и в 3x быстрее QuickJS.

Сборка неидеальна: вместо Fil-C++ GC там calloc, память не освобождается — интерпретатор течёт, просто ScriptBench1 слишком короткий, чтобы это заметить. С реальным GC Yolo-C++-версия была бы ещё быстрее.

В этот момент Zef в 1,9 раза быстрее CPython 3.10, в 1,2 раза медленнее Lua 5.4.7 и в 3 раза быстрее QuickJS-ng 0.14.0. Мы стали в 67 раз быстрее, чем там, где начали.

Итоговая таблица всех оптимизаций

Что получается по ходу работы — в одной таблице (геосреднее по четырём бенчмаркам, чем быстрее, тем лучше):

Выводы

Главное в этом тексте Пизло — не сами оптимизации, а то, что они все простые. SSA здесь нет. GC переделывать не надо. Байткода нет. Машинного кода нет. Есть базовые вещи: не хешировать строки (Symbols), не аллоцировать лишнее (Value by value, специализированные Arguments), не ходить по hashmap'ам (Offsets + IC), запомнить то, что уже видели (inline caches), инвалидировать кеш только когда реально что-то поменялось (watchpoints).

Для тех, кто пишет интерпретатор с нуля — список в статье Пизло работает как чеклист. Первые оптимизации (#1–#5) дают суммарные 1,5x — они дешёвые. #6 даёт 4,55x — это день работы, но переворачивает игру. Всё остальное — серия из 3–8% приростов, которые в сумме добирают разницу.

Для тех, кто хочет потом написать JIT — эта статья объясняет, как выглядит база, на которую JIT потом ложится без сюрпризов. NaN-boxing, новая объектная модель, IC и watchpoints — это ровно то, что должно быть у интерпретатора до того, как вы начнёте генерировать машинный код.

Оригинал: How To Make a Fast Dynamic Language Interpreter, Filip Pizlo, 21 апреля 2026 года. Автор — один из ключевых инженеров WebKit JavaScriptCore, автор FTL JIT, B3, Riptide GC.

Джон Чартер в статье «Things you didn't know about indexes» разбирает не только базовые принципы B-tree, но и три типа индексов, о которых новичкам не рассказывают: функциональные, частичные и покрывающие. Переводим полностью, с примерами на таблице покемонов и объяснением, почему EXPLAIN — ваш лучший друг.

Индексы ускоряют чтение, но замедляют запись. INSERT, UPDATE и DELETE обновляют каждый индекс — восемь индексов на таблице значат восемь дополнительных обновлений.

Композитный индекс (type_1, type_2) работает для запросов на type_1 и на обе колонки вместе, но не для запросов только на type_2. Порядок колонок важен.

Функция над индексированной колонкой убивает индекс. WHERE lower(name) = 'pikachu' не использует индекс на name — нужен функциональный индекс на lower(name).

Частичный индекс с WHERE покрывает только нужные строки. Для soft-delete или редких флагов экономит место и ускоряет запись.

Покрывающий индекс с INCLUDE отвечает на запрос без похода в таблицу — в EXPLAIN это Index Only Scan.

Не угадывайте — используйте EXPLAIN ANALYZE. Он показывает реальный план запроса и реальное время выполнения.

Начнём с того, что вы, вероятно, уже знаете

Индекс в базе данных похож на алфавитный указатель в конце учебника. Хотите найти страницы про фосфор? Идёте в конец, находите тему и номера страниц рядом с ней:

Представим таблицу покемонов:

Без индекса поиск Пикачу означает, что база прочитает каждую строку, проверяя колонку name. На четырёх строках это мгновенно. На десяти миллионах — уже проблема. Такое чтение называется full table scan, и оно не медленное само по себе: современные базы легко прошивают миллионы строк в секунду. Проблема в линейной сложности — удваиваете число строк, удваиваете время. Индексный поиск этой разницы почти не замечает.

Но если добавить индекс на name, получится примерно то же, что указатель в учебнике:

Данные отсортированы, поэтому база может сделать бинарный поиск по имени и найти нужную строку, а не сканировать всю таблицу. Под капотом Postgres хранит это как B-tree (сбалансированное дерево), но идея такая же, как в учебнике: отсортированные данные, по которым можно быстро искать.

Итак, индексируем всё подряд, верно? Не так быстро.

Цена индексации

Как бы ни хотелось проиндексировать всё, у индексов есть компромиссы. Главное правило:

Чтение ускоряется, запись замедляется.

С новым блестящим индексом каждый INSERT, UPDATE и DELETE должен обновить и индекс тоже. Когда мы добавляем нового покемона, база находит правильное место в отсортированном индексе имён и вставляет его туда. А индексов может быть несколько — умножайте эту работу на каждый из них.

Плюс индексы — это реальные структуры данных, и их нужно хранить. Они живут на диске и подгружаются в память: в Postgres это shared_buffers. У таблицы с восемью индексами девять объектов, которые конкурируют за буфер, а не один.

И не забываем про планировщик (query planner) — компонент, который перед каждым запросом оценивает варианты доступа к данным и выбирает самый дешёвый. Чем больше индексов, тем больше вариантов он взвешивает, так что время планирования растёт и на быстрых выборках может даже превысить время выполнения.

Отдельный риск на проде. Обычный CREATE INDEX блокирует таблицу на запись до конца построения. На таблице в десятки миллионов строк это минуты недоступности. В production используйте CREATE INDEX CONCURRENTLY — он строит индекс без эксклюзивной блокировки, ценой чуть большего времени и того, что операция может быть прервана и оставить индекс в состоянии INVALID (который надо пересобрать).

Почему ваш индекс не работает

Вы взвесили компромиссы, решили, что индекс уместен. Отлично. Но он не работает как ожидалось: улучшения нет или, хуже того, скорость падает. Разберём типичные грабли.

Композитные индексы и порядок колонок

Возвращаясь к таблице покемонов: вы могли решить, что хороший индекс — это индекс на type_1 и type_2. «Покажи всех покемонов типа Water и Flying» — вполне разумный запрос.

Этот индекс определённо поможет запросам вроде:

Но вот этому — уже нет:

Удивлены? Когда вы создаёте композитный индекс (type_1, type_2), вы просите базу построить структуру примерно такого вида:

Сначала сортировка по type_1, затем по type_2 внутри каждой группы. Для запросов по type_1 индекс отличный, для запросов по type_1 AND type_2 — ещё лучше, но для запросов только по type_2 он не будет использован так, как вы надеетесь. Посмотрите на Flying: он разбросан под Bug, Electric, Fire и Water — базе некуда прыгнуть.

Задайте себе вопрос: какие запросы будут частыми? Если по type_2 вы будете искать так же часто, как по type_1, создайте второй индекс на type_2.

Функции убивают индекс

Поиск без учёта регистра — частая фича. Пользователям всё равно, пишут ли они «Pikachu», «pikachu» или «PiKaChU» — они просто хотят результат. Поэтому можно написать так:

Я бы не обратил на такой запрос особого внимания. Выглядит нормально. У нас есть индекс на name, запрос должен летать. Но, конечно, он не летает.

Почему? Индекс на name, а не на lower(name). Для базы это две совершенно разные вещи. Ваш индекс — это отсортированный список значений вида Bulbasaur, Charmander, Squirtle, Pikachu, а не bulbasaur, charmander, squirtle, pikachu. Так что когда вы просите строки, где lower(name) = 'pikachu', у базы нет отсортированной структуры для этого — и она откатывается к сканированию всей таблицы, приводя каждое имя к нижнему регистру по ходу дела.

Это касается любой функции, оборачивающей колонку. Если база не видит индексированную колонку слева от сравнения, индекс выбывает из игры.

И вот настоящие грабли: неявные преобразования тоже считаются. Классический пример — колонка user_id типа bigint сравнивается со строкой (WHERE user_id = '42') или timestamp сравнивается со строковой датой. Postgres тихо добавит приведение типа — и индекс работать перестанет с тем же эффектом, что и явная обёртка функцией.

Как обойти это? К счастью, можно построить индекс на выражении. Индекс на lower(name) абсолютно валиден, и запрос выше будет использовать его без проблем. К этому мы ещё вернёмся.

Как избежать этих ловушек

Короткий ответ: не гадайте. Измеряйте. Как? Спросите базу.

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

Index Scan — это то, что вы хотите видеть. Значит, база использует индекс. Сравните с проблемным запросом:

Seq Scan значит, что читается каждая строка. Никаких индексов.

Если хотите реальные тайминги вместо оценок планировщика, используйте EXPLAIN ANALYZE. Он действительно запускает запрос и сообщает, что произошло. Попробуйте на запросе, который, как вам кажется, вы понимаете — результаты часто удивляют. А если Postgres тормозит не из-за индексов — у нас есть 12 шагов диагностики, от pg_stat_activity до auto_explain.

Чего вам не рассказывали

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

Сначала оговоримся про типы индексов в целом. Всё, о чём мы пока говорили, — это B-tree, тип по умолчанию в Postgres. Но для нестандартных задач есть другие: GIN для jsonb и полнотекстового поиска, GiST для геоданных и диапазонов, BRIN для огромных таблиц с физически упорядоченными данными (логи, временные ряды), Hash для точного равенства. Ниже речь идёт именно о B-tree — но идеи функциональных, частичных и покрывающих индексов применимы и к другим типам.

Функциональные индексы

Мы затрагивали это в разделе про функции. Проблемный запрос был такой:

Индекс на name не помогает, потому что база ищет строки с lower(name) = ..., а отсортированной структуры для lower(name) у неё нет. Исправление — дать ей такую структуру:

Это функциональный индекс (его ещё называют индексом на выражении). Вместо того, чтобы индексировать сырую колонку, вы индексируете результат выражения, применённого к ней. Конечно, это не ограничивается lower(). Можно индексировать любое детерминированное выражение:

Годится любая функция с меткой IMMUTABLE — в Postgres это означает, что она возвращает одинаковый результат для одинаковых аргументов при любых условиях (в отличие от STABLE, которая детерминирована только в рамках одной транзакции, и VOLATILE).

Но осторожно. Если тянуться к функциональному индексу при первом же случае, это часто плохой запах. Если мы так часто ищем по имени в нижнем регистре, почему мы вообще не храним имя в нижнем регистре? Альтернативы: отдельная колонка name_lower, которую заполняете на вставке; тип citext (case-insensitive text) из одноимённого расширения; или COLLATE с регистронезависимой коллацией. Функциональный индекс — когда изменить хранение уже нельзя.

Частичные индексы

Большинство индексов покрывает каждую строку таблицы. Но иногда вы запрашиваете только её небольшой срез — и индексировать всё подряд расточительно. Напомню: индексы не бесплатны.

В нашей таблице покемонов есть колонка is_legendary. На момент написания существует около 1000 видов покемонов, из которых легендарными считаются всего 80 — меньше 10%.

Представьте приложение с опцией «показать всех легендарных». Изначально так и хочется создать составной индекс:

Это работает, но это перебор. Индекс теперь содержит запись для каждого покемона, а подавляющее большинство — не легендарные. Мы будем платить за хранение и запись 1000 строк, чтобы обслуживать запросы, которым интересны только 80. Более того, поскольку is_legendary — булево, получается структура, где сначала идёт разделение на False и True, и первая группа — это 920 записей мёртвого груза, оплачивающих свою долю каждой записи в таблицу ради запросов, которые их игнорируют.

Частичный индекс покрывает только строки, которые подходят под условие:

Теперь в индексе 80 записей вместо 1000. Он меньше, быстрее в запросах; а запросы вида WHERE is_legendary = true используют его без вопросов. Запросы, которые не подходят под условие (WHERE is_legendary = false), откатываются к full table scan — что вам и нужно. Эти запросы и так матчат почти каждую строку, так что индекс им не особо помог бы.

Любая колонка, где вы почти всегда запрашиваете одно значение, — кандидат на частичный индекс. Представьте индекс на колонке email в таблице users, где у вас реализован soft-delete:

Soft-deleted строки почти никогда не запрашиваются, но без фильтра всё равно раздували бы ваши индексы.

Покрывающие индексы

Когда база использует индекс, чтобы найти строку, это только половина работы. Индекс указывает, где строка лежит, но потом база должна сходить в саму таблицу и забрать остальные колонки, которые запросил запрос. Две поездки.

А что, если я скажу, что так делать необязательно?

Если в индексе уже есть все колонки, которые нужны запросу, база может ответить на запрос из одного только индекса. Это покрывающий индекс. В EXPLAIN вы увидите его как Index Only Scan — три самых сладких слова из возможного вывода EXPLAIN.

Одна важная оговорка. Даже при Index Only Scan Postgres всё же заглядывает в visibility map — битовую карту, которая для каждой страницы таблицы отмечает, видимы ли все её строки всем активным транзакциям. Если страница «грязная» (были недавние UPDATE/DELETE), Postgres всё равно пойдёт в heap за проверкой MVCC. Так что на интенсивно пишущих таблицах регулярный VACUUM (автовакуум обычно справляется) критичен для того, чтобы Index Only Scan оставался «онли».

Вот запрос:

Наш частичный индекс из предыдущего раздела идеально покрывает этот запрос. Индекс на name, отфильтрованный по легендарным, — и запрос просит name легендарных. Всё, что нужно запросу, уже в индексе. Поход в таблицу не нужен.

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

Теперь на такой запрос можно ответить прямо из индекса:

Почему не положить base_attack прямо в индексируемые колонки? Потому что база считает индексируемые колонки тем, по чему нужно сортировать и искать. Если добавить base_attack в ключевые колонки индекса, вы скажете базе сортировать индекс сначала по name, потом по base_attack — дополнительная работа, которая не нужна, если вы ищете только по name. INCLUDE говорит: «тащи эту колонку с собой, но не морочься сортировкой».

Правка автора: когда на самом деле нужен INCLUDE

В комментариях на Reddit автор получил поправку от u/therealgaxbo и обновил статью. Скорость записи — не главная причина использовать INCLUDE для покрывающих индексов: в обоих случаях (колонка в ключе или в INCLUDE) индекс обновляется при каждой записи, разница по нагрузке скромная.

Реальные причины использовать INCLUDE:

Можно включать колонки, у которых типы данных не имеют подходящего operator class для типа индекса (operator class — набор функций сравнения, по которым Postgres строит индекс для конкретного типа; для некоторых типов он просто не определён). Например, колонку box (геометрический прямоугольник) нельзя добавить в B-tree индекс как ключевую — нет оператора «меньше/больше». А через INCLUDE можно.

Можно добавить колонки в уникальный индекс без изменения его семантики уникальности:

Это обеспечивает уникальность только по email, но при этом покрывает запросы, которым нужен user_id.

Выводы

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

Хотите глубже? Сайт Use The Index, Luke научит вас всему, что только можно знать про индексы в разных СУБД. А если вы только начинаете с Postgres — загляните в наши основы PostgreSQL: от установки до первых запросов.

И не забудьте запустить EXPLAIN ANALYZE хотя бы на одном запросе сегодня — результаты могут вас удивить.

Источник: jon.chrt.dev — Things you didn't know about indexes

Сальваторе Дипьетро (Salvatore Dipietro) из AWS сообщил: на Linux 7.0 с планировщиком PREEMPT_LAZY throughput PostgreSQL упал до 0,51x по сравнению с Linux 6.x. То есть база данных стала работать почти вдвое медленнее — и виновата одна строка в ядре.

• Linux 7.0 убрал режим PREEMPT_NONE — остались только Full и Lazy preemption
• Throughput PostgreSQL на Linux 7.0 упал до 0,51x (50 751 tps против 98 565 tps на Linux 6.x)
• Причина: планировщик прерывает поток, держащий spinlock, — 55% CPU уходит на spinning в ожидании
• Revert-патч восстанавливает производительность до 1,94x
• Linux 7.0 stable выйдет примерно через 2 недели; Ubuntu 26.04 LTS будет на нём

Как обнаружили регрессию

Дипьетро тестировал на EC2 m8g.24xlarge с 96-vCPU процессором Graviton4. Стенд: PostgreSQL 17, утилита pgbench, 1024 клиента, 96 потоков, длительность теста — 1200 секунд. Это типичная нагрузка высоконагруженного OLTP-сервиса.

На Linux 6.x результат составил 98 565 tps. На Linux 7.0 с PREEMPT_LAZY — 50 751 tps, то есть падение до 0,51x. После применения revert-патча производительность выросла до 1,94x относительно Linux 6.x — и достигла 98 565 tps.

Почему ядро изменили и при чём здесь spinlocks

Виновен коммит 7dadeaa6e851 за авторством Питера Зийлстры (Peter Zijlstra) из Intel. В Linux 7.0 убрали режим PREEMPT_NONE: теперь доступны только Full и Lazy preemption. По умолчанию включён PREEMPT_LAZY.

Проблема в том, как PostgreSQL реализует spinlocks. Функция s_lock() в StrategyGetBuffer/GetVictimBuffer крутится в ожидании блокировки. При PREEMPT_LAZY планировщик может вытеснить поток прямо в тот момент, когда он держит spinlock. Все остальные потоки, ожидающие этот замок, начинают активно спиниться — и по замерам 55% CPU уходит именно на это бесполезное ожидание. Затронуты все основные архитектуры: arm64, x86, powerpc, riscv, s390, loongarch.

PREEMPT_NONE означает, что задача будет выполняться до явного вызова schedule() или возврата из системного вызова/прерывания. Это исторически использовалось для серверных нагрузок с активным ожиданием, но мы убираем этот режим — он маскирует проблемы с блокировками вместо того, чтобы их решать.

Патовая ситуация: кто должен чинить?

Разработчики ядра считают, что проблема на стороне PostgreSQL: база данных должна использовать механизм rseq (Restartable Sequences) — расширение Linux, позволяющее коду пространства пользователя эффективно работать с критическими секциями без spinlock-спиннинга.

Правильное решение — использовать rseq time slice extension. Spinlock-спиннинг в пространстве пользователя изначально является проблемным паттерном в вытесняющей многозадачной среде.

Но PostgreSQL rseq не поддерживает, и никаких сроков интеграции нет. Это классический тупик: ядро меняет поведение, опираясь на «правильную» архитектуру, а прикладное ПО годами использует привычные примитивы. В итоге пострадают администраторы баз данных, которые просто обновят ядро.

Что делать администраторам PostgreSQL

До тех пор, пока проблема не решена на уровне ядра или PostgreSQL, администраторам баз данных стоит учитывать следующее:

• Не обновляться на Linux 7.0 в production до появления официального патча или workaround
• Отслеживать параметр preemption model ядра при обновлении дистрибутива
• Ubuntu 26.04 LTS, выходящая примерно в конце апреля 2026, будет использовать Linux 7.0 — проверить совместимость заранее
• При необходимости использовать кастомное ядро с revert-патчем коммита 7dadeaa6e851
• Следить за обновлениями в PostgreSQL hackers mailing list и linux-kernel mailing list

Регрессия производительности PostgreSQL на Linux 7.0 — наглядный пример того, как изменение в ядре может затронуть критическую инфраструктуру. До появления официального решения (патч ядра или поддержка rseq в PostgreSQL) администраторам баз данных следует воздержаться от обновления ядра в production-окружениях. Отслеживать развитие ситуации можно на Phoronix.

Автор блога Database Doctor провёл серию бенчмарков на DuckDB и PostgreSQL (подробнее о нём — в нашем гайде по PostgreSQL), сравнив классическую размерную модель (dimensional model) с подходом «One Big Table». Результаты оказались неожиданными для многих — JOIN не просто «не дорогой», он зачастую быстрее плоской таблицы.

— JOIN в колоночных СУБД (DuckDB) обходится дешевле, чем сканирование широкой OBT-таблицы, уже начиная с 4–6 колонок

— Стоимость сканирования OBT растёт нелинейно (примерно O(n log n)) с увеличением числа колонок

— В строковых хранилищах (PostgreSQL) JOIN тоже выигрывает на большинстве сценариев

— Ральф Кимбалл описал эти закономерности ещё в 1996 году в своей классической книге о размерном моделировании

— Даже при «бесконечном I/O» денормализация не экономит CPU — она его тратит

Постановка эксперимента

Рассмотрим два конкурирующих подхода к моделированию данных:

• Размерная модель (dimensional model) — атрибуты продуктов хранятся в отдельной таблице product, и мы делаем JOIN с таблицей sales каждый раз при чтении
• One Big Table (OBT) — все атрибуты продуктов заранее «вклеены» в таблицу sales_obt, и мы читаем данные через SELECT без JOIN

Очевидно, что вторую таблицу дороже строить в ETL-пайплайне. Но какая из них потребляет меньше CPU при чтении?

Размерная модель

Схема данных:

Здесь c01 ... c20 — строковые колонки с атрибутами продуктов. Кардинальности:

• product — 100 000 строк; каждая из колонок c01–c20 содержит ~100 уникальных значений (MD5-хеши)
• sales — 1 миллиард строк со случайным v и равномерно распределённым id_product

Эта модель, где сущность (product) хранится отдельно от фактов (sales), называется размерной моделью (dimensional model). Подробнее о ней — в конце статьи.

Генерация тестовых данных

Сначала создаём seed-таблицу — универсальный способ генерации последовательности чисел, который работает практически на всех SQL-платформах:

Примечание: да, можно было бы использовать INSERT ... VALUES с несколькими кортежами, но не каждая аналитическая БД поддерживает этот синтаксис. Зато UNION ALL работает, кажется, вообще везде.

С помощью seed-таблицы генерируем миллиард строк для sales:

Таблицу product заполняем MD5-хешами для получения строковых значений с контролируемой кардинальностью:

Примечание: да, можно было бы взять ровно 100 различных значений вместо ~101 для c01–c20, но с приведённым выше кодом проще.

Модель «One Big Table»

На другой стороне ринга — заранее объединённая широкая таблица:

Гипотеза: JOIN медленнее, чем плоская таблица

Итак, вопрос: что быстрее?

Размерная модель с JOIN:

Или OBT без JOIN:

Если «JOIN — это дорого», то размерная модель должна быть медленнее. Мы также должны увидеть более высокое потребление CPU.

Чтобы быть максимально нечестным по отношению к размерной модели, автор запускает тесты на системе, где вся база помещается в оперативную память. Так мы моделируем «бесконечный I/O» и не платим за дисковые операции.

Результаты DuckDB

Тестовая машина: ноутбук с 14 ядрами, 32 ГБ RAM, SSD на 3 ГБ/с. Размер базы — 45 ГБ, из которых sales_obt занимает ~40 ГБ. DuckDB отлично утилизирует ядра: CPU загружен на 100% во время выполнения запросов.

Для тестов автор использовал серию запросов с нарастающим числом колонок:

Примечание: DuckDB использует написание EXPLAIN ANALYZE (а не ANALYSE). В оригинале автор шутит, что DuckDB «правильно» использует британское написание — но на самом деле в DuckDB работает американский вариант.

Базовый замер (measurement 0) — просто чтение v: мы платим за JOIN, но не запрашиваем колонки из product. Читатели, которых интересует эта крайняя ситуация и способы оптимизации, могут изучить тему join elimination в планировщиках запросов. Каждый запрос выполняется трижды, берётся лучшее время.

Время выполнения (wall clock)

Выводы из графика:

• При запросе 1–2 колонок OBT незначительно быстрее
• С ростом числа колонок стоимость OBT взлетает — до 15 секунд при 20 колонках
• JOIN остаётся практически константным по времени (~1 секунда) независимо от числа колонок
• Рост OBT напоминает O(n log n) — нелинейная зависимость

Потребление CPU

DuckDB позволяет замерить CPU-время по каждому оператору в запросе:

Та же закономерность: OBT при 20 колонках потребляет ~200 секунд CPU, тогда как размерная модель — всего ~15 секунд (scan + join). Разница — на порядок.

Почему JOIN быстрее при масштабировании?

Казалось бы, мы читаем каждую строку. Почему не быстрее просто отдать её из плоской таблицы?

Ответ кроется в том, как работают колоночные хранилища (DuckDB, Parquet и другие):

1. Декомпрессия колонок. Сжатые строки хранятся в словаре (dictionary encoding). Чтобы получить данные, движок «соединяет» указатели в сегментах сжатия со словарём. Это по сути тоже своего рода JOIN — но уже внутри Storage Engine. В размерной модели строки уже «материализованы» в таблице product, и эта «декомпрессия» фактически заранее выполнена
2. Сборка строк из колонок. В колоночном формате данные каждой колонки хранятся отдельно. Чтобы собрать строку, нужно пройти по метаданным, найти местоположение каждой колонки и скопировать данные в финальный результат. Каждая колонка — это отдельная аллокация (и деаллокация) памяти. Именно этот механизм, вероятно, и даёт нелинейный рост стоимости сканирования широкой OBT-таблицы

А что насчёт строковых хранилищ?

Не все базы данных используют колоночное сжатие. Строковые хранилища (row stores) хранят данные в формате строк (аналогично AVRO в мире Data Lake).

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

Вопрос: может быть, для OBT лучше использовать строковое хранилище? Давайте проверим.

Гипотеза автора

В пользу OBT в строковом хранилище:

• Данные можно отдать напрямую, без «сборки» строк из колонок
• Не нужна «неявная декомпрессия» сжатых строк
• JOIN на строковых форматах медленнее, чем на колоночных — нельзя векторизовать хеширование

В пользу JOIN:

• Если нужна часть колонок, проекция (отбрасывание ненужных) стоит CPU — это неявный memcpy
• Больший объём данных при сканировании — больше работы с буферами
• У JOIN лучше кеш-локальность для строк — меньше TLB-промахов

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

Тест на PostgreSQL 17

Для теста автор выбрал PostgreSQL 17 — классическое строковое хранилище. Датасет уменьшен до 1% (10 млн строк в sales, 10 000 строк в product), но и так sales_obt занимает 7 ГБ.

Чтобы убрать стоимость сериализации результата для клиента, вместо SELECT * используется:

Примечание: PostgreSQL сериализует результат в клиентский формат даже при EXPLAIN ANALYZE. Это дополнительная работа, которой лишены системы, использующие Arrow-буферы, — там промежуточная сериализация не нужна.

Чтобы убедиться, что PostgreSQL не «хитрит» с NULL-проверкой в COUNT, автор проверил план выполнения. Видно, что агрегат действительно работает со строкой, ширина которой пропорциональна числу входных колонок:

Выводы:

• Как и предполагалось, стоимость «проекции» (отбрасывания ненужных колонок) доминирует при малом числе колонок — OBT проигрывает
• Вопреки ожиданиям, даже в базовом случае (0 колонок из JOIN) размерная модель оказывается быстрее
• Красивая линейная зависимость: строковое хранилище масштабируется предсказуемо в обоих случаях
• JOIN выигрывает или проигрывает OBT с минимальной разницей — но тренд в пользу JOIN

Глубокое погружение: что именно тормозит PostgreSQL?

С помощью EXPLAIN (ANALYZE, BUFFERS) автор убедился, что запрос работает полностью в памяти:

shared hit=909120 означает, что все буферы были прочитаны из памяти (shared buffers), без обращения к диску. PostgreSQL форкает процесс на каждое соединение, поэтому профилировать конкретный запрос можно через SELECT pg_backend_pid().

Автор использовал Windows Performance Recorder для профилирования PostgreSQL на 16-колоночном запросе:

Два самых горячих вызова:

1. tts_buffer_heap_getsomeattrs (файл execTuples.c) — по сути, неоптимальный memcpy. Эта функция копирует данные из буферного пула в представление кортежа. Именно та «проекция», которую автор предсказывал — но реализованная неэффективно
2. ExecInterpExpr (файл execExprInterp.c) — интерпретатор выражений. Современные БД используют векторизованное или компилированное выполнение; PostgreSQL по умолчанию интерпретирует через гигантский switch-блок (JIT-компиляция через LLVM доступна с PG 11, но не используется на дефолтных настройках для дешёвых запросов). Основной вызывающий — ExecAgg: подсчёт COUNT обходится почти так же дорого, как само чтение данных

Важная оговорка: PostgreSQL — не идеальный представитель строковых хранилищ. Базы данных с компилируемыми запросами могут быть значительно быстрее при «сыром сканировании». Тем не менее, строковые хранилища, похоже, почти всегда выигрывают от использования JOIN — если только вы не планируете выбирать практически все колонки из OBT в каждом запросе. Даже денормализация одной колонки ради экономии CPU может оказаться ошибочной.

Как автор собирал PostgreSQL с отладочными символами

Для профилирования PostgreSQL нужны debug-символы. Ни пакет Chocolatey, ни установщик EnterpriseDB их не включают — пришлось собирать из исходников на Windows.

Необходимые пакеты:

Файл msvc.ini в корне репозитория PostgreSQL:

Сборка:

Размерная модель: уроки прошлого

Всё, что мы наблюдаем, не ново. Ещё в 1996 году Ральф Кимбалл опубликовал книгу «The Data Warehouse Toolkit», которая до сих пор переиздаётся и считается классикой.

Кимбалл аргументировал:

• Большие аналитические таблицы (факты) должны содержать только метрики (то, что агрегируется) и целочисленные ключи измерений (то, по чему делается JOIN)
• Все атрибуты сущностей хранятся в отдельных таблицах измерений (dimension tables), к которым присоединяются через foreign key
• Колонки с высокой кардинальностью и единственным значением лучше хранить прямо в таблице фактов — «вырожденные измерения» (degenerate dimensions). Это идеально соответствует нашему наблюдению: чтение одной колонки через JOIN действительно немного медленнее

Кимбалл также рекомендовал объединять связанные таблицы внутри самого измерения (делая таблицу измерения шире) — но только для измерений, не для фактов. И делал он это не ради производительности, а для упрощения работы оптимизатора запросов.

Итоги

Главный вывод:

«JOIN — НЕ дорогая операция по сравнению с альтернативами»

Что мы выяснили:

• Даже при чтении всех строк JOIN зачастую дешевле, чем сканирование One Big Table
• В колоночных хранилищах (DuckDB) преимущество JOIN проявляется начиная с 4–6 колонок и растёт нелинейно
• В строковых хранилищах (PostgreSQL) JOIN тоже выигрывает на большинстве сценариев
• «Жертвовать диском ради экономии CPU на JOIN» — это миф, который противоречит измерениям
• Размерное моделирование (Кимбалл, 1996) — не устаревшая методология, а эффективный инженерный подход

Важно помнить: мы тестировали JOIN большой таблицы (1 млрд строк) с маленькой (100 000 строк). Что произойдёт при JOIN двух больших таблиц — вопрос для отдельного исследования.

В следующей статье автор обещает разобрать, что происходит с производительностью при добавлении фильтров. Спойлер: разрыв между OBT и JOIN становится ещё больше в пользу JOIN — благодаря bloom-фильтрам и pushdown-оптимизациям.

Перевод и адаптация статьи «Joins are NOT Expensive!» из блога Database Doctor. Если вы хотите глубже разобраться в SQL — рекомендуем нашу шпаргалку по SQL.

TurboQuant — алгоритм квантизации KV-кеша (Key-Value cache), промежуточного буфера, в котором LLM хранят контекст разговора. Сжимает его с 16 до 3–4 бит на значение без переобучения модели. Статья принята на ICLR 2026 (arXiv:2504.19874).

— Сообщество создало рабочие реализации TurboQuant для llama.cpp, MLX и PyTorch

— Q8 KV-кеш с rotation — почти без потерь (37,1% vs 37,9% F16 на AIME25)

— Q4 пока проблемный для K-тензоров, рекомендуют TQ8 для K + TQ4 для V

— Текущие реализации в 3–8 раз медленнее из-за неоптимизированного поворота вектора

— Главный выигрыш — длинные контексты: 70B-модель может уместить 536K токенов вместо 109K

Первые бенчмарки: что показали числа

Один из первых тестов опубликован на r/LocalLLaMA — результаты на математическом бенчмарке AIME25 (чем выше — тем лучше). Связанный PR в llama.cpp подтверждает данные:

• F16 KV-кеш (без сжатия): 37,9%
• Q8_0 без rotation: 31,7% — потеря 6,2 п.п.
• Q8_0 с rotation (TurboQuant): 37,1% — почти полное восстановление
• Q4_0 без rotation: 2,0% — катастрофическая деградация
• Q4_0 с rotation: 21,7% — значительное улучшение, но всё ещё далеко от F16

Вывод: при 8-битной квантизации KV-кеша rotation практически полностью компенсирует потерю качества. При 4-битной — улучшение радикальное (с 2% до 21,7%), но до lossless ещё далеко. Безопасный минимум на сегодня — Q8 с rotation для K-тензоров и Q4 для V-тензоров.

Проблема K-тензоров: не всё сжимается одинаково

Разработчик inference-движка Llaminar провёл детальный анализ cosine similarity между сжатым и эталонным FP32-выходом на нескольких моделях. Главный вывод: K-тензоры (Key) и V-тензоры (Value) ведут себя при квантизации принципиально по-разному.

V-тензоры хорошо переносят 4-битное сжатие. K-тензоры — нет. Причина: K-тензоры имеют значительно более высокие нормы векторов по сравнению с V. Измерения показывают соотношение K/V-норм до 100–180x у современных моделей (Qwen2.5, GPT-2). Ошибка квантизации масштабируется с квадратом нормы, поэтому K-тензорам нужно больше бит для сохранения точности.

Практическая рекомендация: TQ8 для K-тензоров + TQ4 для V-тензоров. Это даёт хорошую экономию памяти при минимальной потере качества — компромисс, который подтверждён и бенчмарками, и cosine similarity анализом.

Где TurboQuant действительно меняет правила

Главный выигрыш — не скорость генерации (она пока даже падает), а объём контекста, который помещается в память. Расчёт из обсуждения llama.cpp для модели 70B Q4_K_M с 34 ГБ свободной VRAM:

• FP16 KV-кеш: ~109K токенов
• Q8 KV-кеш: ~218K токенов (2x)
• TurboQuant TQ3: ~536K токенов (5x)

Это значит: одна видеокарта с 48 ГБ памяти может работать с контекстом, который раньше требовал 3–4 карты. Для владельцев MacBook с Apple Silicon — локальная модель на 16 ГБ RAM теперь «видит» в 3–5 раз больше текста при той же скорости.

Реализации TurboQuant: кто уже попробовал

Официального кода от Google нет (ожидается во 2-м квартале 2026). Но сообщество уже создало рабочие реализации, а в vLLM открыт активный PR на нативную интеграцию:

• llama.cpp — минимум 3 независимых форка. Обсуждение интеграции в основную ветку. Флаги зависят от форка: --cache-type-k turbo3 (TheTom) или tq3_0 (другие форки)
• MLX — адаптация для Apple Silicon (M1–M5)
• PyTorch + Triton — reference-реализации для CUDA. Один разработчик получил побитово идентичный выход на Gemma 3 4B при 2-битной точности на RTX 4090
• vLLM — активный PR на нативную интеграцию TurboQuant как опции KV-кеша

Главная проблема текущих реализаций — скорость. Операция поворота вектора (rotation) пока не оптимизирована: сложность O(d²) вместо O(d log d). Замедление составляет 3–8x по сравнению с обычным Q8 KV-кешем. Разработчики работают над оптимизацией через преобразование Уолша–Адамара (Walsh-Hadamard transform), которое снизит сложность до O(d log d).

Реализации TurboQuant очень зависят от качества кода. Я видел vibecoded-реализации со скрытыми багами, которые убивали производительность.

Реакция рынка

В день публикации TurboQuant 25 марта 2026 года акции производителей памяти снизились: SK Hynix потеряла 6,2%, Samsung — 4,8%, Micron — 3,4%. Логика рынка: если inference требует в 6 раз меньше памяти — спрос на HBM снижается. Но это упрощение: TurboQuant сжимает только KV-кеш, а не веса модели, и дешёвый inference увеличивает спрос на LLM в целом.

Что это значит для вас

Если вы запускаете LLM локально через llama.cpp, Ollama или LM Studio — в ближайшие месяцы ожидайте нативную поддержку TurboQuant. Практический эффект:

• Длинные контексты без нового железа — ваша текущая видеокарта или MacBook сможет работать с 3–5x большим контекстом
• Оптимальная конфигурация — TQ8 для K + TQ4 для V. Чистый TQ4 для обоих пока даёт заметную деградацию на K-тензорах
• Скорость пока не выигрыш — текущие реализации замедляют генерацию в 3–8 раз. Ждите оптимизированных ядер с Walsh-Hadamard transform
• Комбинируйте с квантизацией весов — TurboQuant сжимает KV-кеш, а не веса. Q4-модель + TQ4-кеш = максимальная экономия памяти

Выводы

TurboQuant — не серебряная пуля, но значимый шаг для локального inference. Rotation при Q8 KV-кеше работает почти без потерь. Q4 пока проблемный для K-тензоров, но V-тензоры сжимаются хорошо. Главный практический выигрыш — длинные контексты на существующем железе без покупки новых карт.

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

Ссылки: Блог Google Research | Обсуждение в llama.cpp | Наш разбор алгоритма

Ключевые выводы
- SIMD-инструкции (SSE2, AVX2) позволяют обрабатывать 16-32 байта за одну операцию
- В UTF-8 все управляющие символы CSV (запятая, кавычка, перенос строки) занимают ровно один байт и совпадают с ASCII
- Минималистичный код (16 КБ) побеждает оптимизированный, но раздутый (163 КБ) за счёт давления на L1-кэш процессора
- Компилятор и рантайм умеют оптимизировать лучше, если им не мешать микрооптимизациями

Наивная реализация — считаем запятые

Прежде чем строить парсер, поставим простую задачу: как быстрее всего подсчитать, сколько раз символ , встречается в большом UTF-8-файле? Тестируем на CSV-файле размером 500 МБ.

Базовая реализация: 135,305 мс

Простейший вариант: перебираем каждый байт и сравниваем с искомым. Можно ли лучше?

Unsafe-указатели: 128,683 мс

Каждый раз, когда вы обращаетесь к массиву через data[i], рантайм .NET выполняет проверку границ (bounds checking) — убеждается, что индекс не выходит за пределы массива. Если вместо этого использовать unsafe-указатели, мы обещаем рантайму, что не выйдем за границы. Экономия — 7 мс.

Развёртка цикла (unrolling 4x): 105,320 мс

Механика цикла for обманчиво дорога: на каждой итерации нужно проверить условие выхода и выполнить переход в начало. Если обрабатывать по 4 элемента за итерацию, накладные расходы снижаются в четыре раза. «Хвост» данных, не кратный четырём, обрабатывается обычным побайтовым циклом.

Проблема — UTF-8 и Unicode ломают всё

Чтобы понять, почему мы можем сканировать текст настолько быстро, нужно разобраться, как текст хранится в памяти компьютера.

Наименьшая единица данных — байт (числа 0-255). Но человечество использует гораздо больше 256 символов. Ранние системы решали это через кодовые страницы — у каждого региона была своя таблица. Японские системы использовали Shift-JIS, в Китае по закону обязателен GB 18030. Если открыть файл в неправильной кодировке, вы увидите «крокозябры» (mojibake) — бессмысленный набор символов.

Unicode решил эту проблему в 90-х: каждому символу присваивается номер (codepoint), а разные кодировки (UTF-8, UTF-16, UTF-32) определяют, как эти номера записываются в байты.

Вот как UTF-8 кодирует символы в зависимости от количества байтов:

Ключевой факт: байты 0x00-0x7F в UTF-8 полностью совпадают с ASCII. Это значит, что управляющие символы CSV — запятая (,), кавычка ("), перевод строки (\n) — всегда занимают ровно один байт, независимо от того, какие Unicode-символы находятся в данных. И это можно использовать для невероятно быстрого сканирования.

SIMD — ускорение через параллельные инструкции

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

SIMD (Single Instruction, Multiple Data) — это набор процессорных инструкций, которые выполняют одну операцию сразу над несколькими элементами данных. Вся магия происходит в железе, поэтому результат приходит за то же время, что и обычная операция над одним элементом.

Аналогия: сложить два однозначных числа (8 + 2) — просто. Сложить два семизначных — нужно перебирать разряды. А теперь представьте, что вы можете «увидеть» сумму двух семизначных чисел мгновенно, с той же лёгкостью, что и однозначных. Это и есть SIMD.

Вот как выглядит SIMD-сложение 4 элементов за одну операцию:

Мы делаем в 4 раза больше работы за то же усилие.

SSE2: 46,663 мс

SSE2 (появился в x86-процессорах в 2000 году) работает с 128-битными регистрами — 16 байтов за раз. Алгоритм такой:

1. Загрузить 16 байтов данных в SIMD-вектор
2. Сравнить каждый байт с искомым (Sse2.CompareEqual) — на позициях совпадений появятся байты 255, на остальных — 0
3. Извлечь старшие биты из каждого байта (Sse2.MoveMask) — получаем 16-битное число, где каждый установленный бит означает совпадение
4. Подсчитать установленные биты

Для строки "Hello, I, like, commas." это выглядит так:

AVX2: 42,220 мс

AVX2 (с 2011 года) расширяет регистры до 256 битов — 32 байта за итерацию. Код аналогичен SSE2, но с Vector256 вместо Vector128.

Прирост скромный — значит, узкое место сместилось на цикл обработки маски. Нужно ускорить подсчёт битов.

AVX2 + TZCNT: 16,630 мс

BitOperations.TrailingZeroCount — аппаратная инструкция TZCNT, которая мгновенно находит позицию младшего установленного бита. Вместо того чтобы перебирать биты маски по одному, мы прыгаем сразу к следующему совпадению и сбрасываем его.

AVX2 + POPCNT: 13,673 мс

А есть ещё лучше. BitOperations.PopCount — аппаратная инструкция POPCNT, которая за одну операцию считает количество установленных битов в числе. Именно то, что нам нужно:

Мы достигли потолка производительности для подсчёта символов. Ускорение в 10 раз по сравнению с наивной реализацией — отличный результат. Пора применить это к парсингу CSV.

Поиск разделителей через SIMD

При парсинге CSV нас интересуют три управляющих символа: запятая (,), кавычка (") и перевод строки (\n). Правила обработки:

• Запятая — конец текущего поля
• Перевод строки — конец текущей строки
• Кавычка — начало или конец экранированного блока (внутри которого запятые и переносы игнорируются). Две кавычки подряд — это экранированная кавычка в значении

Парсинг разбивается на два этапа. Первый — определение позиций и длин полей через SIMD (функция DetermineFields). Второй — фактическое извлечение и дeкодирование значений, только когда пользователь их запрашивает.

Вот упрощённый код первого этапа (без обработки краевых случаев):

Несколько важных деталей:

• Здесь используется TrailingZeroCount вместо PopCount, потому что нам важна позиция каждого найденного символа, а не только их количество
• Одна и та же схема CompareEqual + MoveMask применяется для каждого управляющего символа, а затем маски объединяются через OR. Отдельные маски сохраняются, чтобы потом определить тип найденного символа
• Мы не касаемся содержимого полей — если пользователю нужен только один столбец, незачем декодировать остальные

Обработка кавычек и экранирования

Когда поле содержит кавычки, нужно выполнить декодирование вручную — убрать обрамляющие кавычки и заменить двойные кавычки на одинарные. Кроме того, C# внутри использует UTF-16 для всех строк (char — это 16-битная единица кода), поэтому при чтении UTF-8 приходится конвертировать.

Если кавычек в поле нет, используется быстрая встроенная конвертация Encoding.UTF8.GetChars. Но если кавычки есть, быстрее выполнить конвертацию и удаление кавычек за один проход:

Хитрость здесь в том, что 2- и 3-байтовые UTF-8-последовательности всегда дают одну единицу кода UTF-16, поэтому кодпоинт можно просто привести к char. Четырёхбайтовые символы (эмодзи и редкие иероглифы) требуют суррогатных пар.

Для UTF-16-строк (внутренний формат C#) парсер использует трюк с Avx2.PackUnsignedSaturate: два 256-битных вектора 16-битных символов «сжимаются» в один 256-битный вектор 8-битных байтов. ASCII-символы сохраняются как есть, а все не-ASCII насыщаются до 255 (или 0 для отрицательных при знаковой интерпретации). После перестановки блоков через Avx2.Permute4x64 можно применять ту же маску, что и для UTF-8.

Бенчмарки — результаты

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

• Реальные данные Reddit — широкий датасет с разными типами данных и большим количеством текста (из Reddit ArcticShift)
• Международный текст — CSV с названиями предметов из Pokemon на множестве языков (кириллица, японский, корейский)
• Финансовые данные — числа с минимумом текста
• Синтетические тесты — числовые поля, короткие файлы (50 строк), файлы с обязательным экранированием, «стресс-тест» с массой кавычек

Полные результаты опубликованы на bepis.io/csv-benchmark.

Итог: FourLambda.Csv оказался самым быстрым в 41 из 70 тестов. Не абсолютная победа, но убедительное лидерство.

Для сравнения, вот как менялась скорость подсчёта символов на файле 500 МБ по мере оптимизации:

Почему FourLambda.Csv быстрее Sep

До этого самым быстрым CSV-парсером на C# считалась библиотека Sep. Вот несколько причин, почему FourLambda.Csv выигрывает:

UTF-8 без промежуточной конвертации. Sep внутри конвертирует UTF-8 в UTF-16 даже если данные не нужны пользователю. FourLambda.Csv работает напрямую с UTF-8.

Давление на кэш. L1-кэш процессора — около 32-64 КБ, и он хранит не только данные, но и исполняемый код. FourLambda.Csv весит ~16 КБ, а Sep — ~163 КБ. Разница в 10 раз означает, что Sep может вытеснять данные из L1-кэша, вызывая медленные обращения к памяти.

Переоптимизация. Sep тщательно контролирует, как данные перемещаются между регистрами. Теоретически это быстрее, но на практике может мешать оптимизациям рантайма. Компилятор и процессор умеют оптимизировать код, если им не указывают точный способ выполнения. Чрезмерная микрооптимизация «связывает руки» и мешает автоматическим улучшениям в новых версиях .NET.

Зависимость от оборудования. Результаты могут отличаться на разных машинах. Например, Sse.Prefetch0 (предзагрузка данных в L1) давала +10-20% на ноутбуке с DDR3, но почти нулевой эффект на десктопе с DDR5. На системах с AVX-512 и ARM у Sep есть аппаратные оптимизации, которых пока нет в FourLambda.Csv.

Выводы

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

Главные уроки:

• SIMD — не магия для избранных. В C# интринсики доступны из коробки и дают кратный прирост на задачах поиска и сравнения
• UTF-8-совместимость ASCII — мощное свойство, которое можно эксплуатировать для быстрого парсинга
• Минимализм побеждает сложность: меньше кода — меньше давления на кэш — быстрее выполнение
• Не мешайте компилятору: иногда лучшая оптимизация — не оптимизировать вручную

Библиотека доступна на GitHub: bbepis/FourLambda.Csv.

Перевод и адаптация статьи How I accidentally made the fastest C# CSV parser с разрешения автора.

Независимый разработчик Tom Turney опубликовал метод sparse V dequantization — оптимизацию для инференса LLM с квантизированным KV-кешем. Вместо того чтобы ускорять деквантизацию каждого значения, он предложил пропускать деквантизацию целиком для позиций, где вес внимания пренебрежимо мал. На Apple M5 Max с моделью Qwen 3.5 35B (MoE) метод дал прирост +22,8% к скорости декодирования на контексте 32K токенов. Перплексия осталась неизменной, а точность поиска needle-in-a-haystack выросла с 7/9 до 9/9.

Ключевые выводы

— Узкое место квантизированного KV-кеша — не то, как вы деквантизуете, а то, сколько значений вы деквантизуете.
— При длинном контексте (32K+) более 90% весов внимания пренебрежимо малы — их деквантизацию можно пропустить.
— Метод работает с любой схемой квантизации KV-кеша: TurboQuant, q8_0, q4_0, NVFP4.
— Реализация — 3 строки в ядре flash attention. Не нужно ни переобучение, ни калибровочные данные.
— NIAH-тест улучшился: 9/9 вместо 7/9. Пропуск деквантизации убирает квантизационный шум от позиций, которые ничего не вносят в результат.

Проблема — узкое место деквантизации

Чтобы понять суть открытия, нужно разобраться в контексте. Современные LLM при генерации текста хранят промежуточные вычисления в так называемом KV-кеше (key-value cache). Это массив ключей (K) и значений (V), которые модель использует в механизме внимания — чтобы при генерации каждого нового токена не пересчитывать всю историю диалога.

Проблема: KV-кеш растёт линейно с длиной контекста и при 32K токенов занимает гигабайты памяти. Решение — квантизация: сжатие значений из 16-битного формата в 3-4 бита. TurboQuant от Google (ICLR 2026) сжимает KV-кеш в 4,6 раза с потерей перплексии всего ~1%. Но при декодировании каждый сжатый блок нужно деквантизовать — преобразовать обратно в числа с плавающей точкой. И на длинных контекстах это становится узким местом.

На Apple M5 Max деквантизация TurboQuant занимает 14-34% времени декодирования. На контексте 32K токенов скорость декодирования падает с 78,3 tok/s (потолок без деквантизации) до 47,0 tok/s — штраф в 40%.

14 попыток, которые провалились

Прежде чем найти решение, Turney перебрал 14 альтернативных реализаций деквантизации на Apple Silicon: регистровые массивы, битовую арифметику, SIMD-шаффлы, FMA без ветвлений, слитые блочные операции. Ни одна не обогнала базовую таблицу подстановки (LUT) в константной памяти GPU.

Вывод оказался фундаментальным: на Apple Silicon 4 дивергентных чтения из константной памяти быстрее любой арифметики, которая даёт тот же результат. Это аппаратный пол — ниже него не опуститься. Единственный оставшийся рычаг — уменьшить количество позиций, которые нужно деквантизовать.

Решение — не ускорять, а пропускать

Ключевое наблюдение: в flash attention ядре веса внимания (softmax) вычисляются из ключей (K) до того, как начинается работа со значениями (V). То есть на момент деквантизации V мы уже знаем, какие позиции контекста получили значимый вес внимания, а какие — нет.

Что такое разреженность внимания? Когда модель генерирует следующий токен, механизм внимания (softmax) распределяет вероятность по всем предыдущим позициям контекста. При коротком контексте внимание распределено относительно равномерно. Но чем длиннее контекст, тем более концентрированным оно становится: модель «смотрит» на несколько десятков ключевых позиций, а 90%+ получают веса ниже 10-6 — они практически ничего не вносят в итоговый результат.

Sparse V dequantization использует этот факт: если вес внимания для позиции ниже порога (10-6), её деквантизация и аккумуляция пропускаются целиком.

Вся реализация — три строки в Metal-ядре:

Это экономит чтения из константной памяти (обращения к LUT), ALU-операции (извлечение индексов, применение знака, умножение на норму) и чтения из глобальной памяти устройства.

Принципиальное отличие от 14 провалившихся подходов: они пытались сделать каждую из N операций быстрее (ограничено аппаратным полом). Sparse V убирает (1-p) x N операций целиком — и выигрыш растёт с длиной контекста, потому что разреженность внимания растёт.

Результаты

Скорость декодирования (M5 Max, Qwen 3.5 35B MoE)

Эффект sparse V масштабируется с длиной контекста — чем длиннее контекст, тем больше позиций пропускается:

• Короткий контекст: +1,4% (внимание плотное, мало что пропускать)
• 4K: +4,0%
• 8K: +7,2%
• 16K: +12,9%
• 32K: +22,8% (с 47,0 до 57,7 tok/s)

При 32K токенов отношение к несжатому q8_0 улучшилось с 0,76x до 0,93x — почти паритет.

Качество: перплексия и retrieval

Перплексия при включении sparse V остаётся численно идентичной варианту без него. На корпусе wikitext-103 (50 чанков, контекст 32K, CI +/-0.021) дельта составила ровно 0,0000. Это подтверждено на всех протестированных длинах контекста: 8K, 16K, 32K.

Ещё более неожиданный результат — в тесте needle-in-a-haystack (NIAH). Этот тест проверяет, может ли модель найти конкретный факт, спрятанный в длинном контексте:

• Без sparse V: 7/9 (q8_0 тоже 7/9)
• С sparse V: 9/9 (100%)

Гипотеза автора: позиции с пренебрежимо малым весом внимания вносят практически нулевой полезный сигнал, но при деквантизации добавляют квантизационный шум. Sparse V убирает этот шум — и соотношение сигнал/шум улучшается.

Почему это работает для любой квантизации

Sparse V работает не на уровне конкретного формата квантизации, а на уровне механизма внимания. Метод использует веса softmax как сигнал для пропуска вычислений — а softmax одинаков вне зависимости от того, как именно сжаты K и V.

Автор валидировал метод на трёх форматах KV-кеша с разной стоимостью деквантизации:

• turbo3 (3,5 бита, TurboQuant) — +22,8% на 32K, перплексия без изменений
• q8_0 (8 бит) — +5% к декодированию, перплексия идентична
• q4_0 (4 бита) — перплексия идентична, скорость в пределах шума

Закономерность: чем дороже деквантизация, тем больше выигрыш. turbo3 использует Walsh-Hadamard-преобразование и полярную декомпозицию — тяжёлые операции, поэтому выигрыш максимален. q4_0 использует простое масштабирование — пропуск дешёвой операции даёт мало. Но в обоих случаях метод не ухудшает ни перплексию, ни retrieval.

Это означает, что sparse V можно включить по умолчанию для любого формата квантизации KV-кеша в llama.cpp — как безусловную оптимизацию, которая ничего не стоит на коротком контексте и даёт ощутимый выигрыш на длинном.

FAQ

Не сломает ли пропуск позиций качество генерации?

Нет. Порог 10-6 выбран консервативно. При контексте 32K с 32 головами внимания вклад пропущенной позиции в итоговый вектор — менее одной миллионной от максимума. Перплексия во всех экспериментах осталась численно идентичной — дельта 0,0000 на 50 чанках wikitext-103.

Почему нельзя пропускать и K-деквантизацию?

Потому что K нужен для вычисления весов внимания. Чтобы узнать, какие позиции имеют пренебрежимо малый вес, нужно сначала деквантизовать все ключи и посчитать softmax. Автор отмечает это как направление будущей работы: двухпроходный механизм, где первый проход вычисляет приблизительные веса для фильтрации K-позиций.

Работает ли это на NVIDIA GPU?

Эксперименты проводились на Apple Silicon (M5 Max, M2 Pro). Реализация — Metal-ядро для llama.cpp. На CUDA профиль узкого места другой (NVIDIA использует тензорные ядра и HBM вместо unified memory), но сам принцип — пропуск работы для позиций с малым весом внимания — универсален. Портирование на CUDA и ROCm автор указывает как следующий шаг.

Выводы

Sparse V dequantization — элегантное решение, которое меняет вопрос с «как деквантизовать быстрее?» на «нужно ли деквантизовать вообще?». Метод использует информацию, которая уже есть в ядре flash attention — веса softmax — как бесплатный сигнал для пропуска вычислений.

Главная ценность подхода — не конкретный прирост в 22,8%, а более широкая идея attention-aware computation: использование собственных паттернов разреженности модели для оптимизации ядер инференса. Чем длиннее контекст, тем сильнее разреженность — и тем больше выигрыш. Именно при тех длинах контекста, где узкое место деквантизации наиболее болезненно.

Код и бенчмарки: TheTom/turboquant_plus (бенчмарки и диагностика), TheTom/llama-cpp-turboquant (реализация, ветка experimental_decode_speed_tests).

Обсуждение на r/LocalLLaMA.

Источник: Sparse V Dequantization — документация turboquant_plus.

Мы разобрались. Объясняем так, чтобы было понятно всем — и тем, кто пишет нейросети, и тем, кто просто хочет запустить ChatGPT-подобную модель на своём ноутбуке.

TurboQuant — алгоритм квантизации KV-кеша для больших языковых моделей (LLM), разработанный Google Research. Сжимает KV-кеш с 16 до 3 бит на значение, уменьшая потребление памяти при инференсе в 5–6 раз без переобучения модели и без потери качества. Представлен на ICLR 2026 (arXiv:2504.19874).

KV-кеш: почему нейросетям нужно столько памяти

Когда вы общаетесь с ChatGPT, Gemini или любой другой LLM, модель должна «помнить» весь ваш диалог. Для этого она использует KV-кеш (Key-Value cache) — специальный буфер в памяти видеокарты, где хранятся промежуточные вычисления механизма внимания (attention).

Представьте: вы читаете книгу и делаете заметки на полях. KV-кеш — это те самые заметки. Без них модели пришлось бы каждый раз перечитывать весь текст с начала, чтобы ответить на ваш вопрос.

Проблема в масштабе:

• Модель Llama 3.1 70B при контексте 128K токенов тратит ~40 ГБ только на KV-кеш — это больше, чем весит сама модель в квантизированном виде
• Чем длиннее контекст (переписка, документ, код) — тем больше памяти нужно, и это растёт линейно
• Именно KV-кеш — главный ограничитель того, сколько текста модель может «видеть» одновременно

И именно KV-кеш сжимает TurboQuant.

Что такое TurboQuant

TurboQuant — это алгоритм сжатия KV-кеша, разработанный Google Research. Статья принята на ICLR 2026 — одну из топовых конференций по машинному обучению. Авторы — Amir Zandieh, Vahab Mirrokni (VP Google, известный исследователь в области алгоритмов) и коллеги.

• Сжимает KV-кеш до 3 бит на значение (с обычных 16) — уменьшение в ~5 раз
• Не требует дообучения модели — работает с любой LLM «из коробки»
• Не теряет качество на стандартных бенчмарках (LongBench, Needle in a Haystack, RULER)
• Ускоряет вычисления attention до 8 раз на NVIDIA H100
• Работает «на лету» — не нужно заранее обрабатывать данные

Важно: TurboQuant сжимает только KV-кеш при инференсе. Он НЕ сжимает веса модели (это делают GPTQ, AWQ, GGUF) и НЕ влияет на обучение. Это принципиально другая задача.

Как работает TurboQuant: PolarQuant и QJL простыми словами

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

Шаг 1: PolarQuant — умное сжатие основных данных

Обычно данные в нейросети хранятся в декартовых координатах — как «иди 3 блока на восток и 4 блока на север». PolarQuant переводит их в полярные координаты — «иди 5 блоков под углом 37 градусов». Перед конвертацией вектор случайным образом поворачивается — это делает распределение координат более однородным.

В полярных координатах данные распределены более предсказуемо. Это позволяет применить оптимальный квантизатор (Lloyd-Max) к каждой координате независимо, без дополнительных битов на хранение параметров квантизации. В обычных методах эти «служебные» биты съедают 1–2 бита на число — при 3-битной квантизации это колоссальные накладные расходы.

Шаг 2: QJL — коррекция ошибок за 1 бит

После PolarQuant остаётся небольшая ошибка. QJL (Quantized Johnson-Lindenstrauss) — алгоритм, который использует математическое преобразование Джонсона–Линденштрауса для сведения остаточной ошибки к нулевому смещению, тратя на это всего 1 дополнительный бит.

Если PolarQuant — это основной «сжиматель», то QJL — это математический «корректор», который гарантирует, что attention-скоры модели остаются точными. Вместе они дают 3-битное представление, которое математически доказано как близкое к теоретическому пределу сжатия (с точностью до константы ~2,7).

Чем TurboQuant отличается от обычной квантизации

Если вы запускаете модели через llama.cpp, Ollama или LM Studio, вы уже используете квантизацию — те самые Q4, Q5, Q8 в названиях файлов. Но это квантизация весов модели. TurboQuant работает с совершенно другой сущностью.

Квантизация весов (GPTQ, AWQ, GGUF) — сжимает параметры модели один раз перед запуском. Чем меньше бит — тем хуже качество. Иногда требует калибровки или дообучения.

TurboQuant — сжимает KV-кеш (промежуточные вычисления) на лету во время работы. При 3,5 битах — нулевая потеря качества. Не требует дообучения вообще.

Эти подходы комплементарны. Вы можете использовать Q4-квантизированную модель И TurboQuant-сжатый KV-кеш одновременно. Одно не заменяет другое — они сжимают разные части системы.

TurboQuant на практике: MacBook, видеокарты и облако

Если у вас MacBook или обычный ПК

Энтузиасты уже запустили Qwen 3.5 9B на обычном MacBook Air M4 (16 ГБ) с контекстом 20 000 токенов — раньше на таком железе длинные контексты были невозможны. Не MacBook Pro, не Mac Studio — обычный Air, самая дешёвая конфигурация. В Reddit-треде есть видео-демо.

Это значит: локальная нейросеть на вашем ноутбуке сможет «видеть» в 5 раз больше текста за раз. Длинные документы, полноценные кодовые базы, многостраничные переписки — всё это становится доступнее без покупки нового железа.

Если у вас мощная видеокарта

Один из разработчиков рассчитал для модели 70B Q4_K_M с 34 ГБ свободной VRAM под KV-кеш:

• Без TurboQuant (FP16 KV-кеш): ~109K токенов контекста
• С Q8 KV-кешем: ~218K токенов
• С TurboQuant TQ3 (3 бита): ~536K токенов
• Полное окно контекста 262K легко помещается на 3× RTX 3090

Если вы разрабатываете ИИ-продукты

• В 5–6 раз меньше GPU-памяти на инференс при длинных контекстах
• До 8× ускорение attention на H100
• Снижение стоимости обслуживания каждого запроса к LLM

Парадокс Джевонса: когда ресурс становится дешевле — его используют больше, а не меньше. Дешёвый инференс = больше компаний внедряют ИИ = спрос на железо в итоге растёт.

TurboQuant в llama.cpp, MLX и PyTorch: кто уже пробует

Прошло всего несколько дней с публикации, но Open Source сообщество уже на коне:

• llama.cpp — минимум 3 независимых реализации, обсуждение интеграции в основную ветку. Одна уже работает на Apple Silicon через Metal
• MLX (Apple Silicon) — разработчики адаптируют алгоритм для маков
• PyTorch + Triton — появились reference-реализации для CUDA-видеокарт
• C/CUDA — рабочая реализация с 18 из 18 пройденных тестов, MSE совпадает с бумагой

Пока реализации не оптимизированы. Бенчмарки показывают падение скорости генерации в 3–8 раз по сравнению с обычным Q8 KV-кешем. Причина — неоптимизированная операция поворота вектора. Разработчики уже работают над оптимизацией через преобразование Адамара.

Как попробовать TurboQuant прямо сейчас

Официального кода от Google нет, но сообщество уже сделало несколько рабочих реализаций. Вот как запустить TurboQuant на своём железе — три варианта в зависимости от платформы.

На Mac (Apple Silicon M1–M5)

Форк llama-cpp-turboquant от TheTom — самая зрелая реализация с Metal-ядрами для Apple Silicon. Работает на M1, M2, M3, M4, M5.

Флаг turbo3 включает 3,5-битную квантизацию KV-кеша (сжатие 4,6× vs FP16). На M5 Max 128 ГБ модель Qwen3.5-35B показывает 2747 tok/s на prefill — на уровне стандартного q8_0, при этом KV-кеш занимает в 4,6 раза меньше памяти.

На PC с видеокартой NVIDIA или AMD

Форк llama-turboquant поддерживает CUDA и ROCm. Тип кеша здесь называется tq3_0 (вместо turbo3).

Python (для исследований и экспериментов)

turboquant-pytorch — reference-реализация на PyTorch. Подойдёт для изучения алгоритма и проверки сжатия на своих моделях.

Ollama и LM Studio пока не поддерживают TurboQuant — они используют свои сборки llama.cpp, в которые метод ещё не влит. Но можно поднять llama-server из форка выше и подключиться к нему как к OpenAI-совместимому API.

Бенчмарки TurboQuant: результаты из бумаги и от сообщества

Из бумаги Google (тестировалось на Gemma и Mistral):

• LongBench, Needle in a Haystack, ZeroSCROLLS, RULER, L-Eval — при 3,5 битах «абсолютная нейтральность качества»
• При 2,5 битах — «маргинальная деградация»
• 4-bit TurboQuant: ускорение attention до 8× на H100 по сравнению с 32-bit baseline
• Сжатие KV-кеша минимум в 6 раз

Из независимых реализаций:

• TQ3 (3 бита): MSE = 0,034, сжатие 4,9× vs FP16
• TQ4 (4 бита): MSE = 0,009, сжатие 3,8× vs FP16
• Размер блока: 52 байта на 128 значений (для TQ3)

Почему TurboQuant обвалил акции Micron — и стоит ли переживать

Рынок отреагировал панически: Micron −25%, Samsung −4,7%, SK Hynix −6,2%. Но аналитики Morgan Stanley, JPMorgan, Citigroup и Goldman Sachs единодушны — реакция чрезмерна. Вот почему:

1. TurboQuant не трогает обучение. HBM-память, основной драйвер прибыли чипмейкеров, нужна для обучения моделей. TurboQuant сжимает только инференс
2. Это исследование, не продукт. Официального кода от Google нет, эксперименты на моделях ~8B параметров
3. Прецедент DeepSeek. В январе 2025 тоже обвалили чипмейкеров — затем спрос только вырос
4. Фиксация прибыли. Micron был +300% за год, Samsung +200%. Инвесторы искали повод зафиксировать прибыль

Если TurboQuant снизит операционные расходы на ИИ до одной шестой от текущего уровня, компании, которые до сих пор не внедряли ИИ из-за высокой стоимости, войдут в ИИ-экосистему.

Подробнее о реакции рынка — в нашей новости.

Часто задаваемые вопросы

Чем TurboQuant отличается от GGUF/GPTQ/AWQ?
GGUF, GPTQ и AWQ сжимают веса модели (параметры). TurboQuant сжимает KV-кеш — временную рабочую память, которая используется во время инференса. Эти подходы дополняют друг друга.

Можно ли уже использовать TurboQuant?
Экспериментально — да. Несколько независимых реализаций для llama.cpp и MLX уже работают. Но в основную ветку llama.cpp и в Ollama/LM Studio метод пока не интегрирован. Ожидается в ближайшие недели–месяцы.

Нужно ли переобучать модель для TurboQuant?
Нет. TurboQuant — data-oblivious метод, который применяется к любой существующей LLM без дообучения и без калибровочных данных.

TurboQuant: итоги и выводы

• TurboQuant — прорыв в сжатии KV-кеша, но не «убийца GPU» и не «конец эпохи дорогого железа»
• Работает вместе с обычной квантизацией весов, а не вместо неё
• Реально позволяет запускать более длинные контексты на том же железе — в 5 раз длиннее
• Сообщество уже пишет реализации для llama.cpp и MLX
• До полноценного внедрения в популярные инструменты — недели или месяцы
• Обвал акций — чрезмерная реакция, аналитики рекомендуют покупать на падении

Следите за GitHub-дискуссией в llama.cpp — именно там появится рабочая реализация для повседневного использования. А блог Google Research и бумага на arXiv — для тех, кто хочет погрузиться в математику.

10. Star Schema — старая рабочая лошадка (которая разваливается на больших данных)

Наша любимая звездочка — это самая базовая модель для аналитики. Таблица фактов (с метриками, напр. продажи) окружена таблицами измерений.

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

Проблемы на практике:

Когда таблица fact_sales растёт до сотен миллионов или миллиардов строк, запросы начинают жёстко тормозить. JOIN-ы с несколькими измерениями и GROUP BY приводят к долгим сканированиям. сложно вносить изменения, все может посыпаться

Типичный запрос может выглядеть так:

И чем больше строк в fact_sales, тем медленнее выполняется такой запрос.

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

9. Snowflake Schema — слишком усложнённая и медлительная

Снежинка — это “нормализованная” версия звездочки: таблицы измерений разбиваются на ещё более мелкие части, как ветви снежинки. В результате каждая иерархия измерений (например продукт → категория → бренд) живёт в своей таблице.

Это улучшает хранение (меньше дублирования данных и меньше места на диске), но делает запросы еще более тяжёлыми, потому что для простого отчёта нужно больше JOIN-ов между таблицами. Зато теперь чуточку легче поддерживать и это уже мене похоже на монолит, хотя все равно таковым является.

Короче говоря:

• Плюсы: меньше избыточности, данные лучше структурированы, нормализовано (хорошо для поддержки целостности).
• Минусы: запросы становятся сложнее и медленнее (много JOIN-ов), сложнее для понимания тем, кто пишет SQL-аналитику. И все равно монолит, который сложно поддерживать.

п=

8. Data Vault — гибко, масштабируемо… и очень сложно

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

Вместо привычных «фактов и измерений» тут три типа таблиц:

· Hubs — бизнес-сущности (клиент, заказ, продукт).

· Links — связи между ними.

· Satellites — атрибуты и история изменений (фио клиента, наименование товара, стоимость товара).

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

Но где подвох?

Во-первых, схема получается гигантской — десятки и сотни таблиц.

И во-вторых, даже простой отчёт превращается в цепочку JOIN-ов на пол-экрана SQL.

А в-третьих, новым людям в команде разобраться в этом всём, как отдельный квест.

Data Vault отлично подходит для enterprise-DWH, где важны аудит, история и масштаб. Но для обычной аналитики это как резать колбасу бензопилой.

Пример запроса:

7. Wide Tables / One Big Table (OBT) — для time-series

Это противоположность сложным моделям вроде Data Vault.

Идея максимально простая - берём данные из разных таблиц и склеиваем всё в одну огромную таблицу.

· Запросы супербыстрые, почти без JOIN-ов.

· Очень удобно для BI и дашбордов.

· Понятная структура: «одна строка = один бизнес-объект».

Но за скорость нужно платить следующими недостатками:

· Дублирование данных на каждом шаге,

· Таблица быстро разрастается до сотен колонок,

· Любое изменение логики требует пересборки всей таблицы,

· Легко поймать несогласованность данных.

Короче:

OBT — это как кеш. Но все это добро практически невозможно поддерживать.

Часто применяется в рамках time-seriesанализа: IoT, анализ метрик, логов, clickstream.

Пример запроса:

6. Graph Models (Neo4j, TigerGraph) — для связей

Когда ценность данных именно в связях (например, в мошеннических схемах, социальном влиянии или цепочках переходов по сети). В таком случае куча join-ов просто перестают работать, особенно при всякого рода рекурсиях.

С этим помогают графовые базы.

Вот к примеру, нужно нам найти всех друзей наших друзей:

• Количество JOIN-ов растёт экспоненциально с каждым уровнем.
• Уже на 3+ переходах запрос становится почти нечитаемым.
• Кратно падает производительность

Теперь посмотрим, как в графовой базе это будет реализовано:

Отлично подходит для антифрода, соцграфов и рекомендательных систем.

И совершенно не подходит для OLAP-аналитики.

5. Streaming Event Sourcing (Kafka + CDC)

Классический batch-ETL плохо сочетается с системами реального времени. Для real-time аналитики более всего подходит CDC.

CDC превращает изменения в базе данных в события, которые отправляются потребителю (DWH).

Данные становятся не снимком, а временной линией.

Как все это работает

· Базы данных → источники событий

· Kafka → надёжный журнал событий

· Потребители → могут пересобрать состояние в любой момент

Пример (из debezium):

Плюсы

· данные в реальном времени

· встроенное восстановление после сбоев

· слабая зависимость между продюсерами и консьюмерами

Минусы

· высокая сложность реализации

· порядок событий и идемпотентность реализовать непросто

· отладка требует видимости на уровне событий

4. Columnar Storage (Parquet, Delta Lake) для дешёвой и быстрой аналитики

Row oriented базы (данные стандартно лежат в виде строк в таблицах) оптимизированы под точечные запросы, а не под аналитику. Если вы выбираете из таблицы всего два столбца из ста, все равно будет считываться весь файл, так как все столбы хранятся в одном файле.

Колоночный же формат подразумевает, что значения столбцов лежат в разных местах.

Ключевые преимущества

· читаются только нужные колонки

· сильное сжатие (RLE, словарное кодирование)

· векторизованное выполнение

Меньше I/O → быстрее запросы.

Структура таблицы:

3. Мульти-модельные (когда SQL и NoSQL одновременно)

В реальной жизни данные редко бывают одного типа.

Современные приложения одновременно работают с:

· реляционными фактами

· полуструктурированным JSON

· связями между сущностями

Мульти-модельные базы позволяют запрашивать всё это в одном месте.

Вот типичный сценарий, когда один из столбцов хранит данные в jsonb:

И вот пример запроса к такой таблице:

Как видно для аналитика это не совсем удобно. Поэтому (как в сценарии с data vault), для аналитиков лучше делать отдельные витрины, где данный json уже разложен на нужные столбцы.

Плюсы

· одна система для разных типов данных

· мощный SQL при гибкой схеме

· меньше ETL и копирования данных

Минусы

· сложнее управлять схемой

· планы запросов могут усложняться

· медленнее специализированных движков

2. Reverse ETL (операционная аналитика, возвращающая данные в приложения)

Классическая аналитика заканчивается дашбордами и отчетами.

Reverse ETL замыкает цикл: данные из хранилища отправляются обратно в операционные системы. Будь то скорректированные данные или какие-то посчитанные в DWH метрики, которые должны также храниться в информационной системе, что отображаться на сайте или еще где-нибудь.

Вот частые примеры использования:

· почти-реальная персонализация

· актуальные метрики здоровья клиента и оттока

· автоматизация продаж и маркетинга (CRM, ESP и т.д.)

1. Единый слой данных (наше будущее)

Вот обычная картина в средней компании: операционные данные хранятся в PostgreSQL, аналитические данные в Greenplum, стриминговые данные в Clickhouse, данные для поиска в Elasticsearch. Четыре системы, между которыми данные нужно синхронизировать и реплицировать.

Unified Serving Layer использует единый логический слой таблиц

Например, Iceberg / Hudi / Delta с разными способами доступа.

То есть, один набор данных, много движков, без ETL.

Данные лежат в одном месте, но читаются разными движками, предназначенными для разных задач.

Что это заменяет

· нет ETL (warehouse → lake → feature store)

· рассинхронизацию данных между системами

· повторную реализацию логики в SQL, Spark и приложениях

Пример таблицы в Iceberg

OLAP-запрос (Trino / Spark SQL)

Плюсы

· единый источник истины

· доступ из разных движков (SQL, ML, стриминг)

· ACID, time-travel, эволюция схемы

· отсутствие vendor lock-in

Минусы

· более сложная платформа

· требуется сильное управление метаданными и governance

· не является прямой заменой OLTP-БД (потому что с нагрузкой может не справиться).

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

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

Что такое таск-менеджер и зачем он нужен

Таск-менеджер (Task Manager) — это программное обеспечение для организации и контроля рабочего процесса. Оно позволяет создавать задачи, назначать ответственных, устанавливать сроки (дедлайны), отслеживать статус выполнения и хранить всю коммуникацию по проекту в едином цифровом пространстве.

Стоит сразу оговориться: никакой, даже самый продвинутый тaск-менеджер, не способен компенсировать отсутствие выстроенных процессов и мотивации в команде.

В базовом варианте это просто доска со стикерами «Нужно сделать», «В работе», «Готово». Но современные таск-трекеры для команды умеют гораздо больше:

• Синхронизация: все видят, кто чем занят прямо сейчас;
• Контекст: обсуждение задачи идет внутри задачи, а не в пяти разных чатах;
• Прозрачность: руководитель видит узкие места, а сотрудник — свой вклад в общий результат;
• База знаний: хранилище всех регламентов и документов в одном окне с задачами.

Без нормального таск-трекера вы управляете компанией вслепую. С ним — у вас появляется приборная панель.

Как мы составляли рейтинг лучших таск-менеджеров

Чтобы составить этот рейтинг таск-трекеров, мы оценивали системы по критериям, которые важны для реального бизнеса в России в 2026 году:

1. Функциональность: насколько глубоко проработаны Kanban, Scrum, диаграммы Ганта?
2. Юзабилити: можно ли начать работать без недельного обучения?
3. Гибкость: насколько легко настроить систему под себя?
4. Локализация: серверы в РФ, оплата в рублях, поддержка на русском;
5. Цена: есть ли бесплатные таск-менеджеры или адекватные тарифы для малого бизнеса.

Топ-10 лучших таск-менеджеров 2026 года

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

1. SimpleOne SDLC — лучший таск-трекер для ИТ-проектов и разработки ПО

Начнем с тяжелой артиллерии. Если ваша компания занимается созданием программных продуктов, вам нужно что-то серьезнее простой доски с задачами.

SimpleOne SDLC — это профессиональная система для управления полным циклом разработки и ИТ-проектами на базе современной Low-code платформе с встроенной ИИ-автоматизацией.

Ключевая функциональность и возможности:

• Управление портфелем продуктов: иерархическая структура «Портфель → Продукт → Модули → Бэклог → Команды» позволяет декомпозировать задачи от глобальной бизнес-цели до конкретного коммита;
• Гибкие методологии (Agile): полноценная поддержка Scrum (управление спринтами, покер-планирование) и Kanban (доски, WIP-лимиты);

• Сквозная интеграция с инструментами разработчиков: Открытый Rest API, а также глубокая связка с Git-системами (GitLab, Bitbucket). Система автоматически отслеживает изменения в коде и связывает их с задачами;

• Аналитика и отчетность: встроенные профессиональные дашборды (Burndown Chart, Cumulative Flow Diagram, Velocity) для контроля скорости и качества разработки;
• Единая экосистема: бесшовная интеграция с ITSM-модулем — инциденты из поддержки легко превращаются в дефекты для разработчиков;
• База знаний: структурированная база знаний с иерархией статей и связью документов, спецификаций и инструкций с задачами и услугами;
• Диаграмма Ганта: интерактивная диаграмма Ганта для планирования сроков, зависимостей и загрузки команды с контролем выполнения и корректировкой планов;
• ИИ анализ кода: автоматический ИИ‑анализ кода в GitLab с выбором модели, отслеживанием статуса проверки и публикацией результатов в виде комментариев к изменениям.

Плюсы:

• Мощная Low-code платформа: можно менять логику процессов и интерфейс «мышкой» без программистов;
• Готовность к высоким нагрузкам (Enterprise-уровень);
• Возможность построить единый контур SDLC + ITSM.

Минусы:

• Избыточен для маленьких команд (до 10 человек), которым нужно «просто двигать карточки»;
• Требует осознанного внедрения и настройки под процессы компании.

Цены:

Стоимость рассчитывается индивидуально (Enterprise-модель лицензирования).

Для кого: крупные продуктовые компании, банки, финтех, интеграторы, которым нужен полный контроль над разработкой.

2. Kaiten — российский таск-трекер для Agile и Kanban команд

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

Ключевая функциональность и возможности:

• Единое информационное пространство: уникальный режим отображения (Combined WIP), позволяющий видеть задачи разных отделов и команд на одном экране;
• Визуализация процессов: гибкие Канбан-доски с возможностью настройки колонок, дорожек (swimlanes) и блокировок;
• Поддержка методологий: готовые шаблоны для Scrum (спринты, бэклог, оценка) и Kanban;
• Управление ресурсами: встроенный учет времени, трекинг часов и автоматические отчеты по эффективности;

• База знаний: встроенный редактор документов для хранения регламентов и проектной документации прямо в системе;
• Интеграции: готовые коннекторы с Telegram, Slack, GitLab, GitHub и другими сервисами.

Плюсы:

• Очень наглядный интерфейс: сразу видно, где «бутылочное горлышко» в процессе;
• Бесплатный тариф с достаточно богатым функционалом для старта;
• Отличная замена Trello и Jira для небольших и средних Agile-команд.

Минусы:

• Может подтормаживать на очень больших объемах задач и сложных досках;
• Слабая кастомизация логики (нельзя переписать поведение системы под себя скриптами).

Цены:

Есть бесплатный тариф (до 5 пользователей). Платные начинаются от 185 ₽ за пользователя/мес (до 15 пользователей) и от 580 ₽ за пользователя/мес (в бизнес тарифе).

Для кого: Agile-команды, стартапы, digital-агентства, продуктовые команды.

3. Strive — таск-менеджер с базой знаний и календарем

Strive — относительно новый игрок, который делает ставку на простоту и объединение задач с регламентами. Это своеобразный гибрид Notion и Trello для тех, кто любит порядок и минимализм.

Ключевая функциональность и возможности:

• Управление задачами: классические Канбан-доски с настраиваемыми этапами и чек-листами;

• База знаний (Wiki): полноценный редактор документов с возможностью вставки мультимедиа, таблиц и ссылок на задачи;
• Планирование: личные и командные календари для визуализации сроков и встреч;
• Регламенты: возможность привязывать инструкции из базы знаний прямо к задачам, чтобы исполнитель видел, как делать работу;
• Рабочие пространства: разделение задач по проектам или отделам (воркспейсы).

Плюсы:

• Чистый, современный дизайн, в котором приятно работать;
• Удобно вести документацию проекта прямо рядом с задачами, не теряя контекст;
• Интуитивно понятный интерфейс, не требующий обучения.

Минусы:

• Пока не хватает многих «взрослых» функций (Диаграмма Ганта, сложные отчеты, автоматизация);
• Мало готовых интеграций с внешними сервисами.

Цены:

Бесплатно до 10 человек (с ограничениями). Pro-тариф от 250 ₽ за пользователя/мес.

Для кого: небольшие команды, контент-мейкеры, редакции, малый бизнес.

4. YouGile — таск-трекер для команд с CRM

YouGile сделал ставку на общение. Это гибрид таск-трекера и корпоративного мессенджера. Идея проста: каждая задача — это чат, где обсуждение не отрывается от дела.

Ключевая функциональность и возможности:

• Аgile-доски: визуальное управление задачами с колонками, стикерами и дедлайнами;
• Контекстное общение: встроенный чат в каждой задаче с поддержкой голосовых сообщений, файлов, реакций и закрепленных сообщений;

• Отчеты и сводки: автоматический сбор статистики по активности команды, просроченным задачам и времени выполнения;
• Роли и права: гибкая настройка доступа к доскам и задачам для сотрудников и клиентов (гостевой доступ);
• Планирование (в Pro): диаграмма Ганта для календарного планирования проектов.

Плюсы:

• Почти нулевой порог входа — интерфейс чатов понятен любому, кто видел Telegram;
• Ничего не теряется в личных переписках, вся история хранится в задаче;
• Полностью бесплатно для команд до 10 человек (весь функционал!).

Минусы:

• При большом количестве задач и активных обсуждениях может возникнуть информационный шум;
• Слабая автоматизация бизнес-процессов по сравнению с Low-code системами.

Цены:

Бесплатно до 10 пользователей. Далее от 594 ₽ за пользователя/мес при оплате за год.

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

5. Weeek — таск-менеджер 2026 с Помодоро и Telegram ботом

Weeek позиционирует себя как экосистема для работы. Внутри одного окна у вас и задачи, и база знаний, и простая CRM. Отличный выбор для тех, кто хочет всё в одном месте.

Ключевая функциональность и возможности:

• Мульти-просмотр: переключение между режимами Доска (Канбан), Список, Неделя (календарь) и Календарь на месяц в один клик;
• Встроенная CRM: ведение базы клиентов и сделок, связанных с задачами;
• База знаний: хранилище документов и регламентов;
• Тайм-менеджмент: встроенный Помодоро-таймер для фокусировки на задачах;
• Уведомления: умный Telegram-бот, через который можно создавать задачи и получать оповещения.

Плюсы:

• Очень стильный, быстрый и современный интерфейс;
• Отличное мобильное приложение, не уступающее десктопной версии;
• Многофункциональность: заменяет сразу несколько сервисов (Trello, Notion, CRM).

Минусы:

• Аналитика пока слабовата для глубокого анализа эффективности;
• Иногда встречаются баги в мобильной версии при слабом интернете.

Цены:

Бесплатно до 5 пользователей. Pro-тариф от 199 ₽/мес.

Для кого: фрилансеры, микро-команды, творческие коллективы, стартапы.

6. Shtab — таск-менеджер с тайм-трекингом и скриншотами

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

Ключевая функциональность и возможности:

• Трекер задач: гибкое управление задачами с видами Доска, Список, Матрица Эйзенхауэра и Календарь;

• Контроль времени: встроенный тайм-трекер с возможностью делать скриншоты экрана сотрудника и отслеживать активность;
• Финансы: автоматический расчет зарплаты сотрудников и стоимости проектов на основе затреканных часов и ставок;
• Командная работа: комментарии, чек-листы, метки и приоритеты.

Плюсы:

• Идеально для тех, кто платит за часы (Time & Material): прозрачный биллинг;
• Прозрачность работы удаленщиков: всегда видно, кто и чем занят;
• Чистый дизайн.

Минусы:

• Функция скриншотов часто воспринимается командой как микроменеджмент и недоверие;
• Слабый функционал для сложной инженерной разработки (нет интеграций с Git, CI/CD).

Цены:

Есть бесплатный период. Платные тарифы от 190 ₽/мес (до 20 пользователей).

Для кого: аутсорс-агентства, бюро переводов, дизайн-студии с почасовой оплатой, команды на удаленке.

7. Битрикс24 — универсальный таск-менеджер с CRM для бизнеса

Битрикс24 — это настоящий комбайн «все-в-одном». Здесь есть всё: от задач до конструктора сайтов и видеозвонков.

Ключевая функциональность и возможности:

• Задачи и проекты: иерархия задач, Канбан, Диаграмма Ганта, контроль сроков и чек-листы;
• CRM-система: мощный модуль для продаж, телефонии и маркетинга, тесно связанный с задачами;
• Коммуникации: корпоративный портал, чаты, видеозвонки, лента новостей;

• Автоматизация: роботы и триггеры для автоматического движения задач и сделок;
• Совместная работа: диск для файлов, онлайн-редактор документов, календари.

Плюсы:

• Огромный функционал за одну цену — можно закрыть почти все потребности офиса;
• Мощная экосистема и маркетплейс приложений;
• Наличие коробочной версии (On-premise) для установки на свой сервер.

Минусы:

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

Цены:

Есть бесплатный тариф. Платные от 1 743 ₽/мес за 5 пользователей при оплате за год.

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

8. Яндекс Трекер — корпоративный российский таск-трекер

Яндекс Трекер — инструмент, выросший из недр Яндекса и ставший публичным облачным сервисом. Надежный, строгий, масштабируемый и глубоко интегрированный в экосистему Yandex Cloud.

Ключевая функциональность и возможности:

• Управление потоком: очереди задач, фильтры, дашборды и гибкая настройка workflow;
• Agile-инструменты: доски для Scrum и Kanban, планирование спринтов, диаграммы сгорания задач;
• Проектное управление: диаграмма Ганта, вехи, статистика;
• Интеграции: нативная связка с Yandex Cloud, Yandex Forms, Wiki и другими сервисами Яндекса.

Плюсы:

• Привычный и понятный интерфейс для тех, кто пользовался сервисами Яндекса;
• Бесплатно для первых 5 пользователей (полный функционал);
• Высокая надежность и безопасность инфраструктуры Яндекса.

Минусы:

• Интерфейс довольно аскетичный и «сухой», ориентирован на инженеров;
• Может быть сложен в первоначальной настройке очередей и прав доступа.

Цены:

Бесплатно до 5 пользователей. Далее от 399 ₽ за пользователя (до 10 сотрудников) при оплате за год.

Для кого: ИТ-команды, стартапы, использующие инфраструктуру Yandex Cloud.

9. ПланФикс — кастомный российский таск-менеджер для процессов

ПланФикс — это не просто трекер, а конструктор, из которого можно собрать хоть CRM, хоть Service Desk, хоть систему управления складом, не написав ни строчки кода.

Ключевая функциональность и возможности:

• Конструктор процессов: полная настройка полей, кнопок, статусов и сценариев перехода;
• Автоматизация: мощные автоматические сценарии (боты) для рутинных действий;
• Коммуникации: интеграция с WhatsApp, Telegram, Email — сообщения превращаются в задачи;
• Планирование: планировщики, календари и Диаграмма Ганта.

• Аналитика: настраиваемые отчеты по любым данным в системе.

Плюсы:

• Невероятная гибкость. Можно реализовать практически любую бизнес-логику;
• Позволяет собрать CRM и таск-трекер в одном интерфейсе;
• Доступная цена.

Минусы:

• Высокий порог входа — чтобы настроить систему, нужно мыслить как системный аналитик;
• Дизайн «на любителя», может показаться перегруженным.

Цены:

Бесплатно до 5 сотрудников. Платные тарифы от 8 $/пользователь (цены в долларах, но оплата в рублях по курсу).

Для кого: компании с нестандартными процессами, готовые инвестировать время в настройку «под себя».

10. LeaderTask — оффлайн таск-трекер для фрилансеров и малого бизнеса

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

Ключевая функциональность и возможности:

• Управление задачами: древовидная структура задач, подзадачи, чек-листы, метки и цвета;
• Планирование: ежедневник, календарь, напоминания;

• Поручения: возможность поручать задачи сотрудникам и контролировать их выполнение;
• Канбан: простая доска для визуализации этапов;
• Оффлайн-режим: полноценная работа без интернета с последующей синхронизацией.

Плюсы:

• Работает без интернета (уникально для современных сервисов);
• Очень быстрый и легкий десктопный клиент;
• Прост в освоении.

Минусы:

• Функционал для командной работы довольно базовый по сравнению с конкурентами;
• Устаревший дизайн десктопной версии.

Цены:

Есть бесплатная версия. Премиум для команд — 4999 ₽/год за одного пользователя.

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

Сравнительная таблица таск-трекеров

Чтобы упростить муки выбора, мы свели ключевые характеристики в одну таблицу.

Как выбрать подходящий таск-менеджер: чек-лист

Не существует «самого лучшего» трекера. Есть тот, который подходит именно вам. Пройдитесь по чек-листу перед покупкой:

1. Размер команды. Если вас 5 человек — берите YouGile или Weeek. Если 500+ разработчиков — смотрите в сторону SimpleOne или Яндекс Трекера;
2. Специфика работы. Для IT важны интеграции с Git и CI/CD (SimpleOne, Kaiten). Для продаж — CRM и чаты (Битрикс24, YouGile);
3. Бюджет. Готовы ли вы платить за каждого пользователя или ищете бесплатное решение на старте?
4. On-premise. Критично ли вам ставить софт на свои сервера? Если да, круг сужается до SimpleOne, Kaiten (Enterprise), Битрикс24 (Коробка);
5. Гибкость. Будете ли вы менять процессы под софт, или софт должен прогнуться под вас? Для второго варианта нужны Low-code платформы (SimpleOne, ПланФикс).

Выводы

В 2026 году рынок таск-трекеров в России перестал быть просто «импортозамещением». Мы видим зрелые платформы, которые формируют собственные методологии.

Ключевой инсайт для CTO и Team Lead: при выборе стека оценивайте не текущий функциональный feature-set, а архитектурный потенциал масштабирования. Классическая ошибка — внедрение инструмента, который идеально закрывает потребности команды из 10-15 человек (низкий порог входа, отличный UX), но становится блокирующим фактором при масштабировании до 50+ сотрудников, когда на первый план выходят регламенты, безопасность и интеграции.

• Для продуктовых команд с планами выхода на Enterprise-уровень целесообразно сразу закладывать фундамент в виде платформ класса SimpleOne SDLC. Это превентивная инвестиция в управляемость техническим долгом и сквозную прозрачность процессов (End-to-End Visibility);
• Для стартапов, где Time-to-Market критичнее формализации, решения вроде Kaiten или YouGile обеспечат необходимую динамику. Однако стоит заранее продумать стратегию миграции данных при неизбежном усложнении процессов.

Главный совет: не выбирайте по скриншотам. Зарегистрируйтесь, заведите реальный проект и попробуйте прожить в системе хотя бы пару дней. Выбирайте не интерфейс, а логику, которая станет основой вашей инженерной культуры.

Реклама. Рекламодатель: ООО «СИМПЛ 1», ИНН 9725013892, erid: 2W5zFJeLnk9

Релиз немного задержался — компания в последний момент отложила старт тестирования, пообещав, что обновление выйдет «скоро». В итоге пауза продлилась всего несколько дней.

Бета уже распространяется «по воздуху» для участников Android Beta Program. Владельцы актуальных Pixel получат обновление автоматически.

Обязательная адаптивность и доработанная камера

Одно из ключевых изменений — обязательная поддержка адаптивных интерфейсов для приложений, ориентированных на Android 17.

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

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

Также в системе появились визуальные правки интерфейса. Google продолжает постепенно дорабатывать дизайн, не меняя радикально общую концепцию.

Как установить и когда ждать релиз

Участники программы тестирования получат Android 17 Beta 1 автоматически. Тем, кто не хочет устанавливать бета-версию, нужно выйти из программы и дождаться стабильной сборки.

Финальный релиз Android 17 ожидается во II квартале 2026 года. Судя по первой бете, Google делает ставку не на громкие функции, а на стабильность, производительность и требования к качеству приложений.

Для экосистемы это может оказаться важнее любой эффектной анимации.

Новый GC по умолчанию: минус до 40% накладных расходов

Так, в релизе включён сборщик мусора greenteagc. Он оптимизирован для частого создания и сканирования мелких объектов.

В приложениях с активной аллокацией это даёт снижение накладных расходов GC на 10–40%. Если у вас сервис с короткоживущими структурами, это обновление может стать бесплатным ускорением, без изменения кода.

cgo стал дешевле

Вызовы функций на C через cgo также подешевели примерно на 30%. Это важно для проектов, которые тянут нативные библиотеки (криптография, обработка изображений, старый C-код).

Дополнительно в runtime для 64-битных платформ включили рандомизацию адресного пространства (heap base). Это усложняет эксплуатацию уязвимостей в C-коде, подключённом через cgo. При необходимости можно отключить через:

new() теперь умеет принимать выражения

Встроенная функция new() получила маленькое, но приятное расширение: теперь можно передать выражение для начального значения.

Было:

Теперь можно:

Мелочь, но код становится компактнее и чище.

Обобщённые типы: разрешили «ссылаться на себя»

Generics стали чуть гибче. Теперь тип может передавать сам себя в список параметров типа:

Раньше такая самоссылка вызывала ошибку. Теперь — нет. Для сложных generic-алгоритмов это снимает лишние ограничения.

Больше аллокаций в стеке, меньше в куче

Компилятор расширил список случаев, когда слайсы размещаются в стеке, а не в куче. А так как меньше давления на GC, то и выше производительность.

go fix переписали полностью

Команду go fix переписали на базе пакета analysis. Теперь она использует анализаторы из пакета modernize, которые предлагают правки с учётом новых возможностей языка и стандартной библиотеки.

Также появился анализатор inline — он разворачивает вызовы функций, помеченных директивой:

Новые пакеты

В стандартную библиотеку добавили:

• crypto/hpke — реализация Hybrid Public Key Encryption
• crypto/mlkem/mlkemtest
• testing/cryptotest

Появился экспериментальный simd/archsimd — низкоуровневый доступ к SIMD-инструкциям на AMD64. Это первый осторожный шаг Go в сторону управляемых векторных вычислений без ассемблера.

Также добавили экспериментальный runtime/secret для безопасного обнуления временной памяти и новый профиль goroutineleak в runtime/pprof — для поиска утечек горутин.

Скачать Go 1.26 можно по ссылке.

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

Движок на Flutter, но с С++ под капотом

Ключевая идея Fluorite — «Dart-first» архитектура. Логика пишется на Dart и напрямую интегрируется с экосистемой Flutter: виджеты, Hot Reload, Widget Inspector и пакеты из pub.dev работают так же, как в обычных приложениях.

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

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

Графика уровня AAA за счет Filament

Для рендеринга Fluorite использует Filament — 3D-движок Google с поддержкой физически корректного освещения (PBR). Это дает современное качество картинки без необходимости писать собственный рендерер или жертвовать производительностью ради кроссплатформенности.

По словам команды, связка Flutter + Filament позволяет разделить ответственность: UI и взаимодействие остаются на Flutter, а графика и сцена — на специализированном движке.

Чем Fluorite отличается от конкурентов

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

За счет этого итерации быстрее, а входной порог ниже, чем у традиционных игровых движков.

Toyota подчеркивает, что Fluorite — open-source проект и его дальнейшее развитие во многом зависит от сообщества. Судя по архитектуре, компания делает ставку на то, что интерактивные 3D-приложения станут таким же обычным сценарием для Flutter, как мобильные и веб-интерфейсы.

Проблема: почему Prisma медленнее «чистого SQL»

Prisma — удобная ORM, но каждый запрос проходит через несколько уровней обработки:

Каждый уровень добавляет задержку. Улучшения в Prisma v7 не устраняют фундаментальные ограничения этой архитектуры.

Практический эффект:

Для высоконагруженных API, которые обрабатывают тысячи запросов в секунду, разница в 0.17 ms на запрос быстро превращается в заметную прибавку к общей задержке.

Решение: выполнять SQL напрямую

Единственный способ добиться производительности «чистого SQL» — обойти Query Engine Prisma, но при этом сохранить привычный API Prisma клиента.

Сравнение архитектур

Обычная Prisma:

Оптимизированный подход:

Если генерировать SQL прямо из JSON-запроса и выполнять его через проверенные драйверы, накладные расходы Query Engine исчезают. Процесс подготовки становится обычным превращением JSON в строку.

Реализация

1) Установка зависимостей

PostgreSQL:

SQLite:

2) Базовая настройка (runtime-режим)

PostgreSQL:

SQLite:

Готово. Код запросов менять не нужно. Все операции чтения теперь выполняются быстрее.

3) Продвинутый режим: generator (предварительная генерация SQL)

Для максимальной производительности можно «запечь» самые частые запросы на этапе сборки.

Добавьте в schema.prisma:

Сгенерируйте код:

Подключите сгенерированное расширение:

Сравнение накладных издержек:

• Prisma v7: ~0.34 ms
• Runtime-режим: ~0.20 ms (примерно в 1.7 раза быстрее)
• Generator-режим: ~0.03 ms (примерно в 11 раз быстрее)

Результаты бенчмарков

Тесты на 137 E2E-запросах, сравнивающих идентичные операции.

PostgreSQL

В среднем: в 2.10 раза быстрее, чем Prisma v7

SQLite

В среднем: в 5.48 раза быстрее, чем Prisma v7

Конфигурация для production

1) Режим отладки

Можно видеть сгенерированный SQL для каждого запроса:

2) Мониторинг производительности

Можно отслеживать время выполнения запросов в production:

3) Выборочная оптимизация

Можно ускорять только «горячие» модели:

4) Настройка пула соединений

Пример конфигурации postgres.js для production:

Поддерживаемые возможности

✅ Что ускоряется (выполняется через «чистый SQL»)

Запросы:

• findMany, findFirst, findUnique
• count
• aggregate (_count, _sum, _avg, _min, _max)
• groupBy с условиями having

Фильтры:

Связи:

Пагинация и сортировка:

❌ Что остаётся на стандартной Prisma (без изменений)

Запись:

• create, update, delete, upsert
• createMany, updateMany, deleteMany

Продвинутые возможности:

• Транзакции ($transaction)
• Сырые запросы ($queryRaw, $executeRaw)
• Middleware
• Другие расширения Prisma Client

Поддержка Edge Runtime

Vercel Edge Functions

Cloudflare Workers

Руководство по миграции

Со стандартной Prisma

Было:

Стало:

С Drizzle ORM

Было:

Стало:

Частые проблемы и решения

1)

Проблема:

Решение:

2) Исчерпан пул соединений

Проблема:

Решение:

3) Результаты отличаются от стандартной Prisma

Проблема:

Решение:

Если результаты действительно расходятся, создайте issue: https://github.com/multipliedtwice/prisma-sql/issues

4) Производительность почти не выросла

Проблема: ожидалось ускорение в 2–7 раз, но прирост минимальный.

Возможные причины:

1. Доминирует сеть: на удалённой БД задержка сети (10–50 ms) «затмевает» накладные издержки (0.2 ms)
2. Очень простые запросы: findUnique по индексированному ID и так быстрый
3. Нет индексов: запросы упираются в план выполнения БД

Что сделать:

Когда это не стоит применять

Оставьте стандартную Prisma, если:

1. Преобладает запись: больше 50% операций — запись
2. Простой CRUD: одна таблица, минимум связей
3. Команда не готова: нет опыта с postgres.js / better-sqlite3
4. Нужны неподдерживаемые функции Prisma: активное использование возможностей, которые здесь не покрыты

Этот подход подходит, когда:

1. Преобладает чтение: более 70% операций — чтение
2. Высокая пропускная способность: >1000 rps, где важны миллисекунды
3. Сложные запросы: много связей, агрегаций, условий
4. Оптимизация затрат: меньше задержка → меньше ресурсов

Заключение

Можно добиться 100% производительности «чистого SQL», не отказываясь от удобства Prisma.

Основные преимущества:

• Ускорение чтения в 2–7 раз без переписывания запросов
• Те же типы и тот же API Prisma Client
• Подходит для production (по заявлению авторов) и покрыто E2E-тестами
• Работает в существующих проектах Prisma

Быстрый старт:

1. Установите prisma-sql и postgres/better-sqlite3
2. Подключите расширение
3. Задеплойте и измерьте эффект

Дальнейшая оптимизация:

1. Подключите generator для «горячих» запросов
2. Включите мониторинг через onQuery
3. Настройте пул соединений

Ресурсы:

• NPM: https://www.npmjs.com/package/prisma-sql
• GitHub: https://github.com/multipliedtwice/prisma-to-sql
• Документация: https://github.com/multipliedtwice/prisma-to-sql#readme
• Примеры E2E-тестов: https://github.com/multipliedtwice/prisma-to-sql/tree/main/tests/e2e

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

1. Visary Tracker: когда нужна экосистема, а не просто доска

Visary Tracker — это часть более крупной платформы Visary Cloud, что сразу даёт понять: система заточена не под стартапы с пятью задачами в бэклоге, а под команды, которым нужна глубокая аналитика и связка процессов. Применяется как в разработке ПО, так и в управлении проектами, поддержке и операционной работе.

Доступ через веб-интерфейс, работает с любой ОС. Развёртывание — на выбор: облако (SaaS на мощностях Cloud.ru) или on-premise, если у компании строгие требования к инфраструктуре. В облачной версии данные хранятся в РФ в соответствии с 152-ФЗ, система включена в реестр отечественного ПО (запись №23958 от сентября 2024 года).

Методологии и визуализация процессов

Для команд, работающих по Agile, реализована поддержка Scrum и Kanban. Можно отслеживать прогресс через Burndown Chart, смотреть на скорость команды через Velocity, планировать долгосрочные работы с помощью дорожной карты.

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

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

В комплект с Visary Tracker входит пакет бесплатных сервисов экосистемы, который включает:

• Сервис коммуникаций (чат, интегрированный в задачи, и сервис видеосвязи);
• Функционал организационной диаграммы (органиграммы);
• Дисковое хранилище для управления, совместного редактирования и хранения файлов;
• Корпоративный календарь.

Права доступа и безопасность

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

Если команда работает с чувствительными данными или ведёт проекты для крупных заказчиков с требованиями по безопасности, можно поднять систему на собственных серверах. С on-premise версией у вас будет полный полный контроль над инфраструктурой и данными.

Производительность и масштабирование

Интересная особенность — отсутствие искусственных лимитов на количество пользователей и проектов. Система не заставляет пересматривать тарифный план, если команда выросла с 10 до 100 человек. Хранилище подбирается под задачи клиента, минимум — 25 Гб, дальше по потребностям.

Для автоматизации рутины предусмотрены:

• REST API и вебхуки для интеграции с системами контроля версий (Git, GitLab, Bitbucket), мессенджерами (Slack, Telegram) и CI/CD-инструментами.
• Планировщик задач и триггеры, которые избавляют от необходимости вручную менять статусы или назначать исполнителей.
• Модуль Visary BI — конструктор дашбордов, если стандартных отчётов не хватает и нужно строить сложную аналитику по проектам.

Тайм-трекинг, встроенный в систему, позволяет вести учёт рабочего времени по задачам. Контроль загрузки команды осуществляется через назначение веса каждой задаче. Для анализа данных в сводной информации по эпику, этапу или спринту отображается суммарный вес всех входящих в них задач.

Миграция и техподдержка

Для команд, которые переезжают с другого трекера, есть инструмент импорта данных. В системе есть специальные сервисы для настройки переноса данных с различных IT-продуктов и настройки интеграции для полноценной работы. Для больших объёмов данных доступны дополнительные опции: платные работы по переносу или приобретение модуля ETL.​

Интерфейс полностью на русском, есть светлая и тёмная темы. Документация, видеоуроки и техподдержка — всё локализовано. Саппорт доступен через Telegram, почту и телефон. Перед покупкой можно запросить демо-доступ и посмотреть, как система работает на реальных данных.

Тарификация

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

2. Аспро.Cloud: когда таски нужно подружить с экономикой проекта

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

Система работает как SaaS, доступна на Windows, macOS, Linux, iOS, Android (облако + мобильное приложение). Все данные находятся на серверах в РФ, есть внутренний аудит действий пользователей, шифрование данных в транзите и безвозвратное удаление данных. Система обновляется без простоя системы.

Методологии и визуализация

Разработчикам и PM-ам здесь выкатили полный набор: Agile-модуль для Scrum и Kanban, и отдельный функционал для Waterfall. В плане визуализации всё стандартно, но функционально:

• Канбан-доски для бэклога и текучки.

• Диаграмма Ганта (timeline) для планирования сроков и зависимостей.

• Календарь и списки.
• Модуль Workload — критичная штука для оценки загруженности команды.

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

Техстек и автоматизация

Для тех, кто не любит рутину, предусмотрена RPA-автоматизация: авто-назначение исполнителей, триггеры на смену статусов и планировщик регулярных задач.

По интеграциям список внушительный:

• Системы контроля версий: GitLab, Bitbucket — связываем коммиты с задачами.
• 1С и API: интеграция с 1С:Бухгалтерия 8.3 и открытый REST API для связки с внутренними системами.
• Мессенджеры и соцсети: Telegram, WhatsApp/WhatsApp Business, ВКонтакте, Viber — уведомления и общение с клиентами в привычных каналах.
• Почта: Gmail, Яндекс.Почта, Mail.ru, Outlook, IMAP — задачи можно создавать прямо из писем.
• Облачные хранилища: Google Drive, Яндекс Диск, OneDrive, Dropbox — файлы к задачам подтягиваются из привычных мест.
• IP-телефония: UIS, Mango Office, Телфин, МегаФон, Новофон, Twilio — записи звонков и история коммуникаций привязываются к проектам.
• Банки: Сбербанк, Т-Банк, Альфа-Банк, ВТБ, Точка, Модульбанк, Райффайзен — автоматическая загрузка банковских операций для контроля бюджета.
• Платежные системы: СБП, ЮKassa, CloudPayments, Robokassa, Дзен-мани — приём оплат и выставление счетов.
• Сайты и сервисы: Tilda, готовые сайты Аспро, Jivo, Calendly, DaData, Xmind — связка с маркетингом и автоматизацией лидогенерации.

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

Безопасность и масштабирование

Система тянет до 300+ пользователей и до 1 ТБ хранилища (лимиты зависят от тарифа). В плане безопасности завезли:

• Гибкое управление ролями (чтобы аутсорсеры не видели лишнего).
• Полный аудит действий пользователей.
• Поддержку IP-белых списков и шифрование данных в транзите.
• Резервное копирование и возможность безвозвратного удаления данных.

Миграция и поддержка

Если решили переезжать, есть штатный импорт из Jira, Asana и Trello. Интерфейс полностью на русском, документация и база знаний тоже. Саппорт отвечает через чат, почту и Telegram в рабочее время.

Тарифы

Модель — подписка от месяца до двух лет.

• Бесплатная версия: до 5 пользователей и 5 ГБ места (функционал урезан).
• Платные тарифы: зависят от количества юзеров и объема хранилища.
• Триальный период: 14 дней, чтобы понять полный функционал.

У команды есть обучающие материалы: видеоуроки, вебинары, курсы, сертификация. Пользователи часто помогают в сообществе в ВК, также есть Telegram-канал и клуб пользователей в чате Telegram-канала.

3. WEEEK: аналог всего знакомого

WEEEK попадает в категорию систем, которые пытаются закрыть сразу всё: трекинг задач, управление проектами, базу знаний и даже CRM. По сути, это попытка собрать рабочее пространство в одном месте, чтобы не прыгать между пятью вкладками. Судя по отзывам пользователей, которые переезжали с Trello, Asana, Notion и даже Jira, система справляется с этой задачей неплохо.

Архитектура и организация работы

Структура здесь трёхуровневая: рабочие пространства → проекты → доски/календари/списки. Классическая матрёшка, как сами разработчики это называют.

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

CRM и документы

Интересная фича — встроенная CRM с воронками продаж и аналитикой по конверсии. Это не основная функция таск-менеджера, но для команд, где разработка завязана на клиентские запросы (студии, агентства, аутсорс), может упростить жизнь.

База знаний работает как внутренний wiki — можно хранить документацию, процессы, регламенты. Поддерживаются Google Docs и Sheets через интеграции, так что если команда уже завела гугл-документы, их можно прикручивать к задачам напрямую.

Автоматизация и интеграции

Уведомления настраиваются гибко: можно отправлять в Telegram, на почту, в браузер или мобильное приложение. Для тех, кто сидит только в Telegram-каналах, это удобно — не нужно постоянно заходить в интерфейс системы, чтобы проверить, что там изменилось.

Из интеграций упоминаются Figma, Miro, Airtable и связка с Google. Есть API, что теоретически позволяет прикрутить систему к своим инструментам или автоматизировать через скрипты.

Тайм-трекинг встроен, плюс есть помодоро-таймер для тех, кто практикует работу интервалами. Горячие клавиши и тёмная тема — стандарт для любого инструмента, которым пользуешься по 8 часов в день.

Миграция и адаптация

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

ИИ-помощница и дополнительные фишки

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

Тарификация

Есть бесплатная версия, которая по отзывам вполне функциональна для небольших команд. Платная подписка расширяет возможности. Для студентов предусмотрена студенческая подписка, что редкость для российских сервисов.

Техподдержка и комьюнити

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

4. Shtab: управление от стратегии до конкретной подзадачи

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

Работает в облаке (SaaS), в изолированном облаке (Private Cloud) и on-premise. Для крупных компаний с требованиями по информационной безопасности есть интеграция с SSO/LDAP и полный аудит.

Архитектура целей и задач

Основная фишка Shtab — иерархия от цели до подзадачи. Структура выглядит так: стратегические цели (OKR/MBO) → портфели проектов → проекты → задачи → подзадачи.

Для разработки можно привязать спринт или фичу к бизнес-цели и показать заказчику или топ-менеджменту, почему эта задача в приоритете. Прослеживаемость работает в обе стороны: снизу вверх можно понять, зачем ты вообще это делаешь, а сверху вниз — контролировать, как движется достижение цели.

Визуализация и представления данных

Система поддерживает несколько режимов работы с одними и теми же данными. Канбан-доски с настраиваемыми столбцами и WIP-лимитами для контроля нагрузки — стандарт для команд, работающих по Kanban.

Диаграммы Ганта для планирования сложных проектов с зависимостями между задачами и контролем загрузки ресурсов. Календарь для временного планирования и матрица приоритетов (срочность/важность) для фокусировки на главном.

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

Управление знаниями и файлами

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

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

Тарификация и развёртывание

Есть бесплатная версия, детали по ограничениям не уточняются. Облачная версия запускается за 5 минут с автоматическими обновлениями. Private Cloud даёт изолированную инфраструктуру в российском облаке с возможностью масштабирования. On-premise — для тех, кому нужен полный контроль и соответствие ФЗ-152.

5. Kaiten: работа по Kanban

Kaiten на рынке больше 10 лет, что для российских таск-менеджеров довольно редкий кейс. Система создавалась Kanban-командой, и это чувствуется в том, как построена работа с потоками задач.

Работает в облаке и on-premise, включена в реестр ПО РФ. Используется более чем в 200 тысячах компаний — от IT и ритейла до производства и строительства. Среди клиентов Сбер, Tele2, РусГидро, Альфа-Банк.

Kanban и Scrum без костылей

Разработчики позиционируют Kaiten как Agile-инструмент с полноценной поддержкой обеих методологий. Для Scrum-команд реализованы спринты с оценкой по Story Points, отслеживание прогресса и ретроспектива. Для Kanban — доски с гибкой структурой: можно настраивать этапы и подэтапы, ограничивать количество задач в процессе через WIP-лимиты, добавлять дорожки для параллельных потоков.

В Agile-аналитике есть Lead time отчеты, чтобы отслеживать время прохождения задачи от начала до конца и находить узкие места в процессе. Блокировки карточек можно фиксировать с указанием причины, а потом анализировать, почему задачи встают на паузу.

Планирование и управление ресурсами

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

Иерархия задач строится через родительские и дочерние карточки, что упрощает декомпозицию — разбиваешь эпик на задачи, задачи на подзадачи.

Kaiten AI

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

Кастомизация и права доступа

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

Интеграции и автоматизация

Для разработчиков есть интеграции с GitLab и GitHub. Можно связывать коммиты и мердж-реквесты с карточками задач, что упрощает трекинг технической работы. Уведомления настраиваются гибко — в приложение, на почту, в Slack или Telegram.

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

Мобильное приложение и шаблоны

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

6. ЛидерТаск: когда нужно просто начать работать

ЛидерТаск — это таск-менеджер, который на рынке уже больше 12 лет и позиционируется как инструмент для личной и командной работы. Если Visary Tracker заточен под экосистемный подход и подробную аналитику, то здесь всё проще — быстрый старт и понятность интерфейса.

Система работает как в облаке, так и на собственном сервере. Доступна через веб-интерфейс, десктопные клиенты для Windows и мобильные приложения для iOS и Android.

Из интересного: есть офлайн-режим с автоматической синхронизацией между устройствами, когда интернет снова появляется.

Организация работы

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

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

Командная работа

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

Порог входа

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

Есть бесплатная версия (ограничения не уточняются) и возможность записаться на 30-минутную демонстрацию, чтобы посмотреть на функционал в действии.

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

*WhatsApp заменил более 160 000 строк C++-кода на Rust в критически важной части приложения — обработке медиафайлов. Новый код уже развернут на миллиардах устройств: от Android и iOS до веба, десктопа и носимых гаджетов.

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

Откуда вообще взялась проблема

История тянется с 2015 года и уязвимости Stagefright в Android. Тогда выяснилось неприятное: достаточно отправить специально собранный видеофайл и он выполнит код на устройстве жертвы еще до того, как пользователь что-то нажмет.

Проблема была в системных медиабиблиотеках операционной системы. Именно поэтому приложения вроде *WhatsApp не могли решить ее самостоятельно.

После этого в *WhatsApp появился собственный C++-модуль wamedia, который проверял медиафайлы на соответствие стандартам, чтобы не скормить ОС заведомо опасный контент.

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

Почему именно Rust

В *WhatsApp довольно рано сделали неприятный, но честный вывод: значительная часть критических багов связаны с банальными ошибками работы с памятью в C и C++. Rust эту категорию проблем убирает на уровне языка.

Вместо аккуратного «подкручивания гаек», разработчики пошли чуть более радикальным путем: переписали медиабиблиотеку целиком, параллельно поддерживая две реализации — на C++ и на Rust.

Их прогоняли через дифференциальный фаззинг, тесты и сравнение поведения, пока результаты не совпали.

Что получилось на выходе

Итог оказался даже лучше ожидаемого. 160 000 строк на C++ превратились примерно в 90 000 строк на Rust. И это уже с тестами.

Производительность не просела, а потребление памяти в ряде сценариев даже снизилось. Основные сложности были не в коде, а вокруг него: размер бинарников из-за стандартной библиотеки Rust и сборка под десятки платформ.

Тем не менее, библиотеку полностью выкатили в прод. Сейчас этот Rust-код ежемесячно доставляется на миллиарды устройств, включая *WhatsApp, *Messenger и *Instagram.

В *Meta прямо называют это крупнейшим клиентским деплоем Rust, о котором им известно.

Зачем это пользователю, который «просто шлет мемы»

Новая система, внутри компании получившая имя Kaleidoscope, проверяет файлы еще до того, как ими займутся системные библиотеки.

Она отсекает битые и нестандартные структуры, ловит подмену типов (когда «картинка» на деле исполняемый файл), отдельно помечает рискованные форматы вроде PDF со скриптами и вложениями.

По сути, это еще один слой защиты. Пользователь его не видит, но это и не нужно.

Разработчики всё чаще используют генераторы API, которые позволяют описать структуру сервиса, а затем автоматически получить готовые эндпоинты, SDK, документацию, тесты или mock-сервисы. Разбираемся, где сегодня удобнее всего генерировать API и какие инструменты актуальны сегодня.

Чем полезны генераторы API

Генераторы API автоматически создают код, документацию или вспомогательные компоненты API на основе формального описания, чаще всего OpenAPI. Они ускоряют разработку, снижают количество ошибок и улучшают взаимодействие команд.

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

Главное преимущество — сокращение цикла разработки. Инструменты генерации API позволяют строить контракты быстрее и с меньшим количеством ошибок, чем при ручной работе. В крупных проектах, где есть десятки сервисов и команд, автоматизация снижает риск расхождений между спецификацией и реальной логикой в коде. Это прямой выигрыш в качестве интеграций и скорости вывода обновлений в продуктив.

Swagger

Полноценная экосистема для разработки, документирования и тестирования API на базе спецификаций OpenAPI/Swagger. Исторически Swagger Codegen был первым популярным генератором кода по Swagger/OpenAPI, но устарел.

Swagger Editor — интерактивный редактор с живой визуализацией документации. Swagger UI превращает спецификацию в интерактивный интерфейс: любой может изучить структуру API и выполнить запросы прямо в браузере, видя ответы с кодами, заголовками и телом.​ Также позволяет выполнять реальные запросы к эндпоинтам с параметрами, мгновенно показывая HTTP-ответы.

Как отмечает Елена Титова, «Swagger / OpenAPI — по-прежнему универсальный стандарт, который легко интегрируется почти с любыми CI/CD-конвейерами».

Стоимость: от €21.20 в месяц.

OpenApi Generator

Инструмент для автоматической генерации кода и артефактов на основе спецификации OpenAPI. Сервис позволяет быстро создавать клиентские библиотеки для взаимодействия с API: доступно более 50 генераторов под разные языки и платформы. Владельцы API могут использовать его для выпуска официальных SDK и полностью настраивать шаблоны генерации с помощью Mustache.

Инструмент также упрощает серверную разработку. OpenAPI Generator умеет создавать серверные заготовки более чем для 40 языков и технологий, включая Java, Kotlin, Go и PHP. В ряде генераторов поддерживается инверсия управления. Это позволяет менять дизайн API через спецификацию OpenAPI, не разрушая бизнес-логику при повторной генерации кода.

Стоимость: бесплатно.

Swagger и OpenAPI Generator — самые надёжные инструменты, которые я могу рекомендовать. Они понятные, экосистема огромная, а главное — они позволяют содержать документацию, SDK и схему API синхронизированными. Это заметно ускоряет работу с партнёрами и интеграторами: у всех один контракт, без сюрпризов.

Postman

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

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

А ещё Postman можно использовать и в быту — например, настроить автоматическую проверку статуса готовности визы.

Стоимость: есть бесплатный тариф, Basic — от $14 в месяц.

Apidog

Универсальный инструмент для тестирования и разработки API, который упрощает работу на всех этапах жизненного цикла API. Благодаря понятному интерфейсу в APIdog легко создавать и отправлять запросы, проверять ответы и автоматизировать тестирование, что делает сервис удобным как для новичков, так и для опытных специалистов.

Сервис поддерживает mock-серверы, позволяя тестировать API без готового бэкенда, автоматически генерирует интерактивную документацию и работает с REST, WebSocket и GraphQL. Управление окружениями помогает быстро переключаться между dev, staging и production, а поддержка всех основных HTTP-методов и популярных способов аутентификации закрывает большинство сценариев тестирования.

Для командной работы есть общие рабочие пространства и контроль версий, что упрощает совместную разработку и интеграцию в CI/CD-процессы.

Стоимость: есть бесплатный режим, тариф Basic — $9 в месяц.

Stoplight

Графический редактор OpenAPI. Вы просто рисуете структуру будущего сервиса, а инструмент генерирует спецификацию и документацию. Это позволяет продумать структуру API до написания кода и снизить риск ошибок.

В основе сервиса — визуальный редактор Stoplight Studio, который поддерживает OpenAPI и JSON Schema и позволяет создавать спецификации через удобные формы, работая напрямую с Git-репозиториями. Платформа автоматически генерирует документацию, создаёт мок-серверы для раннего тестирования и предоставляет инструменты проверки качества.

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

Стоимость: есть бесплатный тариф, Basic — от $41 в месяц.

Low-code наши дизайнеры тоже пробовали — Stoplight, Postman API Builder. Хороши, когда нужно быстро собрать прототип или дать возможность продуктовой команде поиграть с контрактами без участия разработчика. Но в продакшене мы всё равно возвращаемся к OpenAPI: это стабильнее и проще автоматизировать.

Hasura

Платформа для быстрого создания и управления API (GraphQL, REST и др.) поверх любых источников данных. Сервис позволяет запускать и развивать API без ручного кодирования: достаточно подключить базы данных, и система автоматически сгенерирует готовый GraphQL-интерфейс. Такой подход обеспечивает высокую гибкость и подходит как для отдельных сервисов, так и для сложных распределённых архитектур.

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

Стоимость: от $1,5 за активный час.

PostgREST

Независимый open-source веб-сервер, который автоматически превращает базу данных PostgreSQL в полноценный REST API. Вместо ручной реализации CRUD-логики он использует саму структуру базы: таблицы, представления, функции, роли и ограничения напрямую определяют доступные эндпоинты и операции. API соответствует спецификации OpenAPI и позволяет работать даже со сложными связями между таблицами через обычные HTTP-запросы.

Высокая производительность PostgREST достигается за счёт трёх факторов: сервер написан на компилируемом языке Haskell, максимальная часть логики делегируется PostgreSQL, а работа с БД ведётся через эффективный пул соединений и бинарный протокол. PostgREST позволяет администраторам и разработчикам быстро создавать масштабируемые API поверх реляционной модели без лишнего кода.

Стоимость: бесплатно.

Инструменты «API из базы» — например, Hasura или PostgREST — хороши в узких случаях, когда нужен очень быстрый CRUD поверх данных. Но в облачных продуктах, где логика сложнее, мы всё-таки проектируем API осознанно.

Supabase

Платформа разработки на базе PostgreSQL, которая берёт на себя весь бэкенд‑стек и позволяет сосредоточиться на продукте, а не на инфраструктуре. Для каждой таблицы в базе она автоматически поднимает полнофункциональный REST API с поддержкой фильтрации, сортировки и пагинации и превращает схему данных в готовый HTTP‑интерфейс без ручной ручной CRUD‑обвязки. Управление доступом завязано на встроенную аутентификацию и политику Row Level Security, поэтому правила безопасности описываются привычными SQL‑политиками, а не разрозненным кодом в сервисах.

При необходимости разработчик может использовать Edge Functions — серверные функции, которые разворачиваются ближе к пользователю и работают как кастомные HTTP‑эндпоинты. В дополнение к этому Supabase предлагает realtime‑подписки и vector‑API, что позволяет строить многопользовательские интерфейсы и внедрять AI/RAG‑сценарии поверх той же самой базы и её API.

Стоимость: есть бесплатный тариф, Pro — от $25 в месяц.

Для генерации API из базы или других источников данных под конкретные задачи мы используем такие решения, как Hasura, Supabase или внутренние генераторы поверх GraphQL/REST. Они позволяют быстро поднять API-слой для внутренних продуктов, не вкладывая недели в инфраструктуру.

Redocly

Специализированная платформа для API‑документации, выросшая из популярного open‑source‑продукта ReDoc.​ Сервис упрощает разработку и интеграцию API, так как автоматизирует создание подробной документации на основе спецификаций OpenAPI. Благодаря этому документация всегда соответствует актуальному состоянию API и не требует ручного обновления. Интерактивный формат позволяет разработчикам удобно изучать эндпоинты и примеры ответов, что ускоряет работу и снижает порог входа.

Инструмент отличается современным адаптивным дизайном и поддерживает гибкую настройку внешнего вида. ReDoc легко встраивается в существующие сайты. У проекта также активное сообщество и много полезных материалов.

Стоимость: от $10 в месяц.

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

Docusaurus

Удобный инструмент для создания современных API-доков. Это React-ориентированный генератор статических сайтов с поддержкой Markdown и MDX, версионирования, поиска, мультиязычности и гибкой кастомизации. Он хорошо подходит для команд, которые рассматривают документацию как часть продукта, а не как вторичное приложение. С помощью Docusaurus можно быстро собрать удобный портал документации, добавить интерактивные компоненты, встроить примеры запросов и масштабировать контент по мере развития API.

Стоимость: бесплатно.

Как выбрать инструменты для проекта

По словам Елены Титовой, в «Стеллар» выбирают инструменты по следующим критериям:

• Масштабируемость и удобство поддержки — продукт должен жить долго.
• Качество документации и генерации клиентских библиотек — это определяет скорость интеграций.
• Встроенная автоматизация — CI/CD, тестирование, контроль версии.
• Стоимость владения — от лицензии до инфраструктуры.
• Кривая обучения — инструмент должен быть понятен новой команде без месяцев онбординга.

Главный критерий выбора инструмента простой: насколько он вписывается в ваш процесс. Хороший тул должен сокращать количество ручной работы, не ломать привычный пайплайн и обеспечивать воспроизводимость. Чем меньше «магии» и больше предсказуемости — тем лучше.

Тренды и перспективы

Уже сегодня один из главных трендов — подход API-first, при котором API закладывается в фундамент продукта уже на старте. Сначала проектируется интерфейс взаимодействия, а вокруг него выстраиваются сервисы, приложения и интеграции. Это изначально закладывает масштабируемость продукта.

Появляются маркетплейсы API. Так, платформа RapidAPI даёт единый доступ к тысячам API от разных провайдеров. Здесь можно быстро найти нужный сервис, протестировать его и подключить к приложению через единый интерфейс. Это значительно сокращает время на поиск и интеграцию API.

В свою очередь, в России появился «Портал API», на котором можно найти широкий каталог API, подробную документацию и профессиональную поддержку.

Наконец, всё чаще API рассматривается не как вспомогательный технический интерфейс, а как полноценный продукт. Такой подход получил название API-as-a-Product. В этой модели API не просто связывает системы между собой, а предоставляет готовый бизнес-функционал, который могут использовать разные команды, партнёры и внешние разработчики.

Тогда компании нанимали инженеров с запасом, под давлением цифровизации, дешевых денег и страха «остаться позади». По данным Indeed и FRED, пик вакансий пришелся на середину 2022 года. После чего последовал резкий спад, так и не вернувшись до прежнего уровня.

Почему ИИ — удобный, но не главный виновник

ИИ стал публичным оправданием сокращений. Заявление «мы заменяем людей на ИИ» хорошо смотрится в отчетах и перед инвесторами.

На практике же компании сокращали издержки, выравнивали штат и параллельно активнее нанимали за пределами США и Европы, где инженеры стоят дешевле.

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

Как будет выглядеть рынок в 2026 году

Эксперты сходятся во мнении: 2026 год пройдет в режиме «низкого найма — низких увольнений». Массовых сокращений не ожидается, но и бурного роста вакансий не будет. Так выглядит стабилизация рынка.

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

По прогнозу Бюро статистики труда США, число вакансий для разработчиков продолжит расти примерно на 15%. Это медленнее, чем ожидалось раньше, но все еще быстрее большинства профессий.

Почему джунам повезло меньше всего

Самое слабое место рынка — начальные позиции. Количество вакансий для junior-разработчиков упало примерно на 40% по сравнению с допандемийным уровнем.

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

Но это также создает отложенную проблему — без притока новичков рушится кадровый «конвейер».

Какие навыки реально востребованы

В 2026 году ценятся не языки сами по себе, а связки «язык + область».

Тот же Python чаще всего нужен при работе с ИИ и данными. JavaScript и TypeScript — для фронтенда и fullstack. Go — для бэкенда и инфраструктуры. Java — для enterprise-систем.

Параллельно растет спрос на ИИ- и дата-инженеров, а также специалистов по ИИ-инфраструктуре.