Соглашение об уровне обслуживания (SLA)

Этот документ описывает, как мы выполняем и измеряем обязательства по услугам: поддержке и сопровождению сайтов и приложений, управляемой инфраструктуре, мониторингу безопасности и ведению рекламы. Здесь — приоритеты обращений, время реакции, часы работы, эскалация, отчётность и компенсации, если сроки нарушены.

1. Область применения

Соглашение применяется к действующим договорам на поддержку, сопровождение, управляемые услуги и ведение рекламы — в объёме, указанном в договоре. Конкретные значения (время реакции, режим дежурства, часы работы, состав включённых работ) фиксируются в договоре или в приложении SLA к нему.

• Приоритет договора. Если условие договора расходится с этой страницей, действует договор. Страница описывает типовые условия и порядок применения, а не заменяет подписанные обязательства.
• Это не публичная оферта. Публикация страницы не означает, что любой посетитель получает услугу на этих условиях: объём и уровень сервиса согласуются в договоре.
• Что не покрывается. Разовые проектные работы регулируются договором на разработку: там свои сроки и ответственность. Гарантийные обязательства по разработке описаны в разделе 12.
• Время реакции и время решения — разные обязательства. Реакция — начало работы: диагностика, ответ с планом и назначенным инженером. Решение — устранение проблемы. Мы отвечаем за оба срока, но обещать «исправим за 15 минут» на любой инцидент было бы обманом: восстановление базы на несколько терабайт физически занимает часы.

2. Термины

• Обращение — сообщение заказчика через один из согласованных каналов (раздел 4) с описанием проблемы, вопроса или задачи.
• Инцидент — обращение о событии, которое уже влияет на работу сервиса: недоступность, ошибка, деградация, инцидент безопасности.
• Запрос на изменение — обращение о работах, которые не восстанавливают работоспособность, а меняют поведение системы: доработка, новый блок, интеграция. Планируется в спринт и не считается инцидентом.
• Время реакции — интервал от регистрации обращения в канале до начала работы: подтверждение приёма, назначение ответственного, первичная диагностика или обоснованный запрос недостающих данных.
• Время решения — интервал от регистрации обращения до устранения проблемы или до согласованного обходного решения, если полное устранение требует отдельной работы.
• Рабочие часы — Пн–Пт, 9:00–19:00 по московскому времени, кроме нерабочих праздничных дней. Дежурство — режим, при котором инциденты приоритета P1 принимаются круглосуточно.
• Сервисный кредит — уменьшение стоимости следующего периода за подтверждённое нарушение сроков (раздел 14).

3. Часы работы и режимы обслуживания

Обращения принимаются круглосуточно: формы на сайте, Telegram и почта работают всегда. Время реакции отсчитывается в рамках режима, выбранного в договоре.

Дежурство 24/7 распространяется на приоритет P1. Обращения P2–P4 вне рабочих часов принимаются, но время реакции по ним отсчитывается с начала рабочего дня — если иное не согласовано в договоре отдельным пунктом.

4. Как обратиться и когда обращение принято

• Обращение считается принятым с момента, когда оно зафиксировано в одном из каналов выше. Устная договорённость в коридоре или в личном звонке без фиксации в канале соглашением не покрывается.
• Один канал для P1. Согласуем заранее, куда звонить ночью: дежурный телефон и Telegram. Если канал не согласован, дежурство работает по мониторингу и Telegram.
• Что указать в обращении — см. раздел 17: это экономит первый круг диагностики и напрямую влияет на скорость решения.

5. Приоритеты обращений

Приоритет определяется влиянием на бизнес, а не формулировкой обращения. Первичный приоритет выставляет дежурный инженер, заказчик вправе его оспорить — тогда вопрос решает руководитель поддержки, а при разногласии используется эскалация (раздел 10).

Перевод обращения в другой приоритет — не способ ускорить работу. Если задачу нужно сделать вне очереди, скажите об этом прямо: срочные работы выполняем во внеочередном порядке и фиксируем отдельно, вместо того чтобы «повышать приоритет» косметической правке.

6. Уровни обслуживания

Уровни и время реакции ниже — те же, что опубликованы на страницах поддержки и выделенной поддержки по SLA. Состав работ и цена уровня фиксируются в договоре.

7. Время реакции и решения по направлениям

Ниже — сводка по направлениям услуг. Значения в строках совпадают с опубликованными на страницах направлений; при расхождении ориентируйтесь на страницу направления и договор.

