Сергей Педченко, Яндекс 360: «Будущее — за единым продуктом в разных сценариях развертывания»

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

Если мы понимаем, что критически важно полностью контролировать доступы, обновления и доступность новых функций, то это чаще on-premises. Это особенно актуально для регуляторно чувствительных данных, таких как медицинская или финансовая информация, где компания берет на себя ответственность за хранение и обработку и часто предпочитает не выносить такие данные в облако.

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

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

Звучат вопросы: «А где ваши сервера? Где ваши дата-центры, которые хранят данные? Есть ли трансграничная передача данных?» Здесь у нас все замечательно, все дата-центры находятся на территории РФ, с персональными данными мы работаем в рамках федерального законодательства. Но далее начинаются вопросы: «А как нам убедиться, что вы точно не потеряете данные при какой-нибудь аварии, при сбое? Как мы можем контролировать персонал, который работает с сервисами по развитию и обновлению? Как мы можем гарантировать, что никто ничего не смотрит, никто ничего не читает?»

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

Если мы говорим про собственников, то для них самое главное — предсказуемая модель оплаты, чтобы можно было вместе с финансистами прогнозировать рост потребления и четко планировать бюджеты. И в SAAS это удобно, и в on-premises мы тоже поставляем лицензии по понятным, прозрачным моделям.

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

Еще из обязательного — прозрачные требования к инфраструктуре, масштабирование, инструкции по разворачиванию решений, предсказуемые и ритмичные обновления продуктов, соответствия корпоративным стандартам и лучшим практикам на рынке интеграций. Требуют работу с технологией Single Sign-On (удобным единым входом), чтобы можно было использовать один корпоративный пароль, а не десять разных. Также аудируемость, возможность гибкой настройки в зависимости от роли пользователя по работе с сервисами.

Ну и, конечно же, чем крупнее заказчик, тем ответственнее данные, которые там хранятся, а также сервисы и команды, которые их используют. Часто возникают вопросы о поддержке резервирования и Disaster Recovery (набор политик и процедур, которые позволяют восстанавливаться после сбоя), геораспределенности, чтобы можно было продолжать работу в продукте, если, например, часть инфраструктуры у заказчика выйдет из строя. Ну и, конечно же, это наличие понятной модели поддержки и продажи.

Сергей Педченко: Меняется почти все, кроме продукта. Его функциональность должна оставаться той же самой. В Яндекс 360 это наше кредо. Во-первых, мы хотим развивать продукт ритмично и в SaaS, и on-premises. Во-вторых, для пользователя это должно быть привычно. Сейчас мы видим, что SaaS и on-premises — это два полюса. Но мы, делая on-premises, не выключаем SaaS, не «закапываем» его. И, напротив, делая SaaS, не ставим по остаточному принципу on-premises. Модели поставки могут быть разные, но продукт должен быть один. И у пользователя не должно возникать когнитивного диссонанса, он должен видеть, что мы делаем одну логику.

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

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

Одно из требований on-premises — встроиться в то, что уже есть. Есть разные требования к этой инфраструктуре, к интеграции, к скорости обновления в каждой из инсталляций. И у заказчика могут быть разные команды с разным уровнем зрелости для поддержания. Кто-то говорит, что он на «кубере» (Kubernetes) собаку съел, а кто-то спрашивает, что такое Docker. И для нивелирования этой сложности мы развиваем наши партнерские каналы, которые должны предоставить конечную экспертизу заказчику, чтобы вне зависимости от зрелости команды и уровня развития все работало.

Мы как вендор предоставляем не только готовый продукт, веб-интерфейс (Почты, Диска), конечные приложения, но и эксплуатационную совместимость, чтобы они обновлялись, поддерживались и надежно работали вне нашей инфраструктуры так же, как и в облаке.

Заказчик в свою очередь получает больше контроля, имея возможность развернуть продукт в своей инфраструктуре. Но вместе с тем он принимает и больше ответственности: начинает отвечать не только за правильное использование сервиса, но и за среду, резервирование, безопасность, доступы. Если у нас что-то упало, мы это быстро чиним, у нас в договоре прописаны критерии доступности сервисов. Если надо обеспечивать доступность сервиса — мячик на стороне команды заказчика. Поэтому в моем понимании on-premises имеет смысл, когда дополнительный слой и возможности контроля действительно нужны бизнесу.

Сергей Педченко: Вначале спрашиваем: есть ли жесткое требование по работе с данными, которые будут храниться в системе, и каковы контур взаимодействия с этими данными и регуляторика? Если компания занимается медициной, финансами и другими «секретными» областями, то выбор падает на on-premises и в дальнейшем, возможно, на гибрид.

Далее уточняем: насколько критично заказчику управлять полным циклом обновлений и управлением с интеграцией со своей инфраструктурой? Если он хочет, чтобы среда была полностью контролируемая, чтобы она обновлялась при необходимости, то on-premises в этом случае вероятнее.

Следующий вопрос заказчику: есть ли на его стороне инфраструктура, команда, которая знает, как работать с таким классом решений? Если есть компетенции, есть доступ к инфраструктуре, то да, это будет on-premises.

Ну и в конце нужно оценить, действительно ли требования к on-premises, исходя из внутреннего регламента, из общей регуляторики, настолько суровы. Можно ли пойти на некие компромиссы и поработать с внешним сервисом либо необходимо инвестировать в собственный контур.

Исходя из этих четырех пунктов мы находим ответ на вопрос, идти в on-premises либо в быстрый запуск с SaaS и начинать пользоваться уже готовым решением из облака.