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

1. Введение и философия сервиса

1.1. Принцип «Быть, а не казаться»

Наш главный внутренний лозунг — «Быть, а не казаться». Это означает, что SLA для нас реальный механизм управления качеством.

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

1.2. Пользователь как партнер по качеству

Мы рассматриваем каждого пользователя системы как активного участника процесса развития платформы.

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

1.3. Принцип «Необходимости и достаточности»

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

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

Настоящий стандарт является единым для:

Всех инстансов платформы Rightech (On-premise и Cloud);
Всех пользователей, независимо от наличия договора ИТС;
Внутренних процессов команды Rightech (Support, R&D, QA).

Мы убеждены, что качество эксплуатации и надежность программного кода — это базовые характеристики продукта, которые должны быть доступны всему сообществу Rightech.

2. Термины и определения

Для обеспечения прозрачности взаимодействия и исключения двоякого толкования обязательств стороны используют следующие определения:

2.1. Временные метрики (Три точки контроля)

Мы отказываемся от размытого понятия «время реакции» в пользу трех конкретных этапов:

Время первичного ответа (Фиксация) — период с момента регистрации обращения в системе до момента первого ответа специалиста. Цель — 10 минут для всех уровней инцидентов. Этот показатель гарантирует, что сигнал принят, а пользователь обладает достоверной информацией о статусе своего обращения.
Время классификации (Подтверждение) — время, необходимое специалистам техподдержки и R&D для верификации проблемы, определения её реального влияния на систему и присвоения финального приоритета (P1–P4). Для критических инцидентов (P1) этот этап не должен превышать 30 минут. Для инцидентов уровня P1 процесс классификации имеет безусловный приоритет над любыми другими задачами R&D.
Время решения (Устранение) — период до полного восстановления работоспособности системы или предоставления Обходного пути. Время решения не включает в себя интервалы ожидания ответа от пользователя или доступа к его инфраструктуре.

2.2. Классификация событий

Инцидент — любое событие, которое не является частью стандартной работы платформы и приводит к прерыванию или снижению качества её работы (несоответствие Основному сценарию использования).
Баг (Ошибка в коде) — подтвержденный QA-отделом дефект программного обеспечения, приводящий к некорректному выполнению логики платформы в поддерживаемой конфигурации.
Запрос на изменение (Change Request / Предложение) — обращение, содержащее предложение по доработке существующей функциональности, изменению бизнес-логики или развитию продукта, которое выходит за рамки текущей поставки и требует отдельной оценки, согласования и, при необходимости, дополнительного финансирования.
Обходной путь — временный метод восстановления бизнес-процесса, позволяющий пользователю продолжать работу до выпуска финального исправления в коде.

2.3. Сценарии эксплуатации

Основной сценарий — последовательность действий в системе для получения результата в рамках ключевых бизнес-процессов (например, авторизация, получение данных от объектов, выполнение команд).
Альтернативный сценарий — вспомогательные функции, не влияющие на основную жизнеспособность системы (например, ручная выгрузка редкого отчета).

3. Объективная матрица инцидентов

Мы классифицируем инциденты на основе их влияния на бизнес-логику и возможности выполнения основных сценариев эксплуатации. Присвоение уровня критичности осуществляется в момент подтверждения (классификации) инцидента специалистами Rightech.

3.1. Матрица целевых показателей

Ниже приведены гарантированные сроки для каждой стадии обработки обращения. Единое время первичного ответа (10 минут) для всех уровней обеспечивает оперативное подтверждение приёма обращения и позволяет пользователю своевременно получать информацию о его статусе.

Уровень критичности	Описание (влияние)	Целевое время реакции	Целевое время подтверждения и классификации	Целевое время решения
Уровень 1. Критический	Полный отказ системы, утрата данных, критическая уязвимость, влияющая на значительную часть пользователей	10 минут	30 минут	3 часа
Уровень 2. Высокий	Блокировка ключевого бизнес-процесса, отсутствие обходного пути для выполнения основных операций	10 минут	2 часа	1 рабочий день
Уровень 3. Средний	Ошибка в функциональности, работа возможна с использованием альтернативных способов выполнения задач	10 минут	4 часа	1 неделя
Уровень 4. Низкий	Косметические дефекты, улучшения пользовательского интерфейса, орфографические ошибки	10 минут	1 раб.день	Плановые релизы

Примечание к времени классификации:

