День запуска получает всё внимание. Но первые 30 дней после запуска — это период, когда проекты либо стабилизируются, либо начинают сыпаться. Большинство проблем, которые я исправлял в rescue-проектах, не были багами, существовавшими на запуске — они появлялись на второй неделе, когда реальные пользователи делали то, что никто не тестировал.
Вот 30-дневный план, который я запускаю на каждом клиентском проекте. Если ваш разработчик не предлагает что-то подобное — попросите.
Неделя 1 (дни 1–7): наблюдаем за всем
Цель первой недели проста: поймать то, что пропустило тестирование.
День 1: smoke-тест продакшна. Не стейджинга — продакшна. Прогоните пункты 13, 18, 19, 20 и 23 предзапускового чеклиста по живому URL. Проверьте платёжный флоу реальной картой. Убедитесь, что трекинг ошибок получает события, а не просто настроен.
Дни 2–3: мониторим объём ошибок. Первые 48 часов реального трафика вскроют проблемы, которые автотесты никогда не ловят. Правильно настроенный трекер ошибок должен фильтровать шум и алертить о реальных проблемах. Проверяйте его дважды в день.
Дни 4–7: собираем точки трения. Не запросы фич — точки трения. Где пользователи застревают? Где обращаются в поддержку? Где уходят? Если есть аналитика — смотрите воронку. Если нет — спросите первых 10 пользователей напрямую: «Что вас запутало?»
Результат: ранжированный список найденных проблем, категоризированных как критические (блокируют использование), важные (ухудшают опыт) или незначительные (косметические). Критические — исправляем в тот же день. Важные — на вторую неделю.
Неделя 2 (дни 8–14): исправляем и замеряем
Первая неделя — наблюдение. Вторая — действие.
Исправляем важные проблемы с первой недели. Не запросы фич — точки трения. Кнопка, которая не работает в Safari. Форма, которая таймаутит на медленном соединении. Письмо, которое попадает в спам. Это то, что теряет пользователей на первой неделе.
Устанавливаем базовые метрики производительности. Запускаем Lighthouse на 5 самых посещаемых страницах. Фиксируем Core Web Vitals из данных реальных пользователей (не лабораторных тестов). Фиксируем время ответа API на p50 и p95. Эти числа — базовая линия: с ними вы будете сравнивать на 2-м, 6-м, 12-м месяце.
Проверяем серверные расходы против прогнозов. Если вы закладывали €30/мес на хостинг, а видите €90 после недели реального трафика — разбирайтесь сейчас. Частые виновники: неоптимизированные запросы к БД, отсутствие оптимизации изображений, серверлесс-функции с частым cold start.
Результат: все критические и важные проблемы решены. Документ с базовыми метриками: производительность, уровень ошибок, стоимость хостинга.
Неделя 3 (дни 15–21): краевые случаи и масштаб
К третьей неделе очевидные проблемы исправлены. Теперь ищем, что ломается под нагрузкой.
Краевые случаи. Что происходит, когда пользователь отправляет форму дважды? Если открывает приложение в двух вкладках? Если у него 500 элементов вместо 10, на которых вы тестировали? Если в имени апостроф? Это не гипотетические сценарии — это проблемы, которые всплывают на масштабе.
Паттерны нагрузки. Если у продукта предсказуемые пики трафика (понедельник утром для B2B-инструмента, вечера для потребительского приложения) — мониторьте эти периоды отдельно. Проверьте, что подключения к БД не исчерпываются, rate limits настроены правильно, кэширование работает.
Внешние зависимости. Проверьте аптайм и производительность каждого внешнего сервиса: платёжный провайдер, email-сервис, аналитика, CDN. Если у кого-то из них был инцидент в первые две недели — убедитесь, что ваша обработка ошибок реально сработала.
Результат: исправления краевых случаев задеплоены. Заметка о любых проблемах масштабирования, которые нужно решить до следующей вехи трафика (10× текущих пользователей).
Неделя 4 (дни 22–30): передача и план обслуживания
Четвёртая неделя — о том, чтобы проект выживал без режима кризиса.
Обновление документации. Обновите README, гайд по деплою и runbook-и с тем, что узнали за недели 1–3. Продакшн-конфигурация наверняка отличается от запланированной — задокументируйте фактическое состояние.
Настройка мониторинга. К этому моменту вы знаете, какие ошибки реальные, а какие — шум. Настройте пороги алертов. Уберите ложные срабатывания. Настройте еженедельный email-дайджест ошибок, чтобы ловить регрессии без ежедневных проверок.
Аудит зависимостей. Запустите проверку безопасности зависимостей. Настройте автоматические алерты (Dependabot, Renovate) для критических уязвимостей. Не нужно обновлять всё — просто убедитесь, что узнаете, когда что-то потребует внимания.
План обслуживания. Определите, как выглядит текущая поддержка:
- Кто мониторит ошибки? Как часто?
- Какое время реакции на критические баги?
- Когда будут обновляться зависимости?
- Кто обработает следующую веху трафика?
Результат: одностраничный план обслуживания. Не контракт — общее понимание того, что значит «поддерживать это в рабочем состоянии».
Сколько это стоит
30-дневная стабилизация обычно занимает 15–25 часов разработчика, распределённых на месяц. Для проекта со стоимостью сборки €10K–€20K — это примерно €1,500–€3,000 на постзапусковую поддержку.
Сравните со стоимостью предотвратимого аутейджа на 2-м месяце, пробела в GDPR-комплаенсе, обнаруженного жалобой пользователя, или регрессии производительности, которая убивает конверсию прежде, чем вы собрали достаточно данных для диагностики.
Каждый rescue-проект, с которым я работал, не имел периода стабилизации. Разработчик зашипил, отправил финальный счёт и исчез. Через два месяца фаундер искал кого-то, кто починит сломавшееся.
Вопрос, который стоит задать разработчику
Перед запуском спросите: «Как выглядят первые 30 дней после запуска?»
Если ответ «будем чинить баги по мере поступления» — это не план. Это надежда, что ничего не сломается.
Если ответ — структурированный понедельный подход с конкретными результатами — вы работаете с тем, кто уже шипил и знает, что бывает дальше.
Планируете запуск и хотите, чтобы структурированная стабилизация была частью проекта? Напишите — постзапусковая поддержка — часть каждого проекта, который я шиплю, а не запоздалая мысль.