Без маркетинга и успешного успеха. Только боль, костыли и суровый прод! Мой пет-проект - бот «Щёлк-ГДЗ». Это ИИ-помощник, который решает школьные задачки по фоткам, видео, гс, тг-кружкам и PDF. Под капотом Python 3.12.3, aiogram 3, aiosqlite, апи OpenRouter (модель Gemini 3.0 Flash) и Робокасса. Крутится всё это на дешёвом VPS в Нидерландах. Держит 2500+ пользователей и не падает.

В этой статье расскажу, как за 9 месяцев построил логичную архитектуру, победил ошибку FloodWait при стриминге ответа ИИ и почему в условиях 1 гига RAM обычная SQLite - отличное решение.

Нейронка вместо джуна и Уроборос багов

Сразу признаюсь... С нуля я это не писал :) Синтаксис мне генерили LLM-ки. Начинал с Gemini 2.5 Pro, затем перешел на 3.0 Pro, а сейчас использую 3.1 Pro.

Многие думают, что нейронка сама напишет проект "под ключ", но это миф. Я никогда не доверял ИИ проектирование архитектуры и использовал его как продвинутый StackOverflow (скармливал конкретную задачу (например, написать SQL-миграцию) и получал кусок кода).

ИИ — это не архитектор, а джун на спидах.

Как только логика усложнялась - гемини ловил «Уроборос багов». Кидаешь баг А - он его фиксит, но появляется ошибка Б. Скармливаешь и её - фиксит, но возвращается баг А. Цикл замкнулся. Лечилось только созданием новых чатов, в которые я кидал код и писал запросы типа "Найди критические ошибки, логические дыры и баги".

Про продуктовую логику нейронка вообще не слышала. В первой версии рефералки был баг, где любой(если его аккаунта ещё нет в БД) мог написать в конце ссылки что любые 9 цифр (?start=1234567890) и получить бонусы.

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

Немного про архитектуру.

Чтобы код не превратился в нечитаемую лапшу на 5000 строк, я жестко разбил всё на модули. Архитектура бота выглядит так:

main.py - это точка входа с настройкой логгеров, коннетами aiohttp и запуском APScheduler

database.py - вся работа с БД

neiro.py - логика общения с апи OpenRouter (стриминг, сжатие фоток через Pillow, JSON-контекст)

states.py - классы состояний aiogram.fsm.state (например, PaymentProcess, GdzMode)

utils.py - легковесные утилиты. Например лок пользователей (защита от спама запросами):

Хэндлеры вынесены в отдельную папку handlers/:

handlers/common_handlers.py - главное меню с обработкой /start (рефералки, utm-метки).

handlers/gdz_handlers.py - сам процесс ИИ-решения (вход в GdzMode, прием фото, видео, кружочков).

handlers/pay_handlers.py - это логика платежей (Robokassa) и "Умная корзина".

handlers/tasks_handlers.py - квесты (выдача премиума за подписку на каналы спонсоров).

Сборку интерфейсов вынес в all_def.py. Не люблю, когда в хэндлерах генерится полотно текста с кнопками. Там же лежат функции склонения слов (1 запрос, 2 запроса, 5 запросов). А в settings.py лежат списки с рандомными ответами бота, чтоб казался живым.

Так же в settings.py я сделал кэширование картинок, тоесть при первом запуске бот грузит фото меню как BufferedInputFile, сохраняет file_id от Телеграма и дальше шлет картинки моментально по ID. Сервак говорит спасибо за сэкономленный трафик)

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

Диета по токенам

Хранить бесконечную историю диалогов дорого и бессмысленно. В бесплатной версии храню 10 последних сообщений (5 пар вопрос-ответ), а в преме — 30.

Но фотки весят большое кол-во токенов. Если премиум-юзер закинет 30 фоток, OpenRouter выставит мне огромный счет. В итоге я прикрутил ограничение: Из 30 сообщений ИИ видит только 10 последних картинок.

Старые фотки тупо вырезаю из JSON. Подменяю на системный промпт:

С довольно неплохой моделью (gemini 3.0 flash) это работает как часы (она честно признается, что забыла картинку, а не выдумывает что-то из воздуха).

Стриминг, FloodWait и защита баланса

Чтобы бот не выглядел тормозом, я сделал стриминг ответа от ИИ в neiro.py. Я обновляю сообщение в Телеграме чанками по мере получения их от ОпенРоутера.

Но если делать message.edit_text слишком часто, ловишь FloodWait. В итоге я выставил интервал в 0.7 секунд и обернул всё в жесткий try/except:

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

В handlers/gdz_handlers.py это выглядит так:

SQLite тащит

Почему не Postgre? Потому что для микро-SaaS с 2,5к пользователей SQLite хватает за глаза. Но в асинхронной среде она любит кидать ошибку database is locked.

Чтобы этого избежать, я включил WAL-режим при инициализации пула, разделил коннекты на db_writer и db_reader, а сложные операции доверил самому SQL.

Например, 00:00 запускается крон-таска, которая собирает огромную аналитику, начисляет всем активным юзерам +1 ежедневный запрос и сбрасывает просроченные подписки. И это всё это работает атомарно внутри database.py:

Умная корзина на APScheduler

Когда дело дошло до монетизации, всплыли две проблемы:

Первая: юзер оплатил, но забыл нажать кнопку «✅ Я оплатил» в боте. Бот ждет, юзер ждет, товар не выдается, поддержка кипит.

Вторая: юзер сформировал счёт и передумал ("брошенная корзина").

Вместе с LLM я с нуля изучил apscheduler и убил двух зайцев фоновыми задачами. Теперь в handlers/pay_handlers.py при генерации ссылки на оплату я создаю две отложенные таски:

Как это работает?

Через 5 минут срабатывает async def auto_check_payment(), которая тихо стучится в робокассу. Если статус success - бот сам начисляет запросы на баланс и радует клиента. Если статус pending - таска умирает, и в дело вступает 30-минутная таска.

Но она не шлёт спам вслепую, а лезит в БД и проверяет 3 бизнес-правила:

1. await db.has_successful_payment_recently - Не купил ли он другой товар за последние 3 часа?

2. await db.get_latest_invoice_id - А это точно самый последний сгенерированный им счет?

3. await db.can_send_agitation - Не присылали ли мы ему агитацию недавно?

Если проверки пройдены, то юзер получает сообщение: "⏳ Домашка сама себя не решит! Ты начал оформлять покупку, но оплата так и не прошла...". Это поднимает конверсию оплат.

Финал

Почему я не использую Redis для стейтов? Ответ банален: мой дешевый VPS имеет всего 1 гб оперативки. Пул aiohttp, In-Memory стейты и асинхронные таски и так жрут 70% RAM. Редис тупо не влезет.

Как говорится, работает — не трогай.

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

Готов ответить на вопросы по архитектуре и послушать советы в комментариях \(^^)/

P.s. вот ссылка на первую статью о моём проекте:

P.s. Если кто-то хочет потестить вживую(не реклама), то юз бота в тг @gdzshchelk_bot

С практической точки зрения проект на**й не нужен. Есть GitHub, GitLab и куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Почему не JSON

На старте я думал: «Положу всё в JSON, на кой мне база данных?» Проектов мало, пользователей немного, файлы текстовые — чего заморачиваться?

Подергал JSON туда-сюда пару дней и понял: не варик.

1. Конкурентный доступ. Два юзера одновременно коммитят — один перезаписывает файл другого.
2. Целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии.
3. Версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Вывод: JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор SQLite и схема БД

Выбрал SQLite, потому что:

• Не надо поднимать отдельный сервер
• Целостность данных на уровне движка (транзакции, foreign keys, rollback)
• Всё в одном файле — скопировал и унёс

Сущности:

• users — telegram_id, username, current_project_id
• projects — owner_id, name, thread_id (каждый проект живёт в своём треде канала)
• files — filename, current_version, флаг modified (файл изменился и готов к коммиту)
• file_versions — мясо. Каждая версия файла с полным содержимым. Привязана к file_id и опционально к commit_id
• commits — сообщение, время, ссылка на проект
• commit_files — связка коммитов с версиями файлов (many-to-many, чтобы поддержать ветки)

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

В коде вместо голых кортежей из SQL — датаклассы:

Маркдауновый ад

Казалось бы: взял код, обернул в тройные апострофы, кинул в Telegram. Telegram сам подсветит синтаксис, если указать язык. Красота. В теории.

На практике Telegram использует свой диалект Markdown, где куча служебных символов: _ * [ ] ( ) ~ > # + - = | { } . !

Попытка 1: заэкранировать всё подряд. Результат: код превращается в кашу. Вместо def __init__- получается def |_|_init|_|_ — уже не запустишь, и в канале выглядит как говно.

Попытка 2: не экранировать вообще. Telegram шлёт на**й с ошибкой «can't parse entities».

Попытка 3: экранировать только то, что реально ломает разметку. Выяснилось, что порядок важен. Сначала экранируем точки и подчеркивания, потом обратную косую черту. Но и это не панацея — последовательности типа \*

после экранирования превращаются в \\*, и Telegram снова недоволен.

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

Попытка 5 (финал): забил на Markdown и перешёл на HTML. Telegram умеет его принимать. Да, он не такой красивый, но зато предсказуемый:

Никаких точек, подчеркиваний, обратных слешей. Просто экранируем три символа — и код летит как надо.

Security by design

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

Добавил в /commit. Потом решил с другого аккаунта потестировать команды на чужих файлах. И тут бот на каждую команду стал выдавать «файл не найден» или «проект не найден». И я понял: безопасность уже работает. С самого начала. Из коробки. Без единой строчки кода.

Как так вышло? В таблице projects с самого начала было поле owner_id. При создании проекта я писал туда telegram_id владельца. Все запросы к БД фильтруются по этому полю:

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

Команды: от семи до двух десятков

Изначально казалось, что команд будет немного. Но...

Жизнь рассудила иначе.

• База: /start, /init, /use, /list, /ls, /commit, /log, /status
• Удаление: /rm, /rmproject + подтверждение
• Игнор: /ignore, /ignored, /unignore
• Ветки: /branch, /branches, /checkout
• Диффы и просмотр: /diff, /cat

Итого — уже под два десятка. И это не предел.

Простота > абстракции

В моём коде нет абстрактных базовых классов. Совсем. Потому что они нужны только когда у тебя есть минимум две разные реализации одного и того же. В GitGram всё проще: один способ работать с БД, один способ шифровать, один способ парсить .gitignore.

Если завтра появится вторая реализация — тогда и буду делать интерфейс. А пока это просто оверхед.

В GitGram:

• Хочешь понять, как работает add_file — идёшь в database.py и читаешь 10 строк кода.
• Хочешь увидеть обработчик /commit — открываешь bot.py и смотришь.

Никаких AbstractMinerShieldEventProcessor, BaseGitGramManager, InterfaceProviderFactory.

Код должен быть тупым. Чем тупее — тем проще его читать и отлаживать.

Что дальше

В планах:

• Докрутить коллаборацию (несколько человек над одним проектом)
• Приватные репозитории
• Кодспейс прямо в боте (да да знаю я сошёл с ума и бла бла бла..)

Итог

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

На практике GitGram ни к чему. Но сама задумка — Git в Telegram — это же так прикольно. Просто посмотреть, можно ли такое вообще запилить.

Если хочешь поучаствовать

• GitGram
• Чат для хардкорных: @sandbox_hardcore — вся сырая разработка, факапы и обсуждения (без цензуры)

Подписывайся на мой TГ-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

Попытка №1. Путь в лоб: Классы и интерфейсы

Самый очевидный способ - создать родительский класс с переменными, а языки сделать его наследниками. Но это просто… фиаско. Даже если не писать from/toJson, процесс выглядит так:

1. Объявил переменную в родителе.
2. Прописал её в конструкторе.
3. Повторил то же самое для всех дочерних классов (всех языков).

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

Попытка №2. Стандарт (ARB/JSON)

Я поплевался, но решил попробовать - «стандарт» всё-таки. Мало ли, может чего поменялось за годы. Вроде всё завелось, но сам процесс… это боль. Бегать по разным файлам, чтобы добавить одну строчку - так себе удовольствие.

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

Попытка №3. Таблицы и костыли

Подумал: «Окей, почему бы не подтянуть старый добрый CSV или вообще закинуть всё в табличку?». И тут официальный пакет локализации сказал: «Извини, мужик, тут наши полномочия всё».

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

1. Добавляю строку в таблицу.
2. Запускаю генератор.
3. Он лепит «родительский» файл.
4. После Freezed генерит toJson, fromJson…

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

Красный флаг для программиста

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

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

Нутром чуял - флоу неправильный. В итоге я пришел к тому, что называю идеальной локализацией.

Эволюция лени: почему Enum победил интерфейсы

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

Моя философия проста: строку захардкодить - моментально. Добавление даже одной строки в другом файле требует доп. действий. НО, если действий минимум, то кодер поймет, что выигрыш во времени сейчас мизерный против больших потерь в будущем, и исправно добавит строку в правильное место. Этого не произойдет, если для добавления строки нужно «отчитаться» в десяти местах.

Попытка №4. Рекорды (Records)

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

Идеальный костыль: Enum

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

Знаете, мне моё решение так понравилось, что я пошел к нейросетям и проверил его со всех сторон. Все модели остались в полном восторге. Под это дело я даже подготовил монументальную «нейро-статью» на полтора часа внимательного чтения, со всеми графиками, бенчмарками и анализом производительности.

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

А здесь мы будем говорить по делу.

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

Реализация

Принцип разделения:

• enum Strings → типизированный контракт (что существует).
• translator → источник данных (откуда берётся текст).

Структура файлов - минимальная. Никаких внешних зависимостей:

Ядро - strings.dart

Весь контракт локализации в одном enum. Два режима - хардкод switch и серверный кеш - за одним и тем же

. Даже сообщения об ошибках локализации — сами локализованы:

Список языков - languages_enum.dart

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

Хотите грузить с сервера? Одна строка + loader. И

- тоже одна строка, потому что

уже является registry:

Переводчик - i18n/russian.dart

Как это выглядит в жизни (и почему я перестал хардкодить) Я намеренно не привожу здесь код оберток виджетов или конкретных стейт-менеджеров. Всё это - чистая «вкусовщина». Для работы системы нужен лишь элементарный вещатель событий (Notifier), повешенный на метод смены языка.

Но главное - это мой ежедневный флоу. Сейчас, чтобы добавить строку в UI, я просто вызываю нужный мне ключ: Strings.someKey(). Без контекста, везде.

А если ключа еще нет? Я тупо иду в Strings и добавляю одну строчку в Enum. Всё.

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

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

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

Надеюсь, мой опыт сэкономит вам пару литров нервных клеток. Всех благ и чистого кода без «магических строк»!

Мы остановились на открытом симуляторе InferSim от Alibaba. Он умеет считать TTFT, TPOT и пропускную способность без запуска реального инференса. Но из коробки поддерживает только несколько топовых GPU и фиксированный набор моделей — для наших сценариев этого было недостаточно. Пришлось дорабатывать.

Как устроен InferSim

В основе симулятора — двухфазная схема. Сначала на целевом железе запускаются микро-бенчмарки: измеряется реальная производительность на типовых операциях внимания и матричных умножениях. Получается таблица коэффициентов Model FLOPs Utilization (MFU) — сколько процентов от теоретического максимума выдаёт конкретная карта на конкретной операции. Затем, уже без доступа к GPU, симулятор на основе этих MFU и аналитической модели вычисляет задержки. Именно такой подход даёт более точные предсказания, чем оценка по паспортной пропускной способности памяти.

Добавляем своё железо

Первым делом мы внесли в hardware/gpu.py поддержку MetaX C500 64GB. Характеристики добавляются через dataclass-экземпляры:

После этого c500 попадает в словарь gpu_map, и симулятор запускается с ключом --device-type C500 --world-size 2. Значения FLOPS и пропускной способности пришлось оценивать по косвенным источникам — производитель не публикует точных цифр. Позже планируем уточнить их через бенчмаркинг на реальном оборудовании. Таким же способом добавили Nvidia 1xH100 и A100.

Конфигурация моделей и одна болезненная ошибка

Симулятор ожидает стандартный config.json в формате Hugging Face. Для Qwen3-32B подготовили файл qwen3_32b_config.json:

Ключевой момент — правильное значение head_dim. У Qwen3-32B оно равно hidden_size / num_attention_heads = 5120 / 64 = 80. У нас ушло некоторое время, чтобы понять, почему симулятор выдаёт невалидные результаты: изначально в конфиге стояло значение 128. Пока не исправили — KV-кеш переоценивался, и метрики улетали в неадекватные цифры. После исправления всё встало на свои места.

Позже добавили поддержку Qwen3.5‑9B с её гибридной архитектурой, построенной на чередовании Gated DeltaNet и Gated Attention. Главная особенность модели в том, что около трёх четвертей слоёв не создают привычного KV‑кеша, а используют линейное внимание – компактное скрытое состояние, которое лишь обновляется с каждым новым токеном, не увеличиваясь в объёме. Это кардинально снижает расход памяти на длинных контекстах, но привносит и свою цену: на коротких дистанциях такая модель проигрывает в скорости Prefill, потому что Gated DeltaNet работает последовательно и хуже утилизирует матричные вычисления GPU.

Симулятор изначально не умел различать слои двух типов и считал весь KV‑кеш одинаково. Чтобы поддержать Qwen3.5, пришлось доработать расчёт задержек в классе HybridModel: теперь он отдельно обсчитывает full‑attention‑слои с полным кешем и linear‑attention‑слои без кеша, используя параметры num_full_attn_layers и num_linear_attn_layers из конфигурации. В директорию проекта models добавили hybrid_model.py, в котором сделали дополнительные расчёты:

Без такой дифференциации симулятор для Qwen3.5‑9B показывал E2E порядка 2 500 секунд вместо реальных нескольких секунд – та ошибка, которую мы долго отлавливали.

Визуализация и эксплуатация

Чтобы не разбирать каждый раз текстовый вывод InferSim, сделали веб-интерфейс на Streamlit. Симулятор дёргается через subprocess, результаты парсятся из stdout и визуализируются:

• тепловые карты задержек (Prefill, Decode, E2E Total) для разных длин входных и выходных токенов;
• анализ RPS с расчётом требуемой параллельности и сравнением с доступной памятью;
• информация о занятой памяти в формате «X ГБ из Y ГБ».

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

Приложение упаковано в Docker и лежит в репозитории на GitHub. Сервисы — сам Streamlit и Nginx в качестве обратного прокси с SSL-терминацией и базовой HTTP-аутентификацией. Деплой на VDS автоматизирован через GitHub Actions: собрали образ, отправили на сервер, перезапустили контейнеры. SSL-сертификаты Let's Encrypt обновляются по cron.

Что в итоге

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

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

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-БД (потому что с нагрузкой может не справиться).

Проект выглядит как ChatGPT, но под капотом — работа через OpenRouter и цепочка из трех этапов: сбор ответов, взаимная оценка и «решение совета» .

Карпати честно пишет, что это «на 99% вайб-кодинг», субботний хак для души. И он не планирует развивать проект. Но сообщество уже разнесло репозиторий по соцсетям — идея демократичного «совета ИИ» оказалась вирусной.

Как работает LLM Council

По задумке Карпати, механизм должен показать, как разные модели видят одну и ту же задачу — и что они думают о чужих ответах.

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

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

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

Что внутри

В README Карпати описывает минималистичный стек:

• Backend: FastAPI + async httpx, работа через OpenRouter API.
• Frontend: React + Vite, рендеринг через react-markdown.
• Хранилище: JSON-файлы в data/conversations/.
• Управление проектом: uv для Python, npm для фронтенда .

Пользователь добавляет свой OPENROUTER_API_KEY и при желании меняет «состав совета». По умолчанию туда входят GPT-5.1, Gemini 3 Pro Preview, Claude Sonnet 4.5 и Grok-4.

Зачем это вообще нужно

Карпати пишет, что пилил проект для совместного с LLM чтения книг и сравнения, как разные модели анализируют один и тот же материал. Но по факту инструмент получился куда интереснее:

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

И да, все это — буквально субботний хак, который уже набрал несколько тысяч звезд на GitHub.

Продуктивность разработчика повышается, когда к VSCode подключены инструменты для командной работы, контейнеризации и анализа данных. В статье по шагам разобрали, как интегрировать VSCode с GitLab, Docker и Jupyter.

Зачем всё это подключать

VSCode из коробки умеет работать с Git. Но когда ваш репозиторий лежит на GitLab, хочется создавать merge request прямо из редактора, просматривать pipeline, работать с issues.

Docker решает проблему «у меня работает, а у тебя нет». Вы пишете код в контейнере с одними версиями библиотек, и любой член команды запустит точно такое же окружение.

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

Как подключить VSCode к GitLab

Шаг 1. Устанавливаем расширение

Откройте VSCode и нажмите Ctrl+Shift+X. В поиске введите «GitLab Workflow». Установите официальное расширение. После установки в левой панели появится иконка GitLab.

Шаг 2. Получаем токен доступа

Расширению нужен способ общаться с вашим GitLab-сервером. Для этого создадим персональный токен:

1. Зайдите в GitLab через браузер.
2. Кликните на аватар >> Settings >> Access Tokens.
3. Придумайте название токена.
4. Выберите срок действия.
5. Отметьте галочками права доступа: api, read_user, read_repository, write_repository.
6. Нажмите «Create personal access token».
7. Скопируйте токен — он покажется только один раз.

Шаг 3. Настраиваем расширение

Вернитесь в VSCode. Нажмите Ctrl+Shift+P и введите «GitLab: Add Account». Расширение попросит два параметра:

