Как понять, что пора менять хостинг: инструкция на примере GitLab

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

В 2018 году GitLab решил перенести GitLab.com из Microsoft Azure в Google Cloud Platform. Компания объяснила решение публично: доступность и производительность сервиса не соответствовали её требованиям, а новой архитектуре требовалась подходящая платформа. Среди факторов выбора были также возможности для Kubernetes и цена.

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

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

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

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

Запишите данные за последние недели:

Если точных данных нет, достаточно указать, что оформление было недоступно в определённый период. Главная цель на этом этапе — получить несколько проверяемых эпизодов вместо общего впечатления «в последнее время всё тормозит».

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

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

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

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

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

До сравнения чужих тарифов отправьте текущему провайдеру предметный запрос: «В такие-то дни с 14:00 до 15:00 не оформлялись заказы. На этих графиках растёт ожидание базы. Что ограничивало работу сервера? Можно ли изменить конфигурацию? Какие данные вы видите со своей стороны?» Приложите ссылки на графики и обезличенные фрагменты ошибок, если они есть.

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

Есть три возможных вывода:

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

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

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

Заранее согласуйте план перехода: кто делает резервную копию и проверяет её восстановление, как переносятся новые заказы между последним копированием базы и переключением, кто меняет DNS, кто проверяет сертификат и куда откатываться, если тест после перехода не прошёл. При обновлении DNS часть посетителей может ещё некоторое время попадать на старый адрес, поэтому нельзя допустить двух независимых баз, в которые одновременно приходят заказы. Срок зависит от настроек DNS и способа переноса; обещать всем переезд «без секунды простоя» некорректно. (Cloudflare Learning Paths)

GitLab рассматривал простой вариант — остановить сайт, скопировать данные и запустить его в новом облаке. Из-за объёма данных это означало бы слишком долгую недоступность. Компания выбрала синхронизацию с подготовленной копией, проверку перед переключением и репетиции процедуры. Маленькому магазину не нужна такая система миграции, но репетиция и план возврата нужны ему по той же причине: рабочий сайт нельзя использовать как единственное место для проверки гипотез.

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

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

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

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