// подход

Как мы работаем

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

Этап 1

Разбираем задачу

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

На выходе: список задач с оценкой эффекта и понимание, за что браться первым.

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

Этап 2

Проектируем и считаем

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

На выходе: архитектура, смета и честный ответ, стоит ли вообще браться.

Нужно решение по смете и приоритетам: что делаем сейчас, что откладываем.

Этап 3

Пишем и внедряем

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

На выходе: работающая система с метриками и планом отката на каждое изменение.

Нужен тестовый контур и согласованное окно для внедрения.

Этап 4

Сопровождаем

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

На выходе: система, которую может подхватить другая команда.

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

Правила, по которым мы трогаем прод

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

Боевые системы

Сначала отчёт, потом руки

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

Ничего не выкатывается само

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

Бэкап - это восстановление

Наличие файла бэкапа не значит ничего. Проверкой считается только успешное восстановление из него, и делать эту проверку надо до того, как она понадобится всерьёз.

Внедряем частями

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

Устойчивость к сбоям

Отказ одного узла не роняет систему

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

Наблюдаемость с первого дня

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

Версии зафиксированы

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

Безопасность и данные

Свежие релизы на прод не ставим

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

Секреты не живут в коде

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

Приватные данные остаются внутри

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

Инженерная дисциплина

Детерминированная проверка идёт перед моделью

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

Промпты - такой же код

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

Документация пишется для следующего

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

Что получаете в итоге

Качество

Код и архитектура проходят ревью. Тесты и мониторинг с первого дня, а не после инцидента.

Доступность

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

Надёжность

На каждое изменение есть план отката. Бэкапы делаются и проверяются восстановлением.

Чего не делаем

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

Если задача не наша, скажем прямо на первом же разговоре и по возможности подскажем, к кому идти.

Начинается всё с разбора задачи

Опишите, что есть сейчас и что мешает. Первый этап ничего не стоит.

Рассказать про задачу