Привет! Я Мария, продакт-менеджер панели управления ispmanager. Моя работа — делать ispmanager полезным, и я искренне люблю этим заниматься!
Но как узнать, что действительно нужно пользователям? Из отзывов. Одна из постоянно всплывающих тем — импорт данных. Это инструмент миграции, который позволяет перенести пользователей со всеми их «пожитками» (сайтами, почтой и т.д.) с одного сервера под управлением ispmanager на другой. От его работы напрямую зависят сроки переноса проектов и простои сервисов.
Посмотрев на импорт глазами пользователей, я поняла, что процесс миграции в ispmanager был похож на вождение стареньких «жигулей»: вроде едешь, но постоянно что-то отваливается. Чтобы это исправить, мы провели аудит «болевых точек» и разработали план по улучшению инструмента миграции. В этой статье, расскажу, как мы его реализовали и что получилось. Все улучшения, которые я описываю ниже, касаются импорта данных через rsync из ispmanager 6 в ispmanager 6, начиная с версии 6.128.
Проблема 1: Узнаешь о проблеме постфактум
Что не так: нет проверки программного окружения перед импортом
Раньше мы не проверяли конфигурацию сервера перед импортом. Просто запускали процесс, не глядя, стоит ли нужный PHP, СУБД или другое ПО. В результате, часть сущностей не «переезжала» или импортировалась с ошибками.
Конечно мы писали в документации, что перед тем, как начать импорт пользователей, необходимо проверить установленное ПО. Но кто же это читает ;) Так, например, в документации по импорту пользователей сказано, что на сервере-источнике и сервере-приёмнике должно быть установлено одинаковое рекомендуемое ПО. Пользователи же справедливо жаловались, что панель не уведомляет об этом при импорте.
«Почему панель об этом не пишет при импорте? Нам гадать на кофейной гуще всегда?»
В итоге, пользователю приходилось копаться в уведомлениях, чтобы понять в чём проблема, узнать какие сущности не «переехали», исправить это и снова запустить импорт.
Решение: проверяем готовность сервера заранее
Теперь перед началом импорта мы проверяем:
- наличие необходимого ПО на сервере,
- лимиты,
- свободное дисковое пространство.
Мы знаем, какие версии PHP нужны сайтам, какие СУБД используются, сколько места на диске требуется для переноса данных и прочее. Если что-то не так, сообщаем, показываем, каких сущностей это касается, и предлагаем автоматически решить проблему.
Например, если для сайта используется PHP 8.4, а на текущем сервере его нет, мы показываем каких сайтов это касается и предлагаем автоматически установить эту версию PHP. Если она не будет установлена, сайт всё равно «переедет», но ему будет назначена другая версия PHP, максимально близкая к используемой.
Подобного правила мы придерживаемся для всего. Например, сайт использует Node.js, но он не установлен. Мы всё равно переносим такой сайт, только с другими настройками и отмечаем это в журнале. Раньше такие данные не «переезжали» вовсе.
Проблема 2: Отчёт «для галочки»
Что не так: В отчёте об импорте не хватает деталей и он недоступен после закрытия
Раньше отчёт после импорта выглядел так:
Вроде что-то переехало, но если есть ошибки, нужно вручную искать, что потерялось, и разбираться по логам и уведомлениям в чём проблема. Пользователи регулярно отмечали, что отчёты должны быть детальнее и прозрачнее.
«Не хватает отчета об ошибках в самой панели, а то пишет, что N ошибок и понимай как хочешь, что там за ошибки.»
Решение: даём подробный отчёт, к которому можно вернуться в любое время
Теперь, вся информация об импорте сохраняется в журнал. В нём перечислены все переносимые сущности и статус каждой из них.
В обновленном отчёте видно, какие данные «переехали», где возникли ошибки и какие конфигурации изменились.
Проблема 3: Теряем кастомные конфигурации
Что не так: кастомные настройки веб-сервера менялись на типовые
После того, как данные импортированы, начинается этап проверки: корректно ли работают сайты на новом сервере.
Если у сайта были кастомные файлы конфигурации веб-сервера, при переносе они терялись и «конфиги» становились типовыми. Из-за этого сайты могли работать с ошибками.
«Где, настройки, Карл! Почему ничего не работает?!»
Решение: переносим веб-конфигурацию сайтов
Все «секретики» в конфигах теперь «забираем» со старого сервера на новый (конечно, проверяя при этом, что новый веб-сервер готов их принять).
Проблема 4: Синхронизация? Нет, не слышали
Что не так: нельзя импортировать только изменившиеся файлы
Допустим, мы всё проверили и сайты работают. Отлично! Но пока мы занимались импортом и проверкой, сайты продолжали работать со старого сервера. За это время там могли появиться новые данные — заказы, сообщения и т.д.
Как быстро скопировать только новые данные? Никак — можно было только запустить перенос всех данных заново.
При больших объемах данных, это совсем не быстрый процесс.
«Вы что мне предлагаете все заново запускать?! Я так до второго пришествия не перееду.»
Решение: возможность перенести только изменившиеся данные
Сейчас, когда видим, что на сервере уже есть пользователи и их данные, предлагаем несколько вариантов действия.
Опция «Добавить новые сущности и файлы, перезаписать устаревшие файлы» позволяет «донести» только изменившиеся данные. Она импортирует новые сущности пользователей (например, новые почтовые ящики) и заново копирует файлы, которые изменились после начала импорта.
Проблема 5: DNS-коллапс
Что не так: запросы к сайтам продолжают идти на старый сервер
Наконец-то всё проверено и работает отлично! Пора менять «прописку» сайтов: направить DNS на новый сервер.
Но, как мы знаем, DNS записи обновляются не мгновенно. Это значит, что ещё какое-то время, запросы к сайтам могут приходить на старый сервер. Для динамичных сайтов это проблема: можно потерять заказ или обращение клиента.
Решение: настройка проксирования
Мы добавили опцию «Проксирование», которая автоматически настраивает перенаправление запросов к сайтам со старого сервера на новый.
Заключение
Надеемся, что после всех изменений миграция в ispmanager ощущается как поездка на «Лексусе»: стабильно, быстро и предсказуемо. Мы постарались сделать импорт максимально автоматизированным, чтобы админам не приходилось тратить время на исправление мелких ошибок.
Расскажите, как часто вы импортируете проекты между ispmanager и что для вас критично в этом сценарии. Заметили ли улучшения после обновления импорта? Какие проблемы остались?