• GitLab instance URL — адрес вашего GitLab (например, https://gitlab.com или адрес корпоративного сервера).
• Personal Access Token — токен, который только что создали.

Вставьте токен и нажмите Enter. Если всё правильно, в статус-баре внизу появится ваше имя пользователя GitLab.

Шаг 4. Работаем с проектом

Попробуем клонировать проект. Нажмите Ctrl+Shift+P и выберите «GitLab: Clone from GitLab». Расширение покажет список доступных проектов. Выберите нужный, укажите папку для клонирования.

Теперь вам доступны функции Git:

• Pipeline — в боковой панели GitLab видны все запущенные сборки, их статусы и логи.
• Issues — создавайте, редактируйте и закрывайте задачи прямо из редактора.
• Merge requests — посмотрите список MR, оставьте комментарии к коду, одобрите изменения.
• Snippets — сохраняйте фрагменты кода для повторного использования.

Как подключить VSCode к Docker

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

Шаг 1. Подготовка

Установите Docker Desktop с официального сайта. После установки убедитесь, что Docker запущен — в системном трее должна появиться иконка кита.

В VSCode установите два расширения:

• Docker.
• Dev Containers.

Шаг 2. Создаём Dockerfile

В корне проекта создайте файл Dockerfile. Пример для Python-проекта:

Этот файл говорит Docker:

1. Возьми базовый образ Python 3.11.
2. Создай рабочую директорию /app.
3. Скопируй и установи зависимости.
4. Скопируй весь код проекта.
5. При запуске выполни команду python main.py.

Шаг 3. Настраиваем Dev Container

Создайте папку .devcontainer в корне проекта. Внутри создайте файл devcontainer.json:

Конфигурация использует ваш Dockerfile для сборки контейнера. Она автоматически устанавливает Python-расширения внутри контейнера, пробрасывает порт 8000 (если у вас веб-приложение) и выполняет команду после создания контейнера.

Шаг 4. Запускаем разработку в контейнере

Нажмите Ctrl+Shift+P и выберите «Dev Containers: Reopen in Container». Редактор соберёт Docker-образ по вашему Dockerfile, запустит контейнер, подключится к нему и откроет ваш проект уже внутри контейнера.

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

Как подключить VSCode к Jupyter

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

Шаг 1. Установка

Установите расширение «Jupyter» от Microsoft. Оно автоматически подтянет все необходимые зависимости.

В терминале установите Jupyter и ipykernel:

Шаг 2. Создаём первый ноутбук

Создайте файл с расширением .ipynb или нажмите Ctrl+Shift+P >> «Create: New Jupyter Notebook».

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

Шаг 3. Выбираем ядро

Кликните на «Select Kernel» в правом верхнем углу. VSCode покажет список доступных интерпретаторов:

• Локальные Python-окружения.
• Виртуальные окружения (venv, conda).
• Docker-контейнеры (если настроены).
• Удалённые Jupyter-серверы.

Выберите нужное окружение. VSCode запомнит выбор для этого ноутбука.

Шаг 4. Пишем и выполняем код

В ячейке напишите код:

Нажмите Shift+Enter для выполнения ячейки. График отобразится прямо под кодом.

Для Python-файлов можно включить интерактивный режим. Добавьте комментарий # %% в .py файл:

VSCode покажет кнопки «Run Cell» над каждым блоком. Теперь можно выполнять код частям.

Что в итоге

Первая настройка VSCode с GitLab, Docker и Jupyter занимает 30-40 минут. В итоге вы получаете единое рабочее пространство для ваших задач разработки.

Начните с GitLab и научитесь создавать merge requests из редактора. Потом добавьте Docker для одного проекта. Когда освоитесь, подключите Jupyter для работы с данными. Инструменты решают разные задачи, а VSCode объединяет их функции в одном интерфейсе.

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

Если что-то непонятно или не получается настроить — пишите в комментариях, разберёмся вместе!

Меня зовут Юрий Каган, я Software/System Architect в IT_ONE. Расскажу об опыте применения Stryker.NET на проекте в крупном банке.

Качественные юнит-тесты — основа надежного ПО

Несмотря на то, что юнит-тесты — только один из компонентов пирамиды тестирования ПО, они — база для создания качественного кода:

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

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

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

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

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

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

Принципы мутационного тестирования

Алгоритм мутационного тестирования достаточно прост: в исходный код (базу) вносятся различные изменения (мутации). Существует несколько разновидностей мутаций. Основные из них:

– изменение операторов: замена арифметических и логических операторов (например, + на -, >= на >),

– изменение значений: замена булевых значений, удаление вызовов методов или изменение литералов,

– изменение условий: в if, циклах и логических выражениях.

Затем на этом модифицированном коде выполняются модульные тесты для проверки их чувствительности к изменениям. Мутанты, которые вызывают провал тестов, считаются «убитыми» (Killed Mutants), остальные — «выжившими». По итогу проверки формируется отчет, где ключевая метрика качества тестов — Mutation Score — доля убитых мутантов от их общего количества. Если тесты не «убивают» подавляющее число мутантов, значит их нельзя считать достаточно эффективными.

Среди инструментов для автоматизации проведения мутационного тестирования мы остановили выбор на Stryker.NET и вот, почему:

– на данный момент Stryker.NET обладает наибольшим объемом автоматизированных операций: он самостоятельно вносит мутации в исходный код, запускает юнит-тесты и генерирует подробные отчеты;

– Stryker.NET полностью интегрирован с .NET-экосистемой: поддерживает .NET и .NET Framework, основные тестовые фреймворки (xUnit, NUnit, MSTest);

– Stryker.NET – это бесплатный инструмент с открытым исходным кодом, постоянно обновляемый и поддерживаемый сообществом, что гарантирует его актуальность и развитие.

По нашей практике, Stryker.NET будет полезен для трех категорий пользователей:

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

– Ревьюер может быстро и надежно проверить качество тестов в pull request.

– ИТ-архитектор и руководитель разработки могут регулярно строить и анализировать отчеты, чтобы мониторить «здоровье» юнит-тестов во всей кодовой базе.

Установка и использование Stryker.NET

Технически Stryker.NET представляет из себя dotnet tool. Соответственно, чтобы его установить, необходимо выполнить команду в cmd или в PowerShell консоли:

dotnet tool install -g dotnet stryker

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

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

dotnet stryker -p “project.csproj” -tp “c:\git\project.tests\project.tests.csproj”

В результате тестирования программа сгенерирует отчет, где в первой колонке будет выведена метрика Mutation Score в целом по проекту и по отдельным файлам, причем разделённая на две группы: Of total — общее количество мутантов, Of covered — количество мутантов, находящихся в тех фрагментах кода, для которых вообще существуют тесты.

В колонке Killed отображается количество убитых мутантов, в колонке Survived — количество выживших. В колонке Timeout — количество мутантов, которые привели к зацикливанию выполнения тестов и их прерыванию утилитой. Значения остальных колонок, а также другую важную информацию можно посмотреть в документации на официальном сайте https://stryker-mutator.io/docs/stryker-net/introduction/.

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

Stryker.NET умеет генерировать отчеты не только в HTML, но и в других форматах: например, в JSON, который очень удобен для автоматического анализа, если разработчики планируют встроить этот инструмент в свой CI/CD-пайплайн. Кроме того, есть встроенный дашборд, который, к сожалению, невозможно развернуть локально — он доступен только как online сервис (https://dashboard.stryker-mutator.io).

Применение Stryker.NET при разработке банковских продуктов

Мы внедрили использование Stryker.NET в проекте для крупного банка, чтобы с помощью этого инструмента решить ряд взаимосвязанных задач. Самая главная проблема заключалась в том, что мы хотели улучшить качество тестов посредством мутационного тестирования, но его проведение вручную — предельно утомительная и требующая много времени процедура. Ни Product Owners, ни разработчики не были готовы постоянно выделять на это ресурсы.

Без регулярного мутационного тестирования, нам было практически невозможно оценить текущее состояние всей кодовой базы с точки зрения качества unit тестов. У нас было много unit тестов, мы имели высокий процент Code Coverage, но не знали, насколько эти тесты нас защищают. В свою очередь, без понимания текущего состояния у нас не было возможности устанавливать команде цели по улучшению ситуации.

На данный момент команда активно использует Stryker.NET на всех этапах разработки.

Мы столкнулись и с ограничением использования Stryker.NET: попытка его интеграции в CI/CD-пайплайн оказалась неудачной. Это связано с тем, что кодовая база проекта насчитывает несколько миллионов строк, и выполнение всех проверок занимает примерно 12 часов. Однако мы думаем, что на проектах меньшего размера такая интеграция должна сработать.

Мы выбрали альтернативный вариант: был внедрен регулярный автоматический пост-релизный прогон Stryker.NET по ветке master, в результате которого генерируется сводный отчет. Проводится анализ изменений сводного отчета по всем проектам от релиза к релизу. По данным каждого сводного отчета мы можем оценивать работу конкретных проектных команд, и если их метрика Mutation Score недостаточно высока, – ставить цели по улучшению.

Резюме

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

Внедрение Stryker.NET — шаг к более надёжной и предсказуемой разработке. Его регулярное использование помогает уверенно вносить изменения, рефакторить код и добавлять новый функционал.

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

Подробности

Первые скриншоты нового инструмента появились в X. Интерфейс напоминает визуальные редакторы: вы берёте блоки (nodes), соединяете их стрелками и определяете последовательность действий. Можно стартовать с шаблона вроде «Customer service», «Document comparison» или «Data enrichment» — или собрать всё с нуля.

Каждый блок отвечает за отдельную задачу, а все они связаны с агентом, которому можно задать правила работы: выбрать модель, прописать подсказки, определить формат вывода (текст или JSON) и даже задать уровень «усилий на рассуждение».

Agent Builder также поддерживает MCP — это значит, что к агенту можно подключить Gmail, Google Calendar, Google Drive, Outlook, Teams, SharePoint или Dropbox. После подключения он сможет, например, читать файлы, доставать события из календаря или черновики писем.

Подробнее OpenAI расскажет о проекте на конференции DevDay, которая пройдёт сегодня. AI-сообщество уже окрестило этот релиз «Visual Studio моментом» для мира ИИ — настолько простым и гибким инструмент может стать для разработчиков.

GPT-5 — флагманская reasoning-модель с упором на агентные сценарии, кодинг, интеллект и управляемость. «Из коробки» она хорошо решает широкий спектр задач, но качественные промпты (подсказки) заметно повышают стабильность, скорость и соблюдение инструкций. Ниже — проверенные практики, готовые шаблоны и заметки по параметрам API (reasoning_effort, verbosity, Responses).

Предсказуемость агентного рабочего процесса

Используйте API Responses для агентов

Responses сохраняет логические следы между вызовами инструментов: это снижает задержку, экономит токены и повышает качество планов за счёт механизма previous_response_id.

Контролируйте «рвение» агента

Сдержанный режим (меньше вызовов, ниже задержки):

• Установите reasoning_effort=low|medium.
• В подсказке ограничьте глубину поиска контекста и задайте ранние критерии остановки.

Проактивный режим (больше автономии и настойчивости):

• Поднимите reasoning_effort.
• Включите явное требование «не возвращаться к пользователю до полного решения».

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

При ограничении основного поведения сбора контекста полезно явно предоставить модели запасной вариант, облегчающий выполнение более короткого этапа сбора контекста. Обычно это делается в виде условия, позволяющего модели продолжать работу в условиях неопределенности, как «even if it might not be fully correct» в примере выше.

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

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

«Преамбулы» к инструментам (чтобы пользователь понимал, что происходит)

GPT-5 обучен предоставлять чёткие предварительные планы и последовательные обновления о ходе работы с помощью сообщений «преамбулы инструмента».

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

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

Усилия рассуждения и повторное использование контекста

• reasoning_effort регулирует интенсивность размышлений и готовность к вызову инструментов. Значение по умолчанию — medium. Но для многошаговых задач повышайте этот показатель.
• Разбивайте сценарий на несколько ходов агента с сохранением previous_response_id в Responses — модель не тратит токены на перестройку плана.
• Настоятельно рекомендуют использовать API Responses в GPT-5, чтобы улучшить потоки агентов, снизить затраты и повысить эффективность токенов в приложениях. Авторы отмечают, что наблюдали статистически значимые улучшения в оценках при использовании API Responses по сравнению с завершением чата. Например, рост оценки Tau-Bench Retail с 73,9% до 78,2% был только благодаря переходу на API Responses и включению previous_response_id (функции передачи предыдущих элементов рассуждений в последующие запросы). Это позволяет модели ссылаться на предыдущие трассировки рассуждений, экономя токены и устраняя необходимость перестраивать план с нуля после каждого вызова инструмента, что снижает latency. Эта функция доступна всем пользователям API Responses.

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

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

Рекомендованный стек для фронтенд-приложений

• Фреймворк: Next.js (TypeScript), React, HTML
• Стили/UI: Tailwind CSS, shadcn/ui, Radix themes
• Иконки: Lucide / Heroicons / Material Symbols
• Анимации: Framer Motion
• Шрифты: Inter, Geist, Mona Sans, IBM Plex Sans, Manrope

Разработка приложений с нуля

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

Соответствие стандартам разработки

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

Фрагмент подсказки ниже демонстрирует один из способов организации правил редактирования кода для GPT-5: не стесняйтесь изменять фактическое содержание правил в соответствии со своими предпочтениями в программном дизайне.

Форматирование Markdown

По умолчанию GPT-5 в API не форматирует свои окончательные ответы в Markdown, чтобы обеспечить максимальную совместимость с разработчиками, чьи приложения могут не поддерживать рендеринг Markdown. Тем не менее, запросы, подобные следующему, в значительной степени успешно обеспечивают иерархические окончательные ответы в Markdown.

Иногда соблюдение инструкций Markdown, указанных в системном запросе, может ухудшаться в течение длительного разговора. Если вы столкнулись с такой ситуацией, стабильное соблюдение инструкций Markdown будет работать при добавлении их к каждому 3–5 пользовательскому сообщению.

NWinfo позволяет мгновенно получить сводку по системе — включая данные о ЦП, ОЗУ, SMBIOS, CPUID, S.M.A.R.T., PCI, EDID, видеокартах и сетевых интерфейсах. Утилита не требует установки и может запускаться с любого носителя, что делает её удобным решением для диагностики и устранения неполадок. Также поддерживается экспорт отчётов в JSON, YAML и LUA, что облегчает обмен данными и автоматизацию.

В версии 1.4.4 разработчики исправили ряд ошибок, добавили поддержку копирования через Ctrl+C в графическом интерфейсе, внедрили отображение информации о целостности кода (Code Integrity) и обновили драйверы. Также появилась поддержка PawnIO, расширяющая взаимодействие с файловыми системами.

NWinfo часто сравнивают с другими инструментами для анализа аппаратной части ПК, но это не аналог HWiNFO. Последний, напомним, обновился до версии 8.30 в августе 2025 года и используется для системного мониторинга и диагностики. Похожий по функциональности проект Glow 25.12, выпущенный в сентябре 2025 года, предлагает детальный анализ компонентов в интерфейсе на C# под лицензией MIT.

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

1. TabNine

Если вам важна скорость — TabNine стоит попробовать хотя бы ради этого. Расширение — лёгкий AI-ассистент, который работает как умный автодополнитель кода, непохожий на аналоги вроде Codeium или Copilot.

TabNine обучен на миллионах строк открытого кода и умеет предсказывать, что вы напишете дальше, с учётом контекста проекта и языка. Отлично справляется с рутинными вещами: автозавершает функции, переменные, конструкции — всё быстро и чаще всего в тему.

Кому подойдёт: тем, кто хочет ускорить набор кода, но не готов передавать весь проект в облако или открывать чат с Copilot. Поддерживает офлайн-режим и локальное обучение модели.

Плюсы:

• Работает из коробки, не требует тонкой настройки;
• Есть локальная версия — удобно для закрытых проектов;
• Поддерживает большинство языков и фреймворков.

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

2. GitLens

GitLens встраивает историю изменений прямо в VSCode — и делает это максимально удобно. Показывает, кто и когда изменил строку, коммит-месседж, хэш, ветку и другие детали. Можно не уходить в консоль или отдельный Git-клиент для поиска информации.

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

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

Плюсы:

• Информация о коммитах отображается прямо в редакторе под строкой;
• Есть таймлайн изменений файла;
• Удобный diff по коммитам, авторам, веткам и даже фрагментам кода.

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

3. Error Lens

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

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

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

Плюсы:

• Ошибки и предупреждения отображаются прямо в редакторе, рядом со строкой кода;
• Гибкая настройка стилей и уровня детализации сообщений;
• Ускоряет процесс отладки, особенно при работе с большими файлами.

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

4. Path Intellisense

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

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

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

Плюсы:

• Подсказки появляются автоматически при наборе пути;
• Поддерживает большинство языков и фреймворков;
• Учитывает jsconfig.json и tsconfig.json при работе с alias-ами.

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

5. TODO Highlight

TODO Highlight подсвечивает комментарии с задачами (например, TODO, FIXME, NOTE) прямо в коде, делая их заметными и удобными для отслеживания. Расширение помогает не терять важные заметки, которые вы оставляете в коде, и быстро находить места, требующие доработки.

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

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

Плюсы:

• Яркая подсветка TODO-комментариев прямо в редакторе;
• Гибкая настройка ключевых слов и стилей;
• Интеграция с панелью задач для быстрого обзора.

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

6. Prettier – Code formatter

Prettier — расширение, которое автоматически приводит ваш код к единому стилю, избавляет от ручной правки отступов, кавычек и переносов. Оно поддерживает множество языков (JavaScript, TypeScript, CSS, HTML и другие) и интегрируется с линтерами, чтобы ваш код был не только красивым, но и консистентным.

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

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

Плюсы:

• Автоматическое форматирование при сохранении или по хоткеям;
• Поддержка множества языков и кастомных настроек;
• Интеграция с ESLint и другими инструментами для проверки кода.

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

7. Live Server

Live Server запускает локальный сервер прямо из VSCode, позволяя просматривать изменения в HTML, CSS и JavaScript в браузере в реальном времени. После сохранения файла страница автоматически обновляется, что исключает необходимость ручного перезапуска или обновления браузера.

Поддерживает кастомные порты, HTTPS, и работает с любыми фронтенд-проектами, от простых HTML-страниц до сложных приложений на React или Vue. Можно настроить, чтобы сервер открывался автоматически при запуске проекта.

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

Плюсы:

• Автоматическое обновление страницы при изменении кода;
• Простая настройка и поддержка HTTPS для безопасного тестирования;
• Лёгкий запуск сервера прямо из редактора.

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

8. Project Manager

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

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

Кому подойдёт: разработчикам, которые ведут сразу несколько проектов, часто переключаются между ними и устали искать нужный путь через File > Open Folder.

Плюсы:

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

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

9. Code Spell Checker

Code Spell Checker выявляет орфографические ошибки в комментариях, строках и именах переменных прямо в редакторе VSCode. Расширение подчёркивает опечатки волнистой линией и предлагает варианты исправления через Ctrl+. или Cmd+., что позволяет быстро исправить ошибки.

Поддерживает множество ЯП и словари для разных языков (английский, русский, немецкий — с дополнительными расширениями). Можно добавлять свои слова в пользовательский словарь или игнорировать определённые термины, чтобы адаптировать проверку под проект. Работает с camelCase и snake_case, не помечая их как ошибки.

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

Плюсы:

• Мгновенное обнаружение ошибок с подсказками для исправления;
• Гибкая настройка словарей и игнорируемых слов;
• Поддержка технических терминов и различных стилей написания кода.

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

10. REST Client

REST Client позволяет отправлять HTTP-запросы и просматривать ответы непосредственно в VSCode. Достаточно создать файл с расширением .http или .rest, написать запрос в простом текстовом формате, и вы увидите кнопку Send Request для моментального выполнения.

Поддерживает все типы запросов (GET, POST, PUT, DELETE и другие), авторизацию (Basic, OAuth, JWT), переменные окружения и даже генерацию кода на разных языках. Запросы можно сохранять в репозиторий, что удобно для командной работы. Расширение также позволяет использовать динамические переменные по типу {{$timestamp}} или {{$guid}}, всё для гибкой настройки запросов.

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

Плюсы:

• Простая отправка запросов через .http или .rest файлы с кнопкой Send Request;
• Поддержка переменных окружения и авторизации для сложных API;
• Возможность сохранять запросы в репозитории для совместной работы.

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

А какими расширениями пользуетесь вы? Пишите в комментариях!

Все это — на чипе с 3 КБ оперативной и 24 КБ флеш-памяти, без сетевого интерфейса, Wi-Fi или Ethernet.

Откуда там вообще чип?

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

Вместо обычного черного эпоксидного «блоба» он обнаружил маркированный микроконтроллер PUYA C642F15, позже идентифицированный как PY32F002B с ARM Cortex-M0+ частотой 24 МГц.

Вейпы, по сути, оказались носителями полностью программируемых микроконтроллеров.

Как он вывел это в сеть?

Wi-Fi, Ethernet или даже Bluetooth в таких устройствах, разумеется, нет. Но автор воспользовался семихостингом — механизмом отладки, при котором отладчик может отправлять и принимать данные через подключенный JTAG/SWD интерфейс.

Далее он применил довольно хакерское решение: использовал pyOCD для создания telnet-порта с выходом семихостинга, затем через socat пробросил это в виртуальное TTY-устройство, поверх него поднял SLIP (Serial Line Internet Protocol). Да, тот самый, из эпохи dial-up.

После этого на Linux можно было поднять IP-интерфейс sl0 и назначить IP-адрес — теперь микроконтроллер был виден как узел локальной сети.

А веб-сервер?

В качестве TCP/IP-стека был выбран uIP — крайне легкий вариант от Contiki OS, специально рассчитанный на 8- и 16-битные микроконтроллеры.

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

Причем не просто «заработало», а заработало удивительно быстро: после оптимизации буферов и избавления от побайтной передачи, RTT упали до 20 мс, а загрузка страницы — до 160 мс.

Несмотря на сверхограниченные ресурсы (всего 3 КБ RAM, из которых почти половина уже занята сервером), автор сумел:

• организовать буферизацию и кольцевой буфер;
• запустить TCP/IP-стек и веб-сервер;
• реализовать подсчет посещений и возврат JSON-ответов;
• полностью уместить все в оставшиеся ~20КБ флеша.

Он даже добавил простую статистику: уникальный ID микроконтроллера и количество посещений со времени последнего «краша».

Зачем это все?

Как отмечает сам автор, цель была не в создании полезного веб-сервера, а в демонстрации возможностей предельно скромного «железа», которое в обычной жизни просто выбрасывается.

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

Эти пакеты используются в миллионах проектов по всему миру — общее количество загрузок только за неделю превышает 2 млрд.

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

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

• внедрение в методы fetch, XMLHttpRequest, а также Web3-объекты (window.ethereum и др.);
• отслеживание и подмена адресов кошельков при вызовах вроде sendTransaction, approve, transfer;
• использование «похожих» адресов для подмены без визуального отличия;
• манипуляции с параметрами транзакций на этапе подписи;
• сохранение внешней «нормальности» интерфейса, чтобы пользователь ничего не заметил.

Таким образом, атака была нацелена на незаметное хищение криптоактивов прямо из интерфейсов Web3-приложений.

Как злоумышленники получили доступ

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

Он получил письмо с поддельного адреса support@npmjs.help, зарегистрированного 5 сентября 2025 года. После компрометации аккаунта были опубликованы вредоносные версии пакетов.

Автор позднее подтвердил взлом и удалил некоторые версии, но часть вредоносных сборок осталась доступной, включая simple-swizzle.

Список затронутых пакетов

Наиболее популярные зараженные библиотеки:

• chalk
• debug
• supports-color
• strip-ansi
• ansi-regex
• wrap-ansi
• color-name
• color-convert
• color-string
• chalk-template
• has-flag
• has-ansi
• slice-ansi
• error-ex
• simple-swizzle
• backslash
• и другие

Большинство из них используются транзитивно — через другие зависимости.

Что делать разработчикам

1. Проверить package-lock.json или yarn.lock на наличие зараженных версий.
2. Использовать npm audit, snyk, Safe Chain или аналогичные инструменты для анализа зависимостей.
3. Обновить или зафиксировать безопасные версии пакетов.
4. Если проект работает с криптовалютой, проверить, не было ли компрометации в процессе использования.

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

Эта атака стала одной из крупнейших в истории JavaScript-экосистемы и подчеркивает уязвимость цепочек поставки (supply chain) в open-source.

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

Начнем с API

Исторически сложилось так, что наш бэкенд написан на Python с использованием Flask. На старте мы сразу заложили строгую типизацию данных с помощью библиотеки Marshmallow. Это позволяет описывать схемы данных, которые API должен отдавать, и валидировать входящие запросы. Если вы работали с Django REST, то Marshmallow — это аналог их Schemas.

В какой-то момент мы решили, что хотим отдавать OpenAPI-спецификацию для нашего API. Мы попробовали flask-apispec, но столкнулись с проблемой: сгенерированная спецификация имела кучу ошибок в валидаторе, потому что библиотека миксовала OpenAPI v2 и v3. Частично это удалось решить с помощью ручных @doc() декораторов, но это было неудобно и больше походило на костыль, чем на нормальное решение.

В итоге я перешел на flask-smorest. Эта библиотека активно развивается, работает поверх Flask и Marshmallow и умеет генерировать корректный OpenAPI v3. Все завелось «из коробки» с минимальными изменениями. Marshmallow-схемы поддерживают метаданные, которые smorest потом проксирует в спецификацию. Например, так выглядит поле type для проверок в нашем коде:

smorest берёт эти данные и добавляет их в спеку. Кроме того, можно (и нужно) описать, какие коды ответов возвращает ваш API-метод и другие детали:

Как только мы это сделали, то получили приличный Swagger и валидную OpenAPI JSON-спецификаци

SDK

Далее мы поняли, что одного API недостаточно. Чтобы вызывать методы API из будущих CLI или MCP, нам не хотелось писать клиент с нуля. Поэтому мы решили создать SDK.

Если у вас есть OpenAPI-спецификация, то писать клиент с нуля бессмысленно. Для этого есть отличный инструмент — openapi-generator. Он позволяет сгенерировать API-клиенты для разных языков одной командой, просто получив на вход спецификацию.

Так мы получили полноценный Python-клиент и залили его в PyPI. Весь код можно найти на GitHub: pingera/pingera-python-sdk. Особенно интересен файл generate-client.py, который запускает openapi-generator и подменяет директории. После этого оставалось только залить все в PyPI, чтобы можно было использовать пакет в других сервисах и продуктах.

Конечно, имена сгенерированных методов не самые изящные, например v1_checks_check_id_results_check_result_id_get, но это в сто раз лучше, чем каждый раз писать requests.get, добавлять try-except обертки и волноваться об изменениях в API.

Model Context Protocol (MCP) сервер

MCP — это стандарт, разработанный компанией Anthropic (создатели Claude). Его идея — стандартизировать взаимодействие LLM с данными или сервисами, превращая их в ИИ-агентов. Теперь не нужно объяснять агенту, как взять данные из базы данных или JIRA, достаточно указать MCP-сервер, который уже это умеет, и агент сам разберётся.

Мы в Pingera давно задумывались о том, как искусственный интеллект повлияет на мониторинг, поэтому создание собственного MCP-сервера было логичным шагом.

Для создания MCP-сервера мы использовали фреймворк fastmcp. Код MCP-инструментов («tools») повторяет структуру нашего SDK. Например, в MCP есть код, который выводит список проверок:

list_checks здесь просто вызывает метод SDK v1_checks_get().

Из-за такой повторяемости 80-85% кода MCP-сервера было сгенерировано ИИ-агентом Replit (можно взять любой другой). Весь код мы также опубликовали на GitHub: pingera/pingera-mcp. Подробнее о сценариях использования можно прочитать в нашем блоге: Pingera MCP сервер — ближе к AI.

Command Line Interface (CLI)

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

Создание CLI было похоже на работу над MCP — много похожих вызовов методов. ИИ-агент снова отлично справился, хотя были проблемы с выводом результатов. Мы взяли две библиотеки: Typer для создания интерфейса и Rich для красивого, цветного вывода в консоль. С Rich были трудности — то таблица уезжала, то цвет не тот. Но ИИ справился и помог решить эти проблемы.

Весь код также доступен на GitHub: pingera/pingera-cli. Из-за ограниченного контекста LLM, нельзя было скормить агенту всю спецификацию сразу. Поэтому пока наш CLI умеет работать только с проверками.

Заключение

Использование ИИ-агентов для генерации повторяющегося кода — это не просто удобная фича. Как показал наш опыт с Replit, такие помощники берут на себя рутину, освобождая время для более сложных и творческих задач. Когда 80-85% кода MCP-сервера было сгенерировано автоматически, это позволило нам сосредоточиться на архитектуре, логике и оптимизации, вместо того чтобы вручную переписывать однотипные вызовы методов.

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

В релизе задействован новый ключ подписи для репозиториев deb.grml.org, а сборочная система grml-live теперь включает пакеты, которые ранее поставлялись отдельно (grml-autoconfig, grml-etc, grml-scripts, grml-udev-config).

Также исправлены проблемы с опциями загрузки lang= и keyboard=, добавлена поддержка венгерской раскладки и немецкого варианта «neo». Сборки ISO теперь воспроизводимы.

Поддержка и отказ от старого

В инструменте grml-debootstrap прекращена поддержка Debian 10 «buster». Добавлена возможность пропускать udevadm на неподдерживаемых интерфейсах и улучшена работа с ключами и Device Tree.

Ряд устаревших скриптов (например, grml-config-root, grml-setservices, noprompt, noeject) удален. Другие перенесены в основной репозиторий grml-live.

Улучшения в grml-zshrc

В конфигурации zsh произошло несколько важных изменений:

• увеличен размер scrollback до 10 000 строк;
• добавлена функция cdt для быстрого перехода во временные директории;
• экспортируются все известные переменные LC_*;
• убраны устаревшие функции (j, iso2utf, utf2iso и др.);
• удален «checkhome hack», актуальный только для live-ISO.

Все эти нововведения делают рабочую среду более легкой и удобной для кастомизации.

Обновления пакетов

Grml 2025.08 синхронизирован с пакетами Debian 13 на август 2025 года. В дистрибутив добавлены initramfs-tools-bin и tio, а пакеты clamav, clamav-freshclam, lockfile-progs и logrotate удалены.

Также изменена классификация clamav, вынесенная в отдельный класс FRESHCLAM.

Из дополнительного можно отметить:

• в grml2usb новая опция --format заменила --fat16 и теперь использует FAT32;
• grml-hwinfo собирает информацию о ZFS в формате JSON;
• в tmux.conf увеличена максимальная длина правого статус-блока.

Доступность

Grml 2025.08 уже доступен для загрузки на официальном сайте проекта. Следующий стабильный релиз намечен на конец 2025 года.

Одно из главных новшеств — container-aware GOMAXPROCS: теперь по умолчанию значение GOMAXPROCS учитывает лимиты CPU в cgroup.

На Linux это позволит процессам внутри контейнеров (например, в Kubernetes) автоматически адаптировать использование процессорных ресурсов к выделенной квоте.

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

Новый сборщик мусора — до 40% быстрее

В экспериментальном режиме появился garbage collector нового поколения с улучшенной локальностью и масштабируемостью.

Он особенно эффективен в приложениях с большим количеством мелких объектов, снижая накладные расходы на GC на 10–40%. Включается через GOEXPERIMENT=greenteagc.

Trace Flight Recorder: отладка по горячим следам

Введен runtime/trace.FlightRecorder — «черный ящик» для приложений на Go.

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

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

Другие изменения в рантайме и инструментах

• Исправлена ошибка компилятора с отложенной проверкой nil, из-за которой некорректный код мог выполняться без паники.
• Добавлена поддержка DWARF5 — меньше отладочной информации и быстрее линковка.
• Улучшено выделение памяти для слайсов — быстрее в ряде сценариев.
• В Linux теперь можно видеть имена анонимных VMA ([anon: Go: heap]) в отладочных инструментах ядра.
• Новый пакет testing/synctest для тестирования конкурентного кода с виртуальным временем.
• Экспериментальный пакет encoding/json/v2 с ускоренным парсингом и расширенной конфигурацией маршалера.
• Новый метод WaitGroup.Go для удобного запуска горутин с учетом синхронизации.

Платформенные изменения

Go 1.25 требует macOS 12 и выше. 32-битная Windows/ARM-платформа будет удалена в следующем релизе.

На RISC-V появился режим сборки плагинов и поддержка профиля RVA23U64.

Это финальная стадия перед полноценным релизом, который запланирован на 7 октября 2025 года. Версия 3.14.0rc1 уже доступна для загрузки на официальном сайте Python.

Что важно знать

Python 3.14 RC1 — это максимально приближенная к финалу сборка. Отныне в код ядра будут вноситься только багфиксы, прошедшие ревью. Следующий и последний релиз-кандидат — 3.14.0rc2 — выйдет 26 августа.

Важно: с этого момента не будет изменений ABI, а бинарные сборки, созданные под RC1, будут совместимы с финальной версией 3.14.

Разработчиков библиотек призывают начать адаптацию своих пакетов под 3.14 и публиковать .whl-сборки на PyPI.

Главное в Python 3.14

Список нововведений в 3.14 впечатляет — это не просто минорный апдейт. Вот ключевые фичи:

Улучшения производительности и инфраструктуры

• Экспериментальный JIT-компилятор включён в официальные сборки для macOS и Windows.
• Новый тип интерпретатора, обеспечивающий ускорение кода (для некоторых компиляторов).
• PEP 779: Free-threaded Python — полная поддержка свободных потоков.
• Улучшенные сообщения об ошибках.
• Оптимизация генерации UUID v3–v5 (ускорение до 40%).

Новые языковые возможности и модули

• PEP 750: шаблонные строки t"..." — аналог f-строк, но для кастомной обработки.
• PEP 649: отложенное вычисление аннотаций типов.
• PEP 765: теперь return, break, continue нельзя использовать так, чтобы они покидали finally.
• PEP 734: изоляция интерпретаторов в stdlib.
• Новый модуль compression.zstd для поддержки алгоритма Zstandard.
• Цветной вывод в CLI-инструментах (unittest, argparse, json, calendar).
• Обновление uuid, pdb, поддержка подключения к удалённым процессам.

Разработка и отладка

• PEP 768: интерфейс внешней отладки без накладных расходов.
• Новый CLI для анализа запущенных Python-процессов.
• HMAC теперь реализован внутри Python с формально верифицированной библиотекой HACL*.

Что убрали или изменили

• Подписи PGP для артефактов релиза больше не предоставляются. Вместо них — поддержка Sigstore.
• Установщик для Windows заменяется новым Python Install Manager (доступен в Microsoft Store).

Внимание: несмотря на стабильность RC1, использовать его в продакшене пока не рекомендуется. Но для тестов и подготовки библиотек — самое время.

Рассказываем про 7 команд, влияющие на скорость работы в терминале. Вы узнаете:

• про встроенные bash-операции, которые заменяют пайплайны,
• про способы работы с файловыми дескрипторами,
• про wildcards, которые избавляют от сложных конструкций с find.

Каждая команда в подборке решает конкретную проблему:

• массовая обработка файлов,
• отладка скриптов,
• работа с длинными путями.

1. Bash variable expansions

Вместо basename, cut для простых операций со строками можно использовать встроенные возможности Bash:

% режет справа до первого совпадения, %% — до последнего. Символ # работает слева направо.

В реальной работе это помогает при массовой обработке файлов. Например, есть 1000 логов, и нужно каждый переименовать.

Если использовать basename, запустится 1000 отдельных процессов. Variable expansions работают без fork/exec, без задержек на создание процессов.

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

2. Here-string (<<<)

Here-string упрощает передачу строковых данных в команды без создания временных файлов или использования echo с пайпом.

Реальная экономия времени проявляется при отладке и модификации скриптов. Например, когда SQL-запрос или конфигурация зашиты в here-документ. С here-string данные собраны в одном месте, легко редактируются и переиспользуются.

Работает не только с базами данных. Отправка в API, конфигурирование сетевых устройств через expect, передача команд в Docker — через <<< код будет понятнее, а сопровождение проще.

3. /proc/$$/fd

Каждый процесс имеет стандартные дескрипторы 0 (stdin), 1 (stdout), 2 (stderr), которые представлены как символические ссылки. Директория /proc/$$/fd предоставляет доступ к файловым дескрипторам текущего процесса:

Переменная $$ содержит PID текущего процесса, поэтому /proc/$$/fd ведет к дескрипторам именно вашего шелла.

Практическое применение — отладка перенаправлений и работа с дескрипторами в сложных скриптах:

4. Wildcards с диапазонами

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

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

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

5. sudo !!

Набрали длинную команду, нажали Enter, получили «Permission denied». Рука на рефлексе тянется к стрелке вверх и Home, чтобы добавить sudo в начало.

Вот способ в разы быстрее:

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

Двойное восклицание универсально и работает не только с sudo:

• time !! для замера времени выполнения,
• nohup !! & для запуска в фоне,
• strace !! для отладки.

Если между командой и sudo !! выполнялись другие команды, восклицание сработает для последней из них. Для поиска конкретной команды в истории используйте !строка.

6. ^старое^новое

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

Символ ^ ищет первое вхождение слова и заменяет его. Работает с последней командой.

Заменяется только первое вхождение. Если ошибочное слово встречается несколько раз, способ не сработает. В таких случаях придется использовать классическое редактирование или history expansion.

7. Alt+.

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

Комбинация Alt+. (Alt + точка) вставляет последний аргумент предыдущей команды в текущую позицию курсора. Повторное нажатие перебирает аргументы из более ранних команд.

Экономия времени проявляется при работе с файлами и директориями. Например: распаковали архив, теперь нужно зайти в созданную папку, затем посмотреть содержимое, потом изменить права. Вместо того, чтобы 3 раза печатать один путь, можно 3 раза нажать Alt+.

Еще этой комбинацией вставляются:

• имена пользователей,
• IP-адреса,
• названия сервисов,
• параметры конфигурации.

Alt + точка работает в большинстве шеллов. Привыкнув к ней, начинаешь использовать на автомате.

Что запомнить

• ${filename%.*} и встроенные операции со строками работают быстрее внешних утилит. % режет справа, # — слева. Полезно при работе с циклами для массовой обработки файлов.
• <<< — here-string удобен для передачи коротких строковых данных в команды. С многострочными данными лучше использовать here-document или переменные.
• /proc/$$/fd — доступ к файловым дескрипторам текущего процесса. Ускоряет отладку перенаправлений и работу с дескрипторами.
• file[1-5] и [^b]* — диапазоны в wildcards для точного отбора файлов. Кавычки нужны только для передачи литеральных символов.
• sudo !! — повторяет последнюю команду с sudo. Также работает с time !!, nohup !! &. Если между нужной командой и !! выполнялись другие операции, используйте !строка для поиска конкретной команды в истории.
• ^старое^новое — заменяет первое вхождение в предыдущей команде. Работает только с последней командой и заменяет первое совпадение.
• Alt+. — вставляет последний аргумент предыдущей команды. Повторное нажатие перебирает аргументы из истории команд. Экономит время при работе с длинными путями.

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

1. Deeplom Ru — генератор академических работ на базе ИИ

Сервис Deeplom Bot создан специально для студентов и школьников, которым нужно быстро подготовить реферат, курсовую или дипломную работу. В отличие от других ИИ-ассистентов, он фокусируется именно на академических задачах, используя адаптированные версии GPT и Claude. Это позволяет генерировать тексты, соответствующие требованиям ГОСТ и вузовских стандартов. Сервис работает в условиях сжатых сроков или при работе над несколькими проектами одновременно.

Как это работает

Работать с сервисом можно двумя способами: через сайт или телеграм-бота (@DeeplomAIBot). Достаточно ввести тему работы и через несколько минут система сгенерирует демо-версию. Она включает оглавление, введение, первую главу и список литературы.

Особенности:

• полностью анонимная работа — для
  демо-версии не нужен даже email;
• сервис позволяет бесплатно
  ознакомится с демо-версией перед покупкой работы;
• автоматическое оформление по
  ГОСТу, включая заголовки, списки литературы;
• конструктор оглавления для ручной
  корректировки структуры работы;
• поддержка формата DOCX для
  удобного редактирования.

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

Тарифы

Бесплатная версия дает доступ только к части работы. Полный текст можно приобрести за 499-1299 рублей в зависимости от сложности и объема текста. Для постоянных пользователей есть система скидок.

2. Wikibot — интеллектуальный помощник для бизнеса

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

Как работает система

После регистрации через Google или Telegram пользователь получает доступ к панели управления, где может загрузить базу знаний в различных форматах — PDF, DOCX или подключить облачные хранилища вроде Notion и Confluence. Фишка Wikibot в том, что он не только отвечает по шаблонам, а анализирует контекст каждого обращения, используя мощные языковые модели GPT-4.1 и DeepSeek V3,и умеет выполнять действия в системах, как это делает человек. И всё это вы можете настроить самостоятельно в ЛК.

Особенности сервиса:

• автоматическое создание сделок в
  amoCRM и других CRM-системах через API;
• автоматическая классификация
  тикетов по категориям через теги или группы;
• возможность обучать бота на
  истории переписок с клиентами;
• функция «Анализ ответа» —
  показывает, на какие разделы базы знаний опирался ИИ;
• гибкая система кредитов (1 кредит
  — примерно 10 ответов на тарифе Мини);
• интеграция с популярными
  платформами: HelpDeskEddy, Битрикс24, Юздеск,
  Jivo;
• возможность размещения бота во
  внутреннем контуре (по запросу).
• чат-бота можно добавить на свой сайт или интегрировать в собственный телеграм-бот

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

Тарифные планы

Wikibot предлагает гибкую систему тарифов:

• Мини (1000 руб./мес) — подходит
  для тестирования и небольших проектов.
• Старт (4900 руб./мес) — оптимален
  для малого бизнеса.
• Рост (19900 руб./мес) — решение
  для компаний с устоявшимися бизнес-процессами и сформированной командой
  поддержки.
• Бизнес (49900 руб./мес) —
  комплексное решение для крупных компаний.

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

3. Acetone AI — профессиональный инструмент для обработки изображений

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

Как работает платформа

Главное преимущество Acetone AI — моментальный старт. Пользователь может загрузить изображение на главной странице и получить результат через несколько секунд. После регистрации через email или VK предоставляется 50 бесплатных кредитов (эквивалент 5 операций по удалению фона ежедневно).

Особенности сервиса:

• уникальные алгоритмы обработки
  изображений, работающие независимо от зарубежных ИИ;
• пакетная обработка до 50
  изображений одновременно;
• встроенный редактор для тонкой
  настройки результатов удаления фона и объектов;
• многослойный редактор создания
  карточек товара, баннеров и прочих изображений;
• генератор фона с помощью
  нейросети;
• API для интеграции с
  корпоративными системами и автоматизации процессов;
• поддержка популярных форматов:
  JPG, PNG, WEBP.

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

Тарифная политика

Сервис предлагает такие тарифные планы:

• Бесплатный тариф: 10 обработок,
  доступ к базовым функциям редактора, ограничение на размер загружаемых файлов
  (до 5 МБ).
• Подписка «Стандарт» (от 989
  руб./мес): неограниченное количество операций, приоритетная обработка,
  увеличенный лимит на размер файлов (до 25 МБ), доступ к премиум-фильтрам.
• Корпоративные решения:
  индивидуальные квоты на обработку, персональный менеджер, API с увеличенными
  лимитами.

По данным сервиса, среднее время обработки одного изображения составляет менее 3 секунд, а точность распознавания объектов достигает 98%.

4. F5 AI — универсальная платформа для работы с ИИ

F5 AI — это многофункциональное решение с доступом к разным языковым моделям, включая GPT и Claude. Платформа ориентируется на широкий круг пользователей: от маркетологов, создающих SEO-контент, до разработчиков, автоматизирующих написание кода. Особенность сервиса — адаптация под специфические бизнес-задачи российских компаний.

Как работает

Пользователи получают доступ через веб-интерфейс или API, при этом не нужно использовать VPN. Зачисление 500 бонусных рублей происходит при входе через Яндекс или почту.

Особенности сервиса:

• поддержка разных языковых моделей
  (GPT-4, Claude и других) с возможностью выбора оптимального варианта для
  конкретной задачи;
• создание корпоративных
  телеграм-ботов с индивидуальной базой знаний;
• гибкая система управления доступом
  для командной работы;
• API для интеграции с внутренними
  бизнес-процессами компании;
• личная база знаний для хранения
  корпоративных и рутинных документов – в общем вся информация, которую вы хотите скормить ИИ;
• бот, который обращается к
  документам из вашей базы знаний, чтобы давать более точные ответы на вопросы,
  основываясь на имеющихся данных.

Дополнительно:

1. Meet AI — анализ
   видеовстреч и транскрипции созвонов из Контур.Толк. Внутри есть кастомные
   шаблоны для анализа разных типов встреч.
2. Работа с ИИ Ассистентами —
   создание своих умных ассистентов на основе моделей внутри с гибкой
   системой настройки параметров. Новых ассистентов можно также обучить на
   собственных файлах для внутренних процессов компании.

Тарифы

Сервис работает без абонентской платы и подписок: вы платите только за использованные токены. Цена зависит от модели и объема работы. Для пополнения баланса используйте СБП, банковскую карту или счет юрлица — в последнем случае получите закрывающие документы. Все транзакции детализированы по моделям, а расходы доступны в аналитике по дням и месяцам.

Запоминаем главное про платформу: работает без VPN в России, объединяет всех вендоров в одном интерфейсе, предлагает русскоязычную и англоязычную поддержку и интерфейс. Корпоративным клиентам доступны индивидуальные тарифы с увеличенными лимитами API и приоритетной поддержкой.

5. Jadve AI

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

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

Доступ к возможностям Jadve AI предоставляется через веб-интерфейс или тг-бота. Бесплатные функции включают неограниченное использование GPT-4o mini и 10 ежедневных запросов к GPT-4o. Для работы с графикой и видео нужно оформить подписку.

Особенности:

• комплексный доступ к 10+
  актуальным ИИ-моделям разных категорий;
• гибкая система оплаты токенами без
  привязки к конкретным моделям;
• программа лояльности с
  персональными скидками для активных пользователей;
• полная синхронизация между
  веб-версией и ботом.

Практическое применение

Программисты могут генерировать и оптимизировать код блоками до 1000 строк. Маркетологи — создавать рекламные изображения для соцсетей и короткие промо-ролики по готовым шаблонам. Дизайнеры — использовать инструмент для быстрого концепт-арта и адаптации графики под целевые платформы.

Условия использования

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

6. TEXTAGRAM — умный генератор описаний товаров

TEXTAGRAM разработан специально для продавцов на маркетплейсах (Wildberries, Ozon, Яндекс.Маркет) и владельцев интернет-магазинов. Сервис помогает автоматизировать самый сложный этап — создание качественных описаний товаров. По данным сайта, использование TEXTAGRAM сокращает время на заполнение карточек товаров в 5-7 раз.

Как работает платформа

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

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

Ключевые характеристики:

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

Особенности сервиса:

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

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

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

Текущие условия использования

На момент публикации (июль 2025 года) сервис находится в стадии MVP и доступен пользователям в бесплатном режиме.

7. TryChatGPT — универсальный доступ к GPT-моделям с гибкой системой запросов

Сервис TryChatGPT даёт доступ к GPT-моделям для широкого круга задач: от генерации текстов до создания изображений. Основная аудитория — пользователи, которым нужен простой и понятный доступ к ИИ без сложных систем токенов. Подходит для копирайтеров, разработчиков и маркетологов.

Как это работает

Система построена на модели запросов вместо токенов. Пользователь может начать работу сразу после посещения сайта — для тестирования доступно 200 бесплатных запросов к GPT-4.1 nano каждые 30 дней. При этом регистрация не обязательна, но этом случае в функционале будете видеть рекламу.

Особенности:

• прозрачная система запросов вместо
  сложных токенных расчётов;
• функция памяти для сохранения
  контекста между чатами;
• настраиваемый системный промт;
• отсутствие обязательной подписки с
  автопродлением.

Основные возможности

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

Тарифная политика

Бесплатный тариф включает 200 запросов к базовой модели. Платные варианты:

• Без рекламы (590 руб./мес): 500
  запросов к базовым моделям + обработка изображений.
• Творческий (990 руб./мес): акцент
  на генерацию изображений (50 запросов).
• Премиум (1990 руб./мес):
  расширенные лимиты для всех категорий моделей.

Сервис не работает в Индонезии, Индии и Китае, но полностью доступен в России без VPN. По сравнению с аналогами, TryChatGPT предлагает более предсказуемую систему оплаты — пользователи точно знают, сколько запросов получают за свои деньги.

8. Обзор платформы PR‑CY для работы с языковыми моделями

PR‑CY — инструмент для работы с поисковыми данными и генеративными моделями. Через веб‑интерфейс доступны версии ChatGPT (5‑Mini, 4o‑Mini, GPT‑5, O3, O4‑Mini), Claude (4 Sonnet, 3.5 Haiku), Gemini 2.5 Flash и DeepSeek v3. Бесплатный доступ сильно ограничен: всего 5-10 запросов в день. Для серьезной работы потребуется платная подписка. Для проведения комплексных исследований и построения собственных ассистентов доступны платные модели (GPT‑5, GPT‑4o, Gemini 2.5 Pro, DeepSeek R1 и др.), но их использование оплачивается отдельно.

По сути, платформа рассчитана на:

• разработчиков и продуктовых команд, которым нужно быстро проверить гипотезы на разных версиях языковых моделей;
• SEO‑специалистов — интегрированные MCP‑серверы помогают вытаскивать вордстат, SERP‑выдачу, контент страниц и другие метрики;
• тех, кто хочет собрать собственного AI‑ассистента из готовых компонентов, используя свои базы знаний.

Как это работает

Платформа работает через веб-интерфейс, доступна без VPN. После входа пользователь выбирает модель и отправляет ей запрос. Для настройки поведения предусмотрены параметры температуры, длины контекста и системного промпта. Есть возможность загрузить файлы (PDF, DOC и др.) или изображения для анализа, подключить RAG‑базы знаний для ответов из собственных данных, а также настроить голосовой ввод и озвучку ответа.

Сценарии использования

• Гибкие настройки генерации: температура, длина контекста и системный промпт позволяют тонко регулировать ответы ботов под конкретный сценарий.

• Загрузка и анализ файлов: сервис умеет работать с документами и изображениями (PDF, DOC и др.), что удобно для анализа технической документации или баз знаний.

• RAG‑базы знаний: можно подключить собственные источники данных, чтобы модель отвечала, опираясь на внутреннюю информацию команды.
• MCP‑интеграция: для SEO‑задач доступна подключаемая сервисом SEO‑MCP от PR‑CY.
• Голосовой ввод и голосовой ответ: ускоряет взаимодействие — можно проговаривать вопросы и слушать ответы.

Лимиты и тарифы

Базовый доступ даёт 10 запросов в день (5 — без регистрации). Для интенсивной работы предусмотрены тарифы с большим числом запросов и отдельные платные модели; пробный период на тарифе Профи — 7 дней, после чего требуется оплата. Стоимость продвинутых моделей оплачивается отдельно. На повышенном тарифе вы можете протестировать более мощные модели или создать собственных ассистентов.

Кому подойдет

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

9. BotHub — универсальный агрегатор ИИ-моделей

BotHub многофункциональная платформа с доступом к ИИ-моделям, включая ChatGPT-4 Turbo, Midjourney v6 и Claude 3. Сервис популярен среди маркетологов и разработчиков, которым нужно единое решение для работы с разными типами ИИ без переключения между площадками.

Как это работает

После регистрации на сайте пользователь получает доступ к единому интерфейсу, где может одновременно работать с текстовыми и графическими ИИ. Внутри есть функция транскрибации аудио через Whisper, которая распознает до 95% русской речи.

Особенности:

• комбинированный доступ к текстовым
  и графическим ИИ в одном интерфейсе;
• анализ документов с возможностью
  извлечения ключевых данных; высокоточная транскрибация
  аудиофайлов;
• API для интеграции с
  корпоративными CRM-системами.

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

10. Fabula AI — мультифункциональный инструмент для работы с контентом

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

Как это работает

Доступ к сервису происходит через веб-интерфейс и телеграм-бота (@fabula_ai_bot). Основные возможности включают улучшение качества фотографий с апскейлингом до 4K, автоматическое удаление фона с поддержкой пакетной обработки и генерацию описаний товаров на основе их изображений. Есть функция преобразования обычных фото в аниме-стиль.

Особенности и преимущества:

• профессиональное улучшение
  качества изображений;
• пакетная обработка фотографий для
  интернет-магазинов;
• встроенный ChatGPT 3.5 для
  создания текстового контента;
• уникальные стилистические фильтры
  для изображений.

Тарифы

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

11. Chad AI — универсальный ИИ-ассистент в Telegram

Chad AI — многофункциональный телеграм-бот, который объединяет доступ к восьми популярным нейросетевым моделям, включая GPT-4o, Claude 3 и Midjourney V6. Особенно востребован программистами, маркетологами и студентами.

Как это работает

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

Особенности:

• полная локализация на русский язык
  с адаптированными ответами;
• поддержка голосового ввода и
  веб-поиска актуальной информации;
• сохранение истории диалогов в
  течение 30 дней.

Тарифы и условия

Бесплатная версия позволяет совершать до семи запросов в день с использованием модели GPT-4o Mini. Премиум-подписка стоимостью от 590 рублей в месяц открывает неограниченный доступ к GPT-4, DALLE, Midjourney и другим моделям.

12. GenAPI — универсальный шлюз для работы с ИИ-моделями

GenAPI представляет собой удобный API-шлюз, предоставляющий доступ к популярным языковым моделям, включая GPT-4, Claude и Gemini. Сервис подходит разработчикам технологичных компаний, которым требуется надежная интеграция ИИ-возможностей в свои продукты без настройки сложной инфраструктуры.

Как работает

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

Особенности:

• единый API для работы с различными
  ИИ-моделями;
• поддержка потоковой передачи
  данных;
• детальная статистика и мониторинг
  использования.

Тарифы и условия

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

Как выбрать подходящий сервис

При выборе ИИ-помощника ориентируйтесь на три ключевых критерия:

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

Обращайте внимание на наличие бесплатного тестового периода и гибкость тарифов. Российские сервисы без VPN часто выгоднее зарубежных аналогов, но могут уступать в функциональности. Для бизнеса важна поддержка API, студентам — оформление по ГОСТ. Начинайте с бесплатных версий, чтобы оценить качество ответов без финансовых рисков.

1. Pandas

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

Библиотека строится вокруг двух ключевых структур: Series (одномерный массив с индексами); DataFrame (таблица с индексами и колонками).

Какие задачи решает библиотека

Pandas полезна для следующих задач:

• Сам анализ данных: можно быстро фильтровать, группировать, агрегировать и строить сводные таблицы.
• Очистка данных: удаляем пустые строки, заменяем значения, приводим типы.
• Загрузка данных из CSV, Excel, SQL.
• Визуальная разведка данных (EDA) перед построением моделей.
• Подготовка данных для ML и отчётов.
• Автоматизация отчётов и ETL-пайплайнов.

Благодаря Pandas аналитик превращается в инженера данных, а ML-специалист может сосредоточиться на моделях, а не на ручной подготовке датасетов.

Как пользоваться

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

Почему это меняет карьеру

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

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

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

Наконец, даже для разработчиков Pandas может стать неожиданным бустом в карьере. Например, когда нужно автоматизировать отчёты для бизнеса или быстро анализировать логи и данные из БД без поднятия дашбордов — Pandas даёт гибкость и скорость, которые редко даёт что-то ещё в экосистеме Python.

2. Django

Django — фреймворк для веб-разработки на Python, который позволяет быстро создавать надежные и масштабируемые веб-приложения. Он следует принципам DRY (Don’t Repeat Yourself — не повторяй себя), предоставляя разработчику ORM, роутинг, систему авторизации, админку, работу с формами, шаблонами и инструментами безопасности из коробки.

Django подходит как стартапам, которым нужно быстро выйти на рынок, так и крупным проектам с миллионами пользователей. Это не просто библиотека, а полноценный каркас для построения и сопровождения веб-сервисов.

Какие задачи решает библиотека

Каркас, действительно, каркасный. Задачи следующие:

• Создание веб-приложений и API любой сложности.
• Быстрая разработка MVP, прототипов и коммерческих проектов.
• Упрощение работы с базами данных через ORM, без написания сырого SQL.
• Построение административных панелей для управления данными без ручной разработки.
• Гибкая маршрутизация и работа с формами, валидацией и шаблонами.
• Реализация аутентификации, авторизации и защиты приложений.

Django позволяет сосредоточиться на бизнес-логике и продукте, не тратить недели на настройку инфраструктуры.

Как пользоваться

Устанавливаем:

Создаем проект и приложение:

Пример модели:

Миграция базы данных:

Создание админки:

После этого можно запустить сервер:

И перейти по адресу http://127.0.0.1:8000/admin для управления записями через готовую админ-панель.

3. PyTorch

PyTorch — мощная библиотека Python. Она позволяет строить и обучать нейронные сети, проводить вычисления с автоматическим дифференцированием и работать с GPU для ускорения самих вычислений.

Главное отличие PyTorch от других ML-фреймворков — динамическая вычислительная графика (define-by-run): модель строится и изменяется во время выполнения кода, что даёт гибкость при создании и отладке сложных моделей.

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

Какие задачи решает библиотека

В функционал PyTorch входят:

• Построение нейронных сетей любой сложности (CNN, RNN, трансформеры);
• Обучение и тестирование моделей на CPU и GPU;
• Реализация кастомных слоёв и loss-функций;
• Разработка и деплой ML/AI моделей в продакшен;
• Быстрая итерация гипотез с удобной отладкой.

С PyTorch можно начать с простых нейронных сетей, а затем перейти к реализации современных архитектур.

Как пользоваться

Установим PyTorch (на CPU, для GPU потребуется версия с CUDA):

Рассмотрим кейс обучения простой нейронной сети для классификации рукописных цифр MNIST.

После обучения можно использовать torch.save() для сохранения модели и torch.load() для загрузки в продакшн.

Почему это меняет карьеру

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

Для начинающего ML/AI-специалиста PyTorch помогает лучше понять, как устроены нейронные сети, и под капотом увидеть, как происходят вычисления. Это ускоряет рост навыков и делает разработчика востребованным в исследованиях и R&D-проектах.

Для дата-сайентистов PyTorch позволяет превратить исследовательские ноутбуки в готовые к деплою модели, благодаря PyTorch Lightning, TorchScript и ONNX.

Для разработчиков, которые хотят выйти на рынок AI, PyTorch — это мастхев: проекты в стартапах и крупных компаниях всё чаще строятся вокруг него. Умение писать кастомные loss-функции, проектировать сложные пайплайны обучения, настраивать обучение на кластерах и GPU — компетенции, которые существенно бустят зарплату.

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

4. Polars

Polars — современная библиотека для обработки данных в Python, созданная как альтернатива Pandas. Она использует колоночную архитектуру и многопоточность, что позволяет работать с большими объёмами данных значительно быстрее и с меньшим потреблением памяти.

Polars вдохновлена Pandas, но её API оптимизировано для производительности и удобства, а также даёт разработчику возможность писать цепочки ленивых вычислений, которые оптимизируются перед выполнением. Это делает её отличным инструментом для аналитиков, дата-инженеров и дата-сайентистов, которым нужно обрабатывать данные быстро.

Какие задачи решает библиотека

Polars явно есть, чем гордиться:

• Загрузка, очистка и преобразование больших датасетов;
• Анализ данных с использованием цепочек преобразований;
• Быстрая агрегация и группировка данных;
• Ленивые вычисления: построение пайплайнов преобразования данных, которые выполняются только при вызове collect().
• Обработка данных, которые не помещаются в память, за счёт эффективности и колоночной архитектуры.

Если Pandas начинает притормаживаться на данных в несколько гигабайт, Polars обычно продолжает работать быстро, позволяя без боли обрабатывать большие CSV.

Как пользоваться

Установка:

Давайте загрузим данные и проведем базовые трансформации:

А вот и пример ленивых вычислений:

В чем особенность:

• pl.read_csv загружает данные сразу.
• pl.scan_csv создаёт план вычислений для последующей оптимизации.
• Используются выражения (pl.col, .with_columns, .agg), которые композируются без создания промежуточных копий, это ускоряет процесс.

Почему это меняет карьеру

Polars меняет карьеру, потому что даёт преимущество в скорости и эффективности при работе с данными. Там, где Pandas уже не справляется, полярный медведь приходит на помощь.

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

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

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

5. FastAPI

FastAPI — современный фреймворк для создания API на Python, заточенный под скорость, асинхронность и валидацию данных из коробки. Он построен на Starlette и Pydantic, автоматически создаёт OpenAPI-документацию, поддерживает асинхронное программирование и позволяет писать производительные REST и WebSocket API с минимальным количеством кода.

Вместо долгой настройки, как у Flask или Django, в FastAPI многое готово изначально: удобная работа с запросами и ответами, декларативная валидация, документация Swagger, асинхронность и высокая производительность без лишних усилий.

Какие задачи решает

Задач, действительно, много:

• Быстрая разработка REST API для мобильных и веб-приложений;
• Создание бэкенда для ML/DS моделей (деплой моделей в виде API);
• Построение микросервисов с хорошей производительностью;
• Реализация websocket-серверов и асинхронных API;
• Подготовка внутренних инструментов или бэкендов для MVP.

FastAPI помогает быстро запускать API и уверенно масштабировать его в полевых условиях. Это один из немногих фреймворков Python, который по скорости работы сопоставим с Node.js и Go.

Как пользоваться

Во-первых, нужно установить FastAPI и Uvicorn (используем ASGI-сервер для запуска):

Простейший API-пример с эндпоинтом GET /:

Запускаем сам сервер:

После запуска API будет доступен по адресу http://127.0.0.1:8000/. Автоматически доступна интерактивная документация Swagger по адресу http://127.0.0.1:8000/docs.

FastAPI поддерживает валидацию параметров запроса, тел запросов и путей прямо через типы Python. Например, простой эндпоинт с параметром:

При вызове http://127.0.0.1:8000/items/10?q=test FastAPI автоматически проверит, что item_id — это число, и распарсит q как строку.

Почему это меняет карьеру

FastAPI — билет в мир бэкенда, где скорость и чистота кода имеют довольно высокое значение. Для Python-разработчика это возможность быстро освоить создание API и микросервисов, не увязнув в громоздкой настройке, как в Django, и при этом получить систему, готовую к продакшену.

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

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

6. Typer

Typer — современная библиотека для создания CLI-приложений на Python с минимальным количеством кода и автоматической генерацией документации. Автор библиотеки — Себастьян Рамирес, создатель FastAPI.

Главная особенность Typer — использование type hints для автоматического парсинга аргументов командной строки. Вы получаете удобную и читаемую CLI с поддержкой автодополнения и цветного вывода за считанные минуты.

Какие задачи решает библиотека

Список задач такой:

• Создание CLI-утилит любого уровня сложности.
• Быстрое прототипирование и упаковка Python-скриптов в удобные инструменты для продакшена.
• Генерация подробной справки (--help) и автодополнения команд.
• Облегченная поддержка и масштабирование CLI за счёт структуры и читаемого кода.
• Организация CLI с подкомандами, вложенными аргументами и обработкой ошибок.

Typer использует аннотацию типов и минимум шаблонного кода.

Как пользоваться

Установка:

Пример минимальной CLI:

Теперь можно запустить из консоли:

Результат будет такой: Привет, Алиса! Тебе 25 лет.

Почему это меняет карьеру

Typer меняет карьеру тем, что открывает путь к созданию удобных CLI-инструментов, которые автоматизируют рутину и повышают продуктивность.

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

Если вы Data Scientist или ML-инженер, Typer позволяет оборачивать пайплайны в CLI, которые легко запускать из Jenkins, Airflow или вручную. Если вы DevOps или Backend-инженер, можете создавать CLI для работы с инфраструктурой и сервисами без сложных зависимостей.

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

7. Rich

Rich — библиотека Python для красивого форматирования и интерактивного отображения информации в терминале. С её помощью можно выводить цветные таблицы, маркдаун, прогресс-бары, подсвеченный синтаксис кода, деревья каталогов и логирование в понятной и привлекательной форме.

Rich создана для того, чтобы «оживить» консоль Python, сделать логи удобными для восприятия, а CLI-инструменты — профессионально выглядящими без лишних усилий. Это библиотека, которая улучшает и UX, и DX.

Какие задачи решает

Про красоту не забываем! Задачи следующие:

• Цветное и структурированное логирование, понятное при чтении логов в реальном времени.
• Отображение прогресс-баров для долгих операций.
• Вывод таблиц, деревьев каталогов, JSON прямо в терминале.
• Подсветка синтаксиса кода для CLI-инструментов.
• Создание CLI-интерфейсов, которые выглядят профессионально и современно.
• Улучшение читаемости при отладке скриптов.

С помощью Rich можно быстро сделать понятными даже сложные данные при отладке или демонстрации.

Как пользоваться

Установка Rich:

Для примера выведем таблицу с подсветкой в консоли:

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

Почему это меняет карьеру

Rich — это библиотека, которая помогает быстро повысить качество любого CLI-инструмента или дев-опыт в команде. Разработчик, который использует Rich, делает свои инструменты удобными не только для себя, но и для коллег: логирование становится понятным, а отладка скриптов — наглядной.

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

Кроме того, Rich позволяет быстро создавать CLI-интерфейсы, которые выглядят как продакшен-продукты, даже если это внутренние инструменты. Руководство будет радоваться и думать о вас как о крутом разрабе.

Для дата-инженеров и разработчиков DevOps Rich полезна при создании админ-утилит и при мониторинге пайплайнов, для Python-разработчиков — при создании библиотек и фреймворков с CLI.

8. LangChain

LangChain — фреймворк для создания приложений на базе LLM, например, GPT, Claude, Mistral, Gemini. Он позволяет строить цепочки обработки запросов, интегрировать LLM с данными и инструментами, добавлять память и управление состояниями, а также связывать работу модели с внешними API и базами знаний.

LangChain предоставляет удобный слой абстракции над вызовами LLM и ускоряет разработку чат-ботов, RAG-приложений, агентов с инструментами, систем анализа документов и других AI-сервисов.

Какие задачи решает

Список внушительный:

• Интеграция LLM в Python-приложения без необходимости писать тот самый клеевой код вручную.
• Построение цепочек с последовательной обработкой сообщений, включая преобразования и вызовы внешних функций.
• Добавление памяти в чат-боты для сохранения истории общения и контекста.
• Использование агентов для динамического вызова инструментов (веб-поиск, базы данных, API).
• Создание RAG-систем с интеграцией LLM и векторных БД.
• Быстрая сборка прототипов LLM-приложений, которые можно развернуть в продакшен.

Как пользоваться

Установка:

Создадим простую цепочку с чатом GPT:

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

Почему это меняет карьеру

LangChain меняет карьеру, потому что открывает новый пласт Python-разработки в AI и LLM-инженерии, быстро превращая пользователя GPT в создателя полноценных AI-приложений. Вместо того чтобы писать хаотичный клеевой код, вы начинаете системно проектировать цепочки запросов, учитесь строить продуманные промпты и объединять их с инструментами, памятью и внешними API.

Работа с LangChain погружает в практическую LLM-инженерию: вы начинаете создавать RAG-приложения, которые умеют искать и анализировать данные перед генерацией ответа и строить агентов. Это востребовано в продуктах, где нужно подключать ИИ к базам знаний, автоматизировать задачи и разрабатывать интерактивные системы, которые реально используют модели в продакшене.

LangChain позволяет быстро собирать и запускать MVP AI-продуктов, что дает конкурентное преимущество при создании стартапов или внутренних сервисов. А ещё учит мыслить структурами и проектировать масштабируемую архитектуру LLM-приложений и видеть, как генеративный ИИ можно превратить в рабочий инструмент.

9. SQLAlchemy

SQLAlchemy — это мощная ORM и toolkit для работы с базами данных в Python, позволяющая писать SQL-запросы декларативно, создавать модели таблиц и управлять транзакциями в Python-коде без ручного написания SQL.

Библиотека даёт разработчику два уровня контроля:

• Core: низкоуровневая работа с SQL выражениями и соединениями;
• ORM: высокоуровневая декларативная работа с моделями, классами и связями между таблицами.

SQLAlchemy поддерживает PostgreSQL, MySQL, SQLite, Oracle и другие СУБД, давая единую абстракцию, без привязки к конкретному движку.

Какие задачи решает

Пул задач следующий:

• Описание таблиц в виде Python-классов и управление ими через сессии;
• Создание, чтение, обновление и удаление данных;
• Миграция SQL на декларативный стиль без потери гибкости;
• Полный контроль над транзакциями и выполнением запросов;
• Работа с асинхронными приложениями при создании FastAPI/Django-приложений;
• Экранирование параметров, которое снижает вероятность SQL-инъекций и ошибок.

Как пользоваться

Создадим минимальный пример для SQLite с таблицей пользователей:

Этот код создаёт базу example.db, таблицу users, добавляет туда одного пользователя и выводит всех пользователей в базе. При необходимости можно использовать SQLAlchemy Core для написания гибких запросов вручную, если нужно работать ближе к SQL.

Почему это меняет карьеру

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

Знание SQLAlchemy открывает дорогу в мир API, микросервисов и продуктов, где требуется качественное управление данными и гибкая логика работы с БД. Работа с SQL теперь совсем не страшная.

10. Seaborn

Seaborn — библиотека для визуализации данных на Python, построенная поверх Matplotlib и упрощающая создание информативных и стильных графиков с минимальным количеством кода.

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

Библиотека тесно интегрируется с Pandas DataFrame, позволяя использовать колонки данных напрямую для построения графиков, что делает её идеальной для EDA (разведочного анализа данных) и подготовки визуализаций для отчётов и презентаций.

Какие задачи решает

Визуализация безумно важна, особенно в контексте дата-аналитики. Seaborn отвечает за:

• Быстрое построение информативных графиков для анализа данных и поиска инсайтов;
• Автоматическую обработку ошибок отображения и масштабирования, что экономит время;
• Поддержку сложных визуализаций по типу ящиков с усами или тепловых карт без десятков строк кода;
• Стилизацию графиков без ручных настроек Matplotlib;
• Возможность добавлять статистические элементы (линию регрессии, KDE, распределение);
• Интеграцию с Jupyter Notebook для интерактивного анализа данных.

Как пользоваться

Допустим, у нас есть датасет с данными о чаевых:

В три строки мы получаем чистый и читаемый ящик с усами, показывающий, как счет за ужин распределяется по дням недели.

Для построения более сложных графиков можно использовать диаграмму рассеяния:

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

Почему это меняет карьеру

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

Использование Seaborn в Python-стеке помогает выделиться среди разработчиков, которые ограничиваются Pandas и текстовыми логами, ведь визуализация часто позволяет быстрее заметить закономерности и убедить команду или заказчика в правильности гипотезы.

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

А какими библиотеками пользуетесь вы? Делитесь в комментариях!

Может плодить новые эндпоинты или заставлять мобилку делать несколько запросов вместо одного? Каждый запрос жрёт трафик и батарею!

Элегантное решение — архитектура Backend for Frontend (BFF). Это прослойка между клиентскими приложениями и основным API, которая адаптирует данные под потребности конкретного клиента.

Основная идея backend for frontend

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

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

Следуя архитектуре BFF, вы можете создать логику для каждого типа клиента и не засорять основной API. Вместо одного эндпоинта /api/products, который пытается угодить всем, появляются слои:

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

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

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

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

«Можете добавить поле user_avatar в ответ?»

— «Это сломает мобилку».

«Тогда сделайте отдельный эндпоинт».

— «У нас нет времени».

С BFF этого диалога нет. Фронтенд-команда получает свой API и крутит его, как хочет.

Мобильное приложение съедает 10к запросов в секунду? Пишите BFF на Go. Веб-версию делает стажёр, который знает только JavaScript? Ставьте Node.js. Никто не заставляет выбирать одну технологию на все случаи жизни.

Как работает backend for frontend (BFF)

BFF размещается между клиентскими приложениями и основными бэкенд-сервисами, выполняя роль посредника. В отличие от API Gateway, который просто перенаправляет запросы, BFF трансформирует данные.

Архитектура взаимодействия

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

Когда мобильное приложение запрашивает список заказов, его BFF делает несколько вызовов к микросервисам:

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

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

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

Обработка и агрегация данных

BFF не просто перекладывает данные из одного формата в другой. Он выполняет бизнес-логику.

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

Если API возвращает цены в центах, мобильный BFF конвертирует их в рубли и округляет для отображения. Веб-версия получает точные значения с копейками для расчётов.

Независимость и масштабирование

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

4 ключевых преимущества BFF

Оптимизация передачи данных

Самое очевидное преимущество — экономия трафика. Приложение не тащит 2 МБ JSON с полным каталогом товаров на мобильное устройство? BFF отдаёт только нужные поля.

Количество запросов тоже сокращается. Например, чтобы показать профиль пользователя, фронтенд делает 5 запросов:

• за основными данными,
• аватаром,
• списком друзей,
• последними постами,
• настройками приватности.

BFF объединяет всё в один запрос, получая данные параллельно от разных сервисов.

Упрощение фронтенда

Половина фронтенд-кода уходит на трансформацию ответов API:

• парсинг дат,
• группировку массивов,
• вычисление производных значений.

BFF может взять эту работу на себя.

Безопасность через изоляцию

BFF создаёт барьер между клиентами и сервисами. Мобильное приложение никогда напрямую не обращается к БД пользователей или платёжке — только через свой BFF.

Можно настроить разные уровни доступа:

• мобильный BFF видит только публичные данные,
• API для партнёров работает в песочнице.

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

Независимое масштабирование

Когда приложение попадает в топ App Store, нагрузка взлетает в разы. Но страдает только мобильный BFF — веб-версия продолжает работать стабильно. Можно быстро поднять дополнительные серверы только для мобильного трафика.

Появляется возможность экспериментировать с технологиями без риска. Хотите попробовать GraphQL для веб-версии? Внедряйте в один BFF. Тестируете новую базу данных? Подключайте к экспериментальной прослойке, не трогая продакшн.

Когда стоит использовать backend for frontend

BFF — инструмент для конкретных ситуаций.

Когда интерфейсы кардинально отличаются

Если ловите себя на мысли: «этот эндпоинт нужен только для веба» или «мобилка использует 10% полей из ответа», — пора задуматься о BFF.

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

Когда интерфейсы эволюционируют быстрее джунов

Стартапы и продукты в активной фазе развития меняют интерфейсы каждую неделю.

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

Без BFF это означает изменения в основном API, которые могут сломать другие клиенты. С BFF — правки только в одном месте.

Когда команды работают независимо

Если у вас несколько фронтенд-команд, которые постоянно конфликтуют из-за API, BFF даст им свободу.

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

BFF распределяет ответственность: каждая команда поддерживает свой слой.

Когда НЕ стоит использовать BFF

Если у вас простое приложение с одним клиентом, BFF добавит лишнюю сложность. Если API уже идеально подходит всем клиентам, зачем что-то менять?

3 типичные ошибки при внедрении BFF

Дублирование логики

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

Хуже, когда дублируется бизнес-логика. Расчёт скидок, обработка промокодов, правила доступа — это должно жить в основных сервисах, а не размазываться по BFF-слоям.

Избыточная сложность вместо упрощения

Пример: команда создаёт «универсальный BFF-фреймворк» с конфигурацией через YAML, поддержкой плагинов и собственным DSL. В итоге простое добавление поля в ответ требует изучения документации на 50 страниц.

Другая крайность — микро-BFF для каждой мелочи. Отдельный слой для авторизации, отдельный для форматирования дат, отдельный для валидации.

Неправильная гранулярность

Один BFF на все мобильные платформы может быть слишком общим: iOS и Android имеют разные особенности интерфейса. Но отдельный BFF для каждой версии приложения — явный перебор.

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

Практические примеры использования BFF

Netflix

Компания сделала разные API для веб-версии, мобильных приложений, Smart TV и игровых консолей. Каждый BFF оптимизирован под особенности устройства, например, TV-версия предзагружает больше контента из-за медленной навигации пультом.

Spotify

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

SoundCloud

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

Заключение

Страдают все, когда один API пытается обслуживать веб-версию, мобилки и что-то ещё. Фронтенд получает неудобные данные, бэкенд обрастает костылями, пользователи — медленными приложениями.

Backend for Frontend создаёт слой между клиентами и основными сервисами. Каждый тип устройства получает API, заточенный под его потребности.

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

Ты уже программист, если читаешь это! Больше про кодинг — здесь.

В статье рассмотрим:

- Установку локально и в облаке;

- Интеграцию с Python, Node.js и PHP;

- Примеры автоматизаций;

- Интеграцию с AI Mistral.

Установка n8n

Локальная установка

Нам потребуется Docker, проверьте установку:

Шаги установки:

1. Создайте том данных:

2. Запустите контейнер:

После запуска откройте: `http://localhost:5678`

Установка на удаленном сервере

Развертывание мы произведем в облаке Amvera, так как в нем n8n предоставляется как преднастроенный сервис с бесплатным доменом (он нам нужен), настроенными переменными и проксированием до заблокированных в РФ LLM (OpenAI, Gemini, Claude и др.).

1. Регистрируемся на Amvera;

2. Выбираем n8n в плитке на главной странице;

3. Вводим название для проекта и выбираем тариф.

Готово, через 30 секунд запустится n8n с выделенным доменом и настроенными основными переменными.

Настройка n8n

Первоначальная настройка

1. Откройте n8n (локально: `localhost:5678`, в облаке: ваш домен)

2. Заполните данные администратора:

• Email

• Имя/Фамилия

• Пароль

3. По желанию вы можете получить бесплатный лицензионный ключ:

• Введите email → "Send me a free license key"

• Активируйте в разделе Settings → Usage

Настройка для HTTP

1. Создайте новый workflow → Start from scratc

2. Добавьте триггер: Webhook - On webhook call

3. Настройте:

• HTTP Method: POST

• Path: `/n8n` (пример)

• Respond Mode: Using 'Respond to Webhook' node

4. Добавьте обработчик: Core → Respond to Webhook

5. Настройте ответ:

Примеры использования

Пример на Python

В примере на Python мы сделаем калькулятор. Суть: отправляем выражение через POST, n8n делает вычисление, возвращаем результат.

Workflow:

1. Добавьте Core → Code node между Webhook и Respons:

Клиент (Python):

Запустим код и посмотрим результат:

Пример на PHP

В примере на PHP мы сделаем валидацию данных. Суть: отправляем данные через POST, n8n проверяет данные, возвращает результат.

Workflow (Code node):

Клиент (PHP):

Можем зайти на нашу страницу, все работает нормально:

Пример на Node.js

Примером на node.js будет фильтр запрещенных слов. Суть: отправляем текст, n8n проверяет на наличие плохих слов, возвращает результат.

Workflow (Code node):

Клиент (Node.js):

Перед запуском установим библиотеку командой `npm install axios`

Интеграция n8n с Mistral AI

Мы интегрируем нейросеть Mistral в телеграмм-бота на C# с помощью n8n. Перед тем как начать, нам нужно получить токен.

1. Зарегистрируйтесь на Mistral

2. Создайте агента Сreate an agent

3. Перейдите в раздел API Keys

4. Создайте и скопируйте API-ключ (звездочки наложены):

Теперь нужно создать credentials для работы с созданной моделью. Для этого в правом верхнем углу нажмите Create credentials. В списке найдите Mistral Cloud API. В открывшемся окне вставьте скопированный ключ и сохраните.

Осталось настроить workflow.

1. Добавляем Webhook:

• Method: POST

• PATH: n8n

• Respond: Using 'Respond to Webhook' Node

2. Добавляем AI Agent:

• Source for Prompt: Define below

• Prompt: `{{ $json.body.text }}`

3. Подключаем Chat Model к созданному агенту:

• Credential to connect with: Mistral Cloud API

• Model: mistral-large-2411

4. Добавляем Respond to Webhook

Вот так выглядит готовый workflow:

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

Переходим в папку с кодом и редактируем файл `Program.cs`:

Запустите бота с помощью команды `dotnet run`.

Автоматизируем с помощью n8n

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

Для работы с Telegram Node понадобиться создать credentials Telegram API. Туда вставляем токен бота, полученный в @BotFater. Сохраняем и переходим к настройке workflow.

Создаем новый workflow.

1. Добавляем On form submission. В качестве примера я создам самую простую форму:

Перейдите по ссылке в Producrion URL чтобы заполнить форму.

2. Добавляем Telegram Node:

• Credential to connect with: Telegram account

• Resource: Message

• Operation: Send message

• Chat ID: вставьте свой telegram id

Text:

Готово! При новых заявках бот будет присылать уведомления.

Деплой бота в Amvera Cloud

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

Строго говоря, этот файл проще создать в конфигураторе в интерфейсе.

2. Структура проекта будет такой:

tg-bot/

├── Program.cs

├── tg-bot.csproj

├── amvera.yml

├── bin/

└── obj/

Идем В Amvera Cloud и создаем приложение Приложения — Создать приложение. Вводим название и выбираем тариф.

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

Нажимаем Завершить и ждем когда приложение будет запущено.

Заключение

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

Меня зовут Юрий Дубовик, я DevOps-инженер компании «Флант». Мы занимаемся DevOps-сопровождением — помогаем другим компаниям делать инфраструктуру надёжной и создавать комфортную среду для разработки.

Мы много работаем с Kubernetes, и иногда нашим инженерам нужно разобраться с настроенными правами доступа к разным объектам в K8s-кластере клиента. Приходится тратить много времени на сбор и упорядочивание информации, а потом сопоставлять, кому какие роли были назначены. Но сравнительно недавно появился Open Source-инструмент, который упрощает этот процесс, — RBAC Wizard.

RBAC Wizard позволяет быстро проанализировать конфигурации RBAC (Role-based access control) в кластере, а главное, может визуализировать всю собранную информацию. В этом обзоре я покажу, как установить этот инструмент с помощью Helm, и сравню его использование с ручным подходом.

Зачем нужен аудит конфигураций RBAC

RBAC — это механизм распределения прав доступа к объектам в Kubernetes-кластере. Подробно останавливаться на принципах работы RBAC я не буду, поскольку об этом уже написано множество материалов.

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

Что такое RBAC Wizard

RBAC Wizard — это инструмент на Go с открытым исходным кодом, который помогает анализировать и визуализировать конфигурации RBAC вашего кластера Kubernetes. Он обеспечивает табличное и графическое представление объектов RBAC Kubernetes.

Хотя проект появился на GitHub недавно, в 2024 году, он уже успел привлечь интерес сообщества. Сейчас у RBAC Wizard чуть больше 270 звёзд.

Как установить RBAC Wizard

RBAC Wizard можно установить локально, запустить в контейнере или развернуть в кластере с помощью Helm. Процесс просто и понятно описан в самом репозитории.

Я выбрал вариант установки с помощью Helm:

После установки в кластере Kubernetes в пространстве имён rbac-wizard появится одноимённый ингресс rbac-wizard:

У ингресса указан хост rbac-wizard.local. Заменяем его на нужный нам адрес — домен, который находится под нашим управлением, например new.example.com. По этому адресу мы потом увидим RBAC Wizard в браузере.

Это всё! Больше никаких настроек не требуется. У меня на установку ушло 5–10 минут.

Подготовка тестовых ролей

Чтобы сравнить между собой решение задачи по анализу конфигураций в Kubernetes-кластере без RBAC Wizard и с ним, создадим тестовые ServiceAccount, ClusterRole и ClusterRoleBinding. Разумеется, если вы используете инструмент в готовом кластере, этот шаг стоит пропустить:

Анализ конфигурации RBAC без RBAC Wizard

Давайте посмотрим, как можно решить задачу без RBAC Wizard.

Если требуется найти пользователя или ServiceAccount, которые имеют определённую роль, выполняем следующий запрос:

Пример ответа:

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

Пример ответа:

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

Анализ конфигурации с помощью RBAC Wizard

Теперь перейдём в браузере по указанному нами адресу в поле host спеки ингресса rbac-wizard и посмотрим, удобнее ли анализировать конфигурации с RBAC Wizard.

Интерфейс инструмента интуитивно понятный. В верхней его части находится RBAC Table. Как понятно из названия, здесь представлена информация о ClusterRoleBinding и RoleBinding в виде таблицы с возможностью поиска:

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

Под таблицей отображается RBAC Map — граф с визуализацией объектов RBAC и их связей. В фильтре можно выбирать ClusterRoleBinding, RoleBinding и посмотреть их взаимосвязь с Role, ClusterRole, User или Group:

А так выглядят более сложные связи:

Привязку к подам утилита не показывает, то есть узнать, кто именно использует аккаунт, не получится.

Итого, RBAC Wizard позволяет мгновенно получить таблицу со всеми ClusterRoleBinding и RoleBinding, наглядно увидеть, кому и какие роли назначены, и быстро найти нужную информацию с помощью поиска. А граф может пригодиться в случаях, когда связей много.

Заключение

Буду краток. RBAC Wizard — простой как молоток инструмент. Но он неплохо упрощает жизнь, позволяя быстро проводить аудит ролей в кластере Kubernetes.

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

Минутка рекламы

Если перед вами стоят задачи по переходу на Kubernetes, внедрению DevOps-практик или сокращению Time to Market, а своих ресурсов и опыта недостаточно, обращайтесь к нам во «Флант». Мы внедрим проверенные технологии, возьмём на себя полный цикл работ и будем сопровождать вашу инфраструктуру силами выделенной команды с гарантиями по SLA.

Почему «тормоза» — это не всегда про код

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

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

Вот что тормозит, когда код ни при чём:

Архитектура

• Цепочки вызовов: каждый хоп — +latency.
• Синхронные зависимости: завис один сервис — тормозят все.
• Общие ресурсы: shared state, глобальные очереди, блокировки.

Базы данных

• Нет индексов или плохой план запроса.
• N+1-запросы — особенно при неосторожной ORM.
• Частый доступ к одним таблицам — гонка за IO и блоки.
• Нет шардинга или репликации в масштабируемой нагрузке.

Сеть

• Высокая задержка между регионами (особенно multi-cloud).
• Потери пакетов, DNS-проблемы, нестабильность.
• Отсутствие connection reuse: TLS-handshake на каждый вызов.

Очереди и брокеры

• Один медленный потребитель тормозит всех.
• Нет защиты от от backpressure или дедупликации.
• Неправильные batch- и ack-настройки.

Аллокаторы и GC

• Фрагментация памяти, нагрузка на GC.
• Финалайзеры, слабые ссылки, плохо настроенный heap.

Конфигурации

• Маленький пул соединений — пул заканчивается, запросы ждут.
• Агрессивные retry-политики — система перегружается.
• CPU throttling в Kubernetes — контейнеру не хватает ресурсов.

Сериализация и форматы

• Перегруженные JSON/Protobuf.
• Вложенные base64 + gzip + JSON — боли сериализации.

Почему bottlenecks остаются невидимыми до продакшена

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

• мало данных,
• нет конкуренции за ресурсы,
• нет распределённой нагрузки.

В проде начинается хаос. Рассмотрим на конкретных примерах:

• На деве — 2 запроса в секунду, в проде — миллион. Кто-то запустил маркетинговую рассылку, аналитик тащит big report, а клиент ретраит ошибки.
• Архитектура «в лоб»: всё синхронно, каждый сервис вызывает по цепочке десяток других. Пока нагрузка мала — все живет. Как только одно звено не выдерживает — перестает жить.
• Иллюзия масштабируемости: до 100 пользователей — всё окей, на 1000 — каскадная деградация.
• «Невидимая боль» между сервисами: каждый по отдельности быстрый, но блокирует друг друга на базе.

Слои архитектуры и где в них зарыты проблемы

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

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

На уровне клиента

• Тяжёлые бандлы. Огромный JS, куча аналитики, трекеры — и вот страница загружается 8 секунд на старом телефоне.

• Чрезмерные запросы. После загрузки — 10 fetch в секунду. API захлёбывается, браузер — тоже.

• Нет кеша. Даже статичные справочники каждый раз грузятся заново.

• Лаги рендеринга. Бэкенд дал ответ за 100ms, но интерфейс лагает — сложные таблицы, графики, reflow.

На уровне API Gateway / BFF

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

На уровне Backend / бизнес-логики

• Цепочки вызовов. Один сервис вызывает другой, тот — ещё один… И так далее.
• Ограниченный пул соединений — сервис готов работать, но все worker-ы ждут ресурсы.
• Логика в цикле по данным — N+1-запросы, сериализация, дублирование работы.

На уровне базы данных / кэша

• Full table scan. Работает быстро на 1000 строках. Умирает на 10 миллионах.

• Локи и гонка за ресурсы. Один UPDATE лочит строку, остальные ждут.

• Кэш не промахивается, но и не помогает — stale данные, повторные чтения, инвалидация не работают, как ожидалось.

На уровне внешних сервисов (API, брокеры, платёжки)

• Без timeout и fallback. Внешний API залип — вы вместе с ним.
• QPS-лимиты. Вы не знали, а вас уже зарейт-лимитили.
• Нестабильная сеть. DNS тормозит, соединения рвутся, задержки скачут между регионами.

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

Есть архитектурные паттерны риска, которые часто приводят к тормозам через полгода. Во-первых, общий ресурс на всех: один Redis, один Kafka-топик, одна таблица. Пока нагрузка маленькая — ок. Потом начинается бойня за доступ. Во-вторых, микросервисный монолит: формально разделены, но живут как один. Масштабировать невозможно. В-третьих, цепочки вызовов: 5–6 сервисов на путь одного запроса. Один подвис — и вся цепочка тормозит.

Базы данных: когда даже SELECT тормозит всё

В бэкенде одна из самых коварных фраз — «ну это же просто SELECT, что с ним будет». Ответ — сначала ничего. Но со временем появляется 10 миллионов строк, и ваш innocuous SELECT превращается в full scan, который лочит диск, ест CPU и тормозит всё, что движется.

Типичная ситуация: в таблицу пишут JSONB без нормализации и индексов. Пока строк мало — жить можно. Но при росте объёмов каждый запрос превращается в медленное последовательное чтение. Это не просто «долго», а начинает мешать соседним транзакциям: подгружаются stale данные, вытесняется кэш, система начинает проседать вся — вплоть до API.

Отдельная ловушка — смешение OLTP и OLAP нагрузки. Днём — INSERT и UPDATE от клиентов, ночью — фоновая аналитика, высчитывающая отчёт за год с десятком JOIN и чтением всей таблицы. Если все запросы идут в один инстанс, происходит конкуренция за ресурсы: аналитика сбивает кеш, вызывает блокировки, а продакшн-метрики начинают сыпаться.

Как понять, что тормоза идут из базы, а не из бэкенда?

Вот несколько типичных признаков:

• Бэкенд «висит» на запросах к базе — в логах видно, что приложение ждёт результат запроса (долгий await, query(), findMany() и т. д.).

• Latency растёт, а CPU и память в норме — сервис сам по себе не перегружен, но ответ приходит медленно.

• В базе фиксируются медленные запросы — например, SELECT или JOIN занимают секунды, хотя раньше проходили за миллисекунды.

Чтобы подтвердить гипотезу, можно:

• Включить логирование SQL-запросов с таймингом;
• Посмотреть трейс: если шаг DB заметно длиннее остальных — это тревожный сигнал;
• Запустить EXPLAIN ANALYZE на типовые запросы и проверить, где зарыта сложность.

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

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

На что здесь стоит обратить внимание:

• Количество и характер обращений. Один пользовательский запрос не должен порождать десятки обращений к базе. Планирование кэшей, агрегаций, prefetch, нормализация — всё это часть архитектуры.
• Уровень абстракции над данными. ORM может быть удобным, но часто скрывает десятки неэффективных SELECT’ов. Нужно понимать, какие запросы реально идут в базу, и не превращать каждый use case в потенциальный bottleneck.
• Стратегия хранения и агрегаций. Если вы пытаетесь на лету агрегировать 100 миллионов строк без шардинга и партиционирования — тормоза неизбежны. Архитектура должна учитывать нагрузку, частоту агрегаций, структуру данных.

Очереди и событийные системы: скрытые замедления

Событийные архитектуры и очереди вроде Kafka или RabbitMQ часто воспринимаются как универсальное средство от всех проблем: «Сделаем асинхронно — и всё полетит». Но это не серебряная пуля. Очередь не решает проблему — она её откладывает. А иногда сама становится bottleneck’ом.

Типовые ситуации, когда очередь тормозит систему:

• Медленные консьюмеры. Очередь принимает сообщения с высокой скоростью, но обработчики не успевают, и начинается накопление беклога. В результате задержки накапливаются, SLA летит, а вы только недоумеваете, почему всё так тормозит.
• Неправильный размер batch’ей. В Kafka и аналогах размер и частота batch'ей критичны. Слишком большие — ждём, пока соберётся партия. Слишком маленькие — тратим ресурсы на лишнюю загрузку и пересылку. В итоге получаем либо высокую задержку, либо низкую производительность.
• Неравномерное партиционирование. Если сообщения распределяются по партициям неравномерно, то часть узлов будет простаивать, а часть захлёбываться под нагрузкой. Одна горячая партиция может стать bottleneck’ом всей системы.
• Проблемы с retry. Если нет чёткой стратегии повторных попыток, логирования и DLQ (dead-letter queue), битое событие может крутиться в системе бесконечно, тормозя всё остальное. Также если что-то пошло не так и включились retry-механизмы, задержка может вырасти в разы. Особенно если есть backoff или дедлоки.

Почему «асинхронно» ≠ «мгновенно»

Асинхронность — это не про скорость, а про отложенность. Событие отправлено — но когда оно будет обработано, никто не знает. Через секунду, через минуту, через час?

Типичные причины задержек в асинхронной обработке:

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

Что происходит, когда очередь переполнена — и почему это тяжело заметить

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

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

Для защиты от переполнения очереди нужно мониторить несколько важных показателей:

• Глубина очереди (в Kafka — consumer lag, в RabbitMQ — queue.messages_ready или queue.messages): показывает, сколько сообщений накопилось и ждёт обработки.
• Publish rate: сколько сообщений в секунду публикуется.
• Processing rate: сколько сообщений в секунду обрабатывается.
• Утилизация ресурсов воркеров (CPU, memory, I/O).
• End-to-end latency: сколько времени проходит от публикации события до его обработки.

Есть самые частые причины накопления сообщений:

1) Медленные потребители, которые не успевают обработать весь поток сообщений.
2) Шумная архитектура: 10 сообщений там, где можно было обойтись и одним.
3) Неправильное масштабирование брокера (например, неправильно выбранный ключ партиционирования в Kafka).

