Это база

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

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

Что рекомендую по теме:

1. Тонкости работы с PostgreSQL

Мой плотненький доклад на Podlodka PHP Crew (200+ слайдов за 1 час). Это мой же обновленный доклад с PHPRussia / Highload++.

Видео | Презентация

2. PostgreSQL 18 изнутри

Фундаментальная книга Егора Рогова. Если решили разобраться как следует и навсегда. Недавно вышло ее обновление под PG18.

Страница книги | PDF

3. SQL Performance Explained

Эталон баланса содержательности и объема. Можно прочитать за 2-3 вечера, при это всё ключевое дано. Крайне рекомендую.

Сайт книги (платная)

🔗 Инженерия и AI | Ilyas Salikhov

Как-то тут упоминал про Орфея (Orpheus), нашего сквозного AI-агента в RetailCRM. Вообще, одна из очевидных точек приложения агентов — техподдержка. В саппорте обычно выделяют линии поддержки: первая, вторая и тд, которые присутствуют и у нас. Плюс у нас есть процесс дежурств среди разработчиков: один из разработчиков выходит из спринтов на 2 недели и разбирает эскалированные обращения.

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

1. До разработки стало доходить на 37% меньше обращений
Это та часть вопросов, где для ответа клиенту нужно было посмотреть в код, релизы и логи. Раньше это могли сделать только инженеры, а сейчас даже первая линия может сделать такой анализ с помощью Orpheus.

2. Медиана решения вопроса разработчиком снизилась на 27%
Те сложные вопросы, что доходят до разработчиков, разбирать и инженерам стало проще, подключая Орфея.

2. Среднее время решения вопроса разработчиком снизилось на 40%
А вот тут интересно. На показатель среднего времени, в отличие от медианы, больше всего влияют «тяжелые» вопросы, которые не просто про «ответить», а там, где находится баг. Для бага готовят фикс, который проходит этапы задача-код-тесты-CI-деплой. Вопрос отмечаем решенным, когда фикс на проде.

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

Еще деталь. Если посмотрите на график, показатель падает все три месяца, поэтому за август снижение не 40%, а в 2 раза минимум.

—

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

Полнота и глубина данных, что доступны агенту, очень сильно определяет качество и правильность ответа. Про это нечасто говорят, но в AI-переходе это становится определяющим фактором. И если вы не оцифровывали работу компании в до-ai-йную эпоху, то у меня для вас плохие новости. Начать придется именно с этого.

А если нужно помочь с внедрением AI в вашу компанию, пишите нам в Интаро, поможем.

🔗 Инженерия и AI | Ilyas Salikhov

🔳▶️▶️▶️▶️▶️📦◀️◀️

Мы запустили AgentBox — облачные песочницы для ваших AI-агентов с полноценной Linux-средой. А теперь что это и для чего.

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

1. Безопасность. Агент может по ошибке испортить файлы в системе. А может и начать вылазить из вашего окружения. Также бывает нужно в зависимости от сессии давать разные доступы.
2. Изоляция сессий. Сессия не должна видеть данные и енвы других сессий.
3. Системные привилегии. Хорошо бы, чтобы агент мог поднимать docker-окружение проекта, если агент для разработчиков, а это требует системных привилегий. Тут кстати потребуется и изоляция, т.к. докеры разных сессий на одной машине могут начать толкаться локтями
4. Настраиваемая/подготовленная среда. Агент для решения задачи может ставить какой софт, пакеты. Или мы ему хотим заранее поставить пакеты. Пресловутые rg, jq. Но, может, и что-то более специфичное. У нас были кейсы, когда был нужен браузер.
5. Масштабируемость. Что делать, когда одной железки становится недостаточно?
6. Тестовое окружение. Для проверки агента у вас появятся evals. А их нужно где-то прогонять. Нужна воспроизводимая среда.

Мы стокнулись с этим и поняли: елки-палки, это в любом агентском проекте требуется. Не буду лукавить, делали с оглядкой на E2B. Песочницы на Firecracker. Есть готовые образы для популярных харнесов. Можно и свои образы собирать. SDK для TS, Python и гошки.

Запустились недавно, поэтому строго не судите. Но нашу обкатку платформа уже прошла: на ней работает Orpheus, а также AI-помощник в RetailCRM.

Новым аккаунтам кредиты 1000 ₽. Так что велкам)

🔗 Инженерия и AI | Ilyas Salikhov