Начните с результата, который должна вернуть поддержка
Выбирайте команду по проверяемому порядку действий при сбое: кто заметит проблему, кто начнёт разбор, как вернёт основную операцию, кто подтвердит восстановление и что произойдёт при нарушении условий. До сравнения стоимости дайте кандидатам одинаковые сценарии, список систем и рабочий график.
Например, для магазина критичен путь «покупатель оформил заказ, сотрудник получил его в работу». Для сервиса записи важны доступное время, подтверждение визита и уведомление. Если договор охватывает только ошибки экрана, сервер и обмен данными могут остаться за пределами ответственности. Мы предлагаем начинать обсуждение поддержки с этих границ.
Перейти к матрице условий договора.
Разделите реакцию, восстановление и исправление причины
Реакция показывает, когда команда подключится к обращению. В договоре уточните, какое событие её подтверждает: назначен ответственный, началась диагностика, заказчик получил первый статус. Автоматическое письмо о регистрации стоит учитывать отдельным событием.
Восстановление означает, что согласованный рабочий сценарий снова доступен. Иногда для этого подходит возврат к прежней версии или временный обход. Окончательное исправление устраняет причину и требует отдельной проверки: восстановленный сервис ещё может работать с ограничением.
Допустим, после обновления перестал проходить вход. Команда вернула прежнюю серверную версию. Затем проверила вход для затронутых ролей и версий приложения по согласованным критериям. После этой проверки можно зафиксировать восстановление доступа; исправление новой версии продолжается. В журнале нужны обе точки завершения, перечень оставшихся ограничений и следующая проверка.
В руководстве Google SRE различают показатель сервиса (SLI), его целевое значение (SLO) и соглашение с последствиями выполнения или нарушения (SLA). Для покупателя это три понятных вопроса: что измеряем, какой результат хотим и какая ответственность закреплена.
Например, SLI может считать долю успешно завершённых входов за согласованный период, SLO задаёт целевую долю, а SLA описывает условия и последствия отклонения. Это отличается от срока ответа инженера. Процент доступности требует своего источника данных, периода расчёта и правил исключения; смешивать его с реакцией на заявку нельзя.
Проверьте опыт на всей цепочке приложения
В мобильном магазине «Бакаев» мы связали приложение, админ-панель и 1С через сервер синхронизации. Заказ из приложения меняет остатки в админке и 1С; изменения из 1С доходят до приложения. Для сотрудников это единый рабочий процесс, хотя технически в нём участвует несколько систем.
Реальный проект 13FOX
«Бакаев»: заказ должен дойти до сотрудника
Панель объединяет активные и завершённые заказы, их статусы, суммы и назначенных курьеров.
Попросите кандидата разобрать сопоставимый проект: какие части делала команда, какие системы связывала, кто отвечал за выпуск. Полезно увидеть обезличенный разбор инцидента, пример отчёта или инструкцию восстановления. Один красивый экран не раскрывает работу сопровождения; материалы должны соответствовать задачам вашей закупки.
Независимый отзыв проверяйте по автору, дате и описанию работы. Отзыв о дизайне помогает оценить дизайн; для сопровождения ищите конкретику про доступность команды, исправления и передачу проекта. Рейтинг используйте для первоначального списка, затем сравнивайте реальные условия и людей, которые будут работать с приложением.
Сравните предложения по одной матрице
Отправьте эту таблицу всем кандидатам. Попросите дать ответы со ссылками на пункты предложения или приложения к договору. Формулировку «по согласованию» оставьте как открытый вопрос, пока стороны не определили ответственного, событие и результат.
| Условие | Что зафиксировать | Чем проверить |
|---|---|---|
| Состав поддержки | Приложения и версии, сервер, интеграции, магазины, тестовая среда | Перечень объектов и границы работ каждой команды |
| Рабочие часы | Часовой пояс, дни, праздники, дежурство и канал вне графика | Сценарий обращения вечером или в выходной |
| Приоритет | Влияние на пользователей, потерю данных и основную операцию; кто меняет приоритет | Классификация ваших примеров сбоев |
| Реакция | Срок по каждому приоритету, рабочее или календарное время, начало отсчёта и действие команды | Время регистрации и первого содержательного ответа |
| Восстановление | Срок: цель команды или обязательство по договору; допустимый обход и ограничения | Повтор рабочего сценария и подтверждение заказчика |
| Паузы и зависимости | Основание паузы, согласование, внешние поставщики, порядок возобновления | Журнал ожиданий с причиной и следующим действием |
| Доступы и выпуск | Владельцы аккаунтов, роли, код, подпись, полномочия на срочный выпуск и откат | Реестр доступов и повторная тестовая сборка |
| Мониторинг и отчёт | Наблюдаемые операции, оповещения, получатели и период отчёта | Тестовое оповещение и образец отчёта по инцидентам |
| Ответственность | Нарушения, доказательства, последствия, лимиты и порядок разногласий | Совместная проверка условий закупкой, ИТ и юристом |
| Смена команды | Состав передачи, сроки, стоимость перехода, незакрытые задачи и отзыв прав | Приёмочный список с владельцем каждого материала |
Если два предложения называют разное время реакции, сначала уравняйте график и событие начала отсчёта. Ответ в рабочие часы и дежурство по календарному времени потребуют разного состава команды. Отдельно попросите назвать, кто подменит основного инженера и как передаст ему текущий статус.
Проверьте часы и исключения на одном инциденте
Возьмите реальный проблемный сценарий без клиентских данных и пройдите его с каждой командой. Например: сообщение об ошибке входа отправлено в пятницу вечером, затронута часть пользователей, к серверу нужен доступ сотрудника заказчика. Пусть исполнитель покажет момент регистрации, основание приоритета, начало отсчёта реакции и порядок получения доступа.
Для срочных обращений заранее определите основной канал и запасной путь, если портал заявок недоступен. Если сбой обнаружил мониторинг, договор должен объяснять, как сигнал превращается в инцидент и какую временную отметку используют. Иначе одинаковая ошибка получит разные сроки в зависимости от того, кто её заметил.
Запишите паузу как событие. Кто её объявил, что конкретно требуется, кто это предоставит и когда команда сообщит следующий статус. Уточните, какие сроки приостанавливаются и какие обязанности продолжаются. Ожидание внешнего сервиса само по себе не объясняет, почему заказчик перестал получать информацию.
При сбое оплаты подрядчик может управлять приложением и сервером, а срок исправления платёжной платформы зависит от её владельца. Согласуйте, кто откроет обращение поставщику, передаст диагностику, проверит обход и сверит результат. Для мобильного обновления отдельно учитывайте подачу сборки и доступность версии пользователям после решения магазина.
В руководстве Google по работе с инцидентами выделены роли, координация и рабочая запись расследования. Для небольшого приложения один человек может совмещать роли; заказчику всё равно нужен понятный контакт, который ведёт инцидент до согласованного результата.
Отделите инциденты от изменений продукта
Инцидент нарушает согласованную работу продукта: не проходит вход, заказ не доходит до сотрудника, пропадает результат операции. Запрос на изменение добавляет поведение: новый способ оплаты, роль или отчёт. Новые функции требуют требований и приёмки; их очередь не должна скрывать текущее нарушение работы.
Например, ошибка существующего отчёта и просьба добавить новый столбец выглядят как задачи на одном экране. У них разные ожидаемые результаты. Для ошибки нужно восстановить согласованное поведение, для столбца определить данные, права и правила расчёта. Если причина обращения пока неизвестна, сначала назначьте диагностику, затем согласуйте классификацию.
Уточните также границы гарантии, обновлений зависимостей и совместимости с новыми версиями ОС. Запишите, какие работы входят в поддержку, как согласуют превышение объёма и кто решает спорный случай. Состав бюджета и модели оплаты мы отдельно разобрали в статье о стоимости поддержки мобильного приложения.
Сохраните контроль над доступами и сменой команды
До передачи проекта составьте реестр: система, владелец аккаунта, выданная роль, ответственный за оплату, способ восстановления доступа и дата следующей проверки. В него входят репозиторий, сервер, домен, магазины приложений, мониторинг, внешние сервисы и материалы сборки. Для первого обсуждения достаточно перечня; секреты передают по согласованному защищённому каналу.
Мы предлагаем сохранять аккаунты под контролем бизнеса и выдавать исполнителю нужные права. App Store Connect и Google Play Console предусматривают пользователей с разными разрешениями. При смене команды проверьте конкретные роли и доступ к выбранному приложению; смена подрядчика сама по себе не требует переноса приложения в другой аккаунт.
Передачу завершайте проверкой. Например, для магазина новая команда получает актуальный код, инструкцию, сведения о зависимостях, тестовые настройки и список известных проблем. Затем собирает тестовую версию, сверяет её с текущим выпуском и проходит основную операцию. Отдельно проверяет подпись и возможность подготовить обновление через аккаунт владельца. Недостающий ключ, библиотека или конфигурация попадают в список препятствий с ответственным за устранение.
Согласуйте дату переключения ответственности и судьбу открытых инцидентов. После проверки работы новой команды отзовите лишние права прежней, смените переданные секреты по плану и сохраните историю обращений. Условия о правах на результаты, передаче материалов и стоимости перехода проверьте вместе с юристом до подписания.
Попросите мониторинг и отчёт, по которым можно действовать
Наблюдение за сервером помогает заметить технический сбой. Для приложения дополнительно нужны сигналы, связанные с действиями пользователя: ошибки входа, завершение заказа, получение заявки сотрудником. Попросите перечислить, что команда увидит сама, что сообщит заказчик и как проверят работоспособность оповещений.
Например, отчёт о сбое входа должен показывать, когда команда получила сигнал, каких пользователей затронула ошибка, кто вёл разбор, какие паузы возникли и как проверили восстановление. У незакрытых действий нужен ответственный. Для доработок отдельно показывают согласованное изменение, затраченные работы и выпуск. Так руководитель видит причины повторных сбоев и может выбрать следующую задачу.
Для компании в Москве, Санкт-Петербурге или нескольких регионах укажите часовой пояс, контакт заказчика и доступность специалистов внешних систем. При удалённой работе проверьте оповещение и передачу статуса между ответственными. Выезд согласуйте, если он нужен.
Соберите короткий список и проверьте его до договора
Команда подходит, когда её опыт, доступные специалисты и условия совпадают с вашим продуктом. Для приложения с интеграциями проверьте компетенции мобильной и серверной части; для частых релизов дополнительно важны тестирование и публикация. Попросите назвать конкретных участников, подмену и границы работы сторонних специалистов.
- Отправьте одинаковые вводные. Платформы, основные операции, примеры сбоев, связанные системы, часы работы бизнеса и состояние сборки.
- Получите заполненную матрицу. Сравните график, отсчёт сроков, восстановление, исключения и ответственность.
- Проверьте доказательства. Сопоставимый кейс, роль команды, независимый отзыв и обезличенный рабочий документ.
- Пройдите инцидент и передачу. Убедитесь, что новый исполнитель умеет собрать проект, получить сигнал и показать результат восстановления.
- Зафиксируйте первый этап. Условия начала поддержки, препятствия, план первых исправлений и критерии приёмки.
Мы начинаем обсуждение поддержки приложения с контура продукта, доступов и сборки. По результатам диагностики предлагаем состав работ и вопросы для согласования режима. Условия SLA и круглосуточного дежурства определяем под конкретный продукт и договор.
Частые вопросы о выборе поддержки
Гарантирует ли время реакции устранение сбоя?
Время реакции задаёт срок конкретного действия команды после обращения. Восстановление рабочего сценария и окончательное исправление причины нужно описать отдельно, с условиями, зависимостями и способом проверки.
Можно ли принять приложение от другого разработчика на поддержку?
Да, после проверки права работать с кодом, доступов, сборки и основных сценариев. До начала регулярной поддержки согласуйте список препятствий, план их устранения и момент перехода ответственности.
Что включить в договор сопровождения мобильного приложения?
Перечень систем, график, каналы обращений, приоритеты, сроки и их отсчёт, критерии восстановления, паузы, внешние зависимости, доступы, выпуск, отчётность, ответственность и порядок передачи другой команде.
Как выбрать лучшую команду из рейтинга?
Используйте рейтинг для списка кандидатов. Дальше проверяйте сопоставимые проекты, роль исполнителя, отзывы о сопровождении и заполненную матрицу условий. Окончательное решение принимайте по задачам вашего приложения и проверке передачи проекта.
Источники
Определения уровня сервиса и организация работы с инцидентами: Google SRE, Google SRE Workbook. Права пользователей: Apple и Google Play. Проверено 7 октября 2026 года; перед выдачей доступа сверяйте актуальные условия площадки.
Разберём поддержку вашего приложения
Покажите проблемный сценарий, перечень систем и владельцев доступов, сообщите состояние сборки. Мы определим, что нужно проверить до договора, и предложим диагностику с планом первых исправлений. На первом обсуждении согласуем границы проверки и ожидаемый результат.
Для первого обращения достаточно описания проекта. Пароли и клиентские данные в форму не отправляйте.