«СмартАп Технолоджи»: Как обеспечить поддержку заказной ИТ-разработки без привязки к поставщику

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

Особенности заказной ИТ-системы

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

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

Вторая часть системы представляла собой публичный сервис — фактически это сайты, похожие на социальные сети, где доктора могут обмениваться опытом применения лекарств в определенных медицинских областях. Метавселенная ВДНХ 2.8 т

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

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

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

Проблемы «взросления» ИТ-системы

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

Компания активно вкладывала деньги в развитие системы и ожидала соответствующей отдачи. Но темп разработки постоянно деградировал, долгая поставка и увеличение стоимости развития и поддержки неприятно удивляли заказчика, — рассказывает Никита Швыряев, руководитель отдела разработки компании «СмартАп Технолоджи».

Специалисты «СмартАп Технолоджи» уже работали с этим клиентом над публичной частью системы, поэтому именно к ним заказчик и обратился с просьбой сделать систему более приспособленной для дальнейшего развития. При этом, замечает Никита Швыряев, проблема была сформулирована, скорее, эмоционально, чем на техническом уровне, поскольку персонал клиента не понимал, что происходит с системой.

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

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

Выявление проблемных точек системы

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

В данном случае главной жалобой клиента было снижение темпа разработки. Часто причиной этого является повышенная связанность компонент системы, рассказывают в компании «СмартАп Технолоджи». Так же на скорость разработки может влиять неудачный дизайн кода в системе. Еще один возможный фактор — изначально неудачный выбор инструментов, замечает Никита Швыряев:

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

В ходе работы с гипотезами специалисты «СмартАп Технолоджи» выделили несколько ключевых проблем ИТ-системы.

Глубокая связь компонент

Как рассказывает Никита Швыряев, при обследовании системы в глаза бросилось обилие кода, связанного с двусторонней синхронизацией данных двух баз и проверкой актуальности и корректности каждой из них:

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

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

Архитектурная ошибка проектирования

Специалисты «СмартАп Технолоджи» обратили внимание, что два компонента системы взаимодействуют друг с другом не только посредством API, но и через запись в базу MySQL. Получается, что если нужно добавить новую бизнес-логику или скорректировать существующую, например, при валидации данных или изменении связанных записей, очень часто приходится это делать сразу в двух системах. Этот факт, несомненно, обусловливает высокие риски нарушения согласованности данных.

Проблемы со структурами хранения данных и процессами их обработки

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

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

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

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

Кроме того, обнаружилось, что запрос доступности списка докторов для доставки сообщения по определенным каналам выполнялся от 7 до 30 минут. После анализа SQL-запроса его удалось оптимизировать, и время выполнения запроса существенно сократилось: теперь он обрабатывается в пределах от 30 с до 3 мин.

Использование устаревшей технологии

Система управления данными врачей было создана довольно давно, и в ее основу положен фреймворк Yii 1, поддержка которого прекратилась еще в 2015 г. Эта ситуация создает немало проблем. Так, патчи безопасности можно найти не на все уязвимости, некоторые приходится закрывать самостоятельно. Поскольку интерес к устаревшему фреймворку в среде разработчиков сильно унизился, ответы на многие вопросы также приходится искать самостоятельно без надежды на помощь международного сообщества.

Никита Швыряев подчеркивает:

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

Помочь решению этих творческих задач помогают методические рекомендации экспертов «СмартАп Технолоджи» и автоматизация некоторых процессов. К примеру, найти «узкие места» системы помогают интеграционные и нагрузочные тесты.

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

Основные направления модернизации системы

Изменение структуры хранения данных

Из двух информационных контуров системы: хранилища данных докторов с панелью администратора и публичных сайтов для докторов — наибольшую ценность для заказчика представляют данные докторов, так как именно их «покупают» клиенты для своих рекламных кампаний. В старой версии системы информация о медицинских работниках копировалась из основного хранилища в базу данных сайта. При этом сам доктор мог корректировать свою информацию, например, адрес email. Эти изменения сохранялись в базе данных сайта и синхронизировались в системе хранения данных докторов.

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

В целом, взаимодействие компонент системы было улучшено за счет нескольких несложных манипуляций:

• Созданы API в обеих системах для всех сценариев взаимодействия.
• Отключен прямой доступ системы управления контактами к базе данных публичных сайтов.
• Удален сервис синхронизации. Все нужные API вызываются непосредственно в момент обновления данных.

В новой архитектуре вся ответственность за данные докторов лежит на основном хранилище, — рассказывает Никита Швыряев. — Если сайтам нужно получить или изменить данные врача, они обращаются в систему хранения через API. Данные и логика их обработки теперь размещены в одной системе без дублирования.