Включает: первичный анализ, воспроизведение проблемы, консультацию с R&D/QA (при необходимости), финальное присвоение приоритета.
Не включает: время ожидания уточняющей информации от Пользователя. Время решения исчисляется с момента подтверждения и классификации инцидента при условии наличия удалённого доступа к инфраструктуре Клиента (для On-premise). Время ожидания доступа или ответа Клиента не включается в расчёт времени решения, обстоятельства долгой загрузки данных, вследствие ограничения сети и прочее.

3.2. Критерии уровней

Уровень 1 — Критический инцидент

Полный отказ системы или её ключевых компонентов, делающий эксплуатацию невозможной для значительной части пользователей (более 30%) либо приводящий к остановке ключевых бизнес-процессов заказчика.

Признаки:

Полная недоступность платформы (веб-интерфейс, API, шлюзы) или отказ ключевых компонентов (база данных, сервисы сценариев, сервисы обработчиков) — система не выполняет основные функции.
Массовая потеря данных без возможности восстановления либо критическая уязвимость безопасности, требующая немедленного вмешательства.
Сбор телеметрии или выполнение команд недоступны для значительной части объектов (>10% устройств), что блокирует основной бизнес-процесс.
Система формально доступна, но произошла критическая деградация производительности (время ответа делает эксплуатацию невозможной), либо ведется активная DDoS-атака.

Уровень 2 — Высокий приоритет

Блокировка ключевого бизнес-процесса конкретного заказчика при отсутствии обходного пути, что делает невозможным выполнение Основного сценария эксплуатации.

Признаки:

Невозможность авторизации или регистрации для группы пользователей.
Сбой в работе платежных систем или биллинга (некорректные начисления).
Отказ юридически значимых операций (например, построение истории перемещения, просмотр журнала).
Невыдача производственных заданий, если это единственный канал.

Исключения: проблема затрагивает <30% пользователей; существует ручной способ (Обходной путь) выполнения задачи; ошибка воспроизводится только в тестовой среде.

Уровень 3 — Средний приоритет

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

Признаки:

Некорректная работа фильтров, отображения данных или формирования отчётов (аналитика недоступна, но бизнес-процессы выполняются).
Ошибки в административном интерфейсе, требующие ручной обработки задач вместо автоматической.
Сбои в работе уведомлений (SMS, Push, Telegram-боты), не влияющие на критическую логику.
Некорректные или вводящие в заблуждение текстовые сообщения, ошибки локализации, опечатки в интерфейсе.

Исключения:

Проблема имеет возможность обхода через другой раздел интерфейса.
Запрос на улучшение пользовательского опыта (UX) без влияния на функциональность.

Уровень 4 — Низкий приоритет

Запросы, не влияющие на бизнес-логику и выполнение ключевых сценариев: консультационные запросы, косметические дефекты, предложения по улучшению пользовательского опыта (UI/UX).

Признаки:

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

3.3. Исключающие критерии

Инцидент не может быть классифицирован как P1 или P2 в следующих случаях:

Проблема затрагивает менее 20% клиентов (для P1).
Система работает в режиме «только чтение» (данные доступны, но нельзя редактировать).
Ошибка воспроизводится исключительно в тестовой среде.
Существует альтернативная функциональность, позволяющая выполнить бизнес-задачу.
Проблема вызвана инфраструктурой Заказчика (сеть, серверы, ОС), а не кодом ПО.

4. Регламент операционной поддержки и внутренней эскалации

Мы выстраиваем процессы по принципу сквозного цикла «Взять → Сделать → Закрыть» с обязательной фиксацией результата на каждом этапе.

4.1. Жизненный цикл обращения

Все обращения фиксируются в системе учета задач и проходят через следующие статусы:

Новый. Тикет зарегистрирован и ожидает первичной фиксации (в течение 10 минут) и классификации.
В работе. Специалист занимается диагностикой или устранением проблемы. Для этого статуса применяется квантование времени в 15 минут (любая активность округляется в большую сторону).
Проверка. Работа выполнена со стороны R&D или поддержки, результат передан на верификацию в отдел QA.
Готово. Тикет закрывается после подтверждения успеха пользователем или через механику Автоакцепта.

4.2. Режим экстренной эскалации (Уровень 1 и Уровень 2)

Для инцидентов высшего уровня приоритета действуют особые правила, имеющие приоритет над любыми внутренними задачами компании.