API и микросервисы: где тормозит взаимодействие

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

Что тормозит в микросервисах?

Много лишних вызовов

Один пользовательский запрос вызывает лавину внутренних HTTP/gRPC-запросов. Каждый из них — это:

• сетевые задержки (latency),
• сериализация/десериализация данных,
• ретраи при сбоях,
• риск таймаутов и обрывов.

Если таких вызовов много, задержка накапливается каскадом.

Цепочка зависимостей

Классика жанра: заказ зависит от оплаты, оплата — от биллинга, биллинг — ещё от трёх микросервисов.

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

Нет fallback'а и таймаутов

Если вызов к нужному сервису не отвечает, а у вас нет fallback'а или таймаута — всё встаёт. Особенно плохо, если вызов синхронный и блокирует поток.

Наносервисы

Иногда архитекторы увлекаются и дробят сервисы до абсурда. Начинается с «давайте переиспользуем», а заканчивается 10 API-вызовами ради одного действия.

Вместо бизнес-логики система начинает заниматься оркестрацией — координирует сама себя.

Кэш и CDN: почему «ускорители» тоже могут тормозить

Кэш традиционно считается палочкой-выручалочкой для производительности. «Добавим кэш — и всё полетит», — думают команды, особенно под нагрузкой. Но в реальности кэш может не только не ускорить, но и наоборот — замедлить или даже уронить систему, если использовать его без понимания.

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

