Как работает поддержка мобильных приложений

По данным Forrester, 42% компаний теряют более шести миллионов долларов в год из-за интернет-сбоев. При использовании полного стека мониторинга (full-stack Internet Performance Monitoring — комплексное наблюдение за всеми слоями инфраструктуры — от сети и серверов до пользовательских сессий) эти потери сокращаются на 54%.

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

Часто техническая поддержка строится по трехуровневой модели.

L1 — регистрация и первичная диагностика инцидентов, классификация по критичности. Инцидентом считается любое событие, которое нарушает нормальную работу приложения. Например, замедленный отклик, зависание приложения или подозрительная активность. Эти задачи может решать call-центр или отдел первой линии.

L2 — технический разбор: анализ логов, проверка API, устранение нестандартных ошибок. Логи (application logs) — это журналы событий, которые приложение и сервер записывают в процессе работы. По ним можно определить, в какой момент и при каких условиях произошел сбой, а также найти его причину. Этим может заниматься команда поддержки приложения и разработчик.

L3 — работа с кодом и инфраструктурой: исправление багов (ошибок в коде), оптимизация серверов, восстановление после критичных сбоев. На этом уровне может понадобиться координатор поддержки, эксперты и специалисты DevOps.

Кроме этого, есть процессы, которые работают на всех уровнях.

Мониторинг и интеграции.Поддержка отслеживает работу сторонних сервисов (платежных систем, программ лояльности, аналитики и других) и ключевые показатели: доступность серверов, время отклика API, нагрузку на базы данных.

Аналитика инцидентов. Ключевая метрика здесь — MTTR (Mean Time to Resolve). Это среднее время устранения инцидента, частота и причины ошибок.

Информационная безопасность.В задачи поддержки входит обновление библиотек и SDK (Software Development Kit — набора инструментов для разработчиков), устранение уязвимостей, соблюдение требований стандартов (GDPR, PCI DSS и других).

Одно из направлений работы технической поддержки — отзывы в сторах. Пользователи часто сообщают о сбоях в приложении через отзывы App Store или Google Play. Здесь задача поддержки — оперативно реагировать на негативные комментарии, помогать пользователям и фиксировать проблемы для разработки. По данным Google Play, ответ на негативный отзыв в среднем повышает оценку приложения примерно на 0,7 балла.

DevOps

Технически DevOps не относится к техподдержке, но с него все начинается. Это подход, который объединяет разработку (Development) и эксплуатацию (Operations). Если классическая поддержка чаще реагирует на инциденты, то DevOps помогает предотвращать их за счет автоматизации и постоянного мониторинга.

DevOps включает:

• CI/CD (Continuous Integration/Continuous Delivery) — это процесс автоматической сборки, тестирования и доставки новой версии приложения в рабочую среду. Когда разработчик исправляет ошибку, система сама запускает тесты, и если все в порядке, обновление появляется у пользователей.
• Мониторинг — постоянную проверку пульса системы: доступность серверов, скорость отклика, работу баз данных. Это позволяет заметить сбой до того, как о нем напишут пользователи.
• Наблюдение через сбор метрик, логов, трассировок (это пошаговый путь запроса: через какие части системы он прошел и где задержался). Они помогают быстро найти причину сбоя.
• Управление инфраструктурой. Это настройка и автоматизация серверов, на которых работает приложение. Задача — чтобы в любой среде (тестовой или рабочей) приложение запускалось одинаково и без сбоев.

По данным Grafana и New Relic, использование observability (систем, которые позволяют видеть внутреннее состояние приложения через метрики, логи и трассировки) снижает среднее время устранения инцидента (MTTR) на 30–40%.

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

Я считаю, что базовый мониторинг должен быть на любом проекте и, что самое главное, DevOps и технической поддержке должно быть понятно, для чего нужен каждый алерт и каждый график. Звучит банально, из серии «так и должно быть», но в реальности это не всегда так.

Анна Соколова, DevOps Friflex

Когда подключать техподдержку приложений

MVP, первый релиз

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

Мы рекомендуем подключать техническую поддержку с первого релиза. Вот что в нее входит у нас.

Рост аудитории

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

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

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

Алексей Гормаков, руководитель отдела технической поддержки Friflex

Корпоративный масштаб

В сервисах, где сбои напрямую отражаются на бизнес-показателях (банки, маркетплейсы), поддержка превращается в обязательный элемент архитектуры. Здесь важны SLA (Service Level Agreement — соглашение об уровне сервиса между компанией и командой поддержки с конкретными показателями: времени реакции на инцидент, сроке восстановления работы приложения и другими), круглосуточные дежурства, соответствие отраслевым стандартам (ITIL, ISO 27001, PCI DSS) и тесная связь с DevOps.

Что влияет на стоимость техподдержки

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

Есть три основные модели: подписка с ежемесячной оплатой за определенный объем услуг; оплата за инцидент (каждое обращение или сбой тарифицируется отдельно) и гибрид (базовая подписка + отдельная тарификация за критичные инциденты или ночные дежурства).

В стоимости учитывается уровень поддержки (только L1 или полный цикл L1–L3), режим работы (8/5, 12/7, 24/7), метрики SLA: время реакции и восстановления, объем интеграций и инфраструктуры (чем больше внешних сервисов, тем выше риски и нагрузка), требования к безопасности и сертификации (например, ISO 27001, PCI DSS).

Для небольших приложений (например, корпоративных) базовую поддержку (L1 + мониторинг) могут делать один или два специалиста. Для более сложных приложений с десятками тысяч пользователей, таких как маркетплейсы, финтех-сервисы, онлайн-сервисы с высокой нагрузкой, может понадобиться внутренний отдел. Например, инженеры на уровни L1 и L2, дежурный DevOps и разработчики на L3.

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