SLA технической поддержки сайта — это согласованные показатели уровня сервиса: когда команда принимает обращение, как определяется его приоритет, в какие часы действует регламент и как стороны контролируют выполнение обязательств. Без SLA фраза «оперативная поддержка» не имеет измеримого смысла.
Для бизнеса SLA нужен не ради формальности. Он помогает понять, что произойдёт после сообщения о падении сайта, сбое оплаты или некритичной визуальной ошибке. Для подрядчика SLA задаёт реалистичные границы ответственности и позволяет резервировать ресурсы под действительно срочные ситуации.
Содержание:
Что означает SLA
Аббревиатура расшифровывается как Service Level Agreement — соглашение об уровне сервиса. В нём описываются услуги, измеримые показатели, обязанности сторон и правила расчёта сроков. В поддержке сайтов SLA обычно является частью договора или отдельным приложением.
По определению IBM, такое соглашение фиксирует ожидаемый уровень предоставления услуги, способ измерения и последствия невыполнения. Atlassian также разделяет временные цели для подтверждения обращения, обновления статуса и решения. Для сайта важно перевести общую идею в конкретный рабочий регламент.
Какие показатели входят в SLA поддержки сайта
| Показатель | Что означает | Что нужно уточнить |
|---|---|---|
| Время реакции | Когда обращение принято и начата обработка | Рабочие часы, канал и приоритет |
| Время диагностики | Когда команда сообщает первичную причину и план | Какие доступы уже предоставлены |
| Время восстановления | Когда критичная функция снова доступна | Допустимо ли временное решение |
| Время полного решения | Когда устранена причина и завершено тестирование | Зависимости от сторонних сервисов |
| Доступность | Доля времени, когда сайт или сервис работает | Период расчёта и исключения |
| Частота обновлений | Как часто заказчик получает статус | Канал и ответственный |
Время реакции не равно времени решения
Это главное различие, которое часто теряется в коммерческих обещаниях. Реакция означает, что обращение зарегистрировано, специалист начал разбор и заказчик получил подтверждение. Решение означает, что причина найдена, исправление подготовлено, проверено и размещено.
Форму можно исправить за несколько минут, если ошибка очевидна. Сбой обмена с 1С может потребовать анализа журналов, участия второй команды и повторной отправки данных. При падении сервера сначала восстанавливают доступность, а окончательную причину исследуют после стабилизации.
Поэтому обещание «решить любую проблему за 15 минут» почти всегда некорректно. Реалистичный SLA гарантирует скорость подключения и понятную коммуникацию, а срок решения определяется классом проблемы и доступными способами восстановления.
Уровни приоритета обращений
| Приоритет | Пример | Влияние на бизнес |
|---|---|---|
| Критический | Сайт не открывается, не работает оплата, есть риск потери данных | Продажи или ключевой процесс полностью остановлены |
| Высокий | Не оформляется часть заказов, сломана важная интеграция | Функция недоступна значительной части пользователей |
| Средний | Ошибка отдельного сценария, есть обходной путь | Работа затруднена, но основной процесс продолжается |
| Низкий | Визуальная правка, консультация, плановое улучшение | Нет непосредственного влияния на операции |
Приоритет определяется не эмоциональностью сообщения, а влиянием на бизнес. Если любое обращение объявлять критическим, команда теряет возможность действительно быстро обрабатывать аварии. Критерии должны быть понятны обеим сторонам и содержать примеры.
Как считается время
В SLA необходимо указать момент начала и остановки таймера. Обычно отсчёт начинается после регистрации обращения в согласованном канале и получения минимально необходимых сведений. Если сообщение отправлено личному сотруднику в мессенджер, система может его не зафиксировать.
- рабочие дни и часы действия поддержки;
- часовой пояс;
- официальные каналы подачи обращений;
- правила для выходных и праздников;
- условия круглосуточного дежурства;
- остановка таймера при ожидании ответа или доступа от заказчика;
- исключения для сбоев сторонних сервисов и форс-мажора.
Например, если команда запросила доступ к серверу и не может продолжить диагностику, ожидание не должно считаться просрочкой подрядчика. Но запрос должен быть конкретным, а статус — зафиксированным в системе задач.
SLA German Web
В тарифах German Web используются сроки реакции 60, 30 и 15 минут. Они связаны с размером пакета и объёмом ресурсов, который команда резервирует под проект.
| Тариф | Стоимость | Срок реакции | Типичный сценарий |
|---|---|---|---|
| Базовый | 20 000 ₽/мес. | до 60 минут | Небольшой сайт и нерегулярные задачи |
| Развитие | 100 000 ₽/мес. | до 30 минут | Корпоративный сайт или магазин с постоянными изменениями |
| Команда | 250 000 ₽/мес. | до 15 минут | Критичный проект, интеграции и регулярные релизы |
Срок реакции действует в рамках согласованного рабочего процесса и не заменяет оценку конкретной задачи. Если нужна поддержка ночью, в выходные или с отдельным дежурством, условия рассчитываются индивидуально.
Почему более быстрый SLA стоит дороже
Чтобы гарантировать реакцию за короткое время, подрядчик не может загрузить всех специалистов на сто процентов плановыми задачами. Часть ресурсов резервируется, а процессы выстраиваются так, чтобы аварийное обращение не потерялось.
Цена отражает не только минуты работы над тикетом, но и готовность команды переключиться, наличие ответственных, мониторинга, доступов и процедуры эскалации. Чем критичнее сайт и короче допустимый простой, тем дороже такая готовность.
Что должен предоставить заказчик
- актуальные административные и серверные доступы;
- контакты ответственных за бизнес и внешние интеграции;
- описание критичных функций сайта;
- официальный канал постановки задач;
- быстрое согласование действий, способных повлиять на данные или продажи;
- тестовые учётные записи и примеры ошибок;
- контакт для экстренной эскалации.
Если подрядчик не может получить доступ к журналам, базе или панели хостинга, выполнить даже хороший SLA невозможно. Поэтому обязанности заказчика должны быть частью регламента, а доступы — проверены до первой аварии.
SLA для сторонних сервисов
Сайт зависит от хостинга, банка, CRM, 1С, службы доставки и других поставщиков. Команда поддержки может определить, что сбой находится на внешней стороне, передать технические данные и контролировать обращение. Но она не управляет ресурсами чужой компании.
В SLA следует разделить ответственность: подрядчик гарантирует диагностику и коммуникацию в своих границах, а срок устранения стороннего сбоя зависит от соответствующего провайдера. При возможности заранее продумываются временные сценарии: повторная отправка данных, резервный канал или отключение проблемной функции.
Как контролировать соблюдение SLA
Каждое обращение должно иметь время создания, приоритет, исполнителя, изменения статуса и результат. По итогам периода можно анализировать долю обращений, принятых вовремя, среднее время реакции, причины просрочек и повторные инциденты.
- количество обращений по приоритетам;
- процент реакций в пределах SLA;
- среднее и максимальное время реакции;
- время восстановления критичных функций;
- причины остановки таймера;
- повторяемость одинаковых проблем;
- работы, которые нужно вынести в план развития.
Один средний показатель может скрывать проблемы. Если команда быстро отвечает на десятки мелких запросов, но пропускает единственную критичную аварию, формальная статистика выглядит хорошо, а бизнес-результат — нет. Поэтому отчётность рассматривается по уровням приоритета.
Типичные ошибки в SLA
- слова «быстро» и «оперативно» без конкретного времени;
- отсутствие различия между реакцией и решением;
- одинаковый срок для аварии и плановой правки;
- неопределённые рабочие часы и каналы связи;
- обещание отвечать за сбои сторонних сервисов;
- отсутствие обязанностей заказчика;
- нет правил эскалации и отчётности;
- показатели не соответствуют доступному бюджету.
Как составить реалистичный SLA
Сначала определяются критичные функции и допустимые последствия простоя. Затем обращения делятся по приоритетам, назначаются каналы и ответственные, фиксируются рабочие часы и измеримые сроки. После нескольких месяцев регламент полезно пересмотреть по фактической статистике.
SLA должен защищать бизнес от неопределённости, а не создавать красивую, но невыполнимую цифру. Полный перечень работ поддержки разобран в отдельной статье, а цены и условия — в материале о тарифах сопровождения.
Как начать работу
Чтобы подобрать уровень сервиса, отправьте ссылку на сайт, опишите критичные функции, интеграции и ожидаемую скорость реакции. German Web оценит состояние проекта и предложит подходящий формат. Подробнее — на странице технической поддержки сайтов.
Частые вопросы
Что означает SLA простыми словами?
Это измеримые правила работы поддержки: когда команда должна принять обращение, как определяется его важность, в какие часы действует регламент и как фиксируется результат.
Реакция за 15 минут означает исправление за 15 минут?
Нет. Реакция означает начало обработки и подтверждение обращения. Полное решение может занять больше времени в зависимости от причины, доступов и необходимости тестирования.
Можно ли установить одинаковый SLA для всех задач?
Можно, но это обычно неэффективно. Авария, мешающая продажам, и плановая визуальная правка требуют разных приоритетов и сроков.
Работает ли SLA ночью и в выходные?
Только если это прямо указано в договоре. Стандартный SLA часто действует в рабочие часы, а круглосуточное дежурство согласуется отдельно.
Что происходит, если проблема на стороне хостинга или банка?
Команда диагностирует границу сбоя, передаёт данные провайдеру и контролирует обращение. Срок исправления на чужой стороне не может полностью гарантироваться подрядчиком сайта.
Можно ли изменить SLA после начала работы?
Да. После накопления статистики можно пересмотреть приоритеты, часы обслуживания и сроки реакции, если они не соответствуют реальной нагрузке.
