Отвечаем в течение трёх рабочих дней

Пик нагрузки — это не инцидент.Это вторник.

Altessa Solutions строит высоконагруженные платформы, клиентские приложения и AI, которые держат продакшен. Вы говорите с инженерами, которые и будут делать работу, — с первого звонка.

Первый разборКак мы работаем
каждое изменение читает второй инженердо того, как оно дойдёт до продакшена
Что
Высоконагруженные платформы. Клиентские приложения. AI в продакшене.
Как
Фиксированный проект. Выделенная команда. Усиление команды.
Старт
Неделя разбора, старт в течение десяти рабочих дней.
Сферы
  • Финтех и платежи
  • Мобильность
  • Медиастриминг
  • Телеком
  • Медтех
  • Маркетплейсы

Почему мы начинаем с чтения

Нагрузка не ломает системы. Ломают решения, принятые за два года до неё.

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

§ 01 — Что мы делаем

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

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

01

Высоконагруженные платформы

GoJavaC#.NETKotlingRPCProtobuf 3KafkaNATSNATS JetStreamRabbitMQPostgreSQLMongoDBClickHouseRedisElasticsearchk8s

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

Обычно: 5–8 инженеров, 4–6 месяцев, SLO фиксируем письменно

  • 01Аудит архитектуры и план миграции
  • 02Платёжные, букинговые и стриминговые ядра
  • 03Миграция без простоя: двойная запись, бэкфилл, переключение
  • 04Нагрузочный стенд под ваш пик и учения по отказам
  • 05SLO, наблюдаемость, runbook’и для дежурств

02

Клиентские приложения

SwiftSwiftUIKotlinComposeKMPWinUIC#.NETQtC / C++Java

Нативные iOS, Android, macOS и Windows, с общим ядром там, где оно себя окупает. Offline-first данные, телеметрия с первого билда, релизы с фиксированным ритмом.

Обычно: 3–5 инженеров, 3–5 месяцев до стора, релиз каждые две недели

  • 01Windows 10/11, macOS, Linux, Android, iOS/iPadOS, watchOS
  • 02Релизы в сторы, CI, поэтапные выкатки
  • 03Телеметрия крэшей, латентности и воронок

03

AI в продакшене

PythonPyTorchvLLMTritonTensorRTONNXRayRAGMCPpgvectorQdrantLangGraphMLflow

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

Обычно: 2–4 инженера, 8–12 недель до первого продакшен-среза

  • 01Retrieval и поиск по вашим данным
  • 02Агентные сценарии с контрольными точками человека
  • 03Наборы оценок, через которые проходит каждое изменение модели
  • 04Запасной путь на случай недоступности провайдера
  • 05Свой инференс и контроль GPU-затрат

§ 02 — Примеры

Задачи, с которыми к нам обычно приходят.

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

«Всё падает в чёрную пятницу, а переписывать некогда».

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

Платформы · обычно 5–8 инженеров, 4–6 месяцев

«Релиз занимает квартал, и никто не знает почему».

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

Клиентские приложения · обычно 3–5 инженеров, 3–5 месяцев

«Демо на AI впечатлило, в продакшен не пошло».

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

AI в продакшене · обычно 2–4 инженера, 8–12 недель

Что вы видитеЧто под этим лежитЧто мы делаем

Каждая распродажа кончается инцидентом

Синхронные записи в одну базу, повторы платежей, ручной откат

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

Приложение выходит раз в квартал

Ручная регрессия, две кодовые базы, ветка, которую боятся влить

Общее Kotlin-ядро, автотесты регрессии, релиз раз в две недели

Поддержка не справляется с очередью

Знания в головах, ответы не воспроизводимы, AI-пилот не дошёл до продакшена

Retrieval по своим данным, оценки на каждый релиз, свой инференс

С чем приходят ещё

  1. 01

    Поиск тормозит по мере роста каталога

    Ранжирование вне основной базы, бюджет на каждый путь запроса

    3–4 мес
  2. 02

    Телеметрия переросла свою базу

    Приём в поток, история в колоночное хранилище, отчёты без таймаутов

    3 мес
  3. 03

    Две кодовые базы вместо одной команды

    Общее ядро на KMP, нативный UI там, где этого ждёт платформа

    3–5 мес
  4. 04

    Не осталось никого, кто писал систему

    Аудит, письменные решения и команда, которая сможет это вести

    от 1 нед

§ 03 — Как идёт работа

Пять шагов, начиная с одной недели.

Неделя разбора — отдельная платная работа, €12k фиксированно. На выходе архитектура, ранжированные риски и цена. Если что-то из трёх вас не устроит, на этом всё и заканчивается, а документы остаются у вас.

  1. 01неделя 1

    Неделя разбора

    Ваш код, ваши графики нагрузки, ваш дедлайн. Сначала читаем, потом говорим.

  2. 02конец недели 1

    Архитектура и оценка

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

  3. 03каждые 2 недели

    Двухнедельные итерации

    Инкременты на стейджинге, живое демо, burn-chart в приложении.

  4. 04перед запуском

    Нагрузочные тесты и запуск

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

  5. 05дальше

    Ведём или передаём

    Остаёмся на дежурстве или обучаем вашу команду и оставляем ей runbook’и.

Что у вас на руках после первой недели

  • Целевая архитектура и то, что мы бы оставили
  • Реестр рисков, ранжированный по радиусу поражения
  • Модель мощности на 18 месяцев вперёд
  • Состав команды, сроки и ценовой диапазон
  • Решение go / no-go, которое можно нести на борд
  • Всё это в вашем репозитории и остаётся вам