Невалидные или слишком агрессивные стратегии

Если кэш живёт слишком долго — пользователи получают устаревшие данные. Если обновляется слишком часто — создаются лишняя нагрузка на базу и почти постоянные «промахи».

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

Перегрузка кэша

Когда кэш настолько загружен, что сам по себе начинает тормозить — это уже не помощь, а вред. Такое часто случается с Redis, Memcached или in-memory решениями, особенно если они:

• работают на одной машине без шардинга;
• содержат тяжёлые объекты;
• используются как универсальный ответ на все проблемы.

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

Кэш-миссы и лавины запросов

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

Вместо одного запроса вы получаете 10 000, и тормозит всё. Особенно критично это для систем с CDN, где внезапное истечение кэша популярных страниц может вызвать DDoS-подобную нагрузку.

Несогласованность кэшей

Если в системе несколько уровней кэширования (CDN, фронтовый кэш, Redis) и они обновляются по-разному, возникает несогласованность. Один пользователь видит новые данные, другой — старые. Один сервис работает с актуальной версией, другой — с устаревшей. Начинается охота за фантомами: баги вроде есть, но не у всех.

Вычисления и память: что не так с аллокацией

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

Частые и крупные аллокации

Каждый раз, когда создаётся новый объект, память выделяется из кучи. При интенсивной работе (например, при парсинге JSON или обработке больших структур) это может происходить слишком часто, и тогда запускается сборщик мусора (GC).

Сборка мусора — это не бесплатная операция: она останавливает выполнение программы. Частые GC-паузы создают «плавающую» производительность, когда всё работает быстро, но время от времени подвисает даже на секунду.

GC-паузы

Автоматическое управление памятью — благо, но оно же и ловушка. В языках вроде Go, Java или Python невозможно точно контролировать, когда сработает сборщик. Даже задержка в 50 миллисекунд может ощутимо ударить по RPS или нарушить real-time обработку.

Некоторые компании придумывают обходные пути. Так, в Twitch использовали технику memory ballast для Go-приложений, чтобы стабилизировать поведение GC и избежать всплесков пауз.

Синхронные и блокирующие операции

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

Классический пример — однопоточный web-сервер, который просто ждёт ответ от другой системы. Или библиотека, использующая mutex.Lock() в горячем участке, из-за чего десятки горутин встают в очередь.

Ограниченные ресурсы и очереди

Даже в многопоточном приложении можно легко создать узкое место. Например:

• доступ к объекту синхронизирован через mutex или RW-lock;

• пул соединений имеет жёсткий лимит;

• очередь задач не может масштабироваться под нагрузку.

В таких случаях нагрузка растёт, а пропускная способность — нет. Всё упирается в искусственное ограничение, введённое «на всякий случай».

Однопоточные горячие участки

Даже в многопоточной архитектуре может оказаться, что 80% времени тратится в одном месте, которое не масштабируется — например, в процессе сериализации, расчёта или шифрования. Иногда этот участок реализован однопоточно (особенно в Node.js, Python или старом Go-коде) и становится главным тормозом системы. Под высокой нагрузкой это становится особенно заметно.

Что делать: подход к поиску и устранению bottlenecks

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

Шаг 1. Зафиксировать симптомы и контекст

Важно понять, что именно «тормозит» и в каких условиях. Типовые вопросы:

• Когда проявляется проблема: под нагрузкой, в пиковые часы, у конкретных пользователей?
• Что именно работает медленно: API, отчёты, фоновая обработка?
• Как это влияет на систему: задержки, таймауты, ошибки?

Пример: пользователи жалуются, что отчёты стали строиться дольше. Вчера — 5 секунд, сегодня — 20.

Шаг 2. Проверить очевидные метрики

Начинаем с того, что уже доступно в мониторинге:

• латентность API (p50, p95, p99);
• загрузка CPU, использование памяти и диска;
• глубина очередей и backlog;
• паузы GC;
• кэш hit/miss ratio.

Если латентность растёт, а CPU загружен на 20%, это может указывать на проблемы в синхронных вызовах, аллокации или неэффективной работе кэша.

Шаг 3. Сузить область через трейсинг и логирование

Чтобы выяснить, не «тормозит» ли другой сервис, используйте распределённый трейсинг (Jaeger, OpenTelemetry, Sentry Performance) или логирование таймингов внутри запроса.

Пример (Go, обёртка для http.RoundTripper):

Так можно увидеть, что, например, сторонний сервис отвечает 3 секунды, или Redis стал отдавать ответ за 300 мс вместо обычных 3 мс.

Шаг 4. Воспроизвести нагрузку

Если проблема зависит от объёма данных, воспроизведите реальный сценарий или нагрузку:

• используйте инструменты вроде k6, Locust, Artillery;
• проверьте реальные условия (например, отчёт за 30 дней, а не за 3).

Если латентность растёт нелинейно, это может быть признаком N+1-запросов, неоптимального SQL или проблем с аллокацией.

Шаг 5. Подтвердить проблему профилированием

Если есть подозрение на перегрузку CPU или утечку памяти, используйте профилировщики:

• Go — pprof;

• Java — JFR, VisualVM;

• Node.js — clinic.js, chrome://inspect.

Пример (Go, локальный pprof):

Профиль покажет, где тратится CPU, как распределяются аллокации, как часто запускается GC и в каком коде.

Шаг 6. Оптимизировать, перепроверить и зафиксировать

После подтверждения проблемы можно переходить к исправлениям:

• кэшировать внешний вызов;

• заменить тяжёлую сериализацию (например, на easyjson в Go);

• убрать блокирующую операцию;

• перейти на batch-обработку.

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

Итоги: как не попасть в архитектурную ловушку

Bottleneck’и возникают даже в самых технологичных проектах. Это не всегда следствие «плохого кода» — куда чаще они появляются из-за архитектурных просчётов: недооценили нагрузку, не предусмотрели масштабирование, сделали ставку на неправильное решение.

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

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

Думайте об объёмах и росте

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

Настраивайте метрики с первого дня

Без данных вы работаете вслепую. Любой анализ будет превращаться в гадание: виноват код или Redis, где тормозит — непонятно. С самого начала следите за ключевыми метриками: latency, очереди, GC, hit/miss в кэше, ошибки. Это не «доработка потом», а часть живой системы.

Проектируйте с учётом деградации

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

Не усложняйте архитектуру без повода

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

Bottleneck’и — это не баг, а симптом. И хороший архитектор — это не тот, кто устраняет тормоза, а тот, кто их не допускает.

Больше боли коддеров — тут.

Мы в Smart Engines занимаемся разработкой софта для распознавания самых разных документов — начиная от паспорта РФ, свидетельства о рождении и заканчивая первичкой вроде УПД или ТОРГ-12, а также банковских карт, номеров телефона и баркодов. Наши библиотеки написаны полностью с нуля (на плюсах), мы уделяем огромное внимание скорости алгоритмов, нейросетям (новым архитектурам, размеру и правильному применению) и оптимизации, за счет чего наш софт портируется на любые архитектуры и может быть использован на любой платформе.

Сегодня продолжим знакомиться через рассказ о нашем софте, на очереди вторая библиотека — Smart Document Engine и ее возможности работы с жесткими и гибкими формами.

Гибкие и жесткие формы

Вначале про сами формы: они могут быть «жесткими» и «гибкими». Жёсткие формы подразумевают, что положение всех объектов на форме может быть задано прямо в виде координат на шаблоне. Самое простое определение для жестких форм — они совпадают «на просвет». Возьмите пару листов А4 с распечатанной жёсткой формой, наложите друг на друга, и места расположения полей точно совпадут. Гибкие формы устроены гораздо сложнее, но все равно имеют свою характерную структуру и топологию.

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

Кстати, иногда вместо распознавания текста целиком достаточно просто ответить на вопрос «есть ли текст в выбранной области, и, если есть, то где»

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

Также существуют общие для подобных форм проблемы. Правильно интерпретировать галочки в чекбоксах, найти штрихкоды, правильно разметить табличные данные — есть куча проблем, каждая из которых имеет своё state-of-the-art решение и набор алгоритмов, над которыми нужно ломать голову.

Почему не LLM, хотя казалось бы

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

Однако чем сложнее нейросеть, чем глубже степень обучения — тем выше шанс, что она начнёт бредить. Мы все какое-то время назад смеялись над шести-семипалыми героями очередных сгенерированных изображений, сейчас посмеиваемся над сгенерированными сетями текстами с описанием несуществующих фильмов и книг, но смешно ли будет нам (а особенно бухгалтерии), если нейросеть начнет галлюцинировать при распознавании платёжных реквизитов или суммы НДС? И чем выше степень развития сетей — тем менее заметными будут становиться такие ошибки.

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

Вернёмся к библиотеке Smart Document Engine. Как уже говорилось выше, гибкие формы на то и гибкие, что исключительно геометрией на них не обойдёшься — вопрос местонахождения полей решается «на лету». На процесс взаимодействия с библиотекой это влияет в самом конце, на моменте работы с результатом. Перейдем к знакомству с интерфейсом на примере всё того же встраивания в андроид.

Встраивание

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

Логическая и физическая части документа разбираются отдельно, так как в некоторых случаях геометрия вообще не нужна (если результат распознавания документа дальше идёт в базу данных):

Как правило, результат распознавания представляют в виде json-объекта, но для наглядности лучше всего пользоваться html — особенно в случае, когда логические и физические поля имеют больше одного соответствия. Вот простенький генератор html на основе документа:

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

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

На этом мы не заканчиваем, ждите новых статей!

Откуда возник CORS

Всё началось в начале 2000-х, когда веб-приложения становились всё сложнее, а разработчики чаще нуждались в данных с других доменов. Однако браузеры строго придерживались политики одного источника (Same-Origin Policy, SOP), запрещавшей доступ к сторонним ресурсам. Эта политика появилась ещё в 1995 году в Netscape Navigator 2.0 и была призвана защитить пользователей от атак вроде XSS. Проблема в том, что SOP блокировала не только вредоносные, но и вполне легитимные запросы, например, к внешним API. Разработчики пытались обойти ограничения с помощью JSONP или iframe, но такие решения были небезопасными и нестабильными.

В 2005 году инженер Мэтт Ошри предложил идею более надёжного и безопасного механизма, который в дальнейшем стал основой CORS. А в 2008-м Анн ван Кестерен подготовила черновик спецификации для W3C. В 2014 году CORS официально вошёл в стандарт Fetch API и с тех пор стал ключевым элементом работы с кросс-доменными запросами. Он помогает контролировать доступ к ресурсам, сохраняя баланс между открытостью веба и безопасностью пользователей.

Как устроен CORS

CORS работает как диалог между браузером и сервером, основанный на HTTP-заголовках. Когда фронтенд-приложение (например, на сайте frontend.com) запрашивает данные с другого домена (api.com), браузер автоматически добавляет к запросу заголовок Origin: https://frontend.com. Этот заголовок сообщает серверу, откуда пришёл запрос.

Сервер в ответ решает, разрешать ли доступ. Если он включает в ответ заголовок Access-Control-Allow-Origin и указывает там адрес запроса (например, https://frontend.com) или символ * (разрешение для всех доменов), то браузер пропускает ответ. Если такого заголовка нет или значение не совпадает, браузер блокирует ответ — даже если сервер технически его отправил.

Для так называемых «сложных» запросов, например, с методом POST или нестандартными заголовками, браузер сначала отправляет предварительный (OPTIONS) запрос, чтобы уточнить у сервера, допустим ли основной. В ответе сервер указывает, какие методы (Access-Control-Allow-Methods) и заголовки (Access-Control-Allow-Headers) разрешены.

Пример ответа сервера с разрешением:

Топ-7 самых частых ошибок в CORS и как их исправить

Для того чтобы определить оптимальные методы работы, лучше учиться на ошибках. Хорошая новость в том, что почти все CORS-ошибки легко понять и исправить — если знать, где искать. Ниже собрали 7 самых распространённых ошибок CORS, с которыми сталкиваются разработчики, и рассказали, как можно с ними справиться без боли и паники.

Нет заголовка Access-Control-Allow-Origin

Сообщение об ошибке:

"No ‘Access-Control-Allow-Origin’ header is present on the requested resource"

Когда ваш JavaScript-код пытается получить данные с другого домена, браузер ожидает, что в ответе будет заголовок Access-Control-Allow-Origin. Если его нет — браузер блокирует ответ, считая его небезопасным.

Решение 1: Настроить сервер на разрешение CORS

Если вы контролируете сервер, добавьте в ответ заголовок:

Access-Control-Allow-Origin: *

* — разрешение запросов с любого домена

Но для безопасности лучше указать конкретный домен:

Access-Control-Allow-Origin: http://example.com

Решение 2: middleware CORS в Express.js

Если вы используете Node.js с Express, добавьте:

Браузер блокирует preflight-запросы (OPTIONS)

Сообщение об ошибке:

"CORS policy preflight request did not succeed" или что-то похожее.

Иногда перед настоящим запросом браузер сначала отправляет preflight-запрос методом OPTIONS, чтобы проверить, разрешен ли основной запрос. Это происходит, если:

• Метод запроса не GET или POST (например, PUT, DELETE).

• В заголовках есть что-то нестандартное (например, Authorization или Content-Type: application/json).

Если сервер не умеет обрабатывать OPTIONS — все ломается.

Решение: Обработать OPTIONS-запросы на сервере

Пример для Express.js:

app.options('*', cors()); // Разрешаем preflight-запросы

Или настройка CORS с поддержкой OPTIONS:

Запросы с учётом сессий (credentials) блокируются

Сообщение об ошибке:

"The value of the ‘Access-Control-Allow-Origin’ header in the response must not be '*' when the request's credentials mode is 'include'"

Вы отправляете запрос с куками или авторизацией (credentials: 'include'), но сервер разрешает доступ всем (Access-Control-Allow-Origin: *). Это запрещено — нельзя слать credentials, если разрешено всем.

Решение: Указать конкретный домен и разрешить credentials

На сервере также добавьте:

Access-Control-Allow-Credentials: true

Смешанные протоколы — HTTP и HTTPS

Сообщение об ошибке:

"Mixed content: The page at 'https://...' was loaded over HTTPS, but requested an insecure resource 'http://...'."

Ваш сайт работает по HTTPS, а API — по HTTP. Браузеры считают, что это опасно, и банально блокируют запросы.

Решение:

• Переведите API на HTTPS.
• Обновите все ссылки с http:// на https://.

• Если работаете локально и сервер только HTTP, используйте ngrok, чтобы создать HTTPS-туннель.

CORS блокирует редиректы

Сообщение об ошибке:

"Redirect from '...api' to '...login' has been blocked by CORS policy."

API делает редирект, но в ответе на редирект нет CORS-заголовков. Браузер не знает, можно ли доверять редиректу, и блокирует.

Решение:

Убедитесь, что редирект тоже возвращает правильные заголовки:

Access-Control-Allow-Origin: http://example.com

Если используете fetch, добавьте:

Неверно настроен Access-Control-Allow-Headers

Сообщение об ошибке:

"Request header field <X> is not allowed by Access-Control-Allow-Headers"

Ваш запрос содержит нестандартный заголовок (например, Authorization), а сервер не пропускает его.

Решение:

На сервере укажите, какие заголовки разрешены:

Метод запроса запрещён сервером

Сообщение об ошибке:

"Method PUT is not allowed by Access-Control-Allow-Methods"

Вы отправляете запрос методом PUT, PATCH, DELETE, а сервер разрешает только GET и POST.

Решение:

На сервере явно разрешите нужные методы:

Так случалось, пока не появились инструменты вроде TanStack Query и не родились «обертки», которые уменьшают объемы рутины. Как перестать тонуть в запросах на разработку API и начать дышать свободно, рассказывает Дмитрий Скляр, старший разработчик компании Axenix.

API: нервная система цифрового мира

В современном ИТ-ландшафте API давно перестал быть просто техническим термином. Теперь он — один из столпов, на котором держится цифровая цивилизация.

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

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

Но настоящую революцию API совершил в бизнесе, создав целые экосистемы цифровых услуг. Такие компании, как Stripe, Twilio или Plaid построили свои империи именно на API, предоставляя другим разработчикам готовые «кирпичики» для создания финансовых, коммуникационных или аналитических сервисов.

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

Боль, которую никто не замечает

Но не все так просто и далеко не так радужно.

Да, формально API — это универсальный мост, например, между фронтендом и бэкендом. На практике же он часто напоминает шаткую подвесную конструкцию: данные приходят в разном формате, документация устаревает еще до релиза, а поля user_name и username существуют одновременно просто потому, что «исторически сложилось».

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

Сюда можно добавить также сложность поддержки — API меняется, код устаревает.

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

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

Спасение — в системе

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

Тогда и родилась идея фабрики API — слоя абстракции, который скрывает рутину. Для этого мы привлекли возможности TanStack Query, семейство библиотек для управления состоянием данных (data fetching) в клиентских приложениях. Помимо TanStack Query (ранее React Query), к этому классу инструментов также относятся: RTK Query (из Redux Toolkit), Apollo Client (для GraphQL) и SWR.

Их общая философия: «делать рутину невидимой для разработчика». Рассмотрим Конкретные проблемы и их решения.

Однотипные хуки для каждого запроса

В большинстве проектов без дополнительной абстракции каждый хук под API-запрос пишется вручную. Меняется только URL и параметры, а структура остаётся одинаковой: queryKey, queryFn, опции запроса. Это быстро приводит к копипасту, дублированию логики и усложнению поддержки.

Например, для каждого ресурса вроде пользователей, продуктов, заказов и т.д. приходится повторять одну и ту же конструкцию. Если нужно изменить поведение запроса (например, добавить retry или staleTime), правки необходимо делать в десятках мест.

Решение: Универсальная обёртка над хуками TanStack Query

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

Такой подход:

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

Хрупкость при изменении API

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

Решение: Централизованная трансформация данных + class-transformer.

С помощью class-transformer можно объявить классы сущностей и задать правила преобразования один раз.

Плюсы:

• Все данные автоматически приходят в нужном виде;
• Компоненты работают с гарантированно типизированными данными;
• Один источник правды: при изменении API – правим только Entity-класс;
• Удобно масштабируется, особенно если API большое и сложное.

«Мусор» в данных и отчётах

Решение: Валидация данных при трансформации (например, через class-validator); автоматическая синхронизация кеша (актуальные данные во всём приложении).

Почему это лучше ручного подхода? Смотрите: строк кода на 1 endpoint при ручном управлении потребуется 30+, а с фабрикой — 5-10. Времени для добавления нового поля — 1 час вручную, с фабрикой — 5 минут. Количество мест для правки при изменении API — вручную их много, с фабрикой — лишь одно.

Реальный кейс: в проекте с 50+ endpoint’ами переход на фабрику сократил код на 70%. Разработчики перестают быть «переводчиками» между API и интерфейсами сервисов и приложений, а сосредотачиваются на бизнес-логике. Как сказал один тимлид: «Теперь мы не фиксим баги данных, а делаем фичи, которые нравятся пользователям».

Еще пример: вместо пяти отдельных хуков для CRUD-операций фабрика дает одну функцию createApi(). Вместо ручного парсинга — автоматическую трансформацию данных через class-transformer. А главное — единые правила игры для всего проекта.

Как это работает? Представьте, что вы говорите системе: «Вот endpoint для товаров, вот их модель данных, вот правила валидации» — а все остальное она делает за вас. Хотите получить товар по ID? Пишете useGetByIDQuery. Нужно обновить? — useUpdatetMutation. И никакого шаманства с ручным описанием каждого хука.

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

Как договориться и не сойти с ума

Проблема в том, что без четкого контракта, набора правил и подходов фронтенд- и бэкенд-разработчики живут в параллельных реальностях. Один думает, что данные придут в camelCase, другой шлет их в snake_case. Один ожидает массив, другой неожиданно подсовывает null. Итог — бесконечные баги, исправления «на живую» и испорченные нервы.

Решение? Четкий контракт. Простой, прозрачный, однозначный. В нем должны быть:

1. Единые правила именования — если бэкенд отдает snake_case, фронтенд не должен гадать, будут ли остальные поля в camelCase, или, например, если в одной модели данных full_name , в другой не будет fullname и так далее.
2. Единый формат запросов и ответов.
3. Договоренности о структуре URL, формате данных и кодах ошибок.
4. Строгая типизация — TypeScript-интерфейсы, которые знают, какие поля обязательны, а какие могут отсутствовать.
5. Документация, которая не врет — если Swagger говорит, что поле email есть, оно должно быть. Всегда.

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

Но, как правило, контракт сделать тяжело. Каждый видит REST по-своему: разные URL, форматы данных, обработка ошибок. Модели данных непоследовательны — поля то есть, то их нет, вложенность меняется. Документации либо нет, либо она устарела, так что API изучаем методом проб и ошибок. От такого надо отказываться сразу и стараться договорится на берегу.

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

Что получаем в итоге?

Когда контракт есть, а обертка API готова, магия начинает работать:

• Простота использования: вместо десятков хуков — единая фабрика createApi(). Меньше boilerplate-кода.
• Мощные возможности: данные приходят уже в нужном формате без ручных проверок. Кэш, инвалидация и оптимизации — TanStack Query делает за вас всю грязную работу.
• Новички влетают в проект: больше не нужно объяснять, почему useGetEntity в одном компоненте работает не так, как в другом.
• Активное сообщество: TanStack Query — тысячи разработчиков, готовых ответить на вопросы. Здесь можно найти примеры для любых кейсов: от интеграции с Next.js до кастомного кеширования.
• Нет ограничений по использованию: TanStack Query — не только для React, есть версии для Vue, Svelte и даже Solid.js. Также работает с любым API — REST, GraphQL, WebSockets.
• Работа с SSR без боли: готовая интеграция с Next.js, Remix и другими фреймворками. При этом данные, полученные на сервере, автоматически передаются на клиент. TanStack Query синхронизирует серверный и клиентский рендеринг.

Но есть и ложка дегтя. Отладка усложняется, если что-то сломается внутри обертки — придётся копать глубже. Возникает зависимость от библиотек: class-transformer, axios и сам TanStack Query становятся обязательными.

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

Сравнительные примеры

GET /products — Список продуктов

GET /products/:id — Один продукт по id

POST /products — Создание продукта

PUT /products/:id — Обновление продукта по id

DELETE /products/:id — Удаление продукта по id

Как это выглядит в обертке

Все свойства и возвращаемые хуки и конфиги из фабрики:

Пример использования в компонентах:

Использование конфигов:

Для сравнения с классическим решением:

Когда стоит переходить на обертку?

Не каждый проект нуждается в таком подходе к API. Если у вас два-три endpoint’а и они никогда не меняются — возможно, обертка будет избыточной. Но представьте стартап, где каждый месяц добавляются новые сущности: сначала товары, потом отзывы, потом промокоды, рекомендации, аналитика.

Вот где система раскрывается на полную! Новая сущность? Пять минут на добавление — и готовы все CRUD-операции. Изменился бэкенд? Правим в одном месте — и все работает. Пришел новый разработчик? Он не тратит неделю на изучение особенностей API.

Правда, если бэкенд живет в мире хаотичных endpoint’ов (например, GET /fetch_items, но DELETE /removeProduct), обертка не спасет.

Но как навести порядок?

Главный секрет — общаться. Не ждать, пока API сломается, а сразу договориться:

• Какие будут названия полей (created_at vs createdAt);
• Как структурированы ошибки;
• Когда и как можно менять контракт.

Как сказал один разработчик: «фронтенд и бэкенд — как соседи по коммуналке. Можно ругаться из-за бардака на кухне, но лучше сесть и написать правила совместного проживания».

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

Первые две части лежат здесь: рабочее место/облако и Fedora Core/mise.

Начало проекта и утилита make

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

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

• Первая задача — отслеживание зависимостей одних файлов от других, например, при изменении сервиса пересобрать только соответствующий контейнер.
• Вторая задача, легко реализуемая через make — сборка в один файл много команд или скриптов, чтобы удобно их организовать. Как правило, сборка образа, его загрузка в репо, удаление временных файлов и прочее делается несколькими рутинными командами. Точно так же можно поместить в Makefile команды запуска сервисов и тестирование приложения локально.
• Если эти этапы прошли успешно, можно выполнить коммит кода в репо проекта, сделать деплой в dev или stage environment. В github actions это называется jobs и steps. В make такая группа команд называется целью, она указывается параметром при вызове.

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

Разбираемся на практике

Возьмём для примера проект с прокси сервером traefik и бэкендом на golang из репозитария awesome-pods. Этот репо задуман как форк замечательного проекта awesome-compose, в котором собраны конфиги docker compose для 41 самого популярного сервиса. Я же пытаюсь сделать что-то похожее для манифестов podman. Приглашаю к сотрудничеству начинающих девопс — сможете поучаствовать в открытом проекте, заработать почётные гитхаб-бейджи и улучшить своё резюме. Подробнее — здесь.

Мой проект в интересном положении: сделаны манифесты для нескольких сервисов, опробованы описанные выше подходы для миграции конфигов compose.yaml в манифесты kube.yaml. Но захотелось большего: а почему бы не сделать сразу пайплайны для тестирования, коммита в апстрим, деплоя и прочее. Зайдём в каталог traefik-golang и создадим пару мейк-файлов. Для начала сделаем всё это локально, начнём с make_compose:

Этот файл уже в истории, равно как и соответствующий README.md, привожу его для примера. Так как я делаю конфиги сразу для двух платформ — docker и podman, для включения соответствующего Makefile’а нужно сделать линк на него: ln -s make_compose Makefile.

Отлично, основную идею обсудили, идём дальше. В docker’е есть замечательная опция context, позволяющая работать с любыми серверами, где настроен доступ. В нашем случае список контекстов выглядит так:

Здесь я использовал простейший хак — сделал копию дефолтного контекста с именем localhost. Теперь мы можем сделать наш пайплайн способным на удалённый деплой. Достаточно прописать в /etc/hosts имя и адрес нашего dev сервера. Вот новая версия make_compose:

Поясню немного подробнее.

• Самая первая строка — стандартное объявление списка целей.
• Строки 2-4 задают дефолтное значение переменной, если оно не задано в текущем env.
• В хелп — строки 5-10 — добавлено предупреждение о текущем контексте, он задаётся в глобальной переменной, например, export DKR_CONTEXT=localhost для локального контекста.
• Также добавлена цель commit в репо — строки 17-21 — после выполнения цели test.
• Test — строки 31-32 — в свою очередь, выполняется для текущего контекста, см. хак #1. Имя контекста должно совпадать с именем хоста нашего dev-сервера.
• Добавлена также цель clean: очистка старых образов с локальном репо,и зависимости в цель up. Здесь убеждаемся, что образ пересобран и старые контейнеры остановлены.

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

В строке 5 определяются зависимости: target back соберёт исполняемый файл только в том случае, если код main.go или сам make_pods новее уже собранного бинарника.

Строка 6 удаляет backend контейнер с едва заметным знаком минус -, чтобы игнорировать ошибку, если контейнер с именем backend не существует.

Строки 7–10 создают контейнер с именем backend из пустого (scratch) контейнера — команды buildah следуют обычным командам Dockerfile, но в нижнем регистре: FROM -> from, COPY -> copy, RUN -> run, ENTRYPOINT -> config –entrypoint и т. д. Здесь вы видите основное отличие от традиционного docker buildx подхода — вы работаете в двух контекстах одновременно: в локальном контексте, используя установленный компилятор go, и в контексте контейнера, копируя файлы в/из контейнера, запуская команды внутри контейнера и т. д. Другая новая возможность buildah — вы можете собирать образ шаг за шагом, то есть отлаживать процесс сборки.

Строка 8 компилирует main.go в исполняемый файл back с соответствующими флагами.

Строка 11 создаёт из контейнера новый образ (image) с тегом backend:latest.

Цель up — строка 16 — зависит от цели down — строка 14, — то есть она сначала останавливает pod и удаляет контейнеры, если они всё ещё запущены, затем запускает новый под.

Цель down в строке 15 подставляет глобальную переменную $XDG_RUNTIME_DIR из env пользователя в kube.yaml, используемый далее в podman kube командах, принимая новый манифест со стандартного ввода. Это также специфика podman — он работает полностью в пространстве пользователя, контейнеры взаимодействуют через собственный podman.sock. Таким образом, делаем пайплайн независимым от UID.

В подмане есть фунциональность наподобие docker context, под другим именем, в подкоманде system connection:

Первым в списке стоит настроенная в прошлой статье ВМ. Пока искал правильные опции для создания коннекшена (aka контекст в докере), столкнулся с подсказкой от подмана — «создайте сначала машину», а именно:

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

Во-вторых, это полноценная ВМ fedora coreos:

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

Но прежде нам понадобится ещё один хак #2. Если в случае докера переключение контекста можно было сделать любой переменной, то для подмана между локальным соединением через сокет и удалённым, через uri:ssh, имя переменной фиксировано CONTAINER_HOST. Вот как выглядит пайплайн make_pods.v1, настроенный и для локальной сборки, и для деплоя в наш дев-сервер:

По большей части цели мейкфайла остались теми же, но для удалённого деплоя настраиваем переменную export CONTAINER_HOST=ssh://dev@fc42dev:22/run/user/1001/podman/podman.sock — берём её из коннекшена, она служит переключателем между локальным и удалённым контекстом. Для локального контекста эту переменную надо удалить: unset CONTAINER_HOST. Команды в строках 19, 21 и 23 — это обычные команды шелла, они также меняются на локальное либо удалённое исполнение, переопределяются на основе этой же переменной CONTAINER_HOST.

Как заметил внимательный читатель, в цели back исчезла сборка контейнера утилитой buildah. Как и для docker compose, используется возможность самого подмана создавать образы на основе Containerfile, он же Dockerfile, эти названия синонимичны. Это намёк: пора отвыкать от слова докер, контейнеры уже давно стали основой облачных вычислений, для них созданы сотни приложений, например, CNCF и общепризнанные стандарты.

Принципиальный вопрос о контейнерах

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

Основная проблема сборки образа внутри контейнера — неэффективное использование кэша. Да, появились возможности как-то сохранять объемные загрузки внешних библиотек, модулей: это опции --mount=type=cache для некоторых языков. Но, во-первых, эти возможности используются далеко не всегда. Во-вторых, опции для кэширования отличаются в podman и buildah, см. podman-build(1), придётся делать отдельный Containerfile. В-третьих, эффект от такого кэширования минимален. Предлагаю замерить время сборки, сделав ещё одну, третью версию пайплайна. Сначала соберём команды для buildah в отдельный файл:

и поправим пару строк в пайплайне:

Уточню условия нашего эксперимента — мы настроили одинаковую среду разработки с помощью утилиты mise (предыдущая статья) на нашем дев-сервере и у каждого из разрабов команды. Репозитарий git использует этот же дев-сервер, доступ к репо и серверу по ключу, парольный доступ закрыт. Пайплайны настроены как для локальной сборки, так и на дев-сервере. Перед запуском 3-й версии пайплайна на дев-сервере нужно сделать коммит изменений в репо — buildah не знает о коннекшенах, работает с кодом в текущем каталоге (строка 1): после логина на сервер переключается в корень проекта. Предварительно выкачиваем образ компилятора go для сборки в контейнере — это вполне честно, мы же выкачали и настроили компилятор golang заранее. Замеряем:

Мы получили 10+-кратный выигрыш по времени сборки образа для подмана. Абсолютные времена не важны, также не влияет, запускали мы сборку локально или на дев-сервере — мы сравниваем только билд в контейнере и в настроенном локальном окружении. Третье измеренное время — сборка в Docker. Он умеет собирать только в контейнере, для него настроили кэширование в Containerfile:

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

Ещё замечание: конечно, образы, собираемые buildah, совместимы с Docker, их можно использовать в конфигах compose.yaml. Но для этого надо настроить репозиторий образов и сначала загрузить образ в него. Локальные репозитории отличаются: Docker использует общий репо для всех пользователей — Docker Root Dir: /var/lib/docker, а в подмане всё хранится в домашнем каталоге пользователя — graphRoot: /home/$USER/.local/share/containers/storage.

Как я предположил в самом начале, мы попробовали вариант с гипотетической идеальной командой разрабов, работающей в Линукс и умеющей в make. А как быть обычному девопсу с разношерстой командой, где кто-то сидит на Винде, а кто-то ни за что не откажется от привычного Макбука на M4? Есть вариант и для этого случая. Пусть они пишут код и тестируют его как им нравится, а в нашем репо на дев-сервере мы сделаем хак #3, а именно git hook и bare репозиторий — githooks(5), выполняющий наши цели сборки и старта приложения при коммите в репо.

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

1. Заходим под юзером dev на сервер, создадим пустой каталог, например, mkdir -pv ~/bare/t0. Это станет новым GIT_DIR, зайдём в него и выполним cd ~/bare/t0;git init --bare.
2. Видим, что файлы, обычно спрятанные в каталоге .git, лежат прямо в корне. Сделаем дополнительно каталог для логов mkdir logs. Переходим в каталог hooks и создаём файл, где укажем команды выполнения при каждом изменении в репо.

Закомментированные строки 3, 8, 9 полезны при отладке пайплайна. Строки 4 и 5 задают, что есть, собственно, репозиторий, переменная GIT_DIR и переменная WORK_TREE (куда будут записываться файлы проекта). В цикле от строки 6 до 14 читаются и обрабатываются три переменные, с которыми гит вызывает этот хук. Строка 11 принимает все изменения в репо и обновляет WORK_TREE — всё то, что гит обычно делает в общем каталоге, как видим, в bare репо они разные. Далее, в 12 строим имя лога и строка 13 — собственно, пайплайн.

1. Идём в каталог, где расположен репо проекта. Без страха и сожаления удаляем старый и создаём новый под тем же именем: cd ~/src;rm -rf traefik-golang;mkdir traefik-golang.
2. Завершаем сессию на дев-сервере, возвращаемся на рабочий комп и заходим в репо проекта. Конечно, репо цел, клоны репо не так просто уничтожить, пока есть хотя бы одна копия. Теперь смотрим старые настройки git remote -v и удаляем их git remote remove fc42dev в моём случае. Создаём новый remote, указывая новый гит bare репо: git remote add bare.t0 dev@fc42dev:~/bare/t0. Это также нужно сделать всем разрабам в их локальных копиях.
3. Проверяем результат. Возможно, нужно сделать новый комит и push в новый remote. Стоит посмотреть подробнее, как изменился репо проекта на сервере: проверить логи в ~/bare/t0/logs, сравнить конфиги обычного репо проекта и на сервере, проверить, какие команды перестали работать в серверном репо. Например, в WORK_TREE не работают команды гит status; branch; commit; log. То есть наш хак #3 с git --bare не только позволил делать деплой на сервере, но также защитил репо от локальных изменений, а серверный репо всегда в чистоте и порядке. Можно редактировать код, но закомитить его только через обычный репо. Изменения на сервере удалятся после любого коммита.

Надеюсь, мне удалось показать, что пайплайны можно делать на основе древней забытой утилиты make. В следующей статье разберём, как можно добавить в наш скромный дев-сервер нечто похожее на монстров гит-сервисов, Gitlab и Github, создавать пайплайны, совместимые с github Actions, предоставить команде разрабов привычный интерфейс репо в браузере.

Начало истории

Это был просто криптоконвертер, который работал так:

REST API CoinGecko — раз в 10 минут обновлял курс. Кэш в JSON — чтобы не дудосить API. Теперь я решил добавить алерты.

Так как мой мой бот в дальнейшем будет обрастать всё новыми и новыми функциями, я решил разделять их на отдельные файлы.

Чтобы не приходилось постоянно отправлять запросы, реализовал алерты через Websocket binance.

Сделал сохранение настроек в database.json.

Я реально думал что это будет просто, ошибся:

• При деплое выдало Sintaxis Error , хотя на компе всё было нормально;

• Сохранение алертов пропадало после конвертации;

• Алерты дико спамили.

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

Сначала думал, что дело в кодировке и стоит по дефолту UTF-8 BOM. Но нет. Решил: сервер не видит, что скобка открытая в этой строке закрывается ниже. Разделил код:

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

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

Datetime ломал JSON — нельзя просто так сериализовать datetime.now().

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

И добавил преобразование datetime в str

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

Старый скрпит не хочет уступать без боя. Это конфликт ботов.

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

sudo pkill -f “python.*bot.py” && sleep 2

kill -9 <PID>

pkill -f bot.py

Но старый бот так и не умирает. А через некоторое время сам по себе перестает работать. Я пока не понял эту аномалию. Возможно, после команды sudo systemctl reload надо просто попить чаю и дать время сервису нормально перезагрузиться.

Хорошо, бота мы убили. Нового запустили. Все кнопки работают. Включили алерты на ETH и стали ждать…

И тут началось…

Когда Эфириум подскачил на 7%, бот сошёл с ума, начал материться и спамить при малейшем сдвиге курса.

Было решено игнорировать мелкие колебания курса, установить минимальный порог реагирования 5% и высылать алерт не чаще чем 5 минут от предыдущего:

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

Со скриптом можете ознакомится здесь.

P.S. Пишите комментарии, предлагайте свои идеи. Деконструктивная и агрессивная критика приветствуется!))

