SaaS или CMS: кто отвечает за сбои и обслуживание магазина
Как распределить ответственность за обновления, восстановление, интеграции и выход с платформы. Матрица для SaaS и отдельной CMS, учебный инцидент и вопросы подрядчику.
При выборе между готовым сервисом и отдельной CMS выясните, кто будет обслуживать магазин после запуска. Названия модели недостаточно: восстановление заказа, обновление модуля и сбой обмена могут оказаться задачами разных исполнителей. До договора нужно назначить ответственных и проверить, что между ними не осталось незакрытой работы.
В статье разберём обслуживание: кто принимает инцидент, кто выполняет изменение и чем подтверждает результат. Сравнение конкретных продуктов есть в обзоре конструкторов интернет-магазинов; здесь результатом будет матрица ответственности, которую можно приложить к обсуждению условий работы.
Почему SaaS и CMS не определяют всю ответственность
SaaS — способ предоставления программы как сервиса, CMS — система управления содержимым. Это разные характеристики: CMS может работать внутри облачной услуги, а отдельную установку может обслуживать подрядчик. В обычном сравнении «SaaS или CMS» имеют в виду готовый магазин по подписке и самостоятельно размещённую систему. Но даже для такого сравнения нужно читать состав конкретной услуги.
У готового сервиса часть инфраструктуры обычно находится под управлением поставщика. Это не означает, что поставщик отвечает за введённые сотрудником цены, стороннюю интеграцию или все действия в личном кабинете. У отдельной установки контроль шире, но наличие доступа к серверу само по себе не назначает человека для обновлений и аварий.
Поэтому сравнивайте не обещание «всё включено» с обещанием «полная свобода», а покрытие одних и тех же событий. Если обязательный процесс некому поддерживать в доступных условиях, кандидат ещё не готов к выбору.
Матрица обслуживания до договора
У каждой задачи должны быть исполнитель, представитель магазина для решения и путь эскалации. Формулировка «отвечают совместно» без разделения действий оставляет неопределённость: каждый может ждать другую сторону.
Заполняйте матрицу по письменным условиям и доступной проверке. Таблица ниже задаёт вопросы, а не устанавливает характеристики всех сервисов или CMS.
| Событие | Что выяснить для готового сервиса | Что назначить для отдельной установки | Чем подтвердить готовность |
|---|---|---|---|
| Обновление программы | Что обновляет поставщик и как сообщает об изменении совместимости | Кто проверяет ядро, тему, модули и собственный код | Перечень поддерживаемых частей и план проверки после изменения |
| Неудачное обновление | Куда передать сбой и какие способы восстановления предусмотрены | Кто останавливает изменение и выполняет согласованный откат | Процедура, доступы, ответственный и условия обращения |
| Восстановление данных | Что входит в копию и кто запускает восстановление | Кто создаёт, хранит и проверяет копии, кто восстанавливает | Контрольный набор данных после тестового восстановления |
| Сбой обмена | Где заканчивается поддержка сервиса и начинается поддержка интеграции | Кто проверяет обе стороны обмена и повторную обработку | Схема передачи ошибки и сверка заказа, цены или остатка |
| Доступ сотрудника | Что может администратор магазина и что делает поддержка | Кто управляет доступами к CMS, хостингу и подключённым системам | Список ролей, процедура отзыва и контакт при потере доступа |
| Прекращение работы | Какие данные и когда можно выгрузить | Кто передаёт код, базу, файлы и необходимые доступы | Пробная выгрузка и перечень передаваемого по договору |
Резервная копия — ещё не доказательство восстановления. Важно, какие данные в неё попали, насколько они соответствуют нужному состоянию и как будет восстановлена связь заказа с его строками. Универсального допустимого простоя или потери данных для всех магазинов нет: сформулируйте пределы исходя из своих обязательств и согласуйте выполнимый порядок.
Проверьте и исключения. Кто отвечает за платный модуль другого разработчика? Что происходит вне часов поддержки? Кто связывает двух подрядчиков, если каждая сторона видит исправную работу у себя? Назначьте координатора от магазина, который собирает подтверждения и принимает решение, а не рассчитывайте, что поставщики договорятся без участия владельца.
Учебный инцидент: обмен испортил остаток
Представим вымышленный магазин: после изменения формата файла поставщика обмен записал нулевой остаток нескольким товарам, хотя товар есть. Последняя корректная загрузка известна, а после неё в магазине появились новые заказы. Реальных систем и поставщиков в этом примере нет.
Первый шаг координатора — прекратить дальнейшее применение ошибочного обмена согласованным способом и сохранить сведения о затронутой загрузке. Затем определить область ошибки: какие товары, поля и период затронуты. Нельзя считать восстановление всей базы автоматически безопасным: оно может вернуть остатки, одновременно затерев более новые заказы.
Дальнейшие действия зависят от назначения исполнителей:
| Действие | Вариант с готовым сервисом | Вариант с отдельной CMS |
|---|---|---|
| Передать инцидент | Координатор сообщает поддержке и ответственному за интеграцию идентификатор загрузки и примеры | Координатор передаёт сведения сопровождающему специалисту и ответственному за источник |
| Выбрать исправление | Уточняют доступный способ исправить затронутые данные или восстановить их в рамках услуги | Специалист оценивает точечную коррекцию или восстановление на тестовом контуре |
| Сохранить новые заказы | Согласуют состав восстановления и проверку заказов после последней корректной загрузки | Проверяют, что исправление не откатывает новые заказы и изменения других полей |
| Вернуть обмен | Ответственный за интеграцию проверяет формат и контрольную загрузку | Сопровождающий исправляет обработчик и проверяет контрольную загрузку |
| Принять результат | Магазин сверяет контрольные товары и новые заказы | Магазин выполняет ту же сверку |
Критерий завершения один для обеих моделей: затронутые остатки исправлены, новые заказы сохранены, повторная загрузка не возвращает ошибку. Подтверждение «сервис снова работает» этого не доказывает. Для приёмки нужны конкретные товары, ожидаемые значения и несколько заказов, созданных после проблемного момента.
Альтернатива меняет решение: если данные верны, а обмен только не обновляется из-за недоступного источника, восстанавливать базу без оснований не нужно. Сначала проверяют доступность и очередь обработки. Если ни одна сторона не берёт на себя диагностику границы обмена, матрица обслуживания неполна — это надо решить до выбора поставщика или подключения.
Как записать условия без расплывчатых обещаний
Для каждой строки матрицы используйте короткую карточку:
- Событие и граница: что произошло и какие части системы входят в задачу — …
- Координатор магазина: кто передаёт сведения и согласует действия — …
- Исполнитель: кто диагностирует и кто вносит исправление — …
- Канал и условия обращения: куда писать, какие часы и подтверждения предусмотрены — …
- Необходимые доступы: кто их предоставляет и отзывает — …
- Проверка результата: какие данные или действия сверяем — …
- Если первый исполнитель не решил задачу: кому и с какими материалами передаём дальше — …
Не подменяйте время ответа временем устранения. Уведомление о получении заявки не означает, что восстановление началось или завершилось. Если условия содержат сроки, проверьте, к какому событию они относятся и что требуется от магазина для их соблюдения. Не обещайте покупателям доступность, которую ваши договорённости не подтверждают.
Сопоставьте расходы на одинаковый набор обслуживания, включая работу за пределами услуги. Подробный расчёт остаётся в статье о стоимости владения интернет-магазином. Здесь достаточно увидеть незакрытые задачи: низкая цена без исполнителя восстановления ещё не описывает готовое решение.
Как подготовить выход из платформы
Попросите перечень доступной выгрузки и условия её получения до прекращения работы. Файл товаров не равен переносу магазина: отдельно нужны варианты, категории, изображения, идентификаторы, строки и статусы заказов в том составе, который нужен вашей задаче. Оформление страниц и поведение модулей также не переносятся автоматически вместе с таблицей.
На учебном наборе проверьте чтение: можно ли установить, какой вариант купили и какие строки относятся к заказу. Если выгрузка содержит только название и общую сумму, ответить на эти вопросы может быть невозможно. Такой пробел следует закрыть заранее или учесть при выборе.
Не переносите лишние персональные данные ради демонстрации. Определите цель, состав и допустимый порядок передачи. Уточните, когда выгрузка доступна, что произойдёт после прекращения доступа и кто отвечает за дальнейшее хранение. Возможность получить данные и готовность новой системы их принять — разные проверки.