Поддержка и обновления

Поддержка быстрее закрывает вопрос, когда в письме есть продукт, домен и шаг, на котором всё остановилось. Фраза «не работает» без URL и лога превращается в лотерею. Скрин админки полезнее эмоций; текст Fatal Error из лога полезнее скрина белого экрана.

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

Что приложить к обращению

• Название продукта Microscript и версию архива, если указана в комплекте или личном кабинете.
• Адрес страницы (URL) и что ожидали увидеть.
• Шаги: «открыл /install, ввёл БД, нажал далее».
• Текст ошибки из браузера или из error_log / лога PHP-FPM. Без паролей базы и root.
• Версия PHP и тип хостинга: shared Beget/Timeweb, VDS с Nginx, локальный MicroServer.

Не присылайте целиком phpinfo на 200 КБ «на всякий случай» — достаточно ветки PHP и списка модулей, если речь про требования. Сами требования: PHP/MySQL.

Что проверить до тикета

1. Коннект к базе — ошибка MySQL.
2. HTTP 500 / белый экран — ошибка 500.
3. Загрузки и permission denied — chmod.
4. Cron не отрабатывает — cron.
5. Окружение вообще подходит — хостинг / VDS.

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

Обновление скрипта

Перед заменой файлов:

• Дамп базы и архив загрузок — бэкап.
• Копия конфига подключений и локальных правок.
• Понимание, какие каталоги релиз не должен затереть (upload, custom, .env — по readme).

Типичный безопасный путь: распаковать новый релиз рядом, перенести конфиг и user-контент, переключить document root или аккуратно пролить файлы поверх, исключая пользовательские директории. После выкладки откройте главную, кабинет, одну форму с записью в БД, одну загрузку файла, оплату если есть.

Если обновление шло через «залить zip в корень и подтвердить» в панели — всё равно держите свой бэкап. Автобэкап хостера не всегда хранит то, что нужно.

Доступы для разбора

Если просят доступ — временный пользователь админки, FTP/SFTP или SSH read-only по возможности. После работ пароли смените. Не публикуйте доступы в открытых тредах.

Локальное воспроизведение

Многие баги быстрее ловятся на копии: MicroServer, импорт дампа — phpMyAdmin, хост — *.loc. Если локально не воспроизводится, в тикете так и напишите — это тоже данные.

Перенос и миграции

Смена сервера — не «обновление», но часто мешают в одну кучу. Чеклист: перенос, дамп — миграция MySQL. SSL после переноса: SSL.

После ответа поддержки

Сделайте что просили один раз внимательно (путь к php-cli, строка в конфиге, версия PHP). Если не помогло — пришлите новый лог с меткой времени после изменения. «Всё ещё не работает» без нового факта снова растянет цепочку.

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

Как не надо писать

• «Ничего не работает срочно!!!!» без URL.
• Скрин целиком рабочего стола, где не видно текста ошибки.
• Пароль root в теме письма.
• Пять вопросов в одном абзаце про разные продукты.
• Переписка с цитированием всей истории за год без итога «сейчас сломано вот это».

Коротко и по делу читают быстрее. Можно эмоционально — но факты всё равно нужны.

Обновление: типовой провал

Залили новые файлы поверх, затёрли config.php, сайт показал Access denied / 500. Лечение: вернуть конфиг из бэкапа, не пересоздавать базу. Поэтому конфиг копируют отдельно ещё до распаковки архива. Права после заливки от root на VDS: chmod.

Второй провал — обновили код, забыли про SQL-миграции из readme релиза. В логе ошибки про отсутствующие столбцы. Читайте changelog комплекта до нажатия «заменить всё».

Каналы и язык

Пишите в тот канал, который указан для вашего продукта/лицензии. Смена темы каждые два сообщения («это уже про оплату», «нет, про SSL») дробит тикет. Один инцидент — один каркас переписки. Документы SLA: SLA.

Когда просят доступ к серверу

Подготовьте: SSH-ключ или временный пароль, путь к сайту, имя базы, доступ в админку. Не обязательно выдавать пароль от панели хостера целиком, если хватает SFTP и админки. После закрытия тикета доступы отзовите — особенно если это общий root.

На shared иногда достаточно временного FTP и скрина ошибки. На VDS без логов FPM разбор 500 почти слепой: ошибка 500, стек — Nginx.

Параллельные изменения

Пока тикет в работе, не меняйте версию PHP, не мигрируйте DNS и не заливайте ещё один «возможно починит» архив без сообщения. Иначе чиним уже не то. Если очень нужно — напишите: «параллельно сменил PHP на 8.3».

После закрытия

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

Почта, SSL, хостинг — часто смежные мануалы, не «баг»: SSL, хостинг, cron. Установка с нуля: установка.

Если приложите два противоречивых факта («PHP 8.2» в письме и скрин phpinfo с 7.4) — сначала сверим окружение, потом код. Селектор версии в панели Beget/Timeweb/ISPmanager иногда меняют не на том домене. Укажите, для какого именно URL смотрели phpinfo. Для локальных багов приложите, что это MicroServer/OpenServer, не прод: локальный сервер. Дамп для воспроизведения — без лишних персональных данных, пароли админов после импорта смените. Ошибки базы и 500 закрывайте мануалами до тикета, если текст в логе уже однозначный: MySQL, 500. Рамки работ и сроков: SLA.