Правило «Срыва с места»

При подтверждении инцидента Уровня 1:

Никакие внутренние процессы R&D (спринты, планирование, митинги) не имеют приоритета над устранением инцидента.
Ответственные специалисты обязаны немедленно приступить к диагностике и исправлению.
Работа не останавливается до полного устранения причин или предоставления обходного пути.

Канал экстренной связи:

Оповещение об инцидентах Уровень 1 и Уровень 2 дублируется в соответствующий рабочий канал коммуникации.
Если реакция отсутствует в течение 15 минут — осуществляется прямой вызов тимлидов и руководства по резервным каналам.

Эскалация по времени:

Время с момента подтверждения	Действие
>30 минут без прогресса (P1)	Эскалация на CTO / Технического директора
>2 часа без прогресса (P2)	Эскалация на Исполнительного директора
>4 часа без прогресса (P1)	Персональное уведомление Генерального директора

4.3. Взаимодействие Support ↔ QA ↔ R&D

Для обеспечения качества продукта мы вводим строгие фильтры на передачу задач:

Верификация багов: Запрещено передавать баги уровней Уровень 3 и Уровень 4 в разработку (R&D) без предварительного подтверждения отделом QA.
Разграничение зоны задачи (On-premise): Если проблема вызвана инфраструктурой (диски, сеть, ОС), поддержка закрывает задачу с предоставлением консультации и рекомендаций заказчику. В R&D передаются только ошибки в программном коде.
Приемка решения: Баг не считается исправленным, пока отдел QA не проведет регрессионную проверку и не подтвердит устранение инцидента.

4.4. Механика Автоподтверждение и закрытия тикетов

Для исключения «повисших» задач и обеспечения прозрачности учета работ применяется механика автоматического закрытия тикетов.

Правило 72 часов: Если после предоставления решения (статус Проверка) Пользователь был уведомлен о результате (email / тикет / чат), и в течение 72 часов не поступило мотивированных возражений, тикет автоматически переводится в статус Готово.

Защита пользователя:

Уведомление о переходе в статус Проверка отправляется минимум двумя каналами (email + тикет-система).
Пользователь вправе в любой момент до истечения 72 часов вернуть тикет в работу комментарием с обоснованием.

Финальный отчет: При закрытии инцидентов Уровень 1 и Уровень 2 в базу знаний добавляется краткий Post-mortem (причина, решение и меры по предотвращению).

4.5. Приостановка SLA

Время решения инцидента (Resolution Time) автоматически приостанавливается в случаях:

Ожидания уточняющей информации от пользователя, необходимой для устранения инцидента.
Отсутствия необходимого удаленного доступа (SSH/VPN) к инфраструктуре On-premise.
Проведения тестов на стороне пользователя.

5. Специфика On-premise

В случаях, когда программное обеспечение Rightech эксплуатируется на вычислительных мощностях Пользователя, выполнение обязательств по SLA напрямую зависит от стабильности и корректности настройки инфраструктуры.

5.1. Разграничение зон ответственности

Для обеспечения однозначности трактовок мы разделяем зоны ответственности следующим образом:

Зона ответственности Вендора (Rightech)	Зона ответственности Пользователя
Корректность программного кода, работа API, внутренняя логика платформы и базовых модулей (RIC-Gate, RIC-Logic и др.).	Серверное оборудование, операционные системы, сетевая связность, электропитание, безопасность периметра и системное ПО сторонних производителей.

5.2. Процесс «Hard Gate» (Технический вход)

Перевод инсталляции в стадию промышленной эксплуатации и активация обязательств по SLA возможны только при 100% выполнении требований чек-листа технической готовности, приведённой по ссылке: https://rightech.io/ru/infrastructure-requirements.

5.3. Условия диагностики и удаленный доступ

Для соблюдения сроков решения инцидентов уровней Уровень 1 и Уровень 2 Пользователь обязан обеспечить специалистам Rightech удаленный доступ (VPN/SSH).

Приостановка SLA. Если доступ не предоставлен, отозван или ограничен в процессе работы над инцидентом, отсчет времени решения (SLA) автоматически приостанавливается до момента восстановления доступа.
Разграничение. Если в ходе диагностики выявлено, что проблема вызвана инфраструктурой Пользователя (сбой диска, сетевые задержки, ошибки ОС), задача закрывается с предоставлением рекомендаций, а время работы не учитывается как нарушение SLA со стороны Вендора.

