SLA поддержка: что это такое и как составить соглашение об уровне сервиса
Полное руководство по Service Level Agreement для технической поддержки [2026]
Ваше приложение упало в прайм-тайм. Пользователи не могут оплатить заказы, звонки в поддержку растут, бизнес теряет деньги каждую минуту. Как быстро подрядчик должен отреагировать? Через сколько часов проблема должна быть решена? Без чётких договорённостей эти вопросы превращаются в конфликты.
SLA (Service Level Agreement) — это соглашение об уровне сервиса, которое фиксирует обязательства по качеству и скорости технической поддержки. По данным Gartner, компании с чётко прописанными SLA на 40% реже сталкиваются с эскалациями и конфликтами с подрядчиками. И эти цифры могут быть ещё выше. Именно поэтому грамотно составленный SLA — не бюрократическая формальность, а страховка вашего бизнеса.
Мы в Surf сопровождаем десятки продуктов для крупнейших компаний России и Средней Азии. Банковские приложения, e-commerce платформы, фудтех-сервисы — все они требуют гарантированного уровня поддержки. В этой статье делимся опытом: как правильно составить SLA технической поддержки, какие метрики включить и каких ошибок избежать.
Вы узнаете:
- Что такое SLA и чем он отличается от обычного договора
- Какие метрики обязательно включить в соглашение
- Как определить уровни критичности инцидентов
- Как выбрать модель технической поддержки
- Типичные ошибки при составлении SLA и как их избежать
Содержание
- Что такое SLA простыми словами
- Зачем нужен SLA: преимущества для бизнеса
- Ключевые метрики SLA технической поддержки
- Уровни критичности инцидентов
- Структура SLA: что должно быть в документе
- Модели технической поддержки
- Сколько стоит SLA поддержка
- Типичные ошибки при составлении SLA
- Чек-лист: как выбрать подрядчика с хорошим SLA
Ключевые моменты
1. Что такое SLA простыми словами
SLA (Service Level Agreement) — соглашение об уровне сервиса. Это документ, который фиксирует договорённости между заказчиком и исполнителем: что именно входит в поддержку, как быстро нужно реагировать на проблемы и какие гарантии даёт подрядчик.
Если совсем просто: SLA — это правила игры, записанные на бумаге. Без них каждая сторона понимает «хорошую поддержку» по-своему. Для заказчика «быстро» — это 15 минут. Для подрядчика — «в тот же день». И это неизбежно ведёт к конфликтам, когда что-то идёт не так.
SLA vs обычный договор
Обычный договор на разработку фиксирует, что подрядчик создаст продукт. SLA фиксирует, как подрядчик будет этот продукт поддерживать после запуска. Это два разных документа с разными целями, и важно понимать их различия:
Договор на разработку заканчивается, когда продукт сдан. SLA начинается, когда продукт запущен — и продолжается, пока продукт работает.
Три типа SLA
В зависимости от потребностей бизнеса и масштаба услуг, SLA может принимать разные формы:
Customer-based SLA — соглашение с конкретным клиентом. Такой SLA учитывает специфику бизнеса заказчика: часы работы, критичность систем, особые требования к безопасности или compliance. Например, для банка SLA будет значительно строже, чем для информационного портала — потому что последствия простоя несопоставимы.
Service-based SLA — стандартное соглашение для определённого типа услуг. Одинаковые условия для всех клиентов, заказывающих данную услугу. Это типичный подход для хостинг-провайдеров и SaaS-сервисов: вы покупаете тариф, и условия одинаковы для всех на этом тарифе.
Multi-level SLA — многоуровневое соглашение, которое комбинирует общие условия для всех клиентов с индивидуальными параметрами для конкретных услуг или подразделений. Это гибкий подход для крупных организаций с разнородными потребностями.
Большинство IT-компаний, работающих с enterprise-клиентами, используют Customer-based или Multi-level SLA.
2. Зачем нужен SLA: преимущества для бизнеса
SLA систематизирует отношения между заказчиком и подрядчиком, превращая субъективные ожидания в объективные договорённости. Вот как меняется работа при наличии и отсутствии SLA:
Нужна надёжная техподдержка продукта?
Разберём ваш проект, предложим оптимальную модель SLA и дадим оценку сроков.
3. Ключевые метрики SLA технической поддержки
Метрики — это сердце любого SLA. Без измеримых показателей соглашение превращается в набор благих намерений, которые невозможно проверить и невозможно оспорить.
Хорошая метрика должна быть конкретной, измеримой и однозначно понимаемой обеими сторонами. «Быстро реагировать» — плохо. «Время первого ответа — не более 30 минут для P1-инцидентов» — хорошо.
Время реакции (Response Time)
Это время от поступления обращения до первого ответа от службы поддержки. Важно понимать: это не время решения — это именно первый контакт, подтверждение, что проблема принята в работу.
Зачем это нужно? Когда у вас что-то сломалось, самое неприятное — неизвестность. Работает кто-то над проблемой или моё письмо улетело в пустоту? Быстрый первый ответ снимает эту тревогу.
Важно: время реакции — это не просто «ответили что-то». Первый ответ должен быть содержательным и включать: подтверждение получения заявки, присвоенный приоритет, ожидаемое время решения и назначенного ответственного. «Спасибо за обращение, мы свяжемся с вами позже» — это не качественный первый ответ.
Время решения (Resolution Time)
Время от поступления обращения до полного устранения проблемы. Это ключевая метрика для бизнеса: вас волнует не когда начали работать, а когда всё заработало.
Обратите внимание: время решения всегда значительно больше времени реакции. Начать работу над проблемой и решить проблему — это разные вещи. Некоторые клиенты путают эти метрики и удивляются, что «обещали 15 минут, а чинили 3 часа». SLA должен чётко разделять эти понятия.
Uptime (Доступность системы)
Процент времени, когда система работает корректно. Измеряется за период — обычно месяц или год. Эта метрика кажется простой, но дьявол в деталях: что считать «работой»? Если приложение открывается, но оплата не проходит — это uptime или downtime?
Разница между 99% и 99.9% выглядит незначительной, но в реальности это разница между «раз в месяц можем не работать полдня» и «в месяц допускается не больше 43 минут простоя».
Как выбрать нужный uptime:
- 99% — информационные порталы, некритичные внутренние системы
- 99.5% — стандартные веб-приложения, B2B-сервисы
- 99.9% — e-commerce, мобильные приложения, финтех
MTTR (Mean Time To Recovery)
Среднее время восстановления после сбоя. В отличие от времени решения конкретного инцидента, MTTR — это средний показатель по всем инцидентам за период.
MTTR = Суммарное время простоя / Количество инцидентов
Эта метрика показывает общую эффективность процессов поддержки. Если MTTR растёт месяц от месяца — что-то идёт не так, даже если отдельные инциденты решаются в срок.
Ориентиры для разных типов систем:
- Критические системы: < 30 минут
- Важные бизнес-системы: < 2 часов
- Стандартные приложения: < 4 часов
MTBF (Mean Time Between Failures)
Среднее время между отказами — показатель надёжности системы, а не скорости её восстановления. Чем выше MTBF, тем реже система ломается.
MTBF = Общее время работы / Количество отказов
Для критических приложений целевой MTBF — не менее 720 часов (30 дней без сбоев). Если система падает чаще — это сигнал, что нужны инвестиции в стабильность, а не только в скорость реакции на инциденты.
Процент решённых инцидентов с первого раза (FCR)
First Contact Resolution — доля обращений, решённых при первом контакте с поддержкой. Высокий FCR говорит о качественной первой линии поддержки и хорошей документации.
Бенчмарки:
- Отличный FCR: > 75%
- Хороший FCR: 60–75%
- Требует улучшения: < 60%
4. Уровни критичности инцидентов
Не все проблемы одинаково критичны. Ошибка в форме обратной связи — неприятно, но бизнес работает. Неработающая оплата в приложении — катастрофа, каждая минута простоя стоит денег.
SLA должен чётко определять уровни критичности и критерии их присвоения. Это устраняет споры «почему мой баг не чинят первым» и позволяет команде правильно расставлять приоритеты.
Классификация инцидентов
P1 — Критический (Critical)
Система полностью неработоспособна или критическая функция недоступна для всех пользователей. Это ситуация «всё стоит», когда бизнес теряет деньги каждую минуту.
Примеры P1-инцидентов:
- Приложение не запускается у всех пользователей
- Невозможно совершить оплату
- Утечка персональных данных
- Полная недоступность сервиса
P1 означает: бросаем всё, будим людей ночью, чиним немедленно.
P2 — Высокий (High)
Критическая функция ограничена или недоступна для части пользователей. Есть workaround, но он значительно усложняет работу. Бизнес продолжает работать, но с потерями.
Примеры P2-инцидентов:
- Оплата работает только одним способом из трёх
- Приложение работает, но крайне медленно (> 10 секунд на операцию)
- Не работает важная интеграция (например, с 1С)
P3 — Средний (Medium)
Некритичная функция не работает. Бизнес-процессы продолжаются, но с неудобствами. Пользователи недовольны, но могут выполнить свои задачи.
Примеры P3-инцидентов:
- Не работают push-уведомления
- Ошибка в отображении данных (данные верные, но показываются некорректно)
- Не загружаются изображения в ленте
P4 — Низкий (Low)
Косметические дефекты, улучшения, пожелания. Не влияют на работу системы и не мешают пользователям.
Примеры P4-инцидентов:
- Опечатка в тексте
- Неоптимальный UX в редко используемой функции
- Запрос на новую функциональность
Матрица приоритетов
Для объективного определения приоритета полезно использовать матрицу, которая учитывает два фактора: влияние на бизнес и срочность.
Влияние определяется тем, сколько пользователей затронуто и насколько критична функция для бизнеса. Сломанная оплата — высокое влияние, даже если затронуты не все пользователи.
Срочность зависит от наличия workaround и от того, как быстро ситуация ухудшится. Утечка данных — максимальная срочность. Баг, который проявляется раз в неделю — низкая срочность.
Эскалация
SLA должен описывать, что происходит, если проблема не решается вовремя. Эскалация — это не наказание, а механизм подключения дополнительных ресурсов.
Эскалация должна быть автоматической: если P1-инцидент не решён за 2 часа, система сама уведомляет нужных людей. Это снимает страх «беспокоить начальство» и гарантирует, что критические проблемы получат внимание.
Запускаете новый продукт?
Продумаем SLA и процессы поддержки ещё до релиза — чтобы после запуска всё работало как часы.
5. Структура SLA: что должно быть в документе
Хороший SLA — это не юридическая формальность на 50 страниц мелким шрифтом. Это рабочий документ, который обе стороны понимают одинаково и используют в повседневной работе. Если SLA нужно перечитывать каждый раз с юристом — он написан плохо.
Обязательные разделы
1. Описание услуг
Что именно входит в поддержку — и, что не менее важно, что не входит. Чем конкретнее этот раздел, тем меньше споров в будущем.
✓ Мониторинг доступности 24/7
✓ Исправление дефектов в коде
✓ Обновление зависимостей безопасности
✗ Разработка нового функционала
✗ Редизайн интерфейса
Если что-то явно не указано — считайте, что это не входит.
2. Часы работы поддержки
Когда команда доступна для обработки обращений. Это напрямую влияет на стоимость и на реалистичность обещаний.
24×7 звучит привлекательно, но стоит значительно дороже. Если ваши пользователи спят с полуночи до 6 утра — возможно, 18×7 будет достаточно.
3. Каналы коммуникации
Как подавать заявки и получать статус. Это должно быть удобно для обеих сторон:
- Email с гарантированным SLA на ответ — для не срочных вопросов
- Система тикетов (Jira, Zendesk) — для отслеживания и истории
- Телефон для P1-инцидентов — когда каждая минута на счету
- Мессенджеры (Telegram, Slack) — для оперативной связи
4. Метрики и целевые показатели
Все метрики с конкретными цифрами — время реакции, время решения, uptime. Подробно мы разобрали это в разделе 3.
5. Ответственность сторон
SLA — это двусторонние обязательства. Заказчик тоже должен выполнять свою часть:
Что должен обеспечить заказчик:
- Доступ к системам (тестовые среды, логи, мониторинг)
- Контактных лиц для коммуникации
- Своевременное согласование решений
- Информирование об изменениях в инфраструктуре
Что гарантирует исполнитель:
- Соблюдение SLA-метрик
- Компетенцию команды
- Документирование всех работ
- Регулярную отчётность
6. Штрафные санкции
Что происходит при нарушении SLA. Это механизм разделения рисков, а не инструмент наказания.
Типичные схемы:
- Скидка на следующий период (5–20% за каждое нарушение)
- Дополнительные бесплатные часы
- Возврат части оплаты
7. Процедура пересмотра
SLA не должен быть высечен в камне. Как и когда он пересматривается? Рекомендуем — раз в год или при существенных изменениях в системе. Бизнес меняется, требования меняются, SLA должен меняться вместе с ними.
Чего не должно быть в SLA
Размытые формулировки — смерть для SLA:
- «Оперативно реагировать на инциденты» — что такое «оперативно»?
- «Обеспечить высокую доступность» — какую именно?
Нереалистичные обещания:
- 99.999% uptime для обычного веб-приложения — это 5 минут простоя в год
- Время реакции 5 минут в режиме 8×5 — это невозможно обеспечить без круглосуточной команды
Односторонние обязательства:
- Только штрафы для исполнителя
- Никакой ответственности заказчика за предоставление доступов
Если что-то из этого есть в предлагаемом SLA — это повод для переговоров.
Сложная система требует профессиональной поддержки?
Расскажите о вашем продукте — подберём модель SLA с учётом нагрузки и бизнес-требований.
6. Модели технической поддержки
Как организовать поддержку — зависит от сложности системы, бюджета и требований к скорости реакции. Нет универсально правильной модели — есть модель, подходящая для вашей ситуации.
Time & Materials (T&M)
Оплата по факту — за реально потраченные часы. Это самый гибкий вариант, подходящий для непредсказуемой нагрузки.
Плюсы: вы платите только за то, что использовали. Нет фиксированных платежей в месяцы, когда всё работает идеально. Полная гибкость в приоритетах — хотите сегодня чинить баг, а завтра делать доработку — пожалуйста.
Минусы: непредсказуемый бюджет. В плохой месяц счёт может удивить. Нет жёстких гарантий по времени реакции — команда работает на нескольких проектах.
Для кого: системы с редкими инцидентами, когда сложно прогнозировать нагрузку. Подходит на этапе, когда продукт стабилен и не требует постоянного внимания.
Фиксированный пакет часов
Ежемесячный пул часов за фиксированную стоимость. Вы покупаете, например, 40 часов в месяц, и команда работает в рамках этого пула.
Плюсы: предсказуемый бюджет — вы знаете, сколько потратите. Гарантированный ресурс команды — часы уже выделены под вас.
Минусы: риск «сжечь» часы на ненужное или не использовать и потерять. Сложно масштабировать в пик инцидентов — если часы кончились, нужно покупать дополнительные.
Для кого: стабильные системы со средней нагрузкой на поддержку. Когда вы примерно понимаете, сколько часов нужно в месяц.
Dedicated Team (Выделенная команда)
Команда, работающая только на ваш проект. Один или несколько специалистов полностью погружены в ваш продукт.
Плюсы: глубокое знание системы — команда знает каждый уголок кода. Максимальная скорость реакции — не нужно переключаться между проектами. Возможность совмещать поддержку и развитие продукта.
Минусы: высокая стоимость — вы платите за полную занятость людей. Нужен достаточный объём задач, чтобы команда не простаивала.
Для кого: крупные системы, требующие постоянного развития и поддержки. Когда у вас достаточно задач, чтобы загрузить команду на 100%.
SLA-based (Поддержка по SLA)
Фиксированная стоимость за гарантированный уровень сервиса. Независимо от количества инцидентов — если их больше, подрядчик не выставит дополнительный счёт.
Плюсы: полная предсказуемость стоимости и качества. Ответственность подрядчика за результат — ему выгодно, чтобы система работала стабильно. Прозрачные метрики для контроля.
Минусы: не включает развитие продукта — только поддержка. Может быть дороже T&M при малом количестве инцидентов — вы платите за гарантии, даже если они не понадобились.
Для кого: зрелые продукты с предсказуемой нагрузкой. Когда вам нужны именно гарантии.
Сравнение моделей
7. Сколько стоит SLA поддержка
Вопрос стоимости — один из первых, который задают заказчики. И это правильно: понимание ценового диапазона помогает планировать бюджет и сравнивать предложения.
Факторы ценообразования
Стоимость поддержки складывается из нескольких факторов, каждый из которых существенно влияет на итоговую цену.
Режим работы — чем больше часов покрытия, тем дороже:
- 8×5 — базовая стоимость
- 12×7 — +30–50% к базе
- 24×7 — +80–150% к базе
Круглосуточная поддержка требует как минимум трёх смен, а значит — втрое больше людей.
Сложность системы — чем сложнее, тем дороже:
- Простое приложение — базовая стоимость
- Средняя сложность (интеграции, высокие нагрузки) — +30–50%
- Высокая сложность (финтех, распределённые системы) — +50–100%
Чем сложнее система, тем более квалифицированные специалисты нужны для её поддержки.
Строгость SLA — жёсткие гарантии стоят денег:
- Стандартный SLA — базовая стоимость
- Строгий SLA (99.9% uptime, 15 мин реакция) — +50–100%
Обеспечить 99.99% uptime технически сложнее и требует резервирования на всех уровнях.
Как оптимизировать затраты на поддержку
Автоматизация мониторинга. Чем раньше вы узнаёте о проблеме, тем быстрее и дешевле её решить. Инвестиции в качественный мониторинг окупаются снижением MTTR и количества критических инцидентов.
Качественная документация. Если команда поддержки быстро разбирается в системе, инциденты решаются быстрее. Меньше часов на каждый инцидент — ниже общая стоимость.
Регулярное обновление зависимостей. Технический долг накапливает проблемы. Превентивная работа по обновлению библиотек и фреймворков дешевле реактивного тушения пожаров.
Адекватный уровень SLA. Не платите за 99.99% uptime, если вашему бизнесу достаточно 99.5%. Не покупайте 24×7, если ваши пользователи работают с 9 до 18.
Хотите узнать стоимость поддержки вашего продукта?
Проанализируем систему, определим оптимальный уровень SLA и подготовим коммерческое предложение.
8. Типичные ошибки при составлении SLA
За годы работы мы видели десятки SLA — и хороших, и не очень. Некоторые ошибки встречаются настолько часто, что стоит разобрать их отдельно. Зная эти подводные камни, вы сможете избежать их в своих соглашениях.
«Время реакции = время решения»
Это, пожалуй, самая распространённая путаница. Клиент видит «реакция 15 минут» и думает, что проблема будет решена за 15 минут. На самом деле — это время первого ответа. Решение P1-инцидента может занять 4 часа, и это нормально для сложной проблемы.
Как избежать: чётко разделяйте Response Time и Resolution Time в SLA. При обсуждении с клиентом убедитесь, что он понимает разницу. Лучше потратить 10 минут на объяснение сейчас, чем разруливать конфликт во время инцидента.
Нереалистичные целевые показатели
Подрядчик обещает 99.99% uptime и 5 минут реакции 24/7 — за небольшие деньги. Звучит прекрасно. Но такие обещания либо не будут выполнены, либо скрывают подводные камни (например, очень узкое определение «инцидента» или длинный список исключений).
Как избежать: спрашивайте, как подрядчик планирует обеспечить заявленный уровень. Сколько людей в команде? Как организовано дежурство? Какие инструменты мониторинга? Если на эти вопросы нет чётких ответов — это красный флаг.
Отсутствие исключений
SLA без исключений — ловушка для обеих сторон. Что если проблема вызвана DDoS-атакой на вашу инфраструктуру? Сбоем AWS? Ошибкой самого заказчика, который выкатил кривой релиз?
Как избежать: включайте раздел с обоснованными исключениями. Форс-мажор (стихийные бедствия, военные действия). Плановые работы с предварительным уведомлением. Проблемы на стороне третьих сервисов, которые вы не контролируете. Инциденты, вызванные действиями заказчика.
Только штрафы, без бонусов
SLA, построенный только на наказаниях, демотивирует команду и создаёт adversarial-отношения между сторонами. Подрядчик начинает думать не «как сделать лучше», а «как не нарваться на штраф».
Как избежать: добавляйте позитивные стимулы. Бонус за превышение целевых показателей. Пролонгация на улучшенных условиях при хорошей работе. Расширение scope без увеличения стоимости как награда за стабильность.
Игнорирование ответственности заказчика
SLA, где все обязательства — на подрядчике, несправедлив и нереалистичен. Если заказчик не даёт доступы три дня, не отвечает на запросы, выкатывает релизы без уведомления поддержки — SLA будет нарушен, но не по вине подрядчика.
Как избежать: фиксируйте обязательства заказчика. Время на предоставление доступов (например, 4 часа для P1-инцидента). Время на согласование решений. Назначение ответственных лиц с контактами. Порядок уведомления о релизах и изменениях.
Отсутствие процедуры эскалации
Что происходит, если первая линия поддержки не справляется? Без чёткой эскалации проблема «зависает» — никто не хочет признавать, что не может решить, и тянет время.
Как избежать: описывайте эскалацию детально. Кто и когда подключает следующий уровень. Кого уведомлять при критических инцидентах. Как эскалировать на уровень руководства. Эскалация должна быть автоматической, а не зависеть от решения инженера.
9. Чек-лист: как выбрать подрядчика с хорошим SLA
Выбор подрядчика для технической поддержки — решение, с которым вы будете жить годами. Ошибка здесь дорого стоит: и финансово, и репутационно. Вот на что обращать внимание.
Вопросы, которые нужно задать
Про опыт:
- Какие системы вы поддерживаете сейчас? Можете назвать масштаб?
- Есть ли опыт с нашим технологическим стеком?
- Можете показать примеры SLA с другими клиентами (обезличенные)?
Если подрядчик поддерживает только небольшие лендинги, а вам нужна поддержка высоконагруженного приложения — это разный опыт.
Про процессы:
- Как организован мониторинг? Какие инструменты используете?
- Какие инструменты для трекинга инцидентов?
- Как происходит передача знаний при старте? Сколько времени занимает?
Хороший подрядчик расскажет о процессах в деталях. Плохой — скажет «разберёмся по ходу».
Про команду:
- Сколько человек будет работать над нашим проектом?
- Какая квалификация у специалистов? Можно ли посмотреть резюме?
- Как организована подмена при отпусках/болезнях?
Если на вас работает один человек — что будет, когда он уйдёт в отпуск?
Про условия:
- Какие метрики вы готовы гарантировать письменно?
- Какие штрафные санкции предусмотрены?
- Как и когда пересматриваются условия SLA?
Красные флаги
Есть сигналы, которые должны насторожить при выборе подрядчика:
Не готовы фиксировать метрики письменно. Если подрядчик обещает «быструю реакцию», но отказывается писать конкретные цифры в договор — скорее всего, он не уверен, что сможет их обеспечить.
Обещают слишком много за маленькие деньги. Круглосуточная поддержка с 15-минутной реакцией за подозрительно низкую стоимость — либо обман, либо на вас работает один джуниор на полставки. Качественная поддержка стоит денег.
Нет прозрачной отчётности. Вы должны видеть, как выполняется SLA — не раз в год, а регулярно. Если подрядчик не предоставляет ежемесячные отчёты по метрикам — вы не сможете контролировать качество.
Не задают вопросов о вашей системе. Хороший подрядчик хочет понять специфику проекта до того, как давать обещания. Если SLA предлагают «под копирку» без погружения — значит, не понимают, что будут поддерживать.
Нет референсов. Попросите контакты текущих или бывших клиентов, чтобы спросить их мнение. Отказ предоставить референсы — плохой знак.
Чек-лист оценки SLA
Используйте этот чек-лист для оценки предложений от подрядчиков. Каждый пункт — это must have для качественного SLA:
- [ ] Чётко описан scope услуг (что входит, что не входит)
- [ ] Указаны конкретные метрики с цифрами
- [ ] Определены уровни критичности инцидентов
- [ ] Описана процедура эскалации
- [ ] Есть раздел с ответственностью заказчика
- [ ] Указаны обоснованные исключения
- [ ] Предусмотрены штрафные санкции за нарушения
- [ ] Описан процесс пересмотра SLA
- [ ] Предоставляется регулярная отчётность
- [ ] Есть возможность пробного периода
Если какие-то пункты не выполняются — это повод для переговоров до подписания, а не после первого инцидента.
Заключение
SLA технической поддержки — это не бюрократия и не формальность. Это инструмент защиты вашего бизнеса, который работает именно тогда, когда что-то идёт не так. В хорошие времена SLA лежит в папке и никому не нужен. Но когда система падает в пик продаж — вы будете благодарны себе за то, что потратили время на грамотное соглашение.
Ключевые принципы хорошего SLA
Что запомнить
- SLA — не гарантия вечной работы. Это соглашение о том, как быстро проблемы будут решены, а не обещание, что их не будет.
- Разделяйте время реакции и время решения. Это разные метрики с разными значениями, и путаница между ними — источник конфликтов.
- Выбирайте адекватный уровень. Не платите за 99.99% uptime, если достаточно 99.5%. Не покупайте 24×7, если ваши пользователи спят ночью.
- Фиксируйте ответственность обеих сторон. SLA — не односторонние обязательства подрядчика. Заказчик тоже должен выполнять свою часть.
- Требуйте отчётность. Без регулярных измерений SLA — просто бумага с красивыми обещаниями.
Готовы выстроить надёжную поддержку продукта?
Surf — 250+ специалистов с опытом поддержки банковских, e-commerce и фудтех-приложений.
