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

Причина обычно не в том, что кто-то «плохо работает», а в том, что стороны по-разному понимают поддержку: для бизнеса недоступная оплата в течение часа — это авария, а для подрядчика — задача, которую можно взять в работу в рамках обычного рабочего дня.

Именно поэтому SLA в договоре на разработку мобильного приложения — не приложение ради формальности и не таблица с обещанием «быстро отвечать». Это договорённость о том, какой сервис получает бизнес после запуска, как измеряется его качество, кто устраняет инцидент и что происходит, если заявленные показатели не выполнены. По данным Gartner, чётко оформленное соглашение об уровне сервиса снижает частоту эскалаций и конфликтов с подрядчиками на 40%. Цифра объяснима: вместо эмоционального обсуждения «почему приложение опять не работает» у сторон появляется общий язык метрик.

Я неоднократно видела, как в SLA смешивают сроки разработки, время реакции саппорта, гарантии хостинга и общие пожелания к качеству. В результате документ становится длинным, но нерабочим. Хорошее соглашение устроено иначе: оно фиксирует пользовательские боли, превращает их в измеримые показатели и заранее описывает границы ответственности.

SLI, SLO и SLA: три уровня одной договорённости

В Service Level Agreement в договоре IT часто используют три похожие аббревиатуры, хотя они отвечают на разные вопросы. Если не разделить их на старте, документ почти неизбежно окажется расплывчатым.

SLI, Service Level Indicator, — это индикатор. Он показывает, что именно команда измеряет. Например:

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

SLO, Service Level Objective, — это цель для индикатора. Если SLI — фактическая доступность приложения, то SLO может звучать так: доступность должна быть не ниже 99,9% за календарный месяц.

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

На практике мне ближе подход, при котором в SLA сначала описывают не серверы и технологии, а ключевые пользовательские сценарии. Для маркетплейса это регистрация, поиск, корзина, оплата и отслеживание заказа. Для финтех-приложения — вход, просмотр баланса, переводы, подтверждение операций. Для корпоративного сервиса — авторизация сотрудников, доступ к данным, синхронизация и уведомления.

Такой порядок снижает когнитивную нагрузку для обеих сторон. Бизнесу не нужно угадывать, почему «доступность кластера» внезапно стала главным показателем. Команда разработки, в свою очередь, получает понятный приоритет: сохранять бесшовный опыт в тех точках, где пользователь действительно может уйти или потерять деньги.

SLA работает не тогда, когда в нём много процентов, а когда из процента понятно, какой пользовательский сценарий защищён.

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

Приоритеты P1–P4: скорость реакции не равна скорости исправления

Фраза «подрядчик устраняет ошибки в течение 24 часов» почти ничего не говорит о реальном качестве поддержки. Ошибки бывают разными: у части пользователей не открывается история заказов, у всех клиентов не проходит оплата, а где-то в интерфейсе съехала иконка. Для бизнеса это три совершенно разные ситуации, и SLA должен их различать.

Обычно используют уровни P1–P4. Названия могут меняться, но смысл иерархии остаётся одинаковым.

1. P1 — критический инцидент. Приложение или ключевая функция недоступны для всех либо для значительной части пользователей. Например, после обновления не проходит авторизация, не открывается каталог, не работают платежи, приложение аварийно закрывается на старте. Для P1 разумно фиксировать реакцию от 15 минут, а целевой срок восстановления — от двух часов, если архитектура и режим поддержки позволяют это обеспечить.

2. P2 — серьёзная деградация. Сервис доступен, но важный сценарий работает с ограничениями. Например, один из способов оплаты перестал отвечать, отправка заказа занимает несколько минут вместо секунд, уведомления не приходят, часть пользователей не может загрузить документы. Здесь время реакции может быть больше, но документ должен прямо говорить, что считается восстановлением: временный обход проблемы или полноценное исправление.

3. P3 — некритичный дефект. Ошибка мешает части пользователей, но не блокирует основную задачу. Это может быть неверный текст статуса, сбой сортировки, проблема в редком сценарии или неудобная вёрстка на отдельной модели устройства. Такие задачи обычно идут в ближайший плановый релиз.

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

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

Если подрядчик обещает «ответить за 15 минут», это не означает, что платежи заработают через 15 минут. Но и формальное сообщение «видим проблему» не должно закрывать P1-инцидент. В рабочем SLA полезно отдельно указывать:

• канал, по которому регистрируется авария;
• время, с которого начинается отсчёт;
• время подтверждения категории инцидента;
• частоту статус-апдейтов при P1 и P2;
• критерий восстановления;
• срок постинцидентного отчёта с причиной и мерами профилактики.

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