• Управляемая инфраструктура — управление облачной инфраструктурой: дежурство 24/7 на уровнях «Бизнес» и «Критичный», круглосуточные работы до восстановления.
• Поддержка приложений — поддержка приложений по SLA: приём обращений, исправление ошибок, мониторинг исключений, плановые доработки.
• Мониторинг безопасности — мониторинг событий информационной безопасности: при P1 одновременно с началом работ вы получаете первичную оценку.
• Сопровождение сайтов и приложений — уровни поддержки и техническая поддержка.
• Ведение рекламы — Яндекс Директ: каналы с почасовым SLA к рекламным кампаниям не применяются, обязательства по отчётности и реакции фиксируются в договоре на ведение.

Если для решения нужны действия с вашей стороны — доступы, уточнение требований, решение по варианту исправления — мы сообщаем об этом сразу и переводим обращение в статус ожидания. Время ожидания в расчёт срока решения не входит, но мы обязаны назвать, чего именно ждём.

8. Целевая доступность и методика расчёта

• Как считаем. Доступность = 1 − (минуты недоступности ÷ общее число минут периода). Недоступность фиксируется внешним мониторингом с проверкой ключевого сценария не реже одного раза в минуту, а также по подтверждённым обращениям, если мониторинг не увидел проблему (например, сбой затрагивает только часть пользователей).
• Что не вычитается. Плановые работы из раздела 9, форс-мажор, сбои внешних сервисов вне нашего управления, отказы из-за действий заказчика или третьих лиц, а также периоды, когда сервис был остановлен по вашей просьбе.
• Отчёт. Фактическая доступность за месяц — в ежемесячном отчёте (раздел 11). Если значения ниже целевых, применяется раздел 14.

9. Плановые работы

• Окна по умолчанию: вторник и четверг, 02:00–05:00 МСК — время минимальной нагрузки. Для проектов с иной аудиторией окна согласуются отдельно.
• Уведомление: не позднее чем за 3 рабочих дня — что делаем, зачем, сколько ожидается простой и что делать, если после работ что-то не работает.
• Внеплановые работы: закрытие критичной уязвимости или отказ оборудования могут потребовать работ раньше. В этом случае уведомляем до начала работ и объясняем, почему ждать нельзя. Остановку продакшена без вашего согласия не делаем — исключение составляет только ситуация, когда промедление приводит к потере или утечке данных, и это отдельно фиксируется в регламенте.
• Простой в рабочие часы: если работы требуют простоя дольше 30 минут в рабочее время, согласуем дату и время отдельно.
• Откат: перед плановыми работами делается резервная копия, а план работ содержит шаги отката.

Плановые работы, выполненные по согласованному уведомлению, не считаются нарушением SLA и не уменьшают доступность из раздела 8.

10. Эскалация

Эскалация — не жалоба, а инструмент: она подключает к инциденту людей с правом принимать решения. Инициировать её может как наша сторона, так и заказчик.

• Как запросить эскалацию: сообщением в Telegram или звонком с прямым указанием, что нужна эскалация. Мы подтверждаем приём и называем, кто ведёт инцидент и когда будет следующий статус.
• Статусы. На P1 вы получаете обновление не реже чем раз в час, даже если нового мало: «диагностика продолжается, причина сужается до обмена с 1С».
• График дежурств на неделю вперёд с именами инженеров — для пакетов с дежурством. Контакты дежурного передаются заранее, а не ищутся в момент аварии.

11. Отчётность и разборы инцидентов

• Ежемесячный отчёт: обращения по приоритетам, время реакции и решения по каждому, соблюдение SLA в процентах, доступность, выполненные плановые работы, потраченные часы, план на следующий месяц.
• Разбор после P1: в течение 5 рабочих дней — хронология, причина, что сделано для устранения, что меняем, чтобы не повторилось. Разбор делается и тогда, когда причиной стал внешний сервис: важно понять, как раньше узнать о проблеме.
• Статус-борд — по желанию: публичная или закрытая страница с текущим состоянием сервисов и историей инцидентов.
• Регулярные встречи: на «Стандарте» и «Премиуме» — разбор бэклога и приоритетов не реже раза в месяц, на выделенной поддержке — раз в одну-две недели.

12. Гарантия на разработку

Гарантия — отдельный вид обязательств: она относится к проектным работам, а не к поддержке, но описывается здесь, чтобы условия были в одном месте.

• 60 календарных дней с момента передачи результата: ошибки вёрстки, форм, интеграций и аналитики исправляем бесплатно.
• Что не входит в гарантию: новые требования и изменения объёма, ошибки в данных и контенте заказчика, последствия изменений, внесённых вами или третьими лицами, сбои внешних сервисов и хостинга, а также устаревшие версии ПО, обновление которых отложено по решению заказчика.
• Сроки проектных работ и ответственность за просрочку по нашей вине фиксируются в договоре на разработку. Условия по конкретным услугам опубликованы на страницах разработки лендинга и технического аудита.