5.4. Требования к версионности

Обязательства по SLA распространяются исключительно на актуальные версии Продуктов, поддерживаемые Вендором. В случае отказа Пользователя от установки обязательных обновлений безопасности или перехода на поддерживаемую версию, Вендор вправе приостановить действие SLA до момента приведения системы в актуальное состояние.

6. Метрики качества и прозрачность

Rightech стремится к абсолютной прозрачности в вопросах надежности системы. Мы считаем, что доверие рынка строится на честных данных, а не на декларативных лозунгах.

6.1. Показатели доступности (Uptime)

Мы устанавливаем целевой показатель доступности системы на уровне 99,9% в год (без учёта плановых технических работ).

Для On-premise инсталляций данный показатель применяется только к компонентам, находящимся в зоне ответственности Вендора (см. раздел 5.1), и при условии полного соответствия инфраструктуры требованиям, указанным в разделе 5.2.

6.3. Регламент плановых технических работ

Для поддержания стабильности системы нам необходимо проводить плановое обслуживание. Эти работы не считаются простоем системы при соблюдении следующих условий:

Уведомление: Пользователи должны быть уведомлены о работах не менее чем за 3 рабочих дня.
Лимиты: Общее время плановых работ не должно превышать 12 часов в квартал.
Технологическое окно: Мы стремимся проводить работы в периоды минимальной нагрузки на систему (ночное время по МСК).

6.4. Процесс анализа инцидентов (Post-Mortem / RCA)

Прозрачность — это не только цифры, но и выводы. Для каждого инцидента уровня P1 и P2 команда Rightech проводит внутренний разбор — Root Cause Analysis (RCA):

Цель	Результат	Отчетность
Установить первопричину сбоя (код, архитектура, внешние факторы).	Фиксация мер, принятых для исключения повторения подобной ситуации в будущем.	Краткие выводы по результатам RCA могут быть предоставлены сообществу для подтверждения надежности продукта.

7. Исключения и ограничения

Для обеспечения справедливости и прозрачности обязательств, положения настоящего Соглашения не применяются, а показатели качества не считаются нарушенными в следующих случаях:

7.1. Обстоятельства непреодолимой силы (Форс-мажор)

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

7.2. Сбои на стороне третьих лиц

Мы отвечаем за свой программный код, но не можем гарантировать работоспособность внешних сервисов, от которых зависит инсталляция:

Каналы связи и провайдеры: Сбои у операторов интернета, международной и междугородной связи.
Внешние сервисы: Перебои в работе платежных шлюзов, SMS-центров, систем авторизации (OAuth-провайдеры) или картографических сервисов.
Оборудование: Физические поломки серверов, дисковых накопителей или терминалов на стороне Заказчика.

7.3. Нарушение условий эксплуатации

SLA не действует или приостанавливается, если:

Инфраструктурные требования: Использование ПО на оборудовании или в операционных системах, не соответствующих «Рекомендуемым требованиям».
Несанкционированные изменения: Самостоятельная модификация кода программного обеспечения Пользователем или изменение критических настроек конфигурации без согласования с Вендором.
Блокировка лицензии: Отсутствие стабильной связи между On-premise инсталляцией и лицензионным сервером lic.rightech.io по вине Пользователя (блокировка портов, отсутствие интернета).

7.4. Условия приостановки SLA

Обязательства по времени решения (Resolution Time) автоматически приостанавливаются в следующих ситуациях:

Ожидание информации: Срок от момента запроса логов или уточняющих данных у Пользователя до момента их получения, требуемых для устранения инцидента.
Отсутствие доступа: Время, в течение которого Пользователь не обеспечил специалистам Вендора удаленный доступ (SSH/VPN) к инфраструктуре.
Тестирование: Период, затраченный Пользователем на проверку предложенного решения или обходного пути.

7.5. Версионная политика

Вендор гарантирует соблюдение обязательств по настоящему SLA исключительно для актуальных версий платформы, к которым относятся текущая стабильная версия и непосредственно предшествующая ей стабильная версия (N и N-1). Поддержка версий, выпущенных ранее N-1, осуществляется без гарантий соблюдения целевых показателей SLA — такие инциденты обрабатываются по мере возможности и на усмотрение Вендора.

Документ разработан: Командой Rightech

Контакты технической поддержки: support@rightech.io