Почему 99,9% доступности — это не «почти всегда работает»

Цифра uptime кажется интуитивной, пока её не переводят в минуты. Для мобильных приложений, e-commerce и финтех-продуктов распространённый целевой ориентир — 99,9% доступности. За месяц это примерно 43 минуты недоступности. Для стандартного веб-приложения или B2B-сервиса типичным ориентиром может быть 99,5%, для некритичных информационных систем — 99%.

Разница между этими значениями выглядит небольшой только в процентах.

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

Уровень доступности должен соответствовать цене ошибки. Если мобильное приложение помогает сотрудникам согласовывать внутренние заявки, ночная недоступность может быть приемлема. Если приложение принимает платежи или обеспечивает доступ к медицинской записи, допустимое окно сокращается. Здесь продуктовая логика важнее красивого числа.

Нужно также определить, что именно считается доступностью. Приложение может открываться, но не давать оформить заказ. Формально сервер отвечает, а пользовательская ценность отсутствует. Поэтому для критичных сервисов полезно считать не только доступность инфраструктуры, но и успешность ключевой транзакции: входа, оплаты, оформления заявки, загрузки документа.

Метрика восстановления тоже должна быть конкретной. MTTR, Mean Time To Recovery, показывает среднее время восстановления после сбоя: суммарное время простоя за период делят на количество инцидентов. Показатель полезный, но сам по себе недостаточный. Средний MTTR в 40 минут может выглядеть хорошо, если девять инцидентов устранили за 10 минут, а один оставил пользователей без сервиса на пять часов.

Среднее значение успокаивает отчёт. Пользователя в момент сбоя интересует худший, а не средний сценарий.

Поэтому рядом с MTTR я бы фиксировала целевые сроки для P1 и P2, а в ежемесячном отчёте просила показывать не только среднее, но и максимальную длительность инцидента, количество повторных сбоев и долю проблем, обнаруженных мониторингом до обращения пользователей.

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

Самая неприятная ситуация возникает, когда SLA выглядит подробным, но не даёт ответ на простой вопрос: кто именно обязан действовать, если перестал работать конкретный компонент.

Мобильный сервис редко существует в изоляции. В нём могут быть облачный хостинг, CDN, система аналитики, push-провайдер, платёжный шлюз, сервис SMS, карты, авторизация через внешнего поставщика, инструменты краш-аналитики. Заказчик видит один экран с ошибкой. Подрядчик видит цепочку из пяти интеграций и может сказать, что проблема находится «на стороне третьего лица».

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

В документе стоит разложить сервис на зоны:

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

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

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

Исключения не ослабляют SLA, а делают его честным

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

Плановые технические работы — очевидный пример. Если команда заранее объявила окно, провела обновление ночью и сервис был ограниченно доступен в согласованный период, это не должно автоматически ухудшать месячный uptime. Но в SLA нужно указать, за сколько времени предупреждать о работах, какова максимальная продолжительность окна и можно ли проводить его в периоды пикового спроса.

К типовым исключениям также относятся:

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

Но список исключений не должен превращаться в универсальную индульгенцию. Формулировка «исполнитель не отвечает за проблемы сторонних сервисов» недостаточна, если именно исполнитель выбрал интеграцию, настроил её без резервного сценария и не включил мониторинг. Важен не только источник сбоя, но и управляемая реакция на него.

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

Штрафы не заменяют работающий процесс поддержки

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

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

Вместо абстрактного «штрафа за каждый сбой» полезнее сочетать несколько механизмов:

1. Сервисные кредиты или уменьшение стоимости поддержки при подтверждённом нарушении целевых показателей.

2. Постинцидентный разбор для P1 и значимых P2 с причиной, временной шкалой, действиями и владельцами профилактических мер.

3. Периодический пересмотр SLO, когда продукт растёт, появляются новые интеграции или меняется критичность пользовательских сценариев.

4. Прозрачная отчётность по доступности, инцидентам, MTTR, повторяемости ошибок и выполнению профилактических задач.

5. План непрерывности, если приложение критично для выручки: резервные каналы, ручной сценарий обслуживания, переключение провайдеров, порядок коммуникации с клиентами.

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

SLA в договоре на разработку мобильного приложения стоит воспринимать как карту совместной эксплуатации продукта, а не как способ заставить подрядчика пообещать невозможное. Для зрелого мобильного сервиса 99,9% доступности действительно может быть разумным ориентиром, но ценность создаёт не сама цифра. Её создают измеримые SLI, реалистичные SLO, приоритеты P1–P4, честные исключения и чётко проведённая граница ответственности.

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