13. Обязанности заказчика

Уровень сервиса — общее обязательство, а не одностороннее. Чтобы время реакции из разделов 6–7 работало, нужно следующее.

• Актуальные контакты: ответственный за приёмку работ, дежурный контакт для P1 и адрес для эскалации. Изменения — сообщать заранее.
• Доступы: репозиторий, серверы, база, панели внешних сервисов, а также актуальные учётные данные. Просроченные или отозванные доступы останавливают работы.
• Уведомление об изменениях на своей стороне: смена хостинга, DNS, ключей, обновление CMS или плагинов, изменения в интеграциях, действия других подрядчиков. Незаявленное изменение — самая частая причина «внезапных» инцидентов.
• Своевременные ответы: на этапе решения мы можем ждать от вас выбора варианта или данных. Время ожидания не входит в срок решения, но удлиняет его для вас.
• Один канал для P1 и дублирование по телефону — чтобы обращение не потерялось в переписке.
• Оплата по договору в согласованные сроки: при просрочке оплаты услуги могут быть приостановлены, и период приостановки не учитывается в SLA.

14. Ответственность и сервисные кредиты

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

• Порядок. Заявление о кредите направляется в течение 10 рабочих дней после окончания месяца с указанием даты, времени и канала обращений. Рассматриваем в течение 10 рабочих дней.
• Форма компенсации. Уменьшение стоимости следующего периода или возврат, если договор завершается.
• Кредит — исключительная мера. Он не заменяет и не ограничивает иные обязательства, предусмотренные договором, и не является признанием вины в причинении убытков. Пределы ответственности устанавливаются договором.
• Когда кредит не начисляется: если нарушение вызвано причинами из раздела 15 или действиями (бездействием) заказчика, включая невыполнение раздела 13.

15. Что не покрывается соглашением

• Плановые работы, о которых мы уведомили по разделу 9.
• Форс-мажор: стихийные бедствия, военные действия, решения органов власти, массовые отказы сетей и дата-центров.
• Сбои внешних сервисов, которые мы не администрируем: хостинг, DNS, платёжные шлюзы, SMS-провайдеры, сервисы аналитики, банковские и государственные системы, системы на стороне заказчика, включая 1С.
• Атаки, превышающие согласованный уровень защиты, если защита от DDoS не входит в договор.
• Последствия изменений, внесённых заказчиком или третьими лицами без уведомления нашей команды.
• Устаревшие версии платформы, зависимостей или CMS, обновление которых отложено по решению заказчика: риск описываем письменно и продолжаем работы в пределах возможного.
• Данные и контент, предоставленные заказчиком: их корректность, законность и полнота.
• Работы, не входящие в состав уровня: обучение сотрудников, консультации по чужим системам, разработка новых функций сверх включённых часов — выполняются по отдельной договорённости.

16. Изменение соглашения

• Новая редакция публикуется на этой странице с датой обновления.
• Для действующих договоров: изменения, ухудшающие уровень сервиса, вступают в силу не ранее чем через 30 дней после уведомления и только после согласования. Улучшения — время реакции, доступность, отчётность — применяем сразу и без доплат.
• Индивидуальный SLA: если в договоре есть приложение с уровнями сервиса, применяется оно. Эта страница описывает порядок и типовые значения.
• Вопросы и уточнения: contact@webtechretail.com или страница контактов.

17. Как сообщить об инциденте

Полное описание в первом сообщении экономит круг диагностики. Достаточно ответить на шесть вопросов:

1. Что не работает и с какого времени (по возможности — до минуты).
2. Кто затронут: все пользователи или часть; устройства, браузеры, города, конкретные роли.
3. Что видно: текст ошибки, номер заказа или заявки, скриншот, ссылка на проблемную страницу.
4. Что менялось за последние сутки: обновления, правки, работы других подрядчиков, изменения на стороне провайдеров.
5. Насколько срочно и почему: что произойдёт, если подождать до утра, — это помогает корректно выставить приоритет.
6. Контакт для связи и удобный канал в ближайшие часы.

Каналы: Telegram @webtechretail, телефон +7 (962) 368-39-51, почта contact@webtechretail.com, форма на странице поддержки. Мы подтверждаем приём обращения и приоритет — если подтверждения нет, обращение не зарегистрировано, напишите или позвоните повторно.

Обращения по персональным данным — отдельный порядок и отдельные сроки: см. права субъекта данных и порядок обращений. Этот документ регулирует сервисные обязательства, а не обработку персональных данных.