Такой простой механизм на 100% работоспособен, поскольку система работает под невысокой нагрузкой и никаких тяжелых операций при обновлении данных не выполняет. Однако в иных обстоятельствах могут потребоваться дополнительные сервисы типа очереди, поясняют в компании «СмартАп Технолоджи».

Использование облачного функционала AWS Lambda

Фактор неравномерной нагрузки на систему в разных задачах ИТ-системы привел к решению использовать Lambda-функции в облаке Amazon Web Services (AWS Lambda) вместо выделенной виртуальной машины.

Компания и раньше пользовалось облачными услугами AWS, но все сервера заказчика запускались на виртуальных машинах в облаке. Это невыгодный вариант, с точки зрения финансовых затрат, в случае редко используемых сервисов с высокой разовой нагрузкой. Дело в том, что AWS выделяет заказчику некоторые вычислительные мощности, которых должно хватать на пиковые нагрузки. Если такие нагрузки случаются редко, компании приходится оплачивать фактически неиспользуемый запас ресурсов. Так и было в данном случае, рассказывают в компании «СмартАп Технолоджи»: добавление новых докторов зачастую происходит группами по больницам и чаще всего один раз в несколько дней, статистика по докторам генерируется по графику один раз в день, выборка доступных для контакта докторов из списка — тоже разовая операция, которая осуществляется в рабочие часы.

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

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

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

Рис. Обработка файлов, потоковая обработка и запуск интернет-приложений в среде в режиме обработки данных AWS Lambda
Источник: amazon.com

Стоит отметить, что российские облака от Yandex и Mail.ru тоже поддерживают Lambda-функции. Это значит, отмечает Никита Швыряев, что «СмартАп Технолоджи» может реализовывать подобные проекты для российских клиентов на базе российских облаков с использованием доступных сервисов.

Замена устаревшего фреймворка

Интерфейс администратора реализован в виде статичного сайта Single Page Application (SPA). SPA — это одностраничное веб-приложение, которое загружается на одну HTML-страницу и имеет множество преимуществ, таких как скорость, хороший пользовательский интерфейс (UX) и полный контроль HTML-разметки. Он также дает возможность администраторам взаимодействовать с Lambda-функциями.

Такой статичный сайт можно разместить, где угодно, даже не поднимая веб-сервер. Например, можно использовать хранилище файлов или CDN, в зависимости от требований к скорости открытия, — рассказывает Никита Швыряев. — В нашем случае мы выбрали простое хранилище, так как у заказчика не было жестких требований к скорости обмена данными.

SPA-сайт администратора реализован на базе перспективного фреймворка Vue 3. Если сравнивать Vue с другими популярными фреймворками, то у него нет такого широкого набора готовых компонент, как, скажем, у React, и столь богатых возможностей структурирования кода, которые дает прямо из коробки ПО Angular. Но поскольку интерфейс администратора системы не отличается высокой сложностью, наиболее полезен инструмент с быстрой кривой обучения, поясняет Никита Швыряев:

Разработчику не нужно думать об обновлении данных, которые отображаются на экране. Поэтому можно обойтись минимальным набором возможностей, но зато сделать проект быстро и легко развиваемым. Тогда в будущем заказчик сможет при необходимости безболезненно сменить поставщика ИТ-услуг.

Из соображений минимизации инструментальных средств для реализации Lambda-функций решено использовать JavaScript.

Таким образом, интерфейс администратора мы можем отдавать пользователю из статичного хранилища типа S3 или с помощью CDN. Запросы к API направим на специальный сервис API Gateway, который будет подбирать подходящий обработчик. Сами обработчики будут реализованы в AWS Lambda, — поясняет новую концепцию системы Никита Швыряев.

Результаты проекта модернизации системы

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

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

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

Ускорение процессов разработки измерялось на новой функциональности системы в течении трех месяцев после завершения проекта модернизации. Результаты впечатлили заказчика — разработка ускорилась, как минимум, в два раза: параметр Time To Market для новых запросов сократился в среднем с двух недель до одной.

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

Это гарантирует безопасность системы с точки зрения вендорозависимости и дает возможность свободно развивать систему в нужных направлениях в обозримом будущем, — подчеркивает Никита Швыряев.

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

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

«Корпоративный ИТ-продукт полностью готов к изменениям. Мы разработали качественную архитектуру, которую будет легко и удобно развивать любой профессиональной команде. Обучиться работе в новой системе гораздо легче, чем в ситуации с устаревшей версией благодаря скромному набору инструментов и четким зонам ответственности», — подчеркивает Никита Швыряев.