SLA поддержки скрипта

SLA поддержки скрипта — договорённость о сроках реакции и составе работ. Это не «делайте нам новый модуль за вечер» и не бесплатный системный администратор вашего VDS. Путаница в ожиданиях рождает злые тикеты; лучше сразу понимать границы.

Конкретные цифры часов/дней смотрите в условиях вашего тарифа сопровождения. Ниже — смысл, который обычно заложен в такие соглашения для PHP-продуктов Microscript.

Что обычно входит

• Инциденты установки и доступа: не коннектится БД, 500 после выкладки, не проходит установщик — при адекватном окружении.
• Консультация по настройке из мануала: куда прописать SMTP, как повесить cron, куда положить файлы.
• Обновления в рамках поддерживаемой линии версии — с оговоркой про бэкап на вашей стороне.
• Разбор бага продукта, если воспроизводится не из-за кривого хостинга.

Как писать обращение, чтобы не играть в угадайку: поддержка и обновления.

Что обычно не входит

• Дизайн «сделайте как у конкурента» и новые фичи вне roadmap.
• Администрирование чужого VDS с нуля: firewall, панель, миграция десяти сайтов.
• Починка после того, как в ядро залили свои хаки и обновились поверх.
• Настройка рекламы, копирайт, юридические тексты.
• Обучение PHP с нуля.

Часть серверных задач закрывается мануалами: VDS, Nginx, firewall, хостинг. Это самообслуживание; SLA не обязан делать это за вас под ключ.

Сроки реакции vs срок решения

Реакция — «мы увидели тикет и ответили». Решение — «заработало». Между ними может быть ожидание доступа, логов, окна на работах. Если в письме нет error_log и версии PHP, решение отодвигается на круг переписки. Это не саботаж.

Критичность: сайт лежит у всех пользователей ≠ «хочу зелёную кнопку левее». Приоритизация как раз зона SLA.

Обновления и ответственность за бэкап

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

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

Окружение заказчика

Поддержка опирается на заявленные требования: PHP 8, mysqli, utf8mb4 — требования. Если хостинг на PHP 7.2 и «тариф нельзя сменить», это блокер не продукта. Локальная проверка у вас: MicroServer.

Типичные инциденты закрываются мануалами до тикета: ошибка базы, 500, права, cron.

Мониторинг и uptime

SLA продукта ≠ гарантия uptime железа хостера. Падение VDS у провайдера — к провайдеру. Свой мониторинг всё равно полезен: мониторинг. Договор с хостером по железу — отдельно от сопровождения скрипта.

Как ускорить работу по тикету

1. Название продукта и примерно версия архива.
2. URL, шаг воспроизведения.
3. Текст ошибки / кусок лога.
4. Что уже пробовали из мануала.

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

Критичность инцидента

Условно уровни, которые встречаются в сопровождении:

• Сайт недоступен всем / не открывается оплата / данные повреждены после обновления.
• Важный раздел админки падает, но витрина жива.
• Косметика, вопрос «как настроить», пожелание новой кнопки.

Первое уходит вверх очереди. Третье может ждать и часто превращается в отдельную задачу на доработку вне SLA. Не маркируйте всё как «срочно, клиент орёт» — девальвируете срочность.

Воспроизводимость

Баг, который «один раз у клиента в Safari на iPhone 11» без шагов, ловится долго. Запишите браузер, роль пользователя, id сущности если есть. Локальное воспроизведение на MicroServer с вашим дампом сильно ускоряет разбор. Дамп без персональных лишних данных — лучше; пароли пользователей можно сменить после импорта.

Зона ответственности хостера

Упал диск VDS, провайдер три часа чинит ноду — это не просрочка SLA скрипта. Нет mysqli в тарифе shared — тоже. Мы подскажем, что включить; включить на стороне хостера должны вы или его поддержка. Сравнение площадок: хостинг, VDS.

Коммуникация и окна работ

Если нужно зайти на сервер — согласуйте окно. Внезапный restart MySQL днём в пик продаж редко радует. Напишите, когда можно. После работ короткий отчёт: что сделали, что проверить вам.

Обновление движка лучше не совмещать с рекламной кампанией «завтра в эфир». Снимите бэкап: бэкап.

Доработки вне SLA

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

Эскалация

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

Технический минимум во вложении всё тот же: URL, лог, PHP, шаги. Мануал по обращениям: поддержка. Мониторинг с вашей стороны не отменяет SLA, но даёт факты «с 03:12 UTC 500»: мониторинг.

Если инцидент на стороне хостера (сеть, диск, «плановые работы»), зафиксируйте номер обращения к хостеру в тикете по скрипту — чтобы не дублировать диагностику. Мы не ускорим ремонт ноды провайдера, но подскажем, как поднять сайт на временном VDS, если это критично и есть бэкап: бэкап, перенос, VDS. Кастом, залитый в ядро без документации, увеличивает время разбора: чем больше отличий от поставки, тем меньше это «стандартный инцидент SLA» и тем ближе к отдельной оценке. Установка по чистому контуру проще в сопровождении: установка, требования — PHP/MySQL.

Коротко: SLA — про реакцию и сопровождение поставки, не про безлимитную разработку и не про администрирование любого VDS под ключ. Чем точнее тикет и чем ближе окружение к требованиям, тем быстрее закрывается инцидент. Остальное — в мануале поддержки.