Еще одна история участника программы Yandex Cloud Boost - компании-разработчика медицинской информационной системы Medods. Рассказывает основатель сервиса Эмиль Гайнанов.
Личный кабинет пациента
История проекта началась в 2013 году. Как-то раз я подхватил простуду и решил поехать в частную клинику, чтобы сделать рентген легких. Поскольку клиника была в другой части города, то после процедуры, я спросил в регистратуре, не могли бы они отправить результаты мне на email.
Стоит ли говорить, что ни на следующий день, ни через день результатов я так и не получил. Пришлось с температурой ехать через весь город только для того, чтобы получить небольшой клочок бумаги, на котором написано «сердце и легкие в норме». У меня появилось ощущение, что в этой ситуации что-то не так и ее можно исправить. Тогда я и загорелся идеей сделать личный кабинет пациента, через который можно взаимодействовать с клиникой, например, записываться на прием или получать результаты исследований.
Пользовательский опыт во главе угла
Medods помогает автоматизировать бизнес-процессы в клинике: записывать пациентов на прием, вести электронные истории болезни, формировать счета и договоры с пациентами, анализировать финансы, взаимодействовать с пациентами посредством смс, телефонии, личного кабинета и многое другое. Обобщая, можно сказать, что наш продукт уменьшает количество ручной работы, упрощает коммуникацию между клиникой и пациентом, улучшает управляемость, увеличивает прозрачность для руководства, а также помогает предоставлять пациентам лучший сервис. Нашим продуктом пользуются более полутысячи клиник в России и странах ближнего зарубежья. Но так было не всегда.
В 2013 году у меня уже был небольшой бизнес по обслуживанию компьютерной техники в организациях моего города. Я и еще двое ребят быстро сваяли что-то похожее на кабинет пациента, а потом я поехал показывать результат одному из наших клиентов, которым, была сеть медицинских центров.
После встречи у меня сложилось понимание, что важно не только сделать личный кабинет пациента. Каждый такой кабинет пришлось бы интегрировать со всем «зоопарком» систем для управления клиникой. Мы решили создать свою медицинскую информационную систему, которая бы помогла автоматизировать основные процессы в медицинском учреждении.
Несколько человек, имеющих довольно примерное представление о том, что такое программирование и как работают бизнес-процессы в клинике, начали писать код. В течение одного года мы усердно работали, совмещая это с нашей основной деятельностью. В процессе работы выяснилось, что один из моих сотрудников — талантливый программист, а я неплохо понимаю, как сделать пользовательский интерфейс удобным и функциональным. Отмечу, что именно пользовательский опыт мы ставили во главу угла с самого начала разработки Medods.
В начале мы часто говорили покупателям «нет»
После года работы мы получили продукт с базовой функциональностью, который можно было пытаться продавать. Первая версия Medods выглядела довольно аскетично и была лишена множества необходимых функций. Хотя мы установили минимальную цену, продавать его было адски сложно. На большинство вопросов потенциальных покупателей в стиле «а есть ли в программе это или вот это?» звучал ответ «нет» или в лучшем случае «данный функционал в разработке» или «планируется в будущем».
Несмотря на откровенную слабую функциональность первой версии продукта, нам удавалось делать пару продаж каждый месяц, мы нарабатывали опыт и расширяли доступные пользователям возможности. Спустя еще год вышла вторая версия нашего приложения. У нее был обновленный дизайн, реализация бизнес-логики была частично изменена в соответствии с реальными потребностями клиник. Мы наняли еще пару начинающих разработчиков и подняли цены.
Дела постепенно шли на лад: продажи понемногу росли, функционал расширялся, а на насущный вопрос потенциальных покупателей, ответ все чаще звучал «да».
Первые вызовы
По мере дальнейшего развития проекта мы столкнулись с первыми вызовами. С ростом количества клиентов и нагрузки наше монолитное приложение все менее эффективно справлялось с возложенными на него задачами. Мы приняли решение перейти на микросервисную архитектуру и начали выносить блоки бизнес-логики в отдельные сервисы. Решение это было рискованное, поскольку вместо одного языка программирования у нас появилось еще несколько. Техническая сложность реализации постепенно возрастала. Для каждого микросервиса мы выбирали технологии, которые решали конкретную задачу наиболее эффективно. Кроме того, для обмена данными мы задействовали брокер сообщений. Все это, с одной стороны, позволяло приложению развиваться и масштабировать нагрузку, с другой, существенно увеличивало требования к компетенциям команды разработчиков.
Новая архитектура потребовала полноценного использования облачной виртуализации. Мы больше не могли использовать обычные виртуальные выделенные серверы, как это было вначале. Нам требовалось централизованное управление виртуальными машинами для быстрого запуска новых инстансов приложения, обновления версий без простоя и мониторинга ресурсов.
Облачный буст
Мы начали выбор сервиса и остановились на одном небезызвестном облачном провайдере Digital Ocean. Силами нашего талантливого DevOps-инженера мы совершили довольно сложный процесс миграции. Доступный нам функционал позволил закрыть практически все наши потребности. Заметно улучшилась управляемость и объем трудозатрат на обслуживания парка виртуальных машин. Однако было и то, что нас не вполне устраивало — сервис периодически падал без каких-либо предварительных уведомлений и на нас обрушивался шквал звонков от клиентов, которым мы не могли никак помочь, поскольку восстановление работы находилось вне нашей компетенции. Кроме того, нас не устраивала коммуникация, по сути, мы могли только писать тикеты на почту технической поддержки и получали ответ в лучшем случае через несколько часов, даже если ситуация была критической. Все это заставило нас задуматься о смене поставщика облачных услуг.
На тот момент Яндекс уже запустил свой облачный сервис. Лично я довольно лояльно отношусь к Яндексу как к компании в целом — мы решили попробовать переехать к ним. Дождались, когда у них будет доступен Kubernetes, и мигрировали в Yandex.Cloud.
Остановлюсь немного подробнее нам том, что мы используем и для каких целей. Итак, внутри Kubernetes у нас находится несколько сотен инстансов нашего приложения. Каждое приложение разделено на отдельные сервисы, отвечающие за выполнение различных задач, таких как, например: интеграция с кассовым и медицинским оборудованием, интеграции с лабораторными информационными системами, API, аутентификация пользователей и другие задачи. Обмен сообщениями между этими сервисами осуществляется с помощью брокера сообщений Apache Kafka, который на данный момент располагается на отдельной виртуальной машине в Yandex Compute Cloud. В ближайшее время мы планируем задействовать для этих целей Managed Service for Apache Kafka, а также перенести базы данных в Managed Service for PostgreSQL.
Ну и наконец, в Object Storage мы храним собранные дистрибутивы сопутствующего ПО для интеграций, а также для доставки обновленных версий Medods до конечных пользователей.
Впечатления от взаимодействия с командой Yandex.Cloud исключительно положительные. Сервис не падает, техническая поддержка в чате оперативно реагирует на наши обращения и помогает решать даже нетривиальные и нетипичные задачи. Кроме того, есть конкретные люди, которым можно написать, и они, если это необходимо, могут решить конкретный вопрос в ручном режиме.
Впереди нас ждут новые вызовы. Мы продолжаем наращивать функционал, нарабатывать опыт, шлифовать наши бизнес-процессы. Нам предстоит поработать над улучшением клиентского сервиса, расширить команду технической поддержки, ускорить процесс внедрения обновлений. Наша цель — это процесс непрерывного совершенствования.