В статье мы разберёмся, как запустить кодген на основе OpenApi схемы для веб-приложения на стэке React + redux-toolkit.

Для справки: контракт — соглашение о формате данных между клиентом и сервером

Какие проблемы решает кодген?

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

В микро-сервисной архитектуре цена таких ошибок высока — оперативно доставить обновления многочисленным клиентам иногда бывает проблематично.

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

Синхронизация контрактов

При активной разработке бекенд постоянно обновляет контракты. Без кодгена все обновления на стороне фронтенда синхронизируются вручную.

Также на основе контрактов создаются побочные интерфейсы, например, для redux-слайсов и react-компонентов. Ошибка в основном контракте создает цепочку проблем со связанными типами и интерфейсами.

Сочетание кодген-контрактов и typescript-утилит для создания побочных интерфейсов делает доставку обновлений простой и безопасной.

Устранение дубликатов

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

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

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

Что понадобиться для кодгена?

Прежде чем запускать кодген нам нужно минимально настроить проект:

Подготовить схему

OpenAPI-схема в формате yaml:

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

Проверить валидность OpenAPI схемы можно на в swagger редакторе

Настроить Redux

Redux-клиент для API-запросов:

Redux-слайс для хранения данных из API-запроса:

Redux-хранилище с подключенным API-клиентом и редюсером:

Настроить кодген

Для кодгена возьмём официальную библиотеку от Redux — @rtk-query/codegen-openapi

Затем создадим файл настройками кодгена:

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

Если вам нужна гибкость, попробуйте использовать @openapitools/openapi-generator-cli с различными готовыми шаблонами или Orval от tanstack

Запуск кодгена

Для запуска добавим команду в package.json:

Далее заходим в корень проекта и запускаем команду:

На выходе должен получиться файл codegenApi.ts с содержимым:

Проверяем результат:

• Инджект кодген эндпойтов в baseApi;
• Системные типы Props Response Error;
• Контракт User;
• RTK-query хуки.

Совет: создание кодгена можно автоматизировать, например, сделать его отдельным этапом в CI/CD, который выполняется прямо перед билдом приложения.

Возможные проблемы

Необычные типы данных

При внедрении кодгена в проект на Kotlin я столкнулся с проблемой парсинга: кодген не мог распарсить тип данных LocalDateTime, который должен возвращать строку с датой в формате ISO. Вместо строки когден возвращал пустой объект.

LocalDateTime — это класс из Java-библиотеки java.time, который представляет дату и время без учёта временной зоны.

Данную проблему я решил с помощью кодмода:

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

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

Кодмоды отлично генерируются с помощью AI.

Плюсы и минусы кодгена

Плюсы:

• Генерируем API-слой всего приложения за секунды;
• Получаем автоматическое строгое создание интерфейсов и типов;
• Избавляемся от опечаток в URL и параметрах;
• Обнаруживаем проблемы с обратной совместимостью контрактов на ранних этапах сборки;
• Экономим время.

Минусы:

• Качество кодгена зависит от качества описания OpenAPI схемы;
• Если схема не генерируется в автоматическом режиме, актуальности OpenAPI схемы потребуется поддерживать вручную;
• Логику нестандартных запросов придётся описывать вручную.

Напоминание: API-слой сложного проекта невозможно покрыть кодогенерацией на 100% — это нормально. Будьте готовы при помощи методов enhanceEndpoints и injectEndpoints комбинировать когден-эндпойнты с эндпойнтам написанными вручную

Заключение

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

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

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

Неправильная настройка инфраструктуры в CI/CD пайплайне

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

Настройте окружение

Разные окружения (dev, staging, prod) часто имеют отличия в конфигурации (например, версии библиотек, лимиты ресурсов, настройки сетей). Например, переменные окружения, заданные для staging, перезаписываются в prod — зависимости ломаются.

• Используйте Infrastructure as Code (IaC) инструменты, такие как Terraform или Pulumi, для создания идентичных окружений.
• Храните конфигурации окружений в репозитории (например, в формате YAML или JSON) и применяйте их через CI/CD.
• Настройте переменные окружения через секреты (например, HashiCorp Vault, AWS Secrets Manager) и убедитесь, что они не перезаписываются случайно.

Разворачивайте по стратегии

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

• В Kubernetes используйте RollingUpdate с настройками maxSurge и maxUnavailable, чтобы новые поды стартовали постепенно, а старые были постоянно доступны.
• Настройте readinessProbe и livenessProbe, чтобы Kubernetes не направлял трафик на неготовые поды.
• Ответственно подходите к настройке стратегии и выбору количества реплик.
• Для Helm-чартов фиксируйте версии (helm dependency update, helm package) и используйте helm upgrade --atomic для автоматического отката при сбое.

Например, в манифесте Deployment можно указать:

Избегайте race conditions

Параллельные процессы в CI/CD (например, одновременная сборка и деплой) могут вызывать состояния гонки.

• Настройте блокировки (locks) в CI/CD, чтобы не было параллельных деплоев в одно окружение (например, через environments в GitLab CI).
• Используйте атомарные операции в Helm и Server Side Apply в kubectl.

Обрабатывайте ошибки

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

• Регулярно тестируйте пайплайн на staging-окружении, симулируйте реальные сценарии деплоя.
• Проверяйте доступность сервисов после деплоя с помощью health-check скриптов.

Новую проверку можно, например, добавить так:

curl --fail http://any-app.example.com/health

Нет изоляции переменных окружения и секретов

Представьте: в staging-окружении используются тестовые ключи, а в продакшене — боевые. Но из-за ошибки в CI/CD пайплайне или конфигурации staging берет продовые credentials. Как итог — тестовое удаление данных в песочнице стирает боевую базу. Или еще хуже: токены утекают из-за слабых прав доступа к Secret Manager, и вас могут спокойно взломать. Ниже рассказываем, как это пофиксить.

Разделяйте секреты по окружениям

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

• Храните секреты в Secret Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Kubernetes Secrets) с четким разделением по окружениям (например, пути secrets/staging/db, secrets/prod/db).
• Используйте префиксы или теги для идентификации окружения (например, STAGING_API_KEY, PROD_API_KEY).
• Настройте права доступа CD так, чтобы пайплайн мог подтягивать только секреты, которые относятся к текущему окружению.

Например, в Vault это настраивается так:

Не храните секреты в коде

Иначе утечка неизбежна.

• Уберите секреты из репозиториев и .env-файлов и используйте Secret Manager.
• Для Kubernetes используйте Secret-объекты или интеграцию с внешними менеджерами (например, External Secrets Operator).
• Проверяйте репозитории на утечки с помощью инструментов типа truffleHog или gitleaks.

Вот пример Kubernetes Secret:

Ограничивайте доступ

Это принцип Scoped Permissions — с помощью него можно снизить риски случайного или намеренного использования секретов.

• Используйте IAM-роли в облаке (например, AWS IAM Roles for Service Accounts) с минимальными правами.
  
• Ограничивайте доступ разработчиков к продовым секретам через RBAC или Vault-профили.

Вот AWS IAM-политика для staging:

Ротируйте ключи

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

• Настройте автоматическую ротацию ключей в Secret Manager (например, AWS Secrets Manager поддерживает ротацию через Lambda).
• После инцидента сразу же ротируйте скомпрометированные ключи и пересоздавайте секреты.
• Логируйте доступ к секретам для аудита (например, через Vault Audit Logs).

Неправильная настройка health-checks в Kubernetes или других оркестраторах

Неправильная настройка readinessProbe и livenessProbe в Kubernetes — это, можно сказать, классика. Вы обновляете сервис, поды запускаются, но сразу же помечаются как unhealthy. Причина — неправильный readinessProbe или livenessProbe. Например, путь /healthz больше не существует, или проверка уходит в таймаут из-за долгой инициализации. В результате: контейнеры бесконечно рестартуются, сервис недоступен, кластер в панике.

Разделяйте назначение проб

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

• Используйте разные endpoints для проб. Например, /health для readinessProbe (готовность сервиса) и /alive для livenessProbe (проверка зависаний).
• Настройте readinessProbe так, чтобы она возвращала 200 только после полной инициализации (например, подключения к базе).
• Для livenessProbe проверяйте минимальную работоспособность (например, ответ сервера без проверки внешних зависимостей).

Учитывай время инициализации

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

• Установите initialDelaySeconds с запасом, чтобы учитывать время прогрева (например, загрузку кэша или подключение к базе).
• Настройте timeoutSeconds и periodSeconds так, чтобы проба не завершалась слишком быстро, но и не крутилась вечно.
• Используйте failureThreshold для нескольких попыток перед пометкой пода как unhealthy.

Вот пример для сервиса с долгим стартом:

Добавьте grace period

Он дает сервису время корректно завершиться перед рестартом.

• Установите terminationGracePeriodSeconds в манифесте Deployment, чтобы под мог завершить запросы перед остановкой.
• Настройте preStop хук, если нужно выполнить действия перед завершением.

Тестируйте на staging

Проблемы с пробами часто всплывают только в проде, если staging не идентичен.

• Убедитесь, что staging-окружение повторяет прод по конфигурации и нагрузке.
• Добавьте автоматические тесты в CI/CD для проверки endpoints (/health, /alive) перед деплоем.
• Симулируйте реальные сценарии (например, медленный старт или сбой зависимостей) на staging.

В CI/CD можно добавить:

Неправильная работа с конфигурациями через Helm или Kustomize

Представьте: обновили Helm-чарт, но в values.yaml остались старые переменные, которые ломают новые настройки. Или Kustomize патчит не тот ресурс, и манифесты применяются с ошибками. В итоге: поды падают, сервисы недоступны, и никто не знает что делать. Рассказываем, что с этим делать.

Валидируйте Helm-чарты перед деплоем

Так можно найти ошибки до применения манифестов.

• Используйте helm template или helm install –dry-run для рендеринга манифестов и их проверки.
• Включите schema validation для values.yaml с помощью JSON Schema (поддерживается Helm v3.6+).
• Проверяйте манифесты через kubeval или kubectl apply –dry-run=server для подтверждения соответствия Kubernetes API.

Тестируйте Kustomize-конфигурации

Kustomize может патчить не то, что вы ожидали, если селекторы или структура неправильные.

• Прогоняйте kustomize build для генерации итоговых манифестов и проверяйте их перед деплоем.
• Используйте kubectl apply –dry-run=server -k . для валидации в кластере.
• Проверяйте селекторы патчей в kustomization.yaml на точность (например, name и namespace).

Управляйте версиями и структурой

Несогласованность версий чартов или манифестов приводит к неожиданным изменениям.

• Фиксируйте версии Helm-чартов в Chart.yaml и используйте точные теги (например, 1.2.3, а не latest).
• Храните values.yaml отдельно для каждого окружения (values-staging.yaml, values-prod.yaml).
• Для Kustomize используйте базовые манифесты и патчи, разделённые по окружениям (например, overlays/staging, overlays/prod).

Документируйте и мониторьте

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

• Ведите CHANGELOG.md для Helm-чартов и Kustomize патчей, описывая изменения в структуре и значениях.
• Логируйте команды деплоя (helm upgrade –debug, kubectl apply -k .) для отладки.
• Настройте мониторинг статуса подов через Prometheus, чтобы сразу видеть сбои из-за ошибок конфигурации.

Вот пример получения подробного лога helm:

Нет политики управления версиями артефактов

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

Используйте семантическое версионирование (semver) или уникальные теги

Так банально будет однозначность и отслеживаемость версий.

• Присваивайте образам теги по схеме semver (1.2.3), commit hash (abc1234) или временной метке (20250429-1345).
• Избегайте latest в продакшене — это бомба замедленного действия.
• В CI/CD автоматически генерируйте теги на основе версии приложения или Git commit.

Вот пример тег-образа:

docker build -t my-app:1.2.3 -t my-app:$(git rev-parse –short HEAD)

Фиксируйте версии в манифестах и пайплайнах

Immutable теги гарантируют, что деплой всегда использует ожидаемую версию.

• В Kubernetes манифестах указывайте точные теги вместо latest.
• Настройте CI/CD так, чтобы тег образа передавался в Helm или Kustomize как параметр.
• Используйте инструменты вроде helm upgrade с фиксированными версиями чартов.

Настройте retention policy для артефактов

Хранение старых образов позволяет откатиться к стабильной версии.

• В container registry (Docker Hub, AWS ECR, Harbor) настройте правила хранения, чтобы сохранять последние N версий или образы за последние X дней.
• Регулярно очищайте устаревшие артефакты, но сохраняйте критические версии (например, те, что в проде).
• Используйте теги для маркировки стабильных версий (например, prod-1.2.3).

Пример — AWS ECR lifecycle policу:

Автоматизируйте версионирование в CI/CD

• В CI/CD пайплайне генерируйте теги на основе Git тегов, commit hash или переменных окружения.
• Проверяйте, что образ с нужным тегом пушится в registry и используется в деплое.
• Добавьте шаг валидации манифестов, чтобы убедиться, что теги фиксированы.

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

Больше новостей — в нашем тг-канале «Представляешь»

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

Основные особенности

Простой интерфейс

Новый API будет включать минимальный набор классов для работы с JSON, включая:

• JsonValue — базовый интерфейс для всех JSON-значений;
• JsonObject — коллекция ключ-значение;
• JsonArray — упорядоченный список значений;
• JsonString — строковое значение;
• JsonNumber — числовое значение;
• JsonBoolean — логическое значение;
• JsonNull — пустое значение.

Вот как это будет выглядеть:

Пример использования

API будет поддерживать базовые операции, такие как разбор строк JSON и преобразование значений:

Со временем, по мере добавления новых возможностей для сопоставления паттернов (pattern matching) в Java, этот код станет еще более лаконичным.

Работа с числами

Поскольку JSON не различает целые и десятичные числа, новый API будет предлагать несколько способов работы с числами:

1. Получение строкового представления числа.
2. Преобразование строки в BigDecimal для точной работы с десятичными числами.
3. Преобразование в стандартные числовые типы Java (Long, Double, BigInteger) с автоматическим выбором подходящего типа.

Совместимость и производительность

Первая версия прототипа уже доступна в sandbox-репозитории OpenJDK.

Несмотря на раннюю стадию разработки, она успешно прошла большинство тестов из JSONTestSuite, за исключением случаев с дублирующимися ключами, которые намеренно запрещены для упрощения обработки JSON-объектов.

Дальнейшие шаги

Разработчики планируют оформить предложение по улучшению языка (JEP) для включения нового API в будущие версии JDK.

Это может быть обновление существующего JEP 198 (Light-Weight JSON API) или полностью новый документ.

Как работает database sharding

Database sharding (шардирование базы данных) — это техника горизонтального масштабирования, при которой большая база разделяется на несколько частей. Их называют шардами. Эти шарды распределяются по другим серверам и связываются в одну систему. Рассмотрим подробнее.

Принцип: разбиение данных на независимые сегменты (шарды)

Каждый шард работает как отдельная независимая база данных. Ключевым элементом здесь выступает ключ шардирования (shard key). Это правила, которые определяют, в какой именно шард попадёт конкретная строка данных.

Например, мы можем задать правило: если у нас есть user_id и его значение меньше тысячи, то данные попадают в шард 1, если значение больше тысячи, то в шард 2.

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

Так, мы можем параллельно обрабатывать много запросов и увеличивать пропускную способность системы.

Общая архитектура: клиент — роутер — шард

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

Клиент: Программа на стороне пользователя, которая отправляет стандартный запрос к базе данных (например, SELECT * FROM users WHERE user_id = 123).

Маршрутизатор запросов или роутер (Query Router): Это что-то вроде посредника между клиентом и шардом, который выполняет роль диспетчера. Он принимает запрос, при помощи sharding ключа определяет, что это за данные, в какой шард и с какой целью их надо отправить. Далее он отправляет запрос на нужный шард.

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

Благодаря такой архитектуре мы можем «скрыть» database sharding на стороне клиента и обеспечить централизованное управление запросами. Не надо сильно заморачиваться с кодом и архитектурой приложений, ведь вся логика будет на серверах.

Основные компоненты: шард, маршрутизатор, реплика-сеты

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

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

Виды шардинга

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

Горизонтальный sharding (по строкам): самый популярный

При горизонтальном шардинге мы «нарезаем» нашу базу данных по строкам. Допустим, у нас таблица с клиентами. Мы задаём диапазон ключу шардирования с user_id от 1 до 1 000 000. Данные в этом диапазоне, построчно будут храниться в шадре 1. Если user_id попадает в диапазон от 1 000 001 до 2 000 000, то эти данные отправляем на шадр 2. И так далее.

Благодаря этому способу мы можем равномерно распределять данные, и нам будет проще масштабировать систему при помощи создания новых шадров и добавления серверов.

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

Вертикальный шардинг (по столбцам): разделение по функциональности

Если горизонтальный шардинг режет таблицу поперёк (по строкам), то вертикальный — вдоль, разделяя столбцы. Таблица делится на несколько с меньшим количеством столбцов. Обычно они группируются по частоте использования или по смысловой нагрузке. Например, в таблице юзеров можно выделить часто запрашиваемые user_id, username, email в одну таблицу, а редко используемые — biography, preferences, last_login_details — в другую.

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

Directory-based sharding: использование хеш-таблицы маршрутов

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

Вот пример того, как это работает:

• Клиентское приложение отправляет запрос (например, получить данные для order_id = 98765).
• Маршрутизатор запросов перехватывает его.
• Маршрутизатор обращается к каталогу: с запросом, где найти order_id = 98765.
• Каталог ищет в своей таблице соответствий правило, под которое подпадает order_id = 98765. Для быстрого поиска он часто использует эффективные структуры данных, такие как хеш-таблицы или B-деревья (это внутренняя деталь реализации самого каталога).
• Допустим, каталог находит правило «Диапазон order_id 90000-99999 → Shard-3» и сообщает это маршрутизатору.
• Маршрутизатор перенаправляет исходный запрос на Shard-3.

При таком подходе удобнее перемещать данные между шардами, изолировать их и менять логику.

Range-based sharding: разбиение по диапазонам значений

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

Администратор системы (или автоматизированный инструмент) определяет границы диапазонов для ключа шардинга. Маршрутизатор получает запрос, смотрит на значение этого ключа и сравнивает его с известными диапазонами, чтобы определить целевой шард.

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

• id от 1 до 1000 — шард 1;
• id от 1001 до 2000— шард 2;
• id от 2001 до 3000 — шард 3.

Когда пользователи начнут регистрироваться, у нас будет активен шард 1, потом шард 2. Далее вся нагрузка перейдёт на шард 3. Они не будут одновременно равномерно работать. Это может стать проблемой при оптимизации.

Hash-based sharding: равномерное распределение по хешу ключа

Этот подход помогает добиться максимально равномерного распределения нагрузки по всем шардам. Работает следующим образом:

Берём значение ключа для конкретной строки данных (например, user_id = 2001).

Применяем к нему хеш-функцию. Хеш-функция (например, MD5, SHA-1, MurmurHash) — это алгоритм, который превращает входные данные (наш user_id) в строку или число фиксированной длины (хэш), которое выглядит почти случайно. Даже небольшое изменение на входе (например, user_id = 2001 и user_id = 2002) обычно даёт совершенно разные хеши.

Вычисляем номер шарда. Чаще всего делим значение хеша на количество шардов и берём остаток от деления. Например, 548291 % 3 = 2. Далее в зависимости от остатка распределяем данные по шардам. Значение с остатком 2 пойдёт в шард 2, если остаток 1, то в шард 1 и так далее.

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

Примеры реализации

MongoDB: встроенная поддержка шардинга

MongoDB — это NoSQL база данных, которая была разработана с закосом на горизонтальное масштабирование. То есть она адаптирована к тому, чтобы работать на нескольких серверах и расширять это число по мере необходимости. Поэтому sharding здесь доступен из коробки, нам не надо заморачиваться со внешними расширениями.

Рассмотрим пример, как настроить sharding и работать с ним:

• sh.addShard() — добавляем сервер в кластер как шард. MongoDB понимает, что может использовать этот сервер для хранения части данных.
• use socialApp; sh.enableSharding("socialApp") — переключаемся на базу данных «socialApp». При помощи команды sh.enableSharding() разрешаем шардинг в этой БД.
• sh.shardCollection("socialApp.users", { "user_id": 1 }) — применяем sharding к коллекции users. Мы указываем полное имя коллекции (socialApp.users) и ключ шарда ({ "user_id": 1 }). Цифра 1 означает, что мы используем шардинг по диапазонам. Эти диапазоны не нужно задавать вручную, MongoDB определяет их самостоятельно.
• db.users.insertMany([...]) — вставляем данные в коллекцию users. MongoDB автоматически определяет, на какой шард поместить каждого пользователя.
• db.users.findOne({ user_id: 1 }) — запрашиваем данные пользователя user_id = 1. Mongos сам определит, на каком шарде они находятся.

PostgreSQL + Citus

В PostgreSQL нет поддержки встроенного шардинга, поэтому приходится устанавливать на сервер Citus. Это популярное расширение, которое как раз добавляет возможности горизонтального масштабирования и шардинга. Оно превращает кластер стандартных серверов PostgreSQL в распределённую базу данных.

Посмотрим на пример использования SQL-команд для настройки шардинга с помощью Citus:

• CREATE EXTENSION citus; — активируем Citus в текущей базе данных.
• CREATE TABLE app_logs (...) — создаём таблицу app_logs на узле-координаторе точно так же, как создали бы обычную таблицу в PostgreSQL.
• SELECT create_distributed_table('app_logs', 'service_name'); — при помощи этой команды включаем sharding. Citus понимает, что таблицу app_logs нужно распределить по рабочим узлам, используя поле service_name как ключ шардинга. Citus по умолчанию применяет Hash-based sharding, то есть, равномерно распределяет по шардам при помощи хеш-функций.
• INSERT INTO app_logs — добавляем данные логов. Citus перехватывает запрос, вычисляет хеш от значения service_name для каждой строки и распределяет данные по шардам.
• SELECT ... FROM app_logs — запрашиваем данные. Если фильтруем по service_name (как в первом SELECT), Citus направит запрос на нужный шард.

MySQL + Vitess

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

Vitess вместо прямых команд для шардинга определяет его правила в отдельном JSON-файле, который называется VSchema (Vitess Schema).

Допустим, у нас есть база данных commerce. Вот как она выглядит в виде кода:

А вот так она выглядит в виде таблицы:

В базе данных есть таблица orders, её мы и хотим шардировать по customer_id при помощи хеширования (hash-based sharding).

Файл VSchema (vschema.json) может выглядеть примерно так:

• "sharded": true — указываем, что база данных шардирована.
• "vindexes" — определяем hash_index типа hash, который будет использовать хеш-функцию для распределения.
• "tables" — описываются правила для конкретных таблиц.
• "orders" — настраиваем таблицу orders.
• "column_vindexes" — определяем, какой столбец является ключом ("column": "customer_id") и какой vindex ("name": "hash_customer_id") использовать для него.

Проблемы шардирования

Перераспределение шардов (resharding)

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

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

Например, раньше у нас было 4 шарда. Мы брали user_id, например 9, делили на 4 и получали остаток — 1. Значит, данные шли на шард номер 1. После масштабирования стало 5 шардов, и 9 % 5 = 4 — теперь те же данные должны храниться на шардe 4.

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

Неравномерная нагрузка (hot shards)

Вспомним вид шардирования Range-based sharding. Это когда мы разбиваем данные по диапазонам. У нас был пример выше с форумом и шардингом user_id:

• id от 1 до 1000 — шард 1;
• id от 1001 до 2000— шард 2;
• id от 2001 до 3000 — шард 3.

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

Такую проблему называют горячим шардом (hot shards). Производительность всей системы начинает зависеть от самого загруженного шарда. Преимущества шардирования снижаются.

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

Сложности с глобальными транзакциями и агрегациями

Допустим, нужно перевести деньги со счёта А на счёт Б — операция состоит из двух шагов: списание и зачисление. Транзакция позволяет объединить их в единое целое: либо всё выполнится, либо ничего. Это защищает от потери данных и ошибок. В классических базах данных за это отвечают принципы ACID — они гарантируют надёжность в пределах одного сервера.

Но если счёт А находится на одном шарде, а счёт Б — на другом, стандартная транзакция не сработает. Между независимыми серверами нельзя просто так обеспечить ACID-гарантии. Для этого нужны сложные и медленные механизмы координации, например двухфазный коммит (2PC). Либо приходится идти на компромисс и использовать eventual consistency — когда данные приходят в согласованное состояние с небольшой задержкой. Например, деньги уже списались, но ещё не зачислились.

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

Сложность управления и мониторинга

Шардированный кластер — это распределённая система, управлять которой сложнее, чем одним сервером.

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

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

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

Резервное копирование: Создание согласованных резервных копий и восстановление данных со множеством независимых шардов требует более сложных процедур.

Когда стоит применять Sharding

Рост объёма данных и нагрузок

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

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

Не справляется один сервер/реплика

Допустим, у нас один сервер и он не справляется с запросами и большими данными. Конечно, мы можем заняться вертикальным масштабированием, поставить CPU производительнее, добавить больше ОЗУ и так далее. Однако у этого подхода есть ограничения. Во-первых, каким бы мощным ни был бы сервер, он со временем упрётся в потолок своей производительности. Во-вторых, иногда дешевле купить несколько новых серверов помощнее, чем прокачивать старый. Поэтому создание кластера и распределение в нём нагрузки при помощи шардинга — часто более выигрышное решение, чем один сервер.

Потребность в геораспределённости или отказоустойчивости

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

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

Шардирование — полезный инструмент при работе с СУБД. А узнать про большее число подобных инструментов можно в нашем телеграм канале!

