Проверка инфраструктуры после запуска для растущего продукта

Почему неделя запуска может скрывать слабые места

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

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

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

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

Рост также съедает тихие часы. Ночные бэкапы, большие отчёты и тяжёлые деплои могли комфортно укладываться, когда онлайн было мало пользователей. Через несколько месяцев эти «безопасные» окна сжимаются или исчезают. Задания начинают пересекаться, и база остаётся загруженной дольше.

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

Начните с цифр, которые изменились после запуска

Поставьте неделю запуска рядом с последними двумя–четырьмя неделями и сравните их бок о бок. Такая проверка работает лучше, когда вы начинаете с изменений, а не с догадок. Если трафик удвоился, а количество ошибок осталось прежним, это одна история. Если трафик вырос на 20%, а число повторных попыток утроилось, это совсем другая.

Не полагайтесь слишком на средние за день. Они сглаживают те самые пики, которые вредят пользователям. Проверьте пиковые часы, самые загруженные окна фоновых задач и минуты сразу после деплоя. Система может выглядеть спокойной за 24 часа и при этом каждый день страдать в 9:00 утра.

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

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

Простой пример: количество регистраций может вырасти на 30%, но почтовых задач — на 80%, если пользователи стали чаще отправлять напоминания, приглашения и запросы на сброс пароля. Эта несогласованность — место, где появляются трещины.

Если у вас уже есть дашборды в таких инструментах, как Grafana, или трекинг ошибок в Sentry, сохраняйте те же графики для каждой проверки. Последовательные графики упрощают обнаружение трендов и экономят время.

Проверьте кэши до того, как промахи накопятся

Потратьте время на поведение кэша. Кэши могут скрывать медленные запросы и тяжёлую работу приложения недели, а затем сразу перестать работать, когда трафик вырастет.

Начните со страниц или API‑маршрутов с наибольшим трафиком. Если ваш прайсинг, дашборд или поисковые результаты обслуживают большую часть запросов, сравните уровень попаданий в кэш сейчас с тем, что было сразу после запуска. Даже небольшой спад может дать большую нагрузку, потому что каждый промах возвращает работу к базе или апп‑серверу.

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

Короткие TTL часто вызывают проблемы. Команды ставят безопасные времена истечения в начале и забывают про них. Если страница меняется дважды в день, TTL в 60 секунд обычно избыточен. Вы всё время перестраиваете один и тот же ответ без пользы.

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

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

Малые SaaS‑команды часто пропускают это, потому что приложение кажется быстрым в обычном использовании. Потом один холодный старт после релиза превращает страницу с 200 мс в ожидание 4 секунды и доводит базу до предела. Это обычно можно исправить, но только если заметить до следующего удвоения трафика.

Проверьте пулы подключений и давление запросов

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

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

Небольшое несоответствие может вызвать реальное замедление. Если 20 апп‑воркеров, 10 раннеров задач и задача миграции одновременно обращаются к одной базе, лимит пула, который казался достаточным при запуске, может привести к ожиданиям, таймаутам и штормам ретраев.

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

Деплои требуют отдельной проверки. Релиз может запускать дополнительные воркеры, выполнять миграции, прогревать кэши или воспроизводить очереди. Этот короткий всплеск может поднять давление на пул выше, чем обычно. Наблюдайте за использованием подключений во время деплоя, а не только при стабильном трафике.

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

Убедитесь, что окна резервного копирования всё ещё подходят

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

Тестируйте полные и частичные бэкапы в обычный будний день, а не в стенд‑тесте с почти нулевым трафиком. Замерьте, сколько занимает каждое задание, и смотрите, что происходит с CPU, дисковым вводом/выводом, сетью и отставанием реплик во время работы. Задание, которое раньше занимало 12 минут, может незаметно вырасти до 45.

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

Успешный бэкап сам по себе недостаточен. Зелёный статус лишь говорит, что файлы где‑то записаны. Он не говорит, сможет ли команда быстро восстановить базу после неправильных данных, случайного удаления или провального релиза. Проведите тест частичного и полного восстановления и запишите, сколько времени нужно, чтобы привести приложение в рабочее состояние.

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

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

Сократите время деплоя до того, как релизы накапливаются

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

Измеряйте релиз по частям, а не как одно число. Команда может говорить «деплой занимает 25 минут», но это скрывает реальные проблемы. Время сборки, тестов и выкатывания обычно тормозит по разным причинам.

Типичная разбивка проста: 8 минут на сборку артефактов, 11 минут на тесты, 4 минуты на выкатывание и 2 минуты ожидания ручного одобрения. Последняя часть важнее, чем многие думают. Ручные шаги блокируют мелкие фиксы, особенно когда человек, который знает процесс, недоступен или спит.

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

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

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

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

Исправьте оповещения, которые люди уже игнорируют

Шумная система оповещений приучает людей отворачиваться. Если команда получает 60 оповещений в день, и лишь два требуют действий, следующее реальное событие сольётся с остальными.

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

Для каждого оповещения задайте четыре простых вопроса. Кто‑то действовал, когда оно срабатывало в последние разы? Указывает ли оно на боль пользователя, например отказ логина или медленные запросы? Повторяет ли оно событие, о котором уже сообщает другой инструмент? Получает ли его нужный человек в нужное время?

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

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

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

На стеках с Sentry, Grafana, Prometheus и Loki это пересечение случается быстро. Чистая система оповещений должна казаться почти скучной. Когда пейджер звонит, кто‑то должен понять, почему это важно, за несколько секунд.

Проводите проверку шаг за шагом

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

Проходите те же области в одном и том же порядке каждый раз. Это держит проверку в фокусе и не даёт команде бросаться к самому громкому графику.

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

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

Ошибки, которые тратят время на проверке

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

Средние дают ту же проблему. База может выглядеть спокойной за весь день, в то время как один уродливый час делает всю погоду. Если запросы собираются с 14:00 до 15:00, среднее за день это скрывает. Смотрите худший час, а не приятную сводку.

Бэкапы тоже вводят в заблуждение. Зелёный "backup completed" доказывает лишь, что задание запустилось. Он не доказывает, что вы сможете быстро восстановить данные или восстановить их вообще. Команды часто узнают это в худший момент, когда восстановление требует дополнительных шагов, отсутствующих секретов или больше дискового места, чем планировалось.

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

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

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

Пример: небольшая SaaS‑команда после скачка роста

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

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

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

Затем в продукцию попадает баг в загруженный полдень. Исправление простое, но деплой занимает 18 минут, потому что конвейер выполняет тяжёлые шаги друг за другом. Эта задержка кажется намного дольше, когда пользователи ждут и ошибки продолжают поступать.

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

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

Быстрые проверки перед следующим скачком трафика

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

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

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

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

Что делать дальше с выводами

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

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

Превратите заметки в повторяемую рутину

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

Это также помогает в напряжённые недели. Вместо споров о важности команда может сравнить свежие цифры с последней проверкой и увидеть, что изменилось.

Если команда не может договориться о приоритетах, внешняя помощь ускорит процесс. Кто‑то вроде Олега Сотникова на oleg.is может просмотреть стек, ранжировать работу и удерживать объём задач в узких пределах — особенно когда команда занята доставкой и не хочет большого переписывания.

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

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