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

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

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

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

О любом, даже самом продвинутом, гениально написанном и использующем самые мощные ресурсы приложении доподлинно известно одно: под большей нагрузкой оно сломается. А большая нагрузка – это понятие скорее абстрактное, у каждого она своя, много зависит от ресурсов, которые даются для работы, и от здравого смысла, который позволяет соблюсти баланс между ресурсами и экономией средств. Мониторинг производительности на этапе разработки позволяет узнать слабые места приложения, что именно склонно «проседать», и исправить все, что можно до продакшена.

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

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

Возьмем для примера абстрактный интернет-магазин. Удобный, прекрасный, с отличными ценами и ассортиментом. Казалось бы, у него нет причин, чтобы не нравиться пользователям: и узнаваемое имя, и крутая программа лояльности, и удобный интерфейс, и все-все-все. Но в какой-то момент при всей этой красоте поток клиентов начинает снижаться. Хотя объективных причин для этого нет. Поначалу это происходит незаметно, но со временем поступают тревожные звоночки, и чудесным образом (чудесным, потому что сами-то клиенты едва ли будут настолько лояльны магазину, чтобы пожаловаться на работу сайта, они уже нашли ему альтернативу) выясняется, что в процессе выбора товара, регистрации на сайте у пользователя проблем не возникает, а, например, процесс оплаты по непонятным причинам занимает так много времени, что не все готовы доходить до конца.

Изучение кода не позволяет найти ошибку, изучение серверной части – тоже. Но разработчики и администраторы со своей стороны сделали каждый свое. Проблема не найдена, и кто ответственный за ее появление и поимку – непонятно. Или, что еще хуже – внезапно на сайте «отвалилась» база данных или еще что-то, о чем простая проверка доступности ресурса сообщить не может.

Или еще одна история – вы выпускаете просто прекрасное приложение с отличной фичей, которой почему-то никто не пользуется. Оказывается, что тут проблема в UI, который сделан таким образом, что кнопочку, которая ведет к заветной killing feature, просто никто не замечает. Или она спрятана под семью уровнями вложений меню. Выявить причину тоже довольно сложно, если изначально, планируя сервис, никто всерьез не задумывался над тем, как изучать поведение пользователя с ним.

Или, например, вы создали сервис для стран СНГ. При этом он отлично работает в Украине, Беларуси, Казахстане, но из-за каких-то проблем с серверами перестал быть доступным в Армении и России. Об этом тоже не так-то просто узнать от пользователей, для которых лояльность в мире, где есть альтернативы, не больше чем звук.

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

На уровне организации процесса все это выглядит таким образом. Есть развернутое на продакшене приложение. В нем работает агент, который мониторит то, что вы ему «велели», и отправляет отчеты о проблемах и позволяет просматривать в графиках и цифрах в реальном времени. Чем быстрее проблема обнаружена, тем быстрее ее можно решить. Иногда это получается сделать раньше, чем с проблемой сталкивается пользователей – к этому показателю и надо стремиться.

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