1. Топовые инструменты для фронтенд-разработки в 2025 году — собрали самые полезные инструменты, которые помогут фронтендерам работать быстрее и лучше в 2025 году.
2. ReactJS на изи: что реально нужно знать фронтенд-разработчику в 2025 году — кратко и по делу: что должен знать разработчик, работающий с React в 2025 году. Хуки, компоненты, архитектура.
3. Что должен знать уважаемый фронтендер в 2024 году — обновленный список знаний для фронтенд-разработчиков. Современные фреймворки, DevTools и подходы.
4. Фронтенд-разработка: чем занимаются и сколько зарабатывают специалисты — Объясняем, чем занимается фронтенд-разработчик, какие бывают задачи и сколько можно зарабатывать.
5. Как работать с JSON в веб-разработке — простое объяснение JSON: как он устроен, как его использовать и почему без него не обойтись на фронтенде.
6. Как выбрать IDE, если вы начинающий веб-разработчик — обзор самых удобных и популярных сред разработки для начинающих веб-разработчиков, их плюсы и минусы.
7. Эффективные инструменты для оптимизации кода во фронтенд разработке — собрали инструменты, которые помогут ускорить загрузку, уменьшить размер и повысить читаемость кода.
8. 30 самых полезных библиотек Python для веб-разработки в 2024 году — лучшая подборка Python-библиотек для веба: от фреймворков до утилит. Что взять в 2025 году.
9. На каком языке писать сайт в 2024 году — помогаем выбрать язык программирования под сайт в 2025 году. Сравнение по скорости, удобству и экосистеме.

Предыдущие подборки лежат здесь: Python, React, мобильная разработка, С++, инструменты.

Кстати! Забрать все самые топовые нейронки для айтишников можно в нашем большом гайде с 70+ ИИ-инструментами

PostgreSQL: Универсальная объектно-реляционная СУБД

PostgreSQL — объектно-реляционная СУБД (система управления базами данных). Термин реляционная означает, что мы записываем данные в виде взаимосвязанных таблиц со строгой схемой. В этой схеме у нас есть столбцы и ячейки, где занесены значения определённого типа: строки, числа, даты. Прямо как в Excel.

«Объектность» PostgreSQL заключается в том, что в качестве значений мы можем записывать не только числа, строки, даты, но и сложно структурированные данные, например, JSON или XML файлы. Ещё здесь есть наследование, мы можем создавать дочерние таблицы, которые повторяют структуру и данные родительских. Другая фишка PostgreSQL — пользовательские типы. В нём допускается прописывать свои типы данных и работать с ними. По логике это немного напоминает ООП с классами, объектами и наследованием.

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

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

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

ClickHouse: Скорость и аналитика от Яндекса

ClickHouse родился в стенах Яндекса в середине 2000-х. Изначально это была внутренняя разработка для Яндекс.Метрики — чтобы быстро обрабатывать миллиарды событий, подсчитывать статистику и выдавать отчёты, не теряя в скорости. В 2016 году разработку опубликовали на GitHub с опенсорс лицензией.

Особенность ClickHouse заключается в его колоночно-ориентированной архитектуре. Традиционные СУБД работают с данными построчно. Это значит, что каждая строка — как бы отдельная сущность с данными.

Допустим, нам надо считать данные с одного столбца. Классические СУБД пойдут искать ячейки столбца по строкам, вместо того, чтобы выбрать этот столбец.

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

ClickHouse поддерживает векторизацию. Это значит, что он нарезает БД (базу данных) на векторы — отдельные куски. СУБД сразу обрабатывает весь кусок целиком, вместо того чтобы по очереди заниматься каждой ячейкой. Здесь есть Simd-оптимизация — технология, которая позволяет процессору выполнять операции сразу над несколькими элементами данных параллельно.

Благодаря колоночной архитектуре и хорошей оптимизации ClickHouse быстро работает с данными. Его применяют в аналитике Uber, Bloomberg, Google, Netflix, VK, Avito, Т-банк, ну и, конечно же, Яндекс.

DuckDB: Локальная аналитика

DuckDB — ещё одна СУБД с открытым исходным кодом. Как и ClickHouse использует колоночную архитектуру, векторизацию и Simd-оптимизацию. Благодаря этому, хорошо справляется с аналитическими задачами.

Главная фишка DuckDB в том, что он предназначен для работы на стороне клиента и оптимизирован под обычные ПК и ноутбуки. DuckDB популярен среди аналитиков, которые работают с данными локально, например, через Python или R. Его можно подключить как библиотеку и работать с данными внутри проекта.

Сравнение возможностей СУБД

Производительность в тестах

Для сравнения я использовал ClickBench. Это набор данных с тестами для разных СУБД, весом более 70 гб и количеством около 100 млн строк.

В качестве оборудования выбрал c6a.4xlarge. Здесь 32 гб. ОЗУ, 16-ядерный процессор и диск объёмом 500 гб.

Тест предполагает, что СУБД обрабатывает данные при помощи 42 запросов. Cold Run — обработка некэшированных данных, Hot Run — работа с кэшированными данными, Storage Size — сжатие в гигибайтах (1 Гиб ≈ 1.073 Гб).

DuckDB оказался самым шустрым в тесте Cold Run, он обрабатывает некэшированные данные за 372 секунды, тогда как у ClickHouse 470 сек., а у PostgreSQL 937 сек.

Однако, ClickHouse оказывается быстрее в тесте Hot Run — когда данные в кэше. У него 372 сек., тогда как у DuckDB 470 сек. а у PostgreSQL всё те же 937 сек.

Также ClickHouse лучше всех работает с памятью. Он смог сжать 70 гб. данных до 13.48 гибибайт. На втором месте DuckDB, у него 22.03 Гиб. PostgreSQL не только не сжал данные, но и раздул их до 99.18 Гиб (примерно 106 гб). Возможно, ClickHouse и DuckDB проще сжимать информацию, так как у них колоночный подход к работе с данными, ведь в столбце повторяющиеся значения могут встречаться чаще, чем в строке. Увеличение объёма данных в PostgreSQL возможно вызвано тем, что СУБД наплодило много метатегов к данным.

В общем, PostgreSQL сильно уступает в производительности ClickHouse и DuckDB. С памятью работает тоже хуже.

Масштабируемость систем

PostgreSQL — хороший вариант для вертикального масштабирования

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

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

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

ClickHouse масштабируется вертикально и горизонтально

Тоже хорошо подходит для вертикального масштабирования, как и PostgreSQL. Однако он также поддерживает шадрирование и репликацию. Шадрирование означает, что ClickHouse может нарезать базу данных на кусочки и распределять эти кусочки между разными узлами. Репликация означает, что СУБД может копировать их на другие сервера в кластере.

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

DuckDB — только вертикальное масштабирование на обычных ПК и ноутбуках

Мы можем установить DuckDB на обычный ПК и прокачивать компьютер сколько угодно. В этом плане с вертикальным масштабированием никаких проблем нет. Но вот создать кластер и масштабировать горизонтально не получится, так как СУБД предназначена для индивидуального локального использования.

Экосистема и удобство использования

PostgreSQL выделяется своей зрелой экосистемой. Он кроссплатформенный, можно установить на Windows, MacOS, Linux, Docker. После установки необходима небольшая настройка под свои задачи.

Мы можем управлять СУБД через графический интерфейс pgAdmin.

Он поддерживает создание и редактирование объектов, просмотр структуры, визуализацию схемы. Для этого даже необязательно вводить SQL запросы, хотя это тоже можно. Также есть консольный клиент psql.

PostgreSQL поддерживает интеграцию с BI системами, например, Tableau, Metabase, Power BI, и расширения наподобие PostGIS и TimescaleDB.

У PostgreSQL всё хорошо с расширяемостью, мы вправе писать свои функции, индексы, подключать сторонние модули. Здесь можно писать код не только на SQL, но и на Python, C, C++, Java, JS, Rubi, R, Lua.

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

ClickHouse ориентирован на аналитику больших данных в реальном времени, что отражается в его экосистеме. Поддерживает установку на Windows, MacOS, Linux, Docker.

ClickHouse готов к работе «из коробки» для аналитических задач. Можно ничего не настраивать и сразу создать таблицу, но при условии, что СУБД будет работать только на одном устройстве. Если мы собираемся запустить ClickHouse на кластере, то придётся немного повозиться с настройками шадринга и репликации. Есть поддержка как SQL, так и других языков, но только через клиентские библиотеки.

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

Например, на изображении интерфейс agx.

DuckDB можно установить на Windows, MacOS, Linux. Установка напоминает подключение библиотеки к проекту. Просто пишем команду pip install duckdb для Python или install.packages("duckdb") для R и всё установлено локально, без сервера. Поддерживает и другие языки через клиентские библиотеки.

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

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

Также есть интерфейсы от сторонних разработчиков и консольный клиент.

Поддержка транзакций (ACID)

ACID — это набор свойств, которые обеспечивают надёжность транзакций в базах данных:

• Atomicity (Атомарность): Все операции в транзакции выполняются полностью, или ни одна из них не выполняется. Если что-то идёт не так, изменения откатываются.
• Consistency (Согласованность): После каждой транзакции база данных остаётся в согласованном состоянии, соблюдая все ограничения (например, уникальность ключей, внешние ключи).
• Isolation (Изоляция): Транзакции изолированы друг от друга, то есть незавершённые транзакции не видны другим.
• Durability (Долговечность): После завершения транзакции все изменения сохраняются, даже в случае сбоя системы.

ACID особенно важен для OLTP — обработки транзакций в реальном времени. Такие транзакции есть, например, в банковских системах, где требуется строгая согласованность и надёжность. В аналитических сценариях (OLAP) требования к ACID могут быть менее строгими, так как приоритет отдаётся скорости и масштабируемости.

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

ClickHouse жертвует полной поддержкой ACID ради скорости и масштабируемости. Это делает его идеальной СУБД для аналитических задач, но ограничивает использование в OLTP-сценариях.

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

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

DuckDB балансирует между скоростью (для OLAP) и частичной поддержкой ACID (для надёжности). Он поддерживает транзакции, но с ограничениями. Например, СУБД не может работать сразу с несколькими пользователями, что делает её подходящей для одиночной аналитики, но не для OLTP.

Из-за колоночной архитектуры здесь также, как и в ClickHouse есть сложности в плане поддержки атомарности.

Какую СУБД выбрать для аналитики

Выбирая между PostgreSQL, ClickHouse и DuckDB надо определиться, что важнее: транзакционная надёжность, аналитическая скорость или локальная простота.

PostgreSQL: для небольших данных и универсальности

PostgreSQL подойдёт для аналитики не сильно больших данных, например, в интернет-магазине, при условии, что это не маркетплейс размером с OZON. Это особенно хороший вариант для проектов, где нужна гибкость или поддержка транзакций по стандарту ACID.

ClickHouse: для больших данных в реальном времени

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

DuckDB: для локальной аналитики на ноутбуке

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

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

Кстати, для ИИ-приложений, в частности, для Retrieval-Augmented Generation (RAG), pg_vector для PostgreSQL — довольно популярное стартовое решение.

Если нужна «просто СУБД» — PostgreSQL отличное решение «по умолчанию».

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

Для более специфических задач — ultra-low latency, потоковая обработка данных, комбинированные решения — могут потребоваться другие, более сложные инструменты. Примеры: CockroachDB, YugabyteDB (оба — распределённые версии PostgreSQL), Apache Ignite (для ultra-low latency SQL и транзакции), Apache Druid (для быстрой аналитики).

DuckDB — скорее нишевый инструмент для data scientists и data engineers. Например, он подходит для обработки больших объёмов данных в скриптах на Python, когда это нужно сделать локально. Если вы разрабатываете приложения, то, скорее всего, вам DuckDB не нужен.

Я много лет разрабатываю распределённые базы данных (GridGain и Apache Ignite). Помог запустить множество систем, использовавших PostgreSQL и ClickHouse, или заменял их своим продуктом.
PostgreSQL — отличный продукт, очень гибкий. Но, чтобы раскрыть его потенциал нужна или очень сильная команда, или хороший внешний вендор, поэтому у Postgres Professional всё хорошо. Большинству компаний для нетиповых задач, особенно low-latency/real-time, проще найти альтернативное решение.

ClickHouse классно делает ровно одну вещь — быстро обрабатывает SQL запросы на больших данных. Им не решить все задачи аналитики в компании — долгосрочное хранение, трансформация данных и многое другое нужно будет решать другими инструментами.

PostgreSQL, ClickHouse и DuckDB — три очень разные системы, каждая со своей логикой и зоной применения. Тут не про «что лучше», а скорее — «что подойдёт именно под вашу задачу».

PostgreSQL

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

ClickHouse

Если у вас огромные объёмы данных и вы хотите быстро гонять по ним аналитику — это ваш инструмент. СУБД для чтения, не для транзакций. Отлично показывает себя в задачах мониторинга, логирования, аналитики в реальном времени. Очень быстрая, но требует больше внимания: настроек, понимания архитектуры, знание её ограничений (например, с JOIN'ами и транзакциями). Это уже не «поставил и работает», тут придётся повозиться.

DuckDB

Это интересный новичок — очень лёгкая, быстрая аналитическая СУБД, которая отлично работает локально, особенно в связке с Python или Jupyter. Я бы назвал её «SQLite для дата-сайентистов». Не требует сервера, можно просто подключить к CSV, Parquet или Pandas DataFrame и писать SQL-запросы. Для быстрого анализа данных — идеально. В продакшене пока использовать её с осторожностью, но для локальной аналитики — инструмент номер один.

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

Если вы делаете обычное приложение — PostgreSQL. ClickHouse — лучший выбор для аналитики в реальном времени, дашбордов, логирования, мониторинга, и других сценариев с интенсивными SELECT-запросами. DuckDB — отличный выбор для дата-сайентистов, аналитиков и быстрой локальной аналитики. Особенно хорош в ситуациях, когда нужно быстро что-то «пощупать» без подъёма инфраструктуры.

AI, ML, нейросети, аналитика — это явно твоя тема. Поэтому скорее ждем в нашем тг-канале.

Когда говорим про хранение данных, первое, что приходит в голову — это локальные диски: жёсткие (HDD) и твердотельные (SSD). Ещё есть базы данных и бэкап. Давайте рассмотрим преимущества и недостатки каждого из вариантов.

Локальные диски

Чаще всего для хранения используют рейды (RAID) — это способ обезопасить данные, объединив несколько дисков в один массив.

Например, в RAID 10 (1+0) есть как минимум четыре диска. Две пары из них создают зеркала (RAID 1) и дублируют данные. Поэтому, если два диска выйдут из строя (из разных зеркал), то данные всё равно останутся в сохранности.

Плюсы локальных дисков:

• Они очень быстрые.
• Нет задержек сети.

Минусы:

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

Сетевые диски

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

Плюсы сетевых дисков:

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

Но есть и минусы:

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

Бэкап

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

Плюсы бэкапа:

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

Минусы бэкапа:

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

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

Базы данных

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

А вот чтение может происходить с других серверов (реплик), которые копируют данные. Это позволяет разгрузить главный сервер и повысить скорость доступа.

Плюсов у баз данных много:

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

Минусы тоже есть:

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

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

Что такое S3 и распределённые хранилища данных

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

И здесь на помощь приходят распределённые системы хранения данных, которые чаще всего скрываются за аббревиатурой S3 (Simple Storage Service). Они взяли себе всё лучшее из всех перечисленных выше подходов к хранению информации. Такие системы изначально спроектированы под хранение цифровых данных большого объема. У каждого модного провайдера сейчас есть собственный сервис, который предоставляется, как дополнительная услуга.

На самом деле, распределённые системы хранения — это тоже не универсальный инструмент, но при этом они:

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

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

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

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

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

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

Сравниваем разные S3-совместимые системы хранения

Изначально при выборе системы хранения мы рассматривали несколько вариантов:

• Minio.
• Ceph.
• SeaweedFS.

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

Внешняя мета

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

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

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

Как устроено хранилище меты у SeaweedFS:

• Хранилище метаданных работает отдельно.
• Это может быть практически любая база данных со всеми её преимуществами.
• Путь до файла — это абстракция в базе, на самом деле, файл ищется по ID серверов, так мы частично обходим ограничения файловых систем.
• Отдельные папки/бакеты можно вынести в отдельные базы данных, или использовать несколько баз одновременно. Это полезно, если один бакет большой или на него приходится большая часть нагрузки.
• Можно собрать свой конструктор под поставленные задачи.
• Можно отключить листинг, если он не нужен.
• Можно хранить огромное количество маленьких файлов и папок внутри базы.
• Есть преимущества от LIKE, например, поиск по префиксам. Он ускоряет операцию листинга файлов в подпапках и избавляет от необходимости перебирать все вложения.

Хранение данных

У Minio файлы хранятся в виде файлов на файловой системе — с применением erasure coding (EC) для защиты данных. Поведение зависит от файловой системы, а ещё нужен рестарт кластера при добавлении новых дисков.

У Ceph своя сложная структура хранения RADOS, но при этом нужна ребалансировка при добавлении дисков.

Свой подход к хранилищу чанков у SeaweedFS:

• Нет привязки к условиям добавления новых дисков (любые типы и объёмы), не нужна ребалансировка всего кластера.
• Простое устройство волюм-файла.
• Небольшое число настроек волюм-сервера.
• Файлы хранятся в «суперблоке», внутри которого лежат чанки данных. Таким образом в один «файл» на файловой системе помещаются миллионы других файлов без аффекта со стороны файловой системы и её механизмов.

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

Запись данных

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

Ceph тоже по умолчанию создаёт несколько реплик. А ещё они предоставляют дополнительные интерфейсы взаимодействия — блочные устройства и сетевую файловую систему (NFS).

У Minio реализовано больше опций, совместимых с S3 API. Но добиться синхронной записи в реплику невозможно, даже если её включить (:

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

С учётом правильно выбранного erasure coding и других настроек репликация фактически не нужна. Поэтому вариант с “Site Replication” — не замена EC. И вариативность в этом плане ограничена.

Работа с дисками

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

У Ceph удаление может быть отложено. При изменениях в дисковом хранилище нужна массовая ребалансировка данных. Это дополнительная нагрузка на диски и сеть.

Нечто среднее реализовано в SeaweedFS:

• Операции восстановления, репликации и ребалансировки выполняются через внешние команды, а не постоянно в фоновом режиме, что снижает нагрузку на сеть и позволяет гибко контролировать процесс.
• Удаление в первую очередь происходит из базы (на диск по возможности ставится метка удаления).
• Удаление мусора (вакуум) из волюм-файлов запускается по триггеру и может включать полную перезапись файла.
• Ребалансировка при авариях происходит по триггеру: только тогда система автоматически перераспределит данные для восстановления нужного фактора репликации.
• Можно быстро удалить коллекции (полный бакет) благодаря «суперблокам». С дисков нужно удалить всего несколько файлов, это очень быстрая и простая операция.

Масштабирование

Minio поддерживает только одинаковые диски внутри пула и замедляется с ростом файлов. Несмотря на то, что сервис позиционирует себя как S3, фактически он им не является. Это просто сетевое хранилище или сетевой диск.

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

Что можно отметить в работе SeaweedFS:

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

Как устроен SeaweedFS

SeaweedFS — это opensource продукт, что одновременно плохо и хорошо. Главный плюс для нас — мы сами вносим в него изменения. Минус — их вносят и другие люди, поэтому периодически что-то ломают.

У SeaweedFS один основной автор — Chris Lu. Именно он принимает решения, как проект будет развиваться дальше. Новые релизы выходят примерно 2 раза в месяц.

Ещё SeaweedFS написан на Go, который очень любит наша команда инфраструктуры.

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

Путь одного файла выглядит примерно как на рисунке ниже:

• Запись идёт в две реплики.
• Волюм-сервера напрямую реплицируют файлы между собой.
• В конце записи в базу данных заносится информация о новом файле.

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

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

Как выглядят метаданные:

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

Как мы делаем бэкапы

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

Здесь есть много разных вариантов:

• У каждой базы данных есть собственный механизм создания бэкапов.
• Можем экспортировать метаданные так, как их видит SeaweedFS, например чтобы заменить базу данных или произвести бэкап отдельных бакетов.
• Можем копировать волюм-файлы целиком в бэкап (из-за ограничений файловых систем большие файлы перемещаются быстрее, копировать их проще — и суперфайлы, нам в этом помогают).
• Используем «мгновенный бэкап» — инкрементальный встроенный механизм бэкапа. Когда записываем файл в S3, ещё одна его копия сразу же отправляется на отдельный носитель (дополнительно к записи в две реплики), который тоже потом отправляется в бэкап. Благодаря этому, даже если что-то пошло не так, мы можем быстро восстановить даже самые свежие данные.

Главные выводы

S3 и распределённые системы хранения — это конструктор из разных программных и архитектурных решений, которые вместе дают все плюсы распределённых систем хранения:

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

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

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

Делитесь своим опытом в комментариях! Где вы храните данные и с какими сложностями пришлось столкнуться?

Меня зовут Юсуп Изрипов, я сеньор разработчик в VK. Работаю над продуктами, которыми ежедневно пользуются миллионы человек.

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

Container + Presentational Components

На первом месте работы ещё во время разработки на Vue мы с подачи нашего тимлида решили ввести этот паттерн. Глобально у нас были так называемые «умные» и «тупые» компоненты (или как я тактично называл их на демо — визуальные). Как вы наверняка догадались, роль Container у нас исполняли «умные» компоненты, а роль Presentational — «тупые». В чём, собственно, суть этого паттерна? Слышали выражение «разделяй и властвуй»? Паттерн Container & Presentational Components (контейнерные и презентационные компоненты) ровно об этом: он разделяет логику (данные и взаимодействие с ними) и отображение (UI) на разные компоненты.

Presentational Components отвечают только за то, как что-то выглядит. Они получают данные через props и отображают их, больше ничего. Это, как правило, чистые функциональные компоненты, часто без собственного состояния (ну разве что мелкий UI-стейт типа «раскрыт ли dropdown»). Им всё равно, каким образом взять список пользователей — они просто ожидают условный props.users и отображают его в соответствии с дизайном.

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

Зачем же нужен такой подход? Во-первых, лучшая разделённость ответственности (UI отдельно, данные отдельно) упрощает понимание и поддержку приложения. Во-вторых, улучшается переиспользование: один визуальный компонент вероятно использовать с разными источниками данных через разные контейнеры. Дизайнеры могут менять внешний вид компонента в одном месте, не затрагивая бизнес-логику. И тестировать тоже проще: можно отдельно протестировать логику контейнера (без верстки) и отдельно визуальный компонент (с моком данных).

В этом примере UserList не содержит никакого стейта, не подписан на store или контекст, лишь отображает список. Ему всё равно, как и где получают пользователей — просто принимает проп users и выводит его. Контейнер UserListContainer же занимается работой с данными: делает fetch, сохраняет результат в useState, и потом рендерит UserList, прокидывая в него данные. Благодаря такому делению компонент UserList легко переиспользовать — хоть для локальных данных, хоть для данных из Redux или context — достаточно написать другой контейнер.

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

Стоит отметить, что с появлением React-хуков граница между логикой и отображением несколько размылась. Теперь можно выносить логику в кастомные хуки и вызывать их прямо внутри компонента, вместо того чтобы создавать отдельный контейнер-класс, как это делали до 2018 года. Тем не менее, принцип «держи логику отдельно от представления» по-прежнему полезен. Даже с хуками можно структурировать код, разделяя функциональность: написать хук useUsersData() для получения пользователей и применять его в разных компонентах (вместо дублирования запроса).

Плюсы: чёткое разделение обязанностей, возможность переиспользовать и заменять части независимо (UI-компонент можно переиспользовать с разными данными), облегчение тестирования.

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

Higher-Order Component (HOC)

Когда я впервые услышал термин HOC, он показался мне чем-то из математики. Но на практике всё горадо прозаичнее: HOC — это всего лишь функция, которая принимает React-компонент и возвращает новый компонент, оборачивая исходный дополнительной функциональностью. Проще говоря, HOC — это «обёртка». Мы помещаем один компонент внутрь другого, чтобы на выходе получить расширенную версию переданного в HOC компонента.

Зачем это может понадобиться? Представим, у нас есть несколько разных компонентов, и всем им нужно что-то общее: например, обработка ошибок или подписка на внешние данные. Можно было бы скопировать этот код в каждый из компонентов, но куда элегантнее написать HOC один раз и применить ко всем. Классический пример — Redux-функция connect: вы пишете export default connect(mapState)(MyComponent), и ваш компонент получает пропсы из глобального стейта.

connect — как раз и есть HOC, который инъектирует данные из Redux в компонент, не требуя от вас переписывать все под Redux вручную.

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

Здесь withCounter — HOC, он возвращает новый функциональный компонент WithCounter, который внутри себя использует useState и передаёт состояние и функцию увеличения внутрь WrappedComponent. В итоге EnhancedButton — это улучшенная версия ClickButton, которая умеет считать клики, даже если исходный ClickButton об этом не знал.

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

Минусы: за такую магию мы платим усложнением структуры. Когда компонентов обёрток становится много, React-дерево раздувается, и возникает эффект «матрёшки». В DevTools вы могли видеть что-то вроде: Connect(withRouter(WithTheme(MyComponent))) — разобраться, что к чему, становится сложнее. Дебаг таких цепочек — тоже удовольствие то ещё, приходится пробираться через несколько уровней абстракций. Кроме того, HOC часто прокидывают пропсы во внутренний компонент, что чревато конфликтами имён (нужно следить, чтобы, например, prop.title от HOC не перезаписал пропс title, который вы передали самому компоненту). Ещё нюанс — HOC усложняют типизацию в TypeScript (надо правильно описывать generic для пропсов), но это выходит за рамки нашей темы.

React-разработчики со временем несколько охладели к HOC. В официальной документации прямо сказано: «компоненты высшего порядка не так часто используются в современном React-коде». Отчасти их вытеснили хуки, тем не менее, HOC никуда не делись: их продолжают применять сторонние библиотеки — тот же Redux, Relay и другие. Да, и в старом проекте вы почти наверняка встретите хотя бы пару HOC. Поэтому понимать этот паттерн стоит. Просто имейте в виду современные альтернативы и используйте HOC там, где это действительно необходимо.

Паттерн Render Props

Следующий паттерн я бы назвал «перевёрнутый HOC». Render Props — это подход, когда компонент сам не рендерит что-то внутри себя, а принимает функцию (часто через проп render или просто используя детей как функцию) и вызывает её, чтобы получить содержимое. То есть мы передаём компоненту инструкцию, что именно отрендерить, а он сам обеспечивает, когда и с какими данными вызвать эту инструкцию.

Представьте компонент <MouseTracker> для отслеживания положения курсора. Классически он может хранить x, y в своём состоянии и отрисовывать, скажем, <p>Mouse at (x, y)</p>. Но что, если мы хотим переиспользовать эту логику уже с другим UI? Паттерн Render Props предлагает сделать компонент <Mouse>, который не определяет жёстко JSX внутри себя, а вызывает функцию, переданную через проп (или children функцию), передавая ей координаты. Эта функция сама решит, что рисовать. Таким образом, <Mouse> инкапсулирует логику (слежение за мышкой), а отображение делегирует наружу.

Пример: реализуем компонент-утилиту <FilteredList items={...} filter={...}>, который отображает список на основе передаваемого фильтра. Вместо того чтобы жёстко прописывать разметку элемента списка, сделаем его с render проп через children:

Здесь <FilteredList> знает, как отфильтровать массив (items.filter(filter)), но не знает, как отрисовать каждый элемент. Вместо этого он вызывает функцию, которую мы передали в качестве дочернего элемента (children), для каждого элемента списка. Эта функция возвращает <li> для каждого item. В результате логика фильтрации инкапсулируется внутри FilteredList, а конкретное отображение списка задаётся извне. Мы могли бы так же использовать этот компонент для массива объектов, отрисовывая, например, товары — достаточно передать другую children-функцию.

Паттерн Render Props здорово повышает гибкость компонентов. Мы можем переиспользовать <FilteredList> для списков чего угодно — чисел, пользователей, товаров — просто изменяя функцию отображения. Другой пример: компонент <Mouse> может предоставлять координаты курсора, а внешний код решит, просто вывести текст, нарисовать по координатам картинку или вызвать какую-то совершенно другую логику — не нужно делать несколько вариаций компонента для каждого кейса.

Плюсы: Render Props позволяет компоненту-провайдеру (в примере выше FilteredList является провайдером данных) быть максимально универсальным, а конкретную разметку делегировать наружу. Многие библиотеки воспользовались этим паттерном: например, React Router (до версии 6) позволял вместо компонента страницы передать проп render в <Route> — функцию, которая отрисует JSX на основе параметров маршрута. Formik предлагал компонент <Formik> с функцией-ребёнком для рендеринга формы. Downshift (библиотека для автокомплитов) — тоже классический пример паттерна render props.

Минусы: главное неудобство — излишний шум в JSX. Код с вложенными функциями бывает тяжело читать. В нашем простом примере всё компактно, но представьте, если у вас будет несколько уровней таких компонентов: <Foo>{foo => ( <Bar>{bar => ( ... )}</Bar> )}</Foo> — легко получить «оберточный ад» из стрелочных функций прямо в разметке. Это значительно затруднит отладку такого кода при возникновении каких-либо проблем. К тому же, каждый раз при рендере создаётся новая функция, что может негативно сказаться на производительности, если таких компонентов много (React конечно оптимизирует функции в пропсах через механизм сравнения, но всё же). Также возникает неявная связь: внешний код должен знать, какие аргументы ожидает функция. TypeScript конечно помогает, но при чтении кода не сразу видно, что children, например, это не просто элемент, а функция.

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

В следующей части расскажу про хуки и кастомные хуки, а также про Compound Components и Серверные компоненты и Suspense.

Зачем компании собирают данные

Сегодня в интернете более 1 миллиарда сайтов. На великом и ужасном реддите каждый час появляется более 50 000 новых публикаций. На Github уже опубликовано более 300 млн публичных репозиториев. Всё это — открытые данные, которые можно использовать и, главное — собирать. Разумеется, перед этим проверить условия использования сайта, потому что некоторые из них могут запрещать сбор данных.

Зачем это нужно компаниям:

• Анализ рынка: для ритейла это возможность изучить клиентов и конкурентов.
• Мониторинг сайтов вендоров ПО: некоторые компании выкладывают уязвимости в своих продуктах и делятся возможными решениями.
• Создание продукта: собранные данные можно обогатить, прикрутить красивый интерфейс, умный поиск и предложить пользователю новое приложение, типа 2GIS.
• Развитие LLM: например, Google в 2024 году заключил контракт с Reddit на сбор данных. Open AI тоже часто говорят о том, что обучают свою модель на открытых источниках, а в ближайшее время хотят подключить ещё и транскрибации с YouTube.

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

Что такое Scrapy

Это высокоуровневый фреймворк на Python для краулинга и скреппинга сайтов. На GitHub у него больше 53 тысяч звёздочек, 10,6 тысяч форков и много глазиков. А ещё он занимает первое место по тегам #crawling и #scraping.

Есть много причин, почему Scrapy так популярен:

• Это фреймворк с готовой архитектурой — там много инструментов, доступных из коробки, которые можно настроить и использовать.
• Он асинхронный — чаще возникает задача замедлить его, чем ускорить.
• У него простые настройки — нужно всего раз подумать над архитектурой, а добавление новых источников будет занимать минимум времени.
• Scrapy удобно дебажить в любой момент, начиная от загрузки страницы и заканчивая сохранением данных в базе.
• Есть продуманные селекторы, доступны CSS, Xpath. Их можно комбинировать или выбрать что-то одно.
• Большое комьюнити и обновляемая документация. Ответы на большинство вопросов можно легко найти в сети.

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

Scrapy будет не лучшим выбором, если:

• Нужно собрать малый объем данных или собрать их нужно всего один раз.
• Вам нужно отдать просто сырые html или json, а не парсить и преобразовывать данные.
• Среди источников нет общей структуры данных.

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

Как работает Scrapy

После того, как вы установили Scrapy в виртуальное окружение ( '' pip instal scrapy' ) и создали новый проект ( ' scrapy startprogect scraper '' ), вам необходимо написать своего первого «паука».

В Scrapy используется класс spider — он определяет, как мы будем извлекать данные из сайтов. Допустим, нам нужно собрать информацию с одностраничного сайта. Создаём класс TestSpider, наследуемся от scrapy.Spider, добавляем атрибут name с уникальным именем и start_urls, где укажем страницы, с которых нужно начать поиск. После этого переопределим метод parse.

Parse является дефолтным для обработки ответов. Если вы сделаете request и не укажете функцию, которая должна его обработать, то ответ от запроса придёт в метод parse. Поэтому его, как минимум, нужно переопределить и назначить логику.

Допустим, нас интересует информация о компании — название и описание. Можем создать объект данных с двумя элементами — title и content, и с помощью двух xpath селекторов забрать со страницы заголовок и описание.

В конце передаём этот объект данных для последующей обработки в ядро. Это всё, что нужно, чтобы начать парсинг на Scrapy.

Обработка данных в Scrapy

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

В ValidatePipeline мы проверяем объект данных на наличие title, а в SavePipeline — сохраняем объект в качестве json.

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

Зачем нужен Middleware

Middleware очень похож на PipeLine, только он обрабатывает не объекты данных, а запросы и ответы от сайта.

В Scrapy есть несколько разных middleware:

• scheduler middleware: помещает запросы в очередь и извлекает их для обработки.
• spider middleware: управляет данными между пауком и ядром.
• downloader middleware: управляет данными между ядром и загрузчиком.

Получается такая схема работы компонентов Scrapy:

Запрос: Spider → Spider Middleware → Engine → Scheduler Middleware → Scheduler → Engine → Downloader Middleware → Downloader → Server (сайт)

Ответ: Server → Downloader → Downloader Middleware → Engine → Spider Middleware → Spider → Item Pipeline → Storage (хранилище данных)

Скорее всего, в первую очередь вы будете настраивать downloader middleware, поэтому разберём его подробнее.

Ниже продемонстрировал два примера, как можно написать свой Middleware. В RandomProxyMiddleware мы обрабатываем все запросы, которые будет отсылать наш паук с помощью метода process_request (добавляем рандомную прокси к каждому реквесту), а в CheckCaptchaMiddleware — обрабатываем все ответы с помощью метода process_response (проверяем ответ от сайта, ищем в нём слово captcha).

Итак, мы написали Pipeline и Middlewares. Дальше нужно указать, как мы будем их использовать. Для этого запишите их в файле settings.py, где находятся настройки проекта.

Начнём с пайплайнов. Цифра справа — это порядковый номер выполнения. То есть первым будет ValidatePipeLine, а вторым сработает SavePipeline. Обычно цифры указываются от 0 до 1000. И в случае с пайплайнами чем ниже цифра, тем раньше сработает пайплайн.

В случае с middleware картина такая же, но логика немного иная.

Каждый middleware может обрабатывать как request, так и response. При этом middleware стоит посередине между ядром, который отправляет запросы, и загрузчиком. Если ваша middleware обрабатывает запросы, то сработает первой та, что указана с меньшей цифрой, потому что она ближе к ядру. А если middleware обрабатывает ответы, то первой будет та, у которой цифра больше, потому что она дальше от ядра и ближе к загрузчику.

Об этот нюанс часто спотыкаются новички, хотя, скорее всего, он прописан в документации.

Пример, как использовать Scrapy

Рассмотрим, как с помощью одного селектора собрать сайт любой вложенности и архитектуры.

Для начала создаём класс паука, наследуемся от scrapy.Spider, указываем name, start_urls и атрибут allowed_domains — он необязательный, но в данном случае без него не обойтись. В нём мы укажем список хостов, на которые разрешаем ходить нашему пауку, чтобы он не начал собирать другие сайты.

Дальше переопределяем метод parse и, когда к нам приходит ответ от сайта, находим все ссылки. И это и есть тот единственный xpath селектор, который поможет обойти весь сайт и собрать страницы.

Все ссылки помещаем в переменную url в качестве списка, а потом этот список передаём в функцию follow_all объекта response.

Чтобы дописать сохранение, просто передаём объект response вглубь ядра Scrapy, где напишем какой-то нехитрый пайплайн и будем сохранять html-страницы. Так можно собрать абсолютно любой сайт, просто подставьте ссылку на него в start_urls.

Важный нюанс: под капотом follow_all сделает запросы к сайту по всем ссылкам, которые мы нашли на странице. И поскольку в follow all мы не указываем определённый метод в параметре callback, то все ответы придут сюда же в метод parse (потому что он дефолтный в Scrapy). Эта логика будет повторяться на каждой странице.

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

Немного итогов

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

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

Shodan API: Поиск уязвимостей в интернете за минуты

Shodan — поисковая система для интернет-устройств. В отличие от Google, который индексирует веб-страницы, Shodan сканирует открытые порты, сервисы и устройства, подключённые к интернету. Это делает его мощным инструментом для исследователей безопасности, разработчиков и системных администраторов.

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

Как Shodan API экономит время разработчикам?

Ручной аудит серверов и интернет-устройств может занять недели, а то и месяцы, но Shodan API позволяет:

• Быстро находить уязвимые устройства и сервисы
• Проверять, какие технологии и версии ПО используются на серверах
• Получать статистику по открытым портам, SSL-сертификатам и угрозам
• Отслеживать новые уязвимости в реальном времени

Для DevOps, SOC-аналитиков и специалистов по информационной безопасности это возможность автоматизировать рутинные проверки и защитить инфраструктуру от потенциальных атак.

Как использовать Shodan API?

Shodan API предоставляет удобные методы для работы с данными через REST-запросы. Рассмотрим основные возможности.

Поиск открытых сервисов и устройств

Shodan позволяет находить устройства, доступные по определённым портам, IP-адресам или географическим координатам. Например, запрос всех открытых баз данных MongoDB:

Ответ покажет список IP-адресов, страну расположения серверов и используемые версии ПО.

Получение информации об IP-адресе

Допустим, вы хотите узнать, какие сервисы запущены на конкретном IP. Используем команду:

Ответ будет содержать список открытых портов, заголовки HTTP-ответов и используемые технологии.

Поиск устройств по версии ПО

Чтобы найти все серверы с устаревшей версией OpenSSH, можно выполнить запрос:

Это полезно для поиска серверов, подверженных атакам из-за старых версий ПО.

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

Abstract API: Быстрая проверка IP, валидация email и работа с геоданными

Abstract API — сервис, предлагающий набор API для работы с IP-адресами, валидацией email, проверкой телефона, распознаванием валют и многим другим. Это универсальный инструмент для веб-разработчиков, аналитиков и специалистов по безопасности.

Как Abstract API экономит время разработчикам?

Вместо того чтобы искать разные API для работы с геоданными, email-валидацией и IP-адресами, можно использовать Abstract API. Это экономит часы на интеграцию и позволяет быстро решать задачи, такие как:

• Определение страны и города пользователя по IP

• Проверка подлинности email перед регистрацией

• Конвертация валют в реальном времени

• Валидация телефонных номеров

Abstract API помогает автоматически фильтровать спам-регистрации, защищать системы от ботов и улучшать пользовательский опыт.

Как использовать Abstract API?

API работает через REST-запросы и доступно для бесплатного использования с ограничениями.

Определение геолокации по IP

Можно быстро определить страну, город и провайдера пользователя:

Валидация email-адреса

Проверяем, является ли email настоящим, одноразовым или корпоративным:

Что нужно помнить? Бесплатная версия ограничена числом запросов в месяц. А данные по IP-геолокации иногда могут быть неточными (зависит от провайдера).

Zyte API: Интеллектуальный ротационный прокси для веб-скрейпинга без блокировок

Zyte API — мощный API для веб-скрейпинга, который не только обходит блокировки и капчи, но и автоматически структурирует полученные данные. Он объединяет в себе прокси-серверы, обработку JavaScript-страниц и инструменты парсинга, что делает его одним из самых удобных решений для сбора данных с веб-ресурсов.

Как Zyte API экономит время?

Вместо того чтобы вручную разрабатывать сложные парсеры и бороться с защитами сайтов, Zyte API позволяет получить уже готовые структурированные данные:

• Автоматическая обработка JavaScript-страниц (открывает динамически загружаемые сайты, как Selenium).

• Обход капч и блокировок (использует интеллектуальные прокси).

• Автоматическое структурирование данных (не просто HTML, а уже готовая JSON-структура).

• Интеграция с Python и REST API (работает с любыми языками программирования).

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

Как использовать Zyte API?

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

Использование Zyte в curl

Допустим, нужно скачать HTML-страницу сайта example.com:

Что нам ответят:

Интеграция с Python

Для начала нужно установить клиент:

Код для парсинга и получения данных:

Автоматический парсинг данных

Zyte API умеет не только загружать HTML, но и автоматически извлекать полезные данные. Например, спарсить цену, название и описание кроссовок в интернет-магазине (ну или любого другого товара).

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

Common Crawl API: Бесплатная база данных для веб-скрейпинга и анализа интернета

Common Crawl — не просто API, а целый архив интернета, содержащий огромные объемы веб-данных, собранных с 2008 года. В отличие от стандартных API для веб-скрейпинга, Common Crawl предоставляет доступ к готовым копиям страниц, что значительно ускоряет анализ веб-контента и снижает нагрузку на исходные сайты.

Как Common Crawl API экономит время?

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

• Бесплатный доступ к огромной базе веб-страниц (петабайты данных, обновляемых ежемесячно).

• Исторические данные (можно анализировать, как изменялся контент сайтов за годы).

• Отсутствие блокировок и капч (данные уже собраны, вам не нужно бороться с защитами сайтов).

• Возможность массового анализа веба (идеально для NLP, машинного обучения и SEO-исследований).

API и данные Common Crawl полезны для исследователей, дата-аналитиков, SEO-специалистов и разработчиков.

Как использовать Common Crawl API?

Common Crawl предоставляет данные в формате WARC (архивные копии страниц) и WET (чистый текст без HTML). Доступ осуществляется через Amazon S3, но также можно использовать API Common Crawl Index для поиска нужных URL.

Поиск веб-страниц через API

Допустим, нам нужны все страницы, содержащие example.com:

Вот такой ответ может быть:

Получение текста страницы из архива

После получения ссылки на WARC-файл можно скачать его и распаковать:

Ну и затем извлечь текст:

Анализ больших объемов данных с AWS

Если вам нужны миллионы страниц, можно использовать AWS Athena для обработки данных прямо в облаке.

Пример SQL-запроса в AWS Athena для поиска страниц с «machine learning»:

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

GitHub API: автоматизация работы с репозиториями, пользователями и кодом

GitHub API — интерфейс для взаимодействия с кодом, репозиториями, пользователями и организациями на платформе GitHub. Он позволяет автоматизировать задачи, получать аналитику, управлять репозиториями, отслеживать запросы на вытягивание, коммиты и многое другое.

Как GitHub API экономит время?

Вместо ручного управления репозиториями и кодом через интерфейс GitHub можно автоматизировать эти процессы с помощью API:

• Автоматизация деплоя и CI/CD (создание и управление GitHub Actions).

• Мониторинг активности в репозиториях (новые коммиты, запросы на вытягивание, проблемы).

• Управление пользователями и организациями (добавление разработчиков, управление доступом).

• Анализ кода и метрик (подсчёт строк кода, статистика участников).

• Поиск по репозиториям и файлам (быстрое извлечение нужной информации).

GitHub API полезен для DevOps-инженеров, разработчиков, владельцев проектов и аналитиков.

Как использовать GitHub API?

GitHub API работает через REST-запросы и возвращает данные в формате JSON. Для авторизации можно использовать токен личного доступа (PAT) или OAuth.

Получение информации о пользователе GitHub

Допустим, мы хотим узнать данные о пользователе natasharostova:

Как нам могут ответить:

Создание нового репозитория через API

После выполнения запроса появится новый репозиторий new-repo.

Поиск репозиториев по ключевому слову

Допустим, мы хотим найти репозитории, содержащие код на Python, связанный с машинным обучением:

Нужно понимать, что есть ограничение в 5000 API-запросов в час для авторизованных пользователей. Для некоторых функций требуется версия GitHub Enterprise.

MuleSoft API: Универсальный коннектор для интеграции сервисов

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

Как MuleSoft API экономит время?

Вместо того чтобы разрабатывать интеграции с нуля, MuleSoft API предлагает готовые коннекторы, которые позволяют:

• Интегрировать разные системы (CRM, ERP, базы данных, облачные сервисы) без сложного кодинга.

• Автоматизировать обмен данными между приложениями (например, между Salesforce и SAP).

• Обеспечивать безопасность API с помощью встроенных инструментов управления доступом.

• Создавать микросервисную архитектуру, где API работают как модули.

API полезен для DevOps-инженеров, архитекторов ПО, разработчиков корпоративных решений и интеграторов.

Как использовать MuleSoft API?

MuleSoft поддерживает REST и SOAP API, а также интеграцию через готовые коннекторы.

Создание API с помощью Anypoint Platform

Anypoint Platform — облачная среда MuleSoft, в которой можно управлять API.

Пример запроса к API через MuleSoft:

Подключение к базе данных через DataWeave

DataWeave — это язык MuleSoft для трансформации данных. Он позволяет легко преобразовываться в нужные форматы.

Это правило конвертирует XML-ответ базы данных в JSON.

Важно помнить, что бесплатные возможности платформы ограничены. Также сервис требует обучения: для работы с DataWeave и Anypoint Platform нужно разбираться в интеграции API.

JSONPlaceholder API: бесплатный фиктивный REST API для тестирования и создания прототипов

JSONPlaceholder API — бесплатный REST API, предназначенный для тестирования, создания прототипов и обучения разработчиков. Он предоставляет фиктивные данные (пользователей, публикаций, комментариев и т. д.), которые можно использовать при разработке клиентских и серверных приложений без необходимости развёртывать собственный бэкенд.

Как JSONPlaceholder API экономит время?

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

• Позволяет мгновенно получать тестовые данные без развертывания сервера.

• Не требует регистрации или API-ключа.

• Поддерживает стандартные HTTP-методы (GET, POST, PUT, DELETE).

• Полностью совместим с популярными библиотеками и фреймворками (Axios, Fetch API, jQuery и др.).

API полезен для фронтенд-разработчиков, тестировщиков, студентов и преподавателей программирования.

Как использовать JSONPlaceholder API?

JSONPlaceholder предоставляет несколько ресурсов, которые можно запрашивать с помощью HTTP-запросов.

Получение списка пользователей

Простейший GET-запрос возвращает список тестовых пользователей:

Получение списка постов

Можно запросить список фиктивных публикаций:

Добавление нового поста

Можно отправить POST-запрос, чтобы имитировать создание записи:

Обновление записи

Для изменения существующей записи можно использовать PUT-запрос:

Что нужно помнить? Данные статичны — они не сохраняются между запросами. Запросы POST, PUT и DELETE не изменяют реальные данные. А само API предназначено только для тестирования, а не для использования в рабочей среде.

Дисклеймер! Перед прочтением настоятельно рекомендую ознакомиться с первой частью статьи.

Если вы знакомы с FreeBSD, вы уже знаете её достоинства и недостатки по сравнению с Linux. Просуммирую некоторые отличия, важные для выбора облачной ВМ.

• FreeBSD не поддерживает контейнеры в привычном понимании — ни docker, ни podman пока не портированы.
• FreeBSD использует свою собственную лицензию The FreeBSD Copyright, позволяющую не раскрывать derivative work. Оценить распространённость FreeBSD иногда затруднительно, возможно, часть её кода используется и в Windows(C), и в MacOS(C). Только иногда разработчики сами признают её использование, например, Евгений Гаврилов, руководитель проекта vStack.
• Метод разработки FreeBSD ближе к академическому стилю. Есть базовый набор пакетов base, включающий не только ядро, но и достаточно инструментов для сборки остальной системы, именуемой ports. Развитие системы управляется elected Core Team — сейчас в команде 9 человек.
• Во FreeBSD давно используется система snapshots/rollback, позволяющая откатить изменения, если что-то сломалось.

Существует дистрибутив Linux, у которого есть некоторые из перечисленных особенностей — это Fedora Core.

Что такое Fedora Core и как с ней работать

Изначально эти идеи возникли в другом дистрибутиве — RedHat CoreOS.

Во-первых, система ориентирована на использование в облаках: в ней предоставляются образы для всех возможных систем виртуализации и форматов дисков. Во-вторых, она разделена на базовую систему, часть из которой монтируется только в режиме чтения (ro:read only), и остальное, доступное через контейнеры.

Обновление системы возможно автоматически, появилась особая утилита rpm-ostree, и можно откатить на предыдущую версию, если что-то не так. Таким образом, CoreOS становится иммутабельной, изменения базовой части системы невозможны в обход коммитов rpm-ostree.

Я как-то провел эксперимент: установил в Yandex Cloud версию FedoraCore 35, выпущенную в конце 2021 года, с включённым по умолчанию сервисом zincati, который автоматически обновляет базовую систему (у него стабильные релизы). Посчитал, сколько коммитов сделано с тех пор: да, как и в git, здесь используется CAS (content-addressable storage), уже привычные нам хэши. ВМ обновилась и рестартанула 8 раз, если я не пропустил какой-либо рестарт:

Теперь можно сравнить с этой же системой, установленной из свежего имиджа — как и ожидалось, системы не отличались, хэши коммитов одинаковы. Это то, что имеется ввиду под иммутабельностью ОС. Кроме иммутабельности и смонтированных только по чтению некоторых каталогов, есть и другие меры безопасности. Используется версия Security-Enhanced Linux, никаких логинов по умолчанию, настройки пользователя либо через утилиту cloud-init, либо специальная утилита butane и так называемый ignition file.

У проекта Fedora есть подробнейшая документация — в ней лежит самое авторитетное руководство по установке. Тем не менее у меня возникла пара вопросов:

• Во-первых, для преобразования .yaml файла в ignition, который по сути обычный .json файл, используется особый инструмент butane, написанный на языке Go. Судя по размеру образа 130M, он довольно увесистый, но никак не упоминаются другие утилиты для конвертациии .yaml в .json.
• Во-вторых, в простейшем случае для первого логина вообще не нужны ни butane, ни .yaml. Вот пример минимального ignition.json файла, который создаётся руками:

Скопируем этот файл в каталог /tmp, он нужен один раз для первого входа, не содержит секретов, к нему нужно будет указать полный путь. Как и ранее, скачиваем свежий образ для libvirt/qemu: выбираем нужную архитектуру и формат диска, проверяем контрольные суммы и цифровые подписи. Команды для создания ВМ будут немного отличаться от уже опробованных из прошлой статьи — сначала сделаем для нашего ignition.json опцию, которую понимает virt-install:

Затем распаковываем образ в стандартный каталог и создаём ВМ:

Созданная заранее переменная шелл использована как "${IGN[@]}". virt-install выдаст интереснейший лог процесса инсталяции, а в самом конце — перед приглашением — покажет IP-адрес вновь созданной ВМ. Переходим в другую консоль и проверяем наш ssh-ключ: ssh -v core@192.168.100.2 в моём случае. После успешного логина выполняем первоочерёдные проверки и настройки:

Теперь ВМ можно остановить и сделать финальные настройки нашего персонального облака для этой ВМ. Добавим MAC- и статический IP-адреса в dnsmasq.conf и зададим имя новой ВМ в сети (пример есть в прошлой статье). Откроем в virt-manager окно overview, затем откроем вкладку XML и в самом конце удалим конфиг для qemu — целиком вот этот фрагмент:

Далее кнопка Apply. Возможно, virt-manager попросит сначала установить Edit → Preferences → General → Enable XML editing. То же самое можно сделать из командной строки: sudo virsh edit fc41stab. Ignition-файл нужен только для установки, далее эту ВМ можно донастраивать, клонировать, копировать её образ куда угодно, в том числе в большие облака.

А мы продолжим знакомство с этой необычной системой, как её рекламирует проект Федора:

Fedora CoreOS — это автоматически обновляемая, минимальная, монолитная, ориентированная на контейнеры операционная система, разработанная для кластеров, работоспособная автономно, оптимизированная для Kubernetes.

Проверим, что dnsmasq обновился, и начнём по порядку.

Далее выполняем команды внутри ВМ. Основное, к чему придётся привыкнуть, — что часть каталогов смонтированы readonly, запись в них в обход утилиты rpm-ostree невозможна даже судоерам:

Я специально грепнул только реальные устройства, потому что кроме них смонтированы ещё 19 виртуальных — пока углубляться не будем. Как видно, в режиме rw смонтированы /etc и /var. Даже стандартый home — это линк /home → var/home.

За автоматические обновления отвечает сервис zincati. Если его отключить, обновления можно запускать вручную: rpm-ostree --bypass-driver upgrade. После рестарта проверяем новое состояние системы:

rpm-ostree rollback позволяет откатить обновления к предыдущему комиту. Другие полезные команды:

1. rpm-ostree db diff — список обновлённых пакетов между комитами
2. rpm-ostree db list — список и версии пакетов в комитах

А как же устанавливать пакеты привычным dnf? Это своевременный вопрос. Посмотрим сначала что уже стоит:

Это напоминает FreeBSD base, но важно, что набор включает podman, docker, git — для остального есть утилита toolbox. Она делает доступными все пакеты федоры, упакованные в контейнер. Заглянем в toolbox:

Мы оказались внутри контейнера — об этом говорит изменившееся приглашение $PS1. Если снова посмотреть mount, увидим ещё больше хитро подмонтированных каталогов — этакий оверлей из базовой и контейнерной ФС. Но зато работает dnf, поэтому можно устанавливать любые пакеты. Добавим привычные, без них неуютно в новой системе:

Как видим, пакеты доступны, но желательно иметь их вне контейнера. Нет проблем: скопируем их в свой ~/bin каталог, он одинаков и внутри, и снаружи контейнера:

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

А теперь серьезно: настраиваем Fedora Core сервер для команды разрабов

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

Обычно в команде есть один админ или несколько. Уже созданный пользователь core — это админ, у него есть права sudo, плюс ему доступен контейнер tbox. В нашей Федоре каталог с секретами устроен особым образом:

Первоначально обычный файл authorized_keys назывался ignition и располагался в каталоге ~/.ssh/authorized_keys.d, что подразумевает, что можно ещё добавить ключей, назвав их никами других админов. Так же можно поступить с разрабами — настроить для всех один dev env.

Создадим нового пользователя без прав sudo:

Как мы уже знаем, мелкие утилиты можно просто скопировать из тулбокса в ~/bin или /usr/local/bin. Для языков программирования и прочих инструментов есть замечательная программа mise. Сейчас мы её установим для dev и немного познакомимся. Свой ключ я уже добавил в ~dev/.ssh/authorized_keys.d/, так что логинимся и настраиваем инструменты для команды разрабов.

mise позволяет устанавливать и использовать различные версии языков программирования, инструментов и библиотек. Другие менеджеры версий, например, aqua, asdf, ubi — собрали репозитории таких инструментов, и mise их использует в качестве бэкендов. Огласим весь список:

Да, список великоват: сохранил в файл — 883 штук, и он постоянно растёт. Это только названия пакетов, поиск версий, а команда mise ls-remote python выдала 911 вариантов для python.

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

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

Шаг 1. Готовимся к миграции

Посмотрите структуру проекта, чтобы выявить слабые места.

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

Проанализируйте:

• Вид проекта. Ваша разработка — это монолит, модульная система, API, микросервис?
• Зависимости. Определите, какие библиотеки использует проект. Совместимы ли они с Laravel?
• Базу данных. Если в БД встречаются дубли, отсутствуют ограничения, это нужно исправить заранее.

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

Стратегии перехода

Выберем стратегию перехода:

• Big Bang,
• Поэтапный перенос.

Стратегия Big Bang — это полная остановка текущего проекта и создание новой версии на Ларавел с нуля.

Подход идеален для устаревших и запутанных систем.

Из минусов — высокие риски. Во время разработки текущая версия может растерять пользователей. К тому же сроки реализации могут затянуться.

Стратегия с постепенным переходом выглядит надежнее.

Система продолжает работать, а вы поэтапно меняете ее «под капотом».

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

Выбор подхода зависит от проекта

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

Проект напоминает спагетти-код? Плохие новости — Big Bang неизбежен.

Шаг 2. Разворачиваем новое окружение на Laravel

Чтобы установить фреймворк, выполните команду:

Прежде чем работать с кодом, настроим окружение.

В корне проекта для этого есть файл конфигурации .env:

• APP_NAME: имя приложения, чтобы оно отображалось в логах и заголовках.
• APP_URL: адрес, на котором приложение будет доступно (например, http://localhost).

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

Подключение БД

Laravel использует Eloquent ORM для взаимодействия с базой.

Настройка БД выполняется в том же разделе .env:

Для тестирования подключения запустите команду:

Настройка маршрутов

Маршруты изначально хранятся в файлах routes/web.php (для страниц) или routes/api.php (для REST API).

В качестве примера добавим базовый маршрут приветствия:

Если у вас проект с десятками пользовательских маршрутов, интегрируйте их постепенно.

Шаг 3. Переносим модели данных и бизнес-логики

Eloquent ORM работает с классами, представляющими таблицы в базе данных.

Чтобы перенести существующую таблицу, нужно создать модель:

Этот класс автоматически подключается к таблице с именем products.

Когда название таблицы не соответствует модели, это можно указать явно:

Если в таблице есть нестандартные поля (например, столбцы с именами вроде created_time вместо created_at), их тоже можно легко обработать:

Переносим схему БД

Laravel использует механизм миграций для управления таблицами в базе и сиды для внесения данных.

Перенос структуры БД выполняется командой:

Миграция создается в папке database/migrations.

Переносим данные

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

Создаем сид:

Внутри метода run описываем данные:

Переводим бизнес-логику в сервисы и фасады

Старый проект состоит из функционала, размазанного по контроллерам? Улучшим структуру и сделаем код независимым. С этим помогут сервисы и фасады.

Сервисы — это классы, которые объединяют бизнес-логику в одном месте.

Например, если проект выполняет расчеты цен и скидок, можно создать класс:

В этом классе описана бизнес-логика:

Теперь сервис можно вызывать в контроллерах и моделях.

Фасады — это статический интерфейс к сервисам, который делает вызовы более читаемыми.

Например:

С фасадом вызов становится простым:

Шаг 4. Перенос маршрутов и контроллеров

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

Если в старом проекте использовались API-запросы для работы с внешними сервисами или мобильными приложениями, перенесем их в api.php и добавим префикс api для маршрутов:

Теперь про контроллеры. Они отвечают за логику обработки запросов и взаимодействие с моделями. В Laravel контроллеры работают по правилам MVC (Model-View-Controller).

Пример обычного метода контроллера:

Laravel определяет маршруты групповыми методами — по префиксам, middleware или зонам авторизации.

Middleware — это посредники, которые обрабатывают запросы до их поступления в приложение.

Навесим middleware на маршруты, требующие авторизации пользователя:

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

Пример метода политики:

Политики можно подключать к маршрутам или напрямую вызывать в контроллерах.

Шаг 5. Перенос фронтенда и представлений

Если ваш старый проект использует обычные HTML-файлы, они легко преобразуются в Blade.

Blade — это встроенный механизм шаблонов. С его помощью создают пользовательские интерфейсы.

Например, перенесем главную страницу сайта:

Blade-версия:

Теперь можно динамически передавать данные из контроллера:

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

Интегрируем Vue.js или React

Vue.js/React подключают, когда нужен динамичный и интерактивный интерфейс. Например, для SPA, реалтайм-функционала, сложных форм или фильтров.

Blade и JavaScript можно комбинировать: используйте Blade для рендеринга начального интерфейса и Vue.js/React для обработки интерактива.

Динамический интерфейс без JS

Livewire — это инструмент для создания интерфейсов без необходимости обращаться к внешним библиотекам JavaScript. Преимущество в том, что весь код пишется на PHP.

Livewire пригодится для динамических форм, фильтрации таблиц, уведомлений. Он упрощает код, сохраняя гибкость.

Шаг 6. Оптимизируем и тестируем проект

Отправная точка улучшения производительности — работа с Blade-шаблонами. Laravel сам их оптимизирует, но есть практики по дополнительному ускорению:

• Минимизация логики в представлении. Злоупотребление PHP внутри Blade замедляет рендеринг страниц. Вместо описания сложной логики в шаблонах ее лучше перенести в контроллер.
• Кэширование шаблонов. Работу приложения можно ускорить за счет запуска кэширования всех шаблонов, сокращая время компиляции — «php artisan view:cache».
• Переиспользование. Если фронтенд состоит из повторяющихся фрагментов, рекомендуется использовать Blade-компоненты.

В приложениях SPA оптимизируем фрагменты JavaScript.

Laravel Mix генерирует минифицированные CSS и JS. Проверьте размер этих файлов в папке public/js. Если их вес больше 1 МБ:

• Удалите лишние пакеты.
• Используйте динамическую загрузку маршрутов или компонентов.

Для Vue можно использовать динамическую загрузку, чтобы не грузить весь фронтенд сразу:

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

Убедимся, что приложение работает корректно.

Проверим, например, что страница приветствия открывается и показывает нужный текст:

Если используете Vue.js или React, для проверки компонентов применяйте Jest или Mocha.

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

Если приложение работает с API:

Для проверки приложения под нагрузкой можно использовать Artillery или JMeter.

Шаг 7. Разворачиваем и запускаем проект

Перенесли данные, создали маршруты и контроллеры, внедрили представления, оптимизировали приложение и протестировали его. Остался последний шаг — развернуть проект на сервере и запустить его.

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

• Если важна скорость и масштабируемость, выбирайте Nginx. Он быстрее работает под высокой нагрузкой.
• Если важен простой подход, используйте Apache. Он интегрируется с большинством систем.

Фоновые задачи можно связать с Supervisor. Инструмент автоматически запускает воркеров при сбоях, обеспечивая бесперебойную обработку задач.

Автоматизация развертывания

Чтобы релиз прошел безболезненно, нужен рабочий процесс CI/CD. Например, в GitHub Actions можно настроить сценарий, который:

1. Проверит качество кода.
2. Установит зависимости.
3. Выполнит миграции.
4. Зальет проект на сервер.

Предусмотрите откат, например, через Spatie Laravel Backup. Если что-то пойдет не так, у вас должна быть возможность вернуть предыдущую версию.

Инструмент Sentry поможет отслеживать ошибки, а New Relic — оценивать производительность.

Заключение

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

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

TinyGo, MIPS и странности платформы

PS2 построена на процессоре MIPS R5900 (архитектура MIPS-III с расширениями), который не поддерживается стандартной сборкой Go. Проблему частично решает TinyGo, который компилирует Go-код в LLVM IR.

Но даже с ним возникли сложности: ни LLVM, ни сам TinyGo не умеют работать с особенностями PS2 «из коробки». Пришлось вручную описывать платформу через ps2.json, определять baremetal-окружение, runtime и заглушки под прерывания.

Первые успехи: «Hello from Go»

Чтобы код TinyGo можно было линковать с библиотеками из ps2dev (а они скомпилированы под ABI N32), автору пришлось добиваться совместимости: целиться в MIPS-III, использовать hard-float, отключать abicalls и собирать IR с последующей ручной сборкой объектника через Clang с нужными флагами.

После успешного линка и запуска в эмуляторе PCSX2 программа вывела строку и число на отладочный экран PS2.

Собственный main() и отладка

Дальше автор отказался от загрузчика на C и написал полноценный main() на Go, вручную выделяя память под кучу и завершая программу через exit() из ps2dev. Он добавил простую обёртку над scr_printf() — теперь можно печатать текст прямо из Go.

DDIVU и проклятие деления

Серьёзным багом стал сбой fmt.Sprintf: PS2 не поддерживает инструкцию DDIVU, которую LLVM генерирует при делении uint64.

Автор обошёл это, подключив функции __udivdi3, __divdi3 и прочие, а затем пропатчил компилятор TinyGo, чтобы он использовал их при делении int64 и uint64.

Что дальше

Демо работает. Go-код запускается напрямую, выводит текст и корректно делит числа.

Впереди — системные вызовы, inline-ассемблер, поддержка прерываний и, возможно, новая цель в LLVM для процессора r5900.

На типичные вопросы Junior-разработчик должен легко ответить. Вместе с Альбертом Халимовым, TeamLead Frontend Developer в Группе М.Видео-Эльдорадо и ментором Эйч Навыки, разбираемся в тех же вопросах, но смотрим на них под другим углом и узнаем самое главное — готовы ли быть мидлом.

1. Что такое оператор typeof?

Вызов typeof x возвращает строку с именем типа:

2. Что вернет typeof null, typeof new Date, typeof alert?

Date — это встроенный объект, который содержит дату и время, а также предоставляет методы управления ими.

Результатом вызова typeof null является "object". Это официально признанная ошибка в typeof, берущая начало еще со времен создания JavaScript и сохраненная для совместимости. Конечно, null — не объект. Это специальное значение с отдельным типом.

Вызов typeof alert возвращает "function", потому что alert — функция. Функции относятся к объектному типу. Но typeof обрабатывает их особым образом, возвращая "function". Так тоже повелось с момента создания JavaScript. Формально это неверно, но может быть удобным на практике.

Интересный факт: информация об операторе typeof — это последний пункт главы «Типы данных» на https://learn.javascript.ru/.

3. Что такое NaN? Какого типа это значение? Как можно узнать, равно ли значение переменной NaN?

NaN расшифровывается как "Not A Number", это "false" (ложное) значение. Будьте аккуратны: выражение typeof NaN возвращает тип Number. Чтобы проверить значение переменной на соответствие NaN, нужно воспользоваться встроенным методом isNaN() или оператором тройного равенства ===.

4. Какие есть способы объявления функций? В чем их отличия? Что такое стрелочная функция?

Ниже рассмотрим ключевые отличия Function Declaration от Function Expression.

Во-первых, синтаксис: Function Declaration — функция объявляется отдельной конструкцией function… в основном потоке кода.

Function Expression — функция, созданная внутри другого выражения или синтаксической конструкции. В данном случае функция создается в правой части «выражения присваивания» =:

Более тонкое отличие появляется тогда, когда функция создаётся движком JavaScript. Так, Function Expression появляется в то время, как выполнение доходит до него, и затем уже может использоваться.

После того, как поток выполнения достигнет правой части выражения присваивания let sum = function…, функция считается созданной и может быть использована (присвоена переменной, вызвана и т.д. ).

С Function Declaration всё иначе. Она может быть вызвана раньше, чем объявлена. Другими словами, когда движок JavaScript готовится выполнять скрипт или блок кода, прежде всего, он ищет в нём Function Declaration и создаёт все такие функции. Можно считать этот процесс «стадией инициализации».

Только после того, как все объявления Function Declaration будут обработаны, продолжится выполнение. В результате функции, созданные как Function Declaration, могут быть вызваны раньше своих определений.

Например, будет работать так:

Функция sayHi была создана, когда движок JavaScript подготавливал скрипт к выполнению, и такая функция видна повсюду в этом скрипте.

Если бы это было Function Expression, то такой код вызвал бы ошибку:

Функции, объявленные при помощи Function Expression, создаются тогда, когда выполнение доходит до них. Это случится только на строке, помеченной звёздочкой (*). Слишком поздно.

Ещё одна важная особенность Function Declaration заключается в её блочной области видимости.

В строгом режиме, когда Function Declaration находится в блоке {...}, функция доступна везде внутри блока, но не снаружи.

Для примера давайте представим, что нам нужно объявить функцию welcome() в зависимости от значения переменной age, которое мы получим во время выполнения кода. И затем запланируем использовать её когда-нибудь в будущем.

Если мы попробуем использовать Function Declaration, это не заработает так, как задумывалось:

Это произошло, так как объявление Function Declaration видно только внутри блока кода, в котором располагается.

Вот ещё один пример:

Что можно сделать, чтобы welcome была видна снаружи if? Верным подходом будет воспользоваться функцией, объявленной при помощи Function Expression, и присвоить значение welcome переменной, объявленной снаружи if, что обеспечит нам нужную видимость.

Такой код заработает, как ожидалось:

Или мы могли бы упростить это ещё сильнее, используя условный оператор:

Так когда использовать Function Declaration, а когда Function Expression?

Как правило, если нам понадобилась функция, нужно рассматривать синтаксис Function Declaration, который мы использовали до этого. Он даёт больше свободы в том, как мы можем организовывать код. Функции, объявленные таким образом, можно вызывать до их объявления.

Также функции вида function f(…) {…} чуть более заметны в коде, чем let f = function(…) {…}. Function Declaration легче «ловятся глазами».

…Но если Function Declaration нам не подходит по какой-то причине или нам нужно условное объявление (мы рассмотрели это в примере выше), то следует использовать Function Expression.

5. Что такое функции высшего порядка? Приведите примеры.

Функции высшего порядка — это функции, которые могут:

1. Принимать функции в качестве аргументов.
2. Возвращать функции как результат своей работы.

Вот встроенные функции высшего порядка в JavaScript:

• map() — применяет функцию ко всем элементам массива.
• filter() — фильтрует элементы массива на основе условия.
• reduce() — сводит массив к одному значению, применяя функцию.

6. Что такое Promise и какие бывают состояния?

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

Промис может находиться в одном из трех состояний:

• Pending — исходное состояние промиса. Он находится в ожидании выполнения или отклонения операции.
• Fulfilled — промис переходит в это состояние, когда операция успешно завершается.
• Rejected — промис переходит в это состояние, когда операция завершается с ошибкой. Здесь промис возвращает причину ошибки.

Пример:

7. Как сравнивать в JS? Как сравнить два массива?

Когда вы сравниваете примитивные типы (числа, строки, булевы значения и т.д.), используются операторы == (нестрогое сравнение) и === (строгое сравнение).

== проверяет равенство значений после приведения типов.

=== проверяет как равенство значений, так и типов (без приведения типов).

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

Можно преобразовать массивы в строки JSON и сравнить их. Это удобный способ, но он имеет несколько ограничений (например, порядок элементов в массиве имеет значение).

Для более точного сравнения массивов (в том числе с вложенными структурами) можно пройтись по каждому элементу массива с помощью цикла for или методов every/some.

8. Чем отличаются any, unknown и never?

Основные различия:

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

9. Что такое CORS и как его можно решить на фронтенде?

CORS — механизм безопасности, который предотвращает доступ к данным с других источников. Чтобы решить проблемы с CORS:

• На фронтенде можно использовать прокси-серверы для разработки.
• В продакшн-окружении необходимо настроить CORS на сервере.
• Если вы не контролируете сервер, то решением будет обращение к разработчикам API или использование серверного прокси для обхода ограничений.

10. Что такое Progressive Web Apps (PWA)? Зачем нужно?

Progressive Web Apps (PWA) — тип веб-приложений, который использует современные веб-технологии для предоставления пользователям опыта, схожего с нативными мобильными приложениями, но через обычный веб-браузер. PWA можно использовать в любом браузере, который поддерживает стандарты веба. Такие приложения могут работать оффлайн, присылать пуши, быстро загружаться и подстраиваться под любой браузер, который поддерживает эти фичи. Из примеров — банковские веб-приложения, которые можно установить на экран.

Вот главные особенности PWA:

• Работа в оффлайн-режиме (Offline-first). PWA используют Service Workers, которые позволяют веб-приложению работать даже без интернета. Это значит, что приложение может кешировать данные и ресурсы, обеспечивая доступность контента в оффлайн-режиме или при плохом интернет-соединении.
• Установка на устройство (Installable). PWA можно устанавливать на устройства как нативные приложения. При этом скачивать их из магазина пользователю не нужно.
• Push-уведомления. PWA могут отправлять push-уведомления — так пользователь может получать информацию, даже если приложение закрыто.
• Обновления. Приложения могут автоматически обновляться в фоновом режиме.
• Мгновенная загрузка. PWA загружаются быстрее, так как они используют кэширование ресурсов и данных через Service Workers — это улучшает производительность даже при медленном интернете.
• Универсальность. PWA работают на всех платформах (мобильные устройства, десктопы, планшеты) и в любых браузерах, которые поддерживают современные веб-стандарты (например, Chrome, Firefox, Safari, Edge и т.д.).

11. Lifecycle во Vue: когда использовать хуки жизненного цикла?

В Vue 2 жизненный цикл выглядит следующим образом:

beforeCreate → created → beforeMount → mounted → beforeUpdate → updated → beforeDestroy → Destroyed

В Vue 3 жизненный цикл был немного изменен и улучшен. Некоторые хуки переименованы:

beforeDestroy → beforeUnmount

destroyed → unmounted

Кроме того, в Vue 3 появилась возможность использовать Composition API, который предоставляет более гибкий способ организации жизненного цикла компонентов. Теперь можно создавать компоненты с помощью функции setup().

Когда использовать хуки жизненного цикла?

• beforeCreate и created используются для настройки данных, свойств или методов компонента до и после его создания.
• beforeMount и mounted полезны для операций, которые необходимо выполнить при рендере компонента (например, вызов API, настройка сторонних библиотек, или выполнение начальной логики).
• beforeUpdate и updated можно использовать для наблюдения за изменениями данных или для манипуляций с DOM до или после его обновления.
• beforeDestroy и destroyed (или beforeUnmount и unmounted в Vue 3) полезны для очистки ресурсов перед уничтожением компонента.

12. В каком компоненте отработает mounted вначале — дочернем или родительском?

В Vue.js хук mounted вызывается для компонента, как только его DOM вставляется в дерево DOM. Когда компонент — часть иерархии (например, родительский и дочерний компоненты), хуки жизненного цикла выполняются в определенном порядке.

Хук mounted будет вызван для дочернего компонента перед родительским.

Объяснение: родительский компонент инициирует рендеринг и монтирование дочернего компонента. Когда Vue монтирует компоненты, он сначала монтирует все дочерние компоненты, а потом родительский компонент. Это связано с тем, что родительский компонент ждет завершения монтирования дочерних компонентов, чтобы их правильно вставить в DOM.

13. Как изменить commit message

1. Изменить последний коммит

Если нужно изменить сообщение только последнего коммита, используйте команду:

git commit --amend

После этого Git откроет редактор, где вы сможете изменить сообщение коммита. Сохраните изменения и выйдите из редактора.

2. Изменить старый коммит

Если нужно изменить сообщение не последнего коммита, а более старого, можно воспользоваться rebase:

git rebase -i <commit_id>

Здесь <commit_id> — идентификатор коммита, сообщение которого вы хотите изменить. Можно использовать git log для получения ID нужного коммита. В открывшемся файле замените слово pick на reword напротив коммита, который хотите изменить, и сохраните файл. Git откроет редактор для изменения сообщения этого коммита. После редактирования сохраните и выйдите.

Завершите процесс rebase:

git rebase --continue

3. Изменить сообщение в уже отправленном коммите (Push)

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

Измените коммит с помощью git commit --amend или git rebase -i.

После изменения выполните принудительный пуш:

git push --force

Пожалуйста, перед собеседованием повторите CSS. Многие разработчики усиленно готовятся к технической сессии по JS, TS, своему фреймворку, но забывают о верстке. Если вам повезет работать над новым продуктом, то верстка будет занимать больше половины времени.

14. Что такое псевдоклассы в CSS? Как обратиться к псевдоклассу в JS?

Псевдоклассы в CSS — стили, которые применяются к элементам в зависимости от их состояния или структуры в документе.

В JavaScript нельзя напрямую изменить псевдоклассы, но можно использовать селекторы CSS для выбора элементов с псевдоклассами. Это делается с помощью методов по типу querySelector и querySelectorAll.

15. Что такое dvh, lvh, em и rem в CSS? Когда и почему лучше использовать каждую из этих единиц измерения?

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

• dvh (dynamic viewport height) — единица измерения, которая учитывает динамические изменения в размерах окна, например, высота при открытии клавиатуры на мобильных устройствах.
• lvh (large viewport height) — единица измерения, которая использует максимальную высоту вьюпорта, независимо от динамических изменений (например, не учитывает изменения, связанные с клавиатурой на мобильных устройствах).

Когда использовать:

• dvh полезен, когда нужно учитывать изменения размера окна при взаимодействии с мобильными устройствами (например, при открытии клавиатуры).
• lvh полезен для работы с мобильными устройствами, когда нужно обеспечить стабильный дизайн, не зависящий от изменения высоты вьюпорта из-за динамических изменений.
• em — это единица измерения, которая зависит от размера шрифта родительского элемента. 1em равен текущему размеру шрифта родительского элемента. Если в родительском элементе установлен шрифт размером 16px, то 1em будет равен 16px.
• rem — это единица измерения, которая зависит от размера шрифта корневого элемента (<html>). 1rem равен размеру шрифта, установленному на корневом элементе (по умолчанию в большинстве браузеров это 16px).

Когда и зачем использовать каждую из этих единиц?

• dvh/lvh: Используйте, если вам нужно учитывать динамическое изменение высоты вьюпорта (например, на мобильных устройствах при открытии клавиатуры) или если вам нужно работать с максимальной высотой вьюпорта, независимо от динамических изменений.
• em: Используйте, когда размеры элементов должны зависеть от размера шрифта родительского элемента. Это полезно для создания гибких и адаптивных макетов, которые изменяются с размером шрифта.
• rem: Используйте, когда нужно, чтобы размеры были относительно размера шрифта корневого элемента. Так проще поддерживать единообразие и легко масштабировать весь интерфейс.

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

Что вообще такое context collapse

Есть вероятность, что вы слышите этот термин в первый раз. Немного лирики: в мире микросервисов есть два понятия: технический контекст и доменный контекст (Bounded Context).

Технический контекст

Технический контекст — это информация, которая передается между микросервисами для выполнения запросов или операций. В нем лежит большое количество данных: идентификаторы запросов (например, TraceID в трассировке), пользовательские сессии, метаданные или параметры аутентификации.

Без технического контекста микросервисы не могут:

• отслеживать, откуда пришел запрос и куда он направляется,
• сохранять согласованность данных между сервисами,
• выявлять сбои (например, через логи или трассировку).

Доменный контекст (Bounded Context)

Доменный контекст происходит из методологии Domain-Driven Design (DDD) — это про четкое разделение бизнес-логики между микросервисами. У каждого сервиса должна быть своя «ограниченная область» (Bounded Context), где термины, данные и правила имеют уникальное значение.

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

Без доменного контекста:

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

Вернемся к коллапсу контекста

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

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

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

Что на самом деле происходит

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

Сервис теряет важное состояние, например:

• «Это корзина Пети»
• "Этот платеж уже прошел"

И начинается хаос: дублирующиеся API-запросы, потерянные транзакции или, что еще хуже, повреждение данных.

В 2025 году появляется все больше слишком фрагментированных архитектур и гипермасштабируемых систем. Ваши запросы могут проходить через 10, 20 и даже 30 сервисов, но если на каком-то этапе отвалился контекст, то это конец.

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

Как понять, что контекст вот-вот может «коллапснуться»

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

• Всплеск пинга: сервисы запрашивают данные, которые должны бы уже знать, создавая огромное количество лишних вызовов и перегружая API.
• Дублирующиеся действия: повторные списания, задвоенные отправки писем, неожиданные повторные заказы. Пользователи возмущены, рейтинг падает.
• Мистические баги: логи говорят «всё в порядке», но результат явно неверный. Код не видит проблему, а отладка превращается в кошмар.

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

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

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

Опрос CNCF за 2024 год показал, что 68% команд, которые используют микросервисы, сталкиваются с необъяснимыми проблемами производительности. И всему виной в том числе контекстный коллапс.

5 решений, как бороться с контекстным коллапсом

Да, контекстный коллапс — крайне неприятный баг. Главное — чтобы все сервисы работали слаженно и «знали» друг друга.

1. Правильно передавайте контекст

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

Вот пример реализации middleware автором на Go:

2. Кэшируйте с умом

Нет смысла заставлять сервисы угадывать, если они просто могут запомнить. Быстрый кэш, например, с Redis, может хранить временный контекст — например, токены сеанса или состояния запросов, — поэтому сервисы не будут постоянно спрашивать «кто это?» Вот фрагмент кода на Питоне, где используется Redis для хранения и извлечения контекста:

Это позволяет поддерживать контекст во всех вызовах, не перегружая вашу базу данных. А еще TTL (time-to-live) Redis сам за собой убирает — устаревшие данные не скрываются.

3. Используйте Event-Driven Architecture

Микросервисы без сохранения состояния выглядят отлично, пока не контекст не коллапснется. Событийная архитектура идет от обратного: вместо того чтобы надеяться, что службы все запомнят, регистрируйте каждый шаг как событие. Если служба все-таки забудет, воспроизведите поток. Вот пример на Node.js с Kafka:

Здесь также можно использовать RabbitMQ. В общем, больше никаких отговорок со стороны сервиса из разряда «я забыл».

4. Проверяйте логи

Когда контекст теряется, логи — ваше место преступления. Настройте Grafana Loki или Datadog для поиска «потерянных контекстов». Вот пример с Grafana:

Тэгните логи с помощью request_id или user_id, а затем вызовите Loki:

5. Тестируйте на коллапсы

Профилактика лучше, чем лечение. Добавьте хаос-тестирование с помощью, например, Chaos Mesh, чтобы моделировать потери контекста.

Хаос-тестирование — это метод преднамеренного введения сбоев в систему, чтобы проверить, насколько она устойчива и надежна. Обычное тестирование и мониторинг могут выявить проблемы, но хаос-тестирование (Chaos Engineering) помогает увидеть, как система поведет себя в случае неожиданных отказов.

Прервите mid-requests к сервисам — сможет ли система восстановится в таком случае? Если нет, значит, ваша передача контекста недостаточно надежна.

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

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

Ошибка №1: API, завязанный на внутренней структуре

Проблема: API отражает внутреннюю логику, заставляя клиентов разбираться в БД.

⛔ GET /api/database/tables/book_inventory/records?status=1

✅ GET /api/books?available=true

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

Ошибка №2: Кривые URL и HTTP-методы

Некоторые API добавляют глаголы в пути или усложняют структуру.

⛔ POST /api/deleteCustomer/456

✅ DELETE /api/customers/456

Также не стоит делать глубокую вложенность. Например:

⛔ GET /api/companies/456/departments/2/employees/123/projects

✅ GET /api/projects?employeeId=123

Ошибка №3: Игнорирование обработки ошибок

⛔ Самый раздражающий ответ:

✅ Как правильно:

Четкие коды ошибок экономят время и нервы разработчиков.

Ошибка №4: Отсутствие версионирования

Если API обновляется без версионирования, старые клиенты ломаются. Пример правильного подхода:

GET /api/v1/users

Accept: application/vnd.company.api+json;version=1

Важно не удалять старые версии без предупреждения.

Ошибка №5: Слишком много данных в ответах

Распространенная проблема — это когда API отдает всю информацию, даже если она не нужна.

Куда правильнее будет позволять клиенту выбирать поля (fields=id,name,email) и Делить данные на отдельные запросы (GET /api/users/123/orders).

Ошибка №6: Проблемы с безопасностью

Одной из самых частых ошибок с точки зрения безопасности является передача токенов в URL (?token=123). Также начинающие разработчики реализуют API, в которых отсутствуют ограничения запросов (Rate Limit) или используется HTTP вместо HTTPS.

Исправить это достаточно просто. Нужно использовать OAuth2/JWT и ограничивать частоту (HTTP 429).

Ошибка №7: Плохая документация

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

Наиболее частые проблемы по этой части:

• Нет примеров кода
• Непонятно, как авторизоваться
• Ошибки не объясняются

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

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

Data Scraper — извлечение данных с веб-страниц

Ссылка на расширение

Для чего? Автоматический сбор таблиц, списков и других данных с сайтов. Он загружает данные в CSV, Excel или Google Sheets без необходимости программирования.

Пример использования. Вы анализируете цены конкурентов в интернет-магазинах и хотите собрать данные о стоимости товаров. Data Scraper автоматически извлекает нужные элементы и экспортирует их в таблицу.

✅ Плюсы: удобство, простота настройки, экспорт в популярные форматы.

❌ Минусы: ограниченная бесплатная версия, не работает на защищенных сайтах.

Web Scraper — мощный инструмент для автоматизированного сбора данных

Ссылка на расширение

Для чего? Глубокий парсинг с поддержкой вложенных страниц. Инструмент настраивает сценарии обхода динамических сайтов и сбора их данных.

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

✅ Плюсы: гибкость, автоматический обход страниц.

❌ Минусы: требует понимания HTML-структуры сайтов.

Awesome Table — превращение данных в интерактивные отчёты

Ссылка на расширение

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

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

✅ Плюсы: легкость настройки, хорошая интеграция с Google.

❌ Минусы: ограничения в бесплатной версии.

Octoparse — мощный инструмент для парсинга данных

Ссылка на расширение

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

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

✅ Плюсы: Не требует знаний программирования; поддерживает сложные сценарии парсинга (например, клик по кнопке «Показать ещё»).

❌ Минусы: Ограниченный функционал в бесплатной версии; может не работать с сайтами, защищёнными от ботов (например, Cloudflare)

Selenium IDE — автоматизация тестирования прямо в браузере

Ссылка на расширение

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

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

✅ Плюсы: Возможность экспорта сценариев в разные языки (Python, Java, JavaScript).

❌ Минусы: Ограниченные возможности по сравнению с полноценным Selenium WebDriver.

Google Analytics Debugger — отладка событий в GA

Ссылка на расширение

Для чего? Проверка корректности передачи данных в Google Analytics. Показывает, какие события отправляются в аналитику.

Пример использования. Если в аналитике не отображаются клики по кнопке «Купить», Debugger поможет понять, передаются ли данные в систему.

✅ Плюсы: подробные логи, быстрая диагностика проблем.

❌ Минусы: поддерживает только Universal Analytics, не GA4.

DataLayer Checker — проверка передачи данных

Ссылка на расширение

Для чего? диагностика переменных DataLayer в GTM. Показывает, какие данные передаются на сайт.

Пример использования. Хотите убедиться, что в аналитику передаются все параметры заказа? DataLayer Checker покажет их в реальном времени.

✅ Плюсы: помогает в настройке e-commerce аналитики.

❌ Минусы: сложен для новичков.

Tableau Chrome Extension — удобная работа с дашбордами

Ссылка на расширение

Для чего? Облегчает доступ к дашбордам Tableau. Загружает отчеты без необходимости заходить на сайт.

Пример использования. Вы работаете в команде аналитиков и хотите быстро проверять дашборды Tableau прямо из браузера.

✅ Плюсы: ускоряет доступ к данным.

❌ Минусы: требует подписки на Tableau.

Block Yourself from Analytics — исключение собственного трафика

Ссылка на расширение

Для чего? Чтобы не учитывать свои визиты в Google Analytics.

Пример использования. Вы администратор сайта и не хотите искажать данные в GA своими посещениями.

✅ Плюсы: легко включается и выключается.

❌ Минусы: работает только в Chrome.

Table Capture — копирование таблиц с сайтов

Ссылка на расширение

Для чего? Экспорт таблиц с сайтов в Excel и Google Sheets.

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

✅ Плюсы: это, как минимум, удобно.

❌ Минусы: не всегда корректно распознает сложные таблицы.

JSONView — удобное представление JSON-данных

Ссылка на расширение

Для чего? Форматирование JSON-файлов в читаемый вид.

Пример использования. Вы работаете с API и хотите быстро понять структуру JSON-ответов.

✅ Плюсы: цветовая подсветка.

❌ Минусы: не редактирует JSON.

Scraper — быстрый экспорт данных с сайтов

Ссылка на расширение

Для чего? Извлекает текстовые и табличные данные с веб-страниц без сложных настроек.

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

✅ Плюсы: прост в использовании, есть интеграция с Google Sheets.

❌ Минусы: ограниченный функционал по сравнению с Web Scraper.

Wappalyzer — определение технологий сайтов

Ссылка на расширение

Для чего? Показывает, какие CMS, языки программирования, аналитические сервисы и рекламные сети использует сайт. Полезен для конкурентного анализа и технических исследований.

Пример использования. Вы изучаете сайты конкурентов и хотите понять, какие технологии они применяют (используют ли Google Tag Manager и т.д.).

✅ Плюсы: удобный интерфейс, быстрый анализ.

❌ Минусы: иногда пропускает редкие технологии.

OpenLink Structured Data Sniffer — анализ структурированных данных

Ссылка на расширение

Для чего? Извлекает и анализирует JSON-LD, RDF на сайтах. Помогает проверить корректность разметки страниц для поисковых систем.

Пример использования. Вы работаете с SEO и хотите проверить, правильно ли настроены schema.org-разметки на сайте клиента.

✅ Плюсы: детализированный анализ.

❌ Минусы: требует знаний о структурированных данных.

Tag Assistant — анализ работы тегов Google

Ссылка на расширение

Для чего? Проверка корректности работы Google Tag Manager, Analytics и Ads. Анализирует теги, выявляет ошибки в их настройке.

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

✅ Плюсы: удобный интерфейс, анализ сразу всех тегов Google.

❌ Минусы: требует знаний о работе тегов.

А какими расширениями пользуетесь вы? Делитесь в комментариях!

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

Узнаем, что собой представляют cookies, localStorage и sessionStorage, каковы их основные характеристики и особенности, как они применяются и какой способ работы с данными лучше.

Cookies

На заре интернета cookies были безальтернативным вариантом хранения данных на стороне клиента. Файлы куки представляют собой элементарные пары типа «ключ-значение» и используются для:

• управления текущими сессиями;
• персонализации пользователя;
• отслеживания его активности.

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

По сути куки — это ограниченные по размеру текстовые файлы, которые сайт сохраняет на устройстве пользователя. Объем данных в «печеньках» лимитирован — это не больше 4 КБ, при этом у них есть срок хранения, который устанавливает разработчик ресурса.

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

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

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

Закрепим основные характеристики cookies:

• сохраняют данные, которые передаются на сервер с помощью заголовков;
• локальные и сессионные куки-хранилища существуют только на стороне клиента;
• сроки хранения устанавливаются заранее при создании куков;
• объем ограничен (4 КБ);
• бывают защищенные куки, но в этом случае их содержимое будет недоступным на клиентской стороне — такой формат используется для аутентификации пользователей при хранении их токенов.

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

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

Разработчики на JavaScript используют свойство document.cookie, которое предоставляет строковый формат для работы всех cookies, связанных с текущим процессом. Пример кода:

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

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

Разработчики устанавливают и читают cookie через заголовки Set-Cookie и Cookie непосредственно в протоколе HTTP. В приложениях куки устанавливают и считывают с помощью соответствующего API либо модуля файлов cookie на одном из серверных языков — например, Node.js.

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

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

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

LocalStorage

Это более продвинутый формат хранилища в браузере, позволяющий сайтам сохранять больше информации без ущерба для трафика. LocalStorage создали в качестве альтернативы cookie, чтобы обойти ограничения последних. А именно — небольшой объем хранилища, необходимость постоянно передавать данные с сервера в браузер и обратно. В localStorage работа с данными стала проще и эффективнее.

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

Информация хранится в формате «ключ-значение» в виде строк. Даже если ввести числовые или логические данные, они преобразуются в строчные. Для использования хранилища в JavaScript используют объект localStorage.

Пример кода:

Запись напоминает код для сеансового хранилища. Метод setItem() используется для хранения данных, метод getItem() — для их получения, removeItem() — для удаления конкретных элементов, clear() — для полной очистки данных. Несмотря на то, что в localStorage сохраняются только строки, с помощью JSON разработчики могут взаимодействовать и с более сложными типами данных.

Основные характеристики localStorage:

• данные хранятся бессрочно;
• очистить хранилище можно только принудительно — через код JavaScript или полную очистку браузерного кэша пользователем;
• объем данных для хранения — 5-10 МБ (по этому показателю localStorage лидирует среди всех хранилищ);
• старыми браузерами не поддерживается — например, на IE7 это локальный ящик не работает;
• действует по принципу ограничения домена — сохраненная информация доступна лишь одному источнику.

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

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

SessionStorage

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

Объем хранилища ограничен, но в большинстве случаев этого достаточно для хранения инфы в пределах одного сеанса. Данные по сути не защищены, так что вопрос приватности — забота пользователя.

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

Для подключения сеансового хранилища разработчики на JavaScript используют объект sessionStorage и методы для получения, установки и удаления данных.

Пример кода:

Как видите, есть определенное сходство с localStorage, поскольку у хранилищ одинаковый алгоритм работы. Метод setItem() применяется для сохранения данных (первый аргумент — ключ, второй — значение), метод получения — removeItem(), для очистки используется метод clear().

Основные характеристики sessionStorage:

• данные хранятся в течение одной сессии, после закрытия браузера очищаются;
• хранилище использует контекст браузера верхнего уровня, то есть в каждой вкладке содержатся уникальные данные;
• объем данных — 5 МБ;
• старые браузеры формат не поддерживают.

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

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

Сравнение cookies, localStorage и sessionStorage

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

Размер хранилища

• Файлы cookie. Здесь размер минимальный. Для каждого домена куки могут хранить ограниченный объем данных — как правило, не больше 4 КБ.
• LocalStorage. Максимально возможный объем данных для каждого домена — не менее 5 МБ, а при использовании определенных настроек и больше.
• SessionStorage. Здесь хранится больше данных для одного домена в сравнении с cookies. Размер — не более 5 МБ.

Срок хранения

• Файлы cookie. Данные куки могут быть сеансовыми или постоянными в зависимости от настроек. Постоянные имеют свой срок действия, который исчисляется месяцами или даже годами, сеансовые уничтожаются сразу после завершения сеанса.
• LocalStorage. Данные в локальном хранилище остаются после закрытия браузера и его повторного открытия. Удалить их может только пользователь или код JavaScript.
• SessionStorage. Информация в сеансовом хранилище остается, пока открыта вкладка сайта. При закрытии данные удаляются.

Работа с данными

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

Доступ к данным

• Cookies. Доступ к файлам можно получить и изменить через JavaScript API, но существуют определенные ограничения для третьих лиц.
• LocalStorage и sessionStorage. Есть прямой доступ к информации в хранилищах через API JavaScript, который позволяет манипулировать данными.

Сетевой трафик

• Cookies. Данные автоматически отправляются на север после каждого HTTP-запроса для соответствующего домена, что увеличивает загрузку трафика.
• LocalStorage и sessionStorage. Данные не отправляются на сервер, а остаются на стороне клиента, что сокращает объем лишнего трафика.

Когда использовать cookies, localStorage и sessionStorage

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

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

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

Проблемы и перспективы хранилищ данных

Все хранилища потенциально уязвимы для XSS-атак. В cookies применяют дополнительные меры защиты: флаги HTTPOnly и Secure запрещают доступ из JavaScript к файлам, чувствительным к безопасности. Для отправки таких файлов используется передача по шифрованным каналам HTTPS.

Для защиты от атак CSRF (подделка межсайтовых запросов) используют атрибут SameSite, проверку HTTP_Referer/Origin или применение синхронизированных токенов.

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

Учитывайте, что куки могут замедлять загрузку, особенно если у пользователей низкая скорость интернета. LocalStorage на HTTP-запросы не влияет, что положительно отражается на производительности веб-ресурса.

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

Анализируем производительность API

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

• Время отклика — сколько времени проходит от запроса до получения ответа.
• Нагрузка на сервер — сколько ресурсов потребляет API при обработке запросов.
• Частота ошибок — как часто сервер возвращает некорректные ответы.

Отслеживать эти показатели помогают инструменты вроде Postman, New Relic и APM-систем. Они визуализируют данные, автоматизируют тестирование и позволяют находить проблемы в режиме реального времени.

Postman

Используется для ручного тестирования запросов. Postman показывает время отклика и ошибки. Также через него удобно тестировать сценарии работы API.

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

Большой гайд по работе с Postman API Platform

New Relic

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

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

APM-системы

Инструменты Datadog, AppDynamics или Dynatrace сохраняют данные о том, как работает API. Через них можно смотреть трассировку запросов, выявлять проблемы с медленными вызовами или зависимостями от внешних систем.

Ищем узкие места в запросах

Для выявления проблемных фрагментов кода необходимо посмотреть, как API реагирует на разные нагрузки, и как распределяется время обработки запроса.

Поиск состоит из 7 этапов:

• Анализ общей картины. С помощью APM-систем и логирования нужно выделить самые медленные запросы.
• Локализация длинных операций. В одном запросе может быть несколько узких мест (тяжелый SQL-запрос, внешний API-вызов).
• Поиск запросов с высокой частотой вызовов. Например, запросы к слою авторизации или ручки API, к которым обращаются массово при каждом действии пользователя.
• Проверка ошибок. Ошибки приводят к дополнительной нагрузке: например, если клиент совершает повторные запросы после тайм-аута.
• Анализ распределения нагрузки. Если одни эндпоинты перегружены трафиком, а другие используются редко, в рамках рефакторинга нужно сбалансировать нагрузку. Например, добавить серверы только под обработку горячих эндпоинтов.
• Тестирование в условиях пиковой нагрузки. Стресс-тест средствами JMeter поможет выявить проблемы, скрытые в условиях обычного трафика.
• Анализ зависимостей API. Замедленная работа внешнего сервиса увеличивает время отклика для каждого запроса. Через Jaeger или Zipkin можно посмотреть цепочку зависимостей.
• Локализация длинных операций. В одном запросе может быть несколько узких мест (тяжелый SQL-запрос, внешний API-вызов).

Оптимизация запросов к базе данных

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

Что индексировать в первую очередь:

• Поля, используемые в WHERE, JOIN, ORDER BY, GROUP BY. Например, если запросы часто фильтруют по email, имеет смысл добавить индекс.

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

• Только те данные, где индексация действительно ускорит поиск. Например, индекс для gender (male/female) не даст прироста скорости.

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

Агрегация и выбор только необходимых полей

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

Например, команда SELECT * выбирает все колонки таблицы, включая неиспользуемые. Вместо SELECT * FROM users следует указывать целевые поля: SELECT id, name, email FROM users.

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

Снизить объем данных можно за счет COUNT, SUM, AVG, MAX, MIN — эти функции возвращают обобщенные записи вместо отдельных значений. Частичную обработку данных можно выполнять на стороне БД. Например, в PostgreSQL есть встроенные функции по типу JSON_AGG.

Пагинация и лимиты в запросах

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

Самое простое решение — во время рефакторинга ограничить количество строк с помощью LIMIT или FETCH FIRST. Например, вместо загрузки всех пользователей SELECT id, name FROM users LIMIT 30 вернет только первые 30 строк.

Еще можно использовать постраничную выборку (комбинацию LIMIT и OFFSET):

Если производительность упала, значит офсет слишком большой. В таких случаях лучше перейти на модель курсоров.

Пагинация с курсорами заменяет OFFSET значением последнего взятого элемента. Например, вместо LIMIT 20 OFFSET 100 можно использовать запрос:

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

Пагинация на Go в PostgreSQL

Кэширование

Количество запросов к серверу можно сократить, если сохранять часто запрашиваемые данные. Это называется кэшированием. Рефакторинг кэширования уменьшает нагрузку на сервер, снижает время отклика API.

Рассмотрим инструменты для кэширования.

Redis

Подходит для серверного и распределенного кэширования. Поддерживает TTL, работу со списками, хэшами и включение репликации для отказоустойчивости. Для интеграции доступны библиотеки и клиенты — ioredis для Node.js или StackExchange.Redis для .NET.

Как использовать Redis для кэширования и очередей в веб-приложениях

Рефакторинг кэширования повысит производительность сервиса:

• если API возвращает неизменяемые или редко изменяющиеся данные,
• если часть запросов к БД выполняется кратно дольше остальных.

Например, в Redis можно сохранять список активных пользователей:

Memcached

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

Как использовать серверы Redis и Memcached для кэширования

Виды кэша

Выбор типа кэширования зависит от архитектуры API и характера данных.

• Клиентский кэш — данные хранятся на стороне клиента. Например, браузеры загружают страницу дольше в первый раз, но затем мгновенно извлекают её из кэша.
• Серверный кэш — данные сохраняются на сервере или в промежуточном хранилище (Redis, Memcached). Это снижает нагрузку на базу данных: повторные запросы возвращаются из кэша, а не пересчитываются заново.
• Распределённый кэш — данные кэшируются в нескольких узлах для масштабирования и высокой доступности. Например, Redis в режиме кластера помогает организовать кэширование в микросервисной архитектуре.

Уменьшение объема передаваемых данных

Скорость API зависит от объема данных, передаваемых между клиентом и сервером.

Оптимизация формата ответа: JSON vs Protobuf

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

Protobuf (Protocol Buffers) — бинарный формат, разработанный Google. Он компактен, быстрее сериализуется и занимает меньше места по сравнению с JSON. В формате Protobuf каждый элемент закодирован с минимальным количеством байтов.

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

Удаление избыточных данных и компрессия

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

• Удаление ненужных полей — ограничение выборки данных на стороне сервера: используются выборочные запросы к БД, настройка сериализаторов или фильтрация на уровне представлений.
• Сжатие Gzip — уменьшение размера текстовых данных (JSON, XML) на 70–90%, не требуя изменений в API. Включается на уровне Nginx, Apache или через middleware. Клиенты автоматически распаковывают такие ответы, сохраняя прозрачность процесса.

Версионирование API

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

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

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

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

Параллелизация и объединение запросов

Оптимизировать API можно за счет рефакторинга batch-запросов. Они объединяют несколько запросов в один — количество обращений между клиентом и сервером сокращается.

Клиенты отправляют массив запросов, сервер обрабатывает их и возвращает всего один ответ.

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

Например, мобильное приложение может запрашивать информацию о пользователе и связанных с ним объектах (сообщения, уведомления) за один вызов.

Если API поддерживает вложенные запросы, клиент может запрашивать связанные данные одним вызовом. Пример на GraphQL:

Асинхронные операции

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

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

Для асинхронных операций часто используются очереди сообщений RabbitMQ или Apache Kafka.

Оптимизация на уровне серверной логики

Обработку запросов можно откладывать до момента, когда данные действительно понадобятся. Это полезно при работе с запросами, где связанная информация не требуется или используется не полностью. Такое поведение называется lazy loading (ленивая загрузка).

Загружать связанные данные можно заранее в одном запросе, чтобы сократить количество запросов к БД. Такой принцип работы API называется eager loading (стремительная загрузка). Используется в случаях, когда известно, что все связанные данные понадобятся в ходе операции.

Lazy loading подходит, если только небольшая связка данных используется в каждом запросе.

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

Очереди для обработки задач в фоне

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

Очереди используются для задач, не влияющих на основной ответ клиенту:

• отправка писем,
• формирование отчетов,
• обновление статистики,
• построение индексов,
• обработка данных.

При поступлении запроса API выполняет только основные операции (валидацию данных или запись в базу), после чего создает задачу в очереди. Процессы выполняются в отдельной среде, не влияя на основной поток обработки запросов.

Разделение сложных операций на этапы

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

Вместо последовательного выполнения всех шагов, задачу можно поручить системе планировщиков или pipeline в Jenkins. Каждый этап становится в очередь и выполняется отдельным процессом.

Мониторинг и тестирование

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

• нагрузочное тестирование,
• сравнение метрик до и после рефакторинга,
• автоматизацию наблюдения за состоянием API.

Нагрузочное тестирование определяет, как API справляется с возрастающей нагрузкой. Оно выявляет точки перегрузки. Инструменты для стресс-теста API: Apache JMeter, Gatling.

На основе результатов нагрузочного тестирования можно проанализировать, насколько рефакторинг улучшил производительность API. В сборе метрик помогут APM-инструменты.

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

Автоматизация мониторинга повышает надежность API и предотвращает проблемы до их масштабного проявления. Инструменты для поддержания производительности в реальном времени: Prometheus + Grafana, Datadog.

Что запомнить

• Производительность API оценивается с помощью метрик: времени отклика, нагрузки на сервер и частоты ошибок.
• Для мониторинга API используются инструменты Postman, New Relic и APM-системы, которые выявляют узкие места системы.
• Оптимизация запросов к базе данных включает индексацию, удаление избыточных операций и выбор только необходимых полей. Для работы с большими объемами данных используется пагинация с применением LIMIT, OFFSET или курсоров.
• Кэширование снижает нагрузку на сервер, сохраняя востребованные данные локально.
• Уменьшение объема передаваемых данных достигается за счет перехода с JSON на Protobuf, компрессии Gzip и фильтрации полей.
• Для сокращения числа запросов к API применяются batch-запросы.
• Асинхронная обработка операций с помощью очередей RabbitMQ или Kafka ускоряет время отклика API для клиентов.
• Очереди для фоновой обработки задач снижают нагрузку на основной поток запросов.
• Нагрузочное тестирование помогает оценить улучшения после рефакторинга.
• Автоматизация мониторинга предотвращает проблемы API до их критического проявления.

Есть спецификация API? Отлично!

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

Как эффективно работать со спецификацией:

• Разберите каждый эндпоинт: какие параметры обязательны, какие нет.
• Определите HTTP-методы (GET, POST, PUT, DELETE) и их назначение.
• Изучите форматы запросов и ответов (обычно JSON или XML).

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

Ищем спецификацию API и гуглим best practices

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

REST — не просто способ передачи данных, а архитектурный стиль, описанный Роем Филдингом. Его принципы помогают сделать API удобным, поддерживаемым и масштабируемым.

Ключевые best practices для REST API:

• Правильные HTTP-методы: GET — для получения, POST — для создания, PUT — для обновления, DELETE — для удаления.

• Четкие коды ответа: 200 — успех, 404 — ресурс не найден, 500 — ошибка сервера.

• Понятные URL: /users/123 вместо getUserById?id=123.

• Фильтрация и пагинация: если данных много, дайте пользователю инструменты для работы с ними.

Если API не следует этим принципам, это не просто вопрос удобства — возможны проблемы с поддержкой и интеграцией. В таком случае стоит обсудить с командой возможные доработки.

Если находим отличия от best practices — пишем разработчикам

Не все отклонения от best practices — ошибки. Иногда у команды есть технические или бизнес-обоснования для нестандартных решений. Главное — зафиксировать такие моменты и обсудить их с разработчиками.

Пример:

GET обычно используется для получения данных, но он ограничен длиной URL. Если запрос содержит сложные фильтры, иногда используют POST, хотя это и не соответствует стандарту. Важно выяснить, почему принято такое решение, и задокументировать его (кстати, еще примеры здесь).

Что делать при обнаружении отклонений:

1. Зафиксируйте отличие.
2. Запросите у разработчиков или аналитиков объяснение.
3. Если отклонение оправдано — внесите его в документацию.
4. Если это ошибка — обсудите с командой, как её исправить.

Фиксация таких нюансов упрощает поддержку API и снижает риск ошибок в будущем.

Пишем чек-лист или тест-кейсы

После изучения спецификации и обсуждения отклонений от best practices пора переходить к тестовой документации. В зависимости от требований проекта это может быть чек-лист или тест-кейсы.

Чек-лист: быстро и просто

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

Пример чек-листа:

Успешный запрос — отправить корректный запрос и убедиться, что API возвращает 200 OK с ожидаемыми данными.

Аутентификация — запрос без API-ключа должен вернуть 401 Unauthorized.

Некорректные параметры — передать текст вместо числа, убедиться, что API отвечает 400 Bad Request.

Тест-кейсы: подробно и детально

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

Пример тест-кейса:

Проверка метода GET для получения списка пользователей.

Предусловия:

• Доступ к API.
• В системе есть хотя бы один зарегистрированный пользователь.

Шаги:

• Отправить GET-запрос на /users.

• Проверить, что API отвечает 200 OK.

• Убедиться, что в ответе содержится список пользователей.

Ожидаемый результат:

Код ответа — 200, в теле ответа — массив объектов с полями id, name, email.

Как составлять тесты грамотно?

✔ Опираться на спецификацию. Тесты должны соответствовать заявленному поведению API.

✔ Думать как пользователь. Предусматривать реальные сценарии использования.

✔ Покрывать API полностью: позитивные и негативные кейсы, граничные значения.

Выбор между чек-листом и тест-кейсами зависит от требований проекта, но лучшее тестирование — всегда продуманное и системное тестирование.

Больше идей для проверок можно найти здесь.

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