§ 04 — Команда

Кто проектирует систему, тот её потом и держит.

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

Бэкенд и платформа
18
Мобайл и десктоп
9
AI и данные
7
SRE, QA, дизайн
6

Принцип 01

Сеньоры

Медианный опыт — девять лет. Джуны учатся на наших внутренних инструментах, а не на вашем продакшене.

Принцип 02

Дежурим вместе с вами

Инженеры, которые построили систему, носят за неё пейджер.

Принцип 03

Решения письменно

Каждое архитектурное решение фиксируется в вашем репозитории, а не в переписке.

Принцип 04

Без lock-in

Ваше облако, ваши репозитории, ваш CI. Уйти от нас — это приглашение в календаре, а не миграция.

§ 05 — Форматы сотрудничества

Команда, проект или один специалист.

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

ФорматДля чегоКомандаСрокРитмОт
Фиксированный проектЗапуск с жёсткой датой4–8 человекот 3 месяцевЭтапы, фиксированная цена за фазу€100k / фаза
Выделенная командаПродуктовая линия целиком5–12 человекот 6 месяцевПомесячно, уведомление за 30 дней€9.5k / инженер / мес
Усиление командыКонкретные роли в ваших командах1–5 человекот 3 месяцевПочасово, таймшиты еженедельно€58 / час

Входит в каждый формат

  • Ставки — за инженера при 160 оплачиваемых часах в месяц
  • Delivery-лид и QA без отдельного счёта
  • Security-ревью перед каждым релизом
  • NDA и соглашение об обработке данных по GDPR
  • Полная передача прав по оплате
  • Письменный статус еженедельно, стиринг ежемесячно

§ 06 — Стек, за который отвечаем

Обычные инструменты, применённые аккуратно.

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

Бэкенд

GoJavaKotlinC#.NETC / C++PythonNode.jsRustSpring BootASP.NET CoregRPCProtobuf 3GraphQL

Веб и фронтенд

TypeScriptVue.jsNuxtNext.jsReactNode.jsViteWebSocketSSR

Данные и messaging

PostgreSQLMongoDBClickHouseElasticsearchRedisKafkaNATSNATS JetStreamRabbitMQDebeziumAirflow

Инфраструктура

KubernetesHelmDockerTerraformArgoCDGitHub ActionsAWSGCPBare metalPrometheusGrafanaOpenTelemetry

Мобайл и десктоп

iOSiPadOSwatchOSmacOSWindows 10/11AndroidLinuxSwiftSwiftUIKotlinComposeKMPC#.NETWinUIQtFlutter

Нагрузка и качество

k6GatlingJMeterTestcontainersPlaywrightpprofFailure drills

AI и ML

PyTorchvLLMTritonTensorRTONNXRayRAGMCPpgvectorQdrantLangGraphMLflowClaude / OpenAI API

§ 07 — Открытый код

Что мы публикуем.

Библиотеки, выделенные из клиентских проектов, и заметки, написанные по ходу работы. Всё, что мы публикуем, лежит в одном месте:

github.com/altessa-s

§ 08 — Как мы принимаем решения

Архитектурные решения фиксируются письменно.

Не документ, который никто не читает: короткая запись на каждое решение, в вашем репозитории, с ревью как у кода. Через год на вопрос «почему это сделано так» есть ответ.

  1. 01

    Развилку записываем до того, как её пройти

    Варианты, чего стоит каждый и от чего мы отказываемся. Два абзаца, а не презентация.

  2. 02

    Запись проходит ревью как код

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

  3. 03

    Фиксируем причину, а не только выбор

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

  4. 04

    Указываем, когда решение пересматривать

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

§ 09 — Где мы говорим нет

Работа, от которой мы отказываемся.

  • Не беремся без доступа к коду

    Оценка по презентации — это гадание, за которое потом платит кто-то один.

  • Не продаём джунов под видом сеньоров

    Если не можем закрыть проект сеньорами, говорим об этом и отказываемся.

  • Не переписываем ради переписывания

    Дважды рекомендовали оставить систему как есть и уйти. Это оказалось дешевле для всех.

  • Не делаем сайты и лендинги

    И одноразовые приложения, собранные к дате и брошенные. Если это не система, которую кому-то придётся вести годами, мы не та команда.

  • Не держим вас на крючке

    Ваше облако, ваши репозитории, уведомление за 30 дней и runbook’и на выходе.

§ 10 — Вопросы, которые задают в начале

Начните с неудобных.

Если вашего вопроса здесь нет, напишите его в форме ниже. Ответит инженер, письменно.

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

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

Первый разбор

§ 11 — Контакты

Напишите нам.

Опишите систему и то, что с ней не так. Письмо читает инженер и отвечает в течение трёх рабочих дней.

Что будет дальше

Дни 1–3
Инженер читает письмо и отвечает письменно: что, по нашему мнению, происходит и куда мы посмотрели бы в первую очередь.
Если нужно
Короткий созвон с тем же инженером, в удобное вам время. Только если после письма остались вопросы.
Если сходимся
Договариваемся о неделе разбора: неделя чтения вашего кода, €12k фиксированно, архитектура и цена на выходе.
Формат сотрудничества

NDA по запросу. Данные остаются в ЕС. Отвечаем сами, без автоматических рассылок.

Сайт защищён reCAPTCHA; действуют Политика конфиденциальности и Условия использования Google.

Удобнее ответить на вопросы, чем писать письмо?Заполнить бриф проекта