ТЗ на входе, система на выходе, и живёт дальше.
Как здесь делается заказная инженерная работа. На входе — письменное ТЗ или существующий репозиторий. На выходе — система, которая вышла в прод и держит нагрузку. Дальше по шагам, в том порядке, как это происходит.
Сделано, чтобы работать, а не просто запуститься.
Инженерную работу судят не по дню сдачи, а по тому, как она ведёт себя в проде спустя месяцы. Поэтому каждый шаг ниже выстроен вокруг одного: чтобы система продолжала жить.
На входе — сама система: репозиторий, архитектурный документ или письменное ТЗ. Сборку ведём там, где система уже живёт, или на нашей инфраструктуре, если так чище. Проверка — это нагрузка и отказы на реальных объёмах данных: система переживает то, что случается с ней на самом деле, а не удобный сценарий. Выход в прод обратимый, под мониторингом, с runbook. Миграцию можно пройти по шагам и при нужде откатить.
Неизменно в любом проекте: оценка в фиксированных часах, общение начинаем с переписки, созвон — по делу, и правило «кто написал код, тот его и ведёт».
-
01
Приёмка: репозиторий, ТЗ, доступы
Начинаем с реальной системы: репозиторий, архитектурный документ, медленный запрос, доступ к стейджу или реплике на чтение. Если принимаем легаси, руководитель читает его сам, прежде чем что-то предлагать.
-
02
Оценка в фиксированных часах — рискованное прототипируем первым
Объём оцениваем в фиксированных часах по письменному ТЗ. Всё, чья жизнеспособность не доказана (ИИ-функция, новый источник данных, допущение по нагрузке), получает прототип на ваших данных ещё до счёта. Бюджет опирается на работающую вещь, а не на догадку.
-
03
Сборка на вашей инфраструктуре или нашей
Очереди, реплики, ротация прокси, контейнеры — на той инфраструктуре, где система уже живёт, или на нашей, когда так чище. Архитектуру выбираем так, чтобы способ получения данных можно было менять, не трогая схему и накопленные данные.
-
04
Тесты на реальной нагрузке и отказах
Проверка — не прогон по контрольному списку, а выживание системы на реальных объёмах данных и в тех отказах, что случаются на деле: источник банит, запрос уходит мимо индекса, реестр меняет формат. Мы воспроизводим это до выхода в прод, а не после.
-
05
Деплой с runbook — обратимый и под мониторингом
Выход в прод — управляемый обратимый деплой: мониторинг и алерты в рабочий чат с первого дня. Описан так, что миграцию можно пройти по шагам и при необходимости откатить.
-
06
Держим живым — абонемент и реакция на инциденты
После запуска система остаётся на сопровождении: мелкие правки собираем в пакеты, крупные задачи оцениваем отдельно, на инциденты реагируем от нескольких минут до утра следующего дня — с письменным разбором. Кто собрал часть системы, тот ведёт её и годы спустя: не нужно каждый раз заново вникать в контекст.
Есть система, которую нужно
собрать или спасти?
Пришлите ТЗ, репозиторий или часть, которая всё время падает. В течение дня — точные вопросы и честный разбор: объём, риски и что прототипировать первым. NDA по запросу.