ЭОС: предоставление eDocLib по модели SaaS – это принципиально новая модель взаимодействия с пользователем

Сергей, ранее Вы упоминали, что при размещении eDocLib в «облаке» потребовались существенные доработки. Что именно затронули эти доработки и как это повлияло на функциональность решения?

– Я бы не сказал, что потребовались именно доработки eDocLib: потребовался ряд мероприятий для того, чтобы этот сервис запустить. Во-первых, необходимо было некое нулевое приближение от этой аппаратной платформы. Предположим, разработчик ПО выбрал какого-то провайдера, через которого будет предоставлять этот «облачный» сервис. У одного есть программное обеспечение, у другого сотрудники и дата-центр. Провайдер первым делом спрашивает, какие нужны серверные мощности, какие операционные системы и т. д. Выбирая железо, надо условно оценить возможное количество клиентов. Далее возникает ещё один момент: если это ПО базируется на других компонентах (например, на SQL, как eDocLib), встаёт вопрос с лицензированием. Если, не задумываясь, покупать сервера, лицензии и пр., себестоимость платформы, на которой будет развёрнут сервис, окажется за пределами разумной цены, стоимости коробки и всего остального. Чтобы этот сервис был прибыльным и для провайдера, и для разработчика, то надо найти оптимальное соотношение, и здесь не обходится без переговоров о цене, скидках, взаимных уступках и т. д. Но это нормальный процесс, который так или иначе всегда происходит. К примеру: условно говоря, 100 пользователей системы eDocLib могут работать на 2-процессорном сервере, с 8 Гбайт памяти, по нашему опыту этого должно быть достаточно. Следующий этап включает приобретение лицензий: мы смотрим, сколько стоит лицензионное ПО, какие есть варианты его использования и стараемся это также оптимизировать.

Есть ли ещё нюансы, кроме выбора оборудования и приобретения лицензии?

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

Запуск услуги уже состоялся. Что он показал и будут ли вноситься ещё какие-то изменения?

– Мы объявили о коммерческом запуске услуги, и сразу же на сайт нашего партнёра «Инт-Информ» пришло много желающих посмотреть, как она работает. Пока мы не успели сделать Self Service, то есть исполнение заявки происходит в полуавтоматическом режиме, с участием человека, со временем это будет полностью автоматический сервис. Заявок пошло много, они создают высокую нагрузку, и надо быть к этому готовым. В рамках этого стресс-тестирования мы теперь понимаем, как будет масштабироваться аппаратная платформа в случае массового наплыва пользователей.

Как будет выглядеть предоставление услуги с вводом Self Service и почему он необходим?

– Когда мы говорим о SaaS, принятие решения об использовании услуги происходит очень быстро, отказ от неё тоже может происходить очень быстро. В итоге получается, что, если человек захотел получить доступ сейчас, а мы за полчаса ему этот доступ не дадим, он вполне может передумать и пойти к нашему конкуренту, который этот доступ даёт за 5 минут. Поэтому и нужен Self Service, когда человек нажал кнопку и получил свой экземпляр системы. Это требует внесения определённых изменений. В частности, механизм SaaS должен быть встроен в сложившийся механизм продаж. И здесь в том числе требуются определённые технологические доработки, связанные, например, с тем, что в традиционной модели держателем лицензии является конечный потребитель. В SaaS-модели фактическим держателем лицензии является провайдер услуги. Получив определённый комплект лицензий, провайдер должен их инсталлировать клиенту, при этом не получая доступа к клиентским данным. Обычно лицензионный ключ активирует администратор системы, то есть он имеет доступ ко всей информации, как, например, с приобретением лицензии на антивирус. Здесь такой вариант не годится, потому что провайдер не должен иметь доступа к клиентской информации, и в то же время ему надо активировать этот ключ. Для этого создаётся другой механизм активации ключа, который  встраивается в существующее решение. Но это лишь один из вариантов, другой вариант, опять же возвращаясь к Self Service, заключается в том, что пользователь должен нажать кнопку и получить свой экземпляр системы. Если раньше у нас система разворачивалась в режиме диалоговых окон «Далее – продолжить – согласен», то здесь весь процесс должен происходить без вмешательства человека. Потребовалась доработка этой утилиты настройки. Вместо диалогового решения получаем режим «нажали – получили». Все параметры заводятся предварительно. Все эти доработки так или иначе связаны с механизмом предоставления сервиса пользователям SaaS-решений и встраиванием нашего продукта в механизм Self Service.

Есть ли ещё планы по доработке сервиса?

– Кроме очевидно необходимых вещей, про которые я сейчас рассказал, есть и задумки на будущее. Например, встроенная в решение кнопка обращения в Service Desk. Как уже говорилось, SaaS – это другая модель бизнеса, и она требует других механизмов и продаж, и техподдержки, чтобы это дело было прибыльным. Это не прямая переработка решения, но дополнительные вещи, которые позволяют встроить решение eDocLib в эту новую модель взаимодействия с пользователем, новую модель продаж, новую модель администрирования специалистами дата-центра, новую модель получения техподдержки. Это не значит, что старая модель перестаёт работать. По SaaS могут быть и крупные проекты, где существующая техподдержка также может работать. Могут быть разные модели использования SaaS-решения и в том числе быстрые малобюджетные. Это приметы SaaS: с одной стороны, размер платежей небольшой, с другой – они происходят очень быстро. Но чтобы что-то заработать, их надо быстро обрабатывать. И если что-то пойдёт не так, клиент очень легко от этого сервиса откажется, так как заплатил за него совсем немного.

Подводя итог, перечислите, пожалуйста, то, что необходимо для предоставления eDocLib по схеме SaaS.

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

Большое спасибо!