SLA поддержки мобильного приложения: какие обязательства согласовать с подрядчиком
Договор на поддержку мобильного приложения обычно описывает состав работ и почти не описывает скорость: сколько приложение может быть недоступно, за какое время подрядчик ответит и за какое вернёт сервис в работу. SLA переводит поддержку в проверяемые числа, и дальше мы разбираем, какие обязательства в нём зафиксировать и чем их измерять.
Что такое SLA поддержки мобильного приложения
SLA (Service Level Agreement — соглашение об уровне обслуживания) — приложение к договору с измеримыми параметрами услуги: что считается инцидентом, с какой скоростью подрядчик реагирует, в какие часы доступен и что происходит при невыполнении. Вместо «оперативно отреагируем» появляется «ответ в течение 30 минут в рабочее время по первому уровню».
Терминология пришла из управления ИТ-услугами: её описывают ITIL 4 и ГОСТ Р ИСО/МЭК 20000-1. Для мобильного приложения есть поправка: продукт состоит из клиентской части на устройстве и серверной части с API, и обязательства по ним формулируются по-разному.
Границы SLA и остальной части договора
SLA отвечает за скорость и доступность; состав работ, приёмка, стоимость и ответственность сторон живут в самом договоре. Разделение удобно практически: состав работ меняется редко, а значения по времени реакции пересматривают при росте нагрузки или переходе на круглосуточное дежурство.
Риски поддержки без согласованного SLA
Поддержка без согласованных параметров держится на доброй воле и загрузке команды. Пока инцидентов мало, разницы не видно; она проявляется в пятницу вечером, когда в приложении перестаёт работать оплата.
Спор о приоритете вместо работы над инцидентом
Без описанных уровней каждое обращение обсуждается заново. Заказчик считает неработающую авторизацию остановкой продаж, подрядчик — ошибкой для планового обновления. Переписка о приоритете занимает часы, которые ушли бы на починку.
Нечем измерить качество поддержки
Вторая проблема возникает через полгода, когда нужно оценить работу подрядчика или сравнить предложения на год вперёд: без метрик обсуждение опирается на впечатления сторон. По нашему опыту SLA экономит не столько время на инцидентах, сколько время руководителей на разбор спорных случаев.
Доступность, время реакции и время восстановления: три разные метрики
Главная путаница в переговорах — склейка трёх независимых обязательств в фразу «поддержка 99,9%». Это три параметра: измеряются по-разному и нарушаются независимо.
Три метрики SLA: что именно измеряет каждая
| Метрика | Что измеряет | Как считается | Кто на неё влияет |
|---|---|---|---|
| Доступность сервиса | Долю времени, когда серверная часть корректно отвечает на запросы | Процент от периода за вычетом регламентных работ | Подрядчик, хостинг, внешние сервисы интеграций |
| Время реакции | От регистрации обращения до ответа инженера с уровнем инцидента | По отметкам в системе учёта, внутри окна поддержки | Подрядчик и дежурная смена |
| Время восстановления | От регистрации обращения до возврата сценария в работу | По отметке закрытия, с остановкой счётчика на ожидании заказчика | Подрядчик, заказчик, сторонние поставщики |
Доступность сервиса
Доступность относится к серверной части: к API, которое отдаёт приложению каталог, корзину, статус заказа и профиль. Приложение на устройстве запускается и без связи с сервером, поэтому предмет обязательства — серверная часть и интеграции, а не «доступность приложения».
Процент удобно переводить в минуты, чтобы обе стороны понимали, о чём договариваются. За 30 календарных дней допустимый простой выглядит так:
Доступность в процентах и в минутах простоя за 30-дневный период
| Доступность | Допустимый простой за 30 дней | Что это означает на практике |
|---|---|---|
| 99,0% | 7 часов 12 минут | Почти рабочий день простоя в месяц — внутри обязательства |
| 99,5% | 3 часа 36 минут | Приложение с дневным трафиком, дежурство по рабочим дням |
| 99,9% | около 43 минут | Нужны круглосуточное дежурство и резерв серверной части |
| 99,95% | около 22 минут | Оплата идёт круглосуточно; удорожает инфраструктуру |
Арифметика простая: в 30 сутках 43 200 минут, каждая десятая доля процента — 43 минуты. Проверьте, что в договоре названы расчётный период, способ фиксации простоя и события, которые в расчёт не попадают.
Время реакции
Время реакции — обязательство ответить на обращение: подтвердить получение, присвоить уровень инцидента и назвать следующий шаг. Исправление в этот интервал не входит. Метрика зависит в основном от организации дежурства у подрядчика, поэтому проверяется легче остальных.
Измеримой её делают два условия. Первое — единая точка регистрации: система учёта заявок или выделенный адрес, по отметкам которого считается время (в мессенджере момент регистрации не фиксируется). Второе — счётчик идёт внутри окна поддержки: обращение в 23:40 при дежурстве до 19:00 попадает в утро следующего рабочего дня.
Время восстановления
Время восстановления — интервал до возврата сценария в рабочее состояние. Здесь нужны два уточнения, без которых метрика не измеряется.
Первое — что считать восстановлением. Обходное решение (отключённая функция, откат серверной части, ручная обработка заказов) закрывает инцидент, а причина устраняется отдельной задачей со своим сроком. Без этого разделения спор возникает там, где продажи вернулись, а ошибка в коде ещё жива.
Второе — остановка счётчика. Пока подрядчик ждёт доступ к учётной системе, подтверждение тестового заказа или ответ поставщика платежей, время не идёт в его обязательство. Основания для остановки — закрытый список в SLA.
Уровни инцидентов и приоритеты обращений
Единых значений для всех обращений не бывает: у неработающей оплаты и у опечатки в карточке товара разные сроки. Уровни инцидентов распределяют обращения по влиянию на бизнес, и каждому достаются свои числа.
Пример градации уровней для приложения интернет-магазина. Значения справа — пример заполнения шаблона: в договоре их согласуют под нагрузку и режим дежурства проекта
| Уровень | Признак | Пример обращения | Реакция | Восстановление |
|---|---|---|---|---|
| Первый (критический) | Продажи остановлены или приложение не запускается | Не проходит оплата; приложение закрывается на старте после обновления системы | 30 минут | 4 часа до обходного решения |
| Второй (высокий) | Ключевой сценарий работает частично или на одной платформе | Не приходят уведомления о статусе заказа, поиск не отдаёт часть каталога | 2 часа | 1 рабочий день |
| Третий (средний) | Ошибка заметна пользователю, но сценарий проходится | Скидка в корзине считается неверно при одном способе доставки | 1 рабочий день | 5 рабочих дней |
| Четвёртый (низкий) | Косметическая правка или запрос на изменение | Опечатка в тексте экрана, смена баннера на главной | 2 рабочих дня | В ближайшем плановом обновлении |
Порядок присвоения уровня
Рабочая схема: заказчик присваивает уровень при регистрации, подрядчик подтверждает или предлагает изменить его внутри времени реакции, несогласие выносят руководителям проекта. Схема снимает оба перекоса: когда уровень назначает только подрядчик, обращения тяготеют к третьему; когда только заказчик — к первому.
Формулировка признака уровня
Признак уровня описывается словами сценария пользователя. «Оплата не проходит» понятно обеим сторонам; «ошибка 500 на отдельном методе API» — только разработчикам, и сотрудник, который регистрирует обращение в восемь утра, уровень по такому признаку не выберет. К SLA полезно приложить список примеров из реальных обращений.
Окна поддержки и дежурства
Окно поддержки — часы, в которые действуют обязательства по времени реакции. Раздел влияет на стоимость сильнее прочих: круглосуточное дежурство требует сменной работы и другой численности команды.
Три типовых режима
Режимы поддержки и их применимость
| Режим | Когда подходит | Что проверить в формулировке |
|---|---|---|
| Рабочие дни, 8 часов | Заказы идут днём, пик — на рабочей неделе | Часовой пояс окна и порядок обращений в выходные |
| Семь дней в неделю, расширенное окно | Выходные дают заметную долю заказов: доставка еды, розница | Границы окна в праздники, состав дежурной смены |
| Круглосуточно | Оплата и заказы идут непрерывно, ночной простой стоит денег | Канал вызова дежурного инженера и время его подъёма по тревоге |
Частый компромисс — разные окна по уровням: круглосуточное дежурство по первому, остальные обращения в рабочие дни. Схема закрывает риск остановки продаж без круглосуточной смены на поток правок.
Регламентные работы
Обновление серверной части, перенос базы данных, работы хостинга — запланированный простой, который по согласованию не входит в расчёт доступности. Чтобы оговорка не закрывала любой инцидент, в SLA фиксируют три условия: срок предупреждения, длительность одного окна и лимит такого простоя за период.
Пиковые даты
Отдельно стоит описать даты, когда регламентные работы не проводятся и действует усиленное дежурство: распродажи, предпраздничные недели, старт сезонных коллекций. Календарь таких дат заказчик передаёт заранее, приложением к SLA.
Мониторинг: откуда берутся цифры в отчёте
Метрика без источника данных остаётся декларацией. Если в SLA не указано, какая система фиксирует простой и падения, отчёт сводится к слову подрядчика против впечатления клиента.
Серверные метрики
Доступность API измеряют внешними проверками с фиксированным интервалом и журналами ошибок на сервере. В SLA стоит назвать инструмент и интервал: «проверка каждую минуту с двух географических точек» проверяема, «постоянный мониторинг» — нет.
Метрики клиентской части
Качество приложения на устройстве измеряют по двум группам событий: падения и зависания интерфейса, когда приложение перестаёт отвечать на действия пользователя. Считают их платформы по-разному: Google Play Console даёт долю пользователей, столкнувшихся с падением и с зависанием (в документации Android — ANR, Application Not Responding), у Apple те же события приходят через MetricKit, а сопоставимую по обеим платформам долю сессий без падений даёт система сбора ошибок:
- Android vitals — пороговые значения по падениям и по зависаниям интерфейса публикует Google в документации для разработчиков: о падениях и о зависаниях интерфейса.
- MetricKit — набор показателей производительности и стабильности приложений на платформе Apple, описан в документации Apple.
- Системы сбора ошибок — например, Firebase Crashlytics: дают стек ошибки и версию приложения, на которой она воспроизводится.
Долю сессий без падений стоит вынести в отдельное обязательство с конкретным значением и одним названным источником — обычно это система сбора ошибок, а консоль стора идёт на сверку. Тогда подрядчик отвечает не только за скорость реакции, но и за стабильность продукта.
Доступы к мониторингу
Отдельный пункт — кому принадлежат учётные записи в консолях сторов, в мониторинге и в системе сбора ошибок. Рабочая схема: записи оформлены на юридическое лицо заказчика, подрядчику выданы права доступа. Заказчик видит те же числа, что и в отчёте, и проверяет его сам.
Релизы и обновления внутри SLA
У мобильного приложения исправление доходит до пользователя не сразу: между готовой версией и установкой стоят проверка в сторе и готовность обновиться. Без этой поправки подрядчик берёт на себя срок, которым не управляет.
Что входит в зону ответственности подрядчика
Подрядчик управляет сроком до готовности исправленной версии и до отправки её на проверку; срок самой проверки устанавливает площадка. Требования, по которым проходит проверка, Apple публикует в App Store Review Guidelines, у остальных сторов действуют свои правила публикации, а фактический срок меняется от загрузки площадки. Корректная формулировка разделяет оба интервала: «версия отправляется на проверку в течение N часов с подтверждения инцидента первого уровня; срок проверки в сторе в обязательство не входит».
Серверные исправления и правила обхода проверки
Часть инцидентов закрывается на серверной стороне без выпуска новой версии: правки в API, переключение функции признаком включения, изменение конфигурации. Когда ключевые сценарии управляются с сервера, восстановление по первому уровню выполнимо даже при длительной проверке в сторе. Это требование к архитектуре продукта, не только пункт SLA.
Плановые обновления и совместимость с новыми версиями платформ
Apple и Google ежегодно выпускают крупные версии операционных систем и обновляют требования к публикуемым приложениям. Совместимость — предсказуемая работа, и в SLA она идёт отдельной строкой: за какой срок после выхода новой версии платформы приложение проверяется и обновляется. Там же фиксируют регламент плановых публикаций и перечень целевых сторов — App Store, Google Play, RuStore и другие сторы, где опубликован продукт.
Формулировки, которые не работают
Шесть конструкций из проектов SLA, которые не дают измеримого обязательства, — с последствием и проверяемой заменой.
- «Реакция в кратчайшие сроки». Обязательства нет, выполнение не оценить. Замена: число в минутах или часах по каждому уровню.
- «Доступность приложения 99,9%». Предмет обязательства не определён: приложение запускается и без связи с сервером. Замена: «доступность серверной части и API — 99,9% за расчётный месяц».
- «Обращения принимаются круглосуточно». Приём подменяет обязательство по реакции: ночью заявка остаётся в очереди до утра. Замена: отдельно окно приёма и отдельно окно действия времени реакции.
- «Устранение в течение одного рабочего дня». Без разделения на обходное решение и устранение причины спор возникает на первом крупном инциденте. Замена: два срока — до возврата сценария в работу и до починки причины.
- «Подрядчик обеспечивает работоспособность интеграций». Он отвечает за простой платёжного сервиса и учётной системы, которыми не управляет. Замена: ответственность за свой код и за оповещение, с остановкой счётчика на время ожидания поставщика.
- «Нарушение SLA влечёт ответственность по договору». Последствие не определено, нарушение остаётся без издержек. Замена: механизм — перерасчёт ежемесячного платежа, дополнительные часы работ, право расторжения при повторных нарушениях.
Шаблон SLA: из каких разделов он состоит
Структура ниже — шаблон для подготовки к переговорам и сверки присланного проекта. Это не действующий договор: значения согласуются под нагрузку, а финальные формулировки проверяет юрист.
- Предмет и термины. Инцидент, обращение, обходное решение, восстановление, расчётный период.
- Состав услуги. Что входит в поддержку и что оплачивается отдельно как доработки.
- Уровни инцидентов. Градация с признаками и примерами, порядок присвоения и пересмотра.
- Время реакции и восстановления. Значения по каждому уровню, основания остановки счётчика.
- Доступность. Предмет измерения, целевой процент, расчётный период и исключения.
- Окна поддержки. Часы и дни по уровням, часовой пояс, порядок вызова дежурного инженера.
- Регламентные работы. Срок предупреждения, длительность окна, лимит за период, пиковые даты.
- Мониторинг и отчётность. Инструменты, интервал проверок, владелец учётных записей, срок ежемесячного отчёта.
- Релизы. Срок до отправки версии на проверку, регламент плановых публикаций, перечень целевых сторов, совместимость с новыми версиями платформ.
- Последствия и изменения. Механизм перерасчёта, разбор спорных случаев, периодичность пересмотра значений.
Дополнительный раздел для приложения с интеграциями
Для приложения интернет-магазина добавляется раздел о границах ответственности на стыках: обмен с учётной системой, платёжный сервис, доставка, уведомления. По каждой интеграции фиксируют три вещи: кто отвечает за канал, как измеряется его доступность и кто оповещает вторую сторону о сбое поставщика.
Чек-лист перед подписанием
Десять вопросов по проекту SLA:
- Доступность, реакция и восстановление описаны как три отдельных обязательства со своими числами?
- Для доступности назван предмет измерения — серверная часть и API, а не «приложение»?
- Указаны расчётный период и способ фиксации простоя?
- Уровней инцидента не меньше трёх, и у каждого есть признак на языке сценария пользователя?
- Определено, кто присваивает уровень и как разрешается несогласие?
- Разделены обходное решение и устранение причины, у каждого свой срок?
- Перечень оснований для остановки счётчика — закрытый список?
- Названы инструменты мониторинга и владелец учётных записей?
- Срок проверки в сторе выведен из обязательства отдельной оговоркой?
- Последствие нарушения описано механизмом, а не ссылкой на договор?
Итог: SLA на одной странице
SLA превращает поддержку в услугу с проверяемыми параметрами. Документ держится на четырёх опорах: три метрики измеряются раздельно, уровни инцидентов описаны словами бизнеса, цифры в отчёте берутся из системы с доступом у заказчика, внешние сроки выведены из обязательств подрядчика. Такой договор — оптимальный вариант для обеих сторон: заказчик получает измеримую услугу, подрядчик — обязательства, которыми управляет.
Готовите договор на поддержку приложения или получили проект SLA от подрядчика — пришлите документ нашей команде: разберём по пунктам этого чек-листа и отметим формулировки, выполнение которых по данным мониторинга не проверяется.
Частые вопросы
Что такое SLA в поддержке мобильного приложения?
SLA — приложение к договору с измеримыми параметрами поддержки: доступность серверной части, время реакции, время восстановления, уровни инцидентов, часы дежурства, источники данных для отчёта и последствия невыполнения. Задача документа — перевести поддержку в числа, выполнение которых обе стороны проверяют по одному источнику. Состав работ, стоимость и ответственность сторон остаются в договоре.
Чем время реакции отличается от времени восстановления?
Время реакции — обязательство ответить: подтвердить получение, присвоить уровень инцидента, назвать следующий шаг. Время восстановления — обязательство вернуть сценарий в работу. Первая зависит прежде всего от организации дежурства, вторая — ещё и от сложности сбоя, доступов заказчика и сторонних поставщиков. Поэтому у них разные значения и разные основания остановки счётчика.
Какая доступность нужна мобильному приложению интернет-магазина?
Значение выбирают по тому, сколько стоит простой. При 99,5% допустимая недоступность серверной части за 30 дней — 3 часа 36 минут; этого хватает магазину с дневным трафиком и дежурством по рабочим дням. Уровень 99,9% оставляет около 43 минут в месяц, но требует круглосуточного дежурства и резерва серверной части, то есть удорожает поддержку и инфраструктуру. Промежуточный вариант — круглосуточное обязательство только по первому уровню.
Как считать время восстановления, если обновление проходит проверку в сторе?
Сроком проверки в сторе подрядчик не управляет, поэтому в обязательство он не входит. В договоре разделяют два интервала: до готовности версии и её отправки на проверку — зона подрядчика, сама проверка — внешнее условие площадки. Когда ключевые сценарии управляются с серверной стороны через конфигурацию и признаки включения функций, большинство критических инцидентов закрывается без выпуска новой версии.
Какие уровни инцидентов стоит прописать в договоре?
Рабочий минимум — три уровня, по нашему опыту удобнее четыре: остановка продаж, частичная неработоспособность ключевого сценария, заметная пользователю ошибка с проходимым сценарием, косметические правки и запросы на изменение. Признак каждого уровня описывается словами сценария пользователя: по техническому симптому сотрудник, который регистрирует обращение, уровень не выберет. К документу полезно приложить список примеров и пересматривать его раз в полгода.
Кто должен владеть доступами к консолям сторов и мониторингу?
Учётные записи в консолях сторов, в мониторинге и в системе сбора ошибок стоит оформлять на юридическое лицо заказчика, а подрядчику выдавать права доступа. Результат двойной: заказчик видит те же числа, что попадают в отчёт, и может проверить его сам, а при смене подрядчика приложение и история его работы остаются доступны без отдельных переговоров.
Что должно быть последствием нарушения SLA?
Формулировка «нарушение влечёт ответственность по договору» самого последствия не описывает и издержек за нарушение не создаёт. Проверяемые механизмы — перерасчёт ежемесячного платежа пропорционально невыполненным обязательствам, дополнительные часы работ в следующем периоде, право расторжения при нескольких нарушениях подряд. Механизм привязывают к данным ежемесячного отчёта и к закрытому перечню оснований остановки счётчика. Конкретные формулировки перед подписанием проверяет юрист.
Источники
- Apple. App Store Review Guidelines: developer.apple.com (19.10.2026).
- Google. Android vitals, падения: developer.android.com (19.10.2026).
- Google. Android vitals, зависания (ANR): developer.android.com (19.10.2026).
- Apple. MetricKit — стабильность и производительность: developer.apple.com (19.10.2026).
- Google. Firebase Crashlytics — сбор ошибок: firebase.google.com (19.10.2026).
- Терминология уровней услуг — ITIL 4 и ГОСТ Р ИСО/МЭК 20000-1 «Информационные технологии. Менеджмент услуг».
