Почему IT-проекты ломаются после запуска и как мы это предотвращаем

Запуск — это не финал, а смена режима нагрузки

Бизнес часто воспринимает дату релиза как точку «проект сдан». На практике именно после запуска система впервые получает реальную нагрузку: настоящих пользователей, непредсказуемый трафик, грязные данные, параллельные интеграции и требования регуляторов. То, что прекрасно работало на демонстрации с тремя тестовыми аккаунтами, начинает вести себя иначе, когда к продукту одновременно подключаются тысячи людей, а данные копятся месяцами.

Поэтому «поломка после запуска» — это почти всегда не случайность и не саботаж подрядчика. Это закономерное проявление решений, принятых (или не принятых) на этапе проектирования. Если разработка IT-проекта под ключ велась без архитектурного планирования и без выстроенных DevOps-процессов, деградация наступает предсказуемо: растёт время ответа, копятся ошибки, релизы становятся рискованными, а любая мелкая правка превращается в спецоперацию. Ниже разберём, почему так происходит и что конкретно мы в OneDev делаем, чтобы этого не было.

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

Большинство проблем эксплуатации сводится к нескольким повторяющимся причинам. Они редко связаны с «плохими программистами» — чаще это отсутствие инженерной дисциплины и ответственности за систему после релиза.

• Архитектура «на сейчас», а не «на рост». Решения, оптимальные для MVP с минимальной нагрузкой, плохо переживают масштабирование. Монолит без разделения ответственности, синхронные вызовы там, где нужна очередь, отсутствие кэширования — всё это не видно на старте и больно бьёт через два-три месяца.
• База данных как узкое место. Запросы без индексов, отсутствие пагинации, выборки «всё и сразу», N+1-запросы. Пока таблицы маленькие, всё летает. Когда в таблице появляются сотни тысяч строк, время ответа растёт нелинейно, и кабинет начинает «висеть».
• Нет наблюдаемости. Если у команды нет логов, метрик и алертов, она узнаёт о сбое от разозлённого клиента, а не от системы мониторинга. Диагностика превращается в гадание, а время простоя растягивается на часы.
• Ручные и хрупкие релизы. Деплой «руками по SSH», без воспроизводимой сборки и без возможности быстро откатиться, гарантирует, что рано или поздно на прод уедет недособранный артефакт или конфиг, и сервис ляжет.
• Игнор доверия к данным. Системы предполагают, что данные всегда корректны: время с устройств точное, поля заполнены, формат не меняется. В реальности приходят пустые значения, будущие даты, дубли — и код, не готовый к этому, падает с белым экраном.

Технический долг, который «выстреливает» отложенно

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

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

Сюда же относится тихое поглощение маршрутов при переезде на новый фронтенд: SPA-фоллбэк перехватывает старые серверные пути, GET возвращает пустую страницу со статусом 200 (выглядит «живым»), а POST-вебхуки молча отваливаются. Внешне всё в порядке, а приём платёжных и почтовых статусов уже не работает. Такие дефекты опаснее всего: они не дают явного сбоя, а медленно подтачивают бизнес-процессы.

Что мы делаем на этапе проектирования

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

• Архитектура под нагрузку и под изменения. Разделяем ответственность сервисов, выносим тяжёлые и долгие операции в фоновые очереди, закладываем кэширование и горизонтальное масштабирование там, где это оправдано. Не усложняем ради усложнения, но и не загоняем продукт в потолок на старте.
• Модель данных и индексы заранее. Проектируем схему с расчётом на рост объёмов, продумываем индексы и пагинацию до того, как таблицы распухнут. Любую вставку и тяжёлый запрос проверяем на реалистичных объёмах данных.
• Защитное программирование по умолчанию. Любое поле из внешнего источника считается потенциально пустым или некорректным. Данные фильтруются по надёжным серверным меткам, а не по тому, что прислал клиент.
• Безопасность с первого дня. Разграничение доступа, хранение секретов отдельно от кода, защита платёжных и персональных данных — это часть архитектуры, а не «фича на потом».

DevOps-процессы: как мы держим систему стабильной после запуска

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

• Воспроизводимые сборки и CI/CD. Каждый релиз проходит через автоматическую сборку и проверки. На прод уезжает только то, что собралось корректно и прошло тесты, — это исключает класс аварий вида «недособранный артефакт в продакшене».
• Быстрый откат. Если новая версия повела себя неожиданно, мы возвращаемся к предыдущей за минуты, а не разбираем последствия часами.
• Мониторинг и алерты. Метрики времени ответа, ошибок, нагрузки на БД и количества соединений собираются постоянно. О проблеме команда узнаёт от системы и до того, как её заметит бизнес.
• Автоматический перезапуск и устойчивость к сбоям. Сервисы настроены так, чтобы подниматься после падения, а не оставаться лежать до утра. Резервное копирование данных регулярное и проверяемое восстановлением.
• Тестирование интеграций после деплоя. Платёжные шлюзы, вебхуки и внешние API проверяются реальными запросами после каждого изменения окружения — статус 200 на GET не считается доказательством работоспособности.

Сопровождение как часть продукта, а не «гарантия на брак»

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