Провалы случались, случаются и будут случаться. От неудач не застрахован никто, даже самый крутой дизайнер или аналитик. Продукты усложняются с каждым годом, пользователи становятся всё более притязательными, бизнес ищет новые источники дохода.
Те, кто читает мой Дзен регулярно, уже знает, что это не первая статья на тему IT-фэйлов. Прошлые несколько были с реальными примерами, но на довольно общую тематику (ссылки будут в конце статьи). Теперь же я хочу рассказать о конкретном решении конкретной проблемы. Здесь тоже будет немного общих рассуждений, но – лишь немного.
Кейс
История эта произошла относительно давно, года четыре назад. Ребята делали небольшое мобильное приложение для узкой спортивной аудитории. Там был профиль, лента, достижения, какие-то настройки и карта. Собственно, на ней продукт и споткнулся.
Карта наполнялась пользователями, каждый из них мог оставить сколько угодно маркеров на своём пути. Аудитория была активная, жила преимущественно в Москве, накатывали по городу часы и десятки километров ежедневно.
Меня пригласили ровно за три дня до того, как стали прилетать первые репорты о краше приложения. На следующий день приложение падало у каждого седьмого. Поддержка трубила тревогу, владелец продукта наезжал на разработку, но никто ничего не понимал. На всех тестовых стендах всё было отлично. Тестировщики гоняли приложение и в хвост, и в гриву, но оно работало стабильно. А у реальных пользователей – стабильно вылетало. Причём чаще всего вылеты происходили в одних и тех же локациях. Таких "бермудских треугольников" было с десяток.
Разработчики оперативно выпустили обновление, добавив логирование всего, что можно, но сторы пока задерживали его публикацию.
Расследование
Изначально меня пригласили настроить систему технической поддержки и развития продукта, но во вновь открывшихся обстоятельствах пришлось резко менять планы. Мы с одним из тестировщиков взяли по два смартфона и покатились по городу, стараясь повторить наиболее распространённые сценарии, приведшие к вылетам.
Причина была найдена уже у первой точки "массовых" падений приложения. Ею, как и ожидалось, оказалась банальная кластеризация маркеров.
Кластеризация – это такой механизм, который объединяет маркеры на карте, когда их становится слишком много.
Кластеризация производилась на смартфоне. Сервер отправлял в приложение список маркеров, приложение их объединяло и показывало пользователю аккуратные кружочки с цифрами.
Это стандартный подход, так делают почти все сайты и приложения, где есть подобный механизм объединения.
Если сильно упростить, то получалась примерно такая схема:
Вообще, с кластеризацией меня связывают особенные отношения. И я бы не назвал их тёплыми. Около года до этого я уже выпускал одно приложение с кластерами, и обожглись мы примерно на том же.
Поэтому в тот день, выезжая из офиса компании, я уже почти наверняка знал, в чём причина.
Сценарий
Примерный порядок действий выглядел следующим образом:
- Пользователь добирается до любого из мест, где маркеров особенно много. Здесь много и людей, что слегка перегружает сотовую сеть (в нашем случае это был крупный торговый центр).
- Пользователь открывает карту, чтобы поставить отметку.
- В округе до него уже отметилось значительное количество его "соратников", причём по несколько раз. Отметок на карте тьма.
- Приложение это понимает, и пытается подтянуть с сервера все маркеры в этой области. Из-за нестабильной сети это происходит с перебоями, "рывками".
- Каждый такой "рывок" приложение пытается объединить маркеры в кластеры, потому что иначе они покрывают собой полностью весь экран. Уже объединённые кластеры разбираются и включаются в новые.
- Кроме того, между "рывками" постоянно появляются новые маркеры, которые сервер послушно отдаёт приложению.
- Кластеризация – ресурсоёмкая процедура, каждый раз она отнимает кучу сил у оперативки и процессора.
- В определённый момент операционная система смартфона просто вырубает процесс приложения из-за нехватки оперативной памяти.
Именно поэтому в "тепличных" условиях офиса всё было хорошо. Интернет был стабильным, а маркеров было совсем мало – смартфон легко справлялся с их объединением.
Решение
Со слабым соединением мы ничего не могли сделать. С количеством маркеров – тоже (это было киллер-фичей продукта). Оставалось поработать с процессом кластеризации.
Так как даже со стабильным соединением количество маркеров всё равно могло оказаться слишком большим, и бюджетные смартфоны могли бы не справиться с их объединением, мы решили проводить кластеризацию на сервере.
В итоге схема претерпела небольшие изменения:
Конечно, такое решение имеет некоторые недостатки: например, лоадер нужно показывать при каждом зуме карты, так как в этот момент происходит более долгий запрос на сервер. Да и сам сервер стал более загруженным. Но если выбирать между этим и падением приложения, то выбор очевиден.
Но на разработку, тестирование и внедрение нам тогда понадобилось больше двух недель.
Это были тяжёлые две недели для бизнеса.
Выводы
Выводов здесь можно сделать сразу два:
Контекст и технологии
При проектировании всегда учитывайте технологические ограничения и контекст использования вашего продукта. Самое неприятное вылезает всегда неожиданно.
Тестирование
Тестируйте ваше решение в условиях, приближенных к боевым. А лучше - в боевых. Стерильное тестирование хорошо только для сверки интерфейсов с макетами.
Ещё провалы
Обещанные ссылки на другие факапы:
Чтобы не пропустить следующие, подписывайтесь на канал. Будет весело, гарантирую.
