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

В СМИ всегда попадают именно масштабные инциденты. Да и в поддержку пользователи пишут только тогда, когда что-то совсем не работает.

Раньше и я боялся больших инцидентов. Но как только мы сделали большой и сложный сервис (облако для простого хостинга Amvera), я понял, что бояться надо другого.

Казалось бы, uptime для облака/хостинга — это ключевой показатель качества. Но, правда, немного сложнее. Uptime действительно критически важен для определенной категории проектов. Но для многих других даунтайм хоть и неприятен, но если он случается редко, то не наносит существенного ущерба. Я молчу про некоторые проекты, которые практически к нему нечувствительны, такие тоже есть.

Хотя и не спорю, что падение инфраструктуры это неприемлемо, так как есть проекты, по которым это сильно бьёт.

К сожалению, по-крупному падают если не все, то почти все. И AWS, и Cloudflare и GitHub. Но, как пишут в статусах Вконтакте “побеждает не тот кто не падает, а тот кто поднимается”)

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

И неожиданно оказалось, что есть вещи, которые приводят к гораздо большим потерям, чем глобальные, но ограниченные падения. 

Когда что-то работает плохо, все молчат – видимо, думают, что так и надо. А когда все молчат, баг день за днём, месяц за месяцем отталкивает пользователей от вашего продукта. И главное, такие баги скрыты, как под плащом невидимкой. Вы их не заметили, так как ваши собственные сценарии использования сервиса не покрывают все сценарии пользователей. Тестировщики их не увидели, просто потому что не увидели. А пользователи видят, но молчат.

Я честно удивляюсь, насколько люди бывают терпимы к неудобству и не сообщают о проблемах.

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

Но если вы видите проседание продуктовых метрик, все уже совсем плохо. А если пользователей немного, вам могут и не написать о проблеме никогда.

А такие баги бывают у всех. И особенно они коварны для сложных проектов, так как прячутся в большом количестве продуктов/сценариев/функций.

Сложный продукт — понятие растяжимое, поэтому опишу на нашем примере. 

В нашем облаке 

• две зоны доступности (в России и Европе), 

• 5 типов продуктов (сервис запуска и обновления кода на сервере одной командой, управляемый postgresql, маркетплейс преднастроенных сервисов, таких как n8n, API LLM с оплатой в рублях и сервис крон джобов. У каждого продукта много внутренних мелких и крупных особенностей и задействованных технологий.

• 20+ микросервисов и много зависимостей от внешних сервисов (пакетных менеджеров, API LLM, эквайринга и прочего).

И для нашей команды такое количество “движущихся элементов” создаёт серьёзную когнитивную нагрузку. Отследить, что ничего из технологий не отвалилось и работает как надо — сложно.

А еще сложнее понять, что все работает удобно, так как от постоянного использования “глаз замыливается”.

Самое интересное — даже на прямой вопрос “все ли удобно и хорошо?” пользователи отвечают — “да, все удобно”. Затем просишь человека созвониться и показать экран, как он работает с сервисом, и видишь, какой творится кошмар.

Так, в одном из модальных окон у нас не было кнопки закрыть — оно закрывалось просто если нажать на любую часть экрана. И был баг, который ререндерил эту страницу, закрывая модальное окно раз в несколько минут. И такое наблюдение выявило, что некоторые пользователи просто сидят и ждут 2-3 минуты, пока окно “само закроется”. В итоге мы пофиксили рендеринг и добавили явную кнопку закрытия, которую раньше считали ненужной.

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

Последнее время мы пробуем покрыть самые частые сценарии тестированием на основе Playwright. Когда скрипт, эмитируя пользователя, выполняет действия в интерфейсе и записывает результат. Может, попробуем ещё AI-агентов. Проблема в том, что это дополняет стандартное тестирование, но покрывает только несколько основных сценариев.

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

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