На сегодня уже давно и прочно вошли в нашу жизнь облачные (cloud) приложения. Едва ли не все крупные производители ПО предоставляют своим клиентам web-based приложения наряду с классическими загружаемыми приложениями для ПК, либо мобильных устройств, работающими с собственной инфраструктурой предприятия (on-premise).

Трудно представить себе хотя бы один день современного человека занятого в ИТ без использования, например, Gmail. Точно также и современный Enterprise в силу современных требований часть своих процессов переносит в SaaS. Здесь и далее под SaaS мною будут подразумеваться в первую очередь облачные приложения, предлагаемые различными компаниями по платной подписке. Такого рода сервисами могут быть: почтовые службы, CRM системы, офисные приложения и т. п. Зачастую системы, отдаваемые на откуп в SaaS, не требуют сложных интеграций с большим количеством информационных системам предприятия, а значит, объем информационного обмена между SaaS платформой и корпоративной средой может быть минимизирован. Очевидно также, что облачные приложения потенциально имеют больший успех среди предприятий меньшего размера в силу специфики бизнес-процессов и упрощённой самой процедуры внедрения.

Но я хочу остановиться на другом аспекте. Каким может быть главный риск для предприятия передачи того или иного бизнес-процесса на откуп в SaaS? Самая первая проблема, которая лежит на поверхности и сразу озвучивается клиентами — утечка внутренних данных на сторону, т. е. вопрос безопасности и доверия компании-поставщику SaaS решения. Есть ли что-нибудь ещё не столь очевидное, но не менее значимое для компании, которое разом может поставить крест на миграции в облако? Есть, и я постараюсь показать такой пример.

Волею судеб наша небольшая компания долгое время использовала один популярный зарубежный сервис, скажем так, онлайн-таблицы. На заре запуска его возможности были не столь впечатляющими по сравнению с тем же Google Docs. Но время шло, сервис развивался, рос и мы пользовались им регулярно. Скажу сразу, что сервис зарубежный и достаточно крупный, следовательно, количество его подписчиков исчисляется десятками и сотнями тысяч. Бесплатных подписок нет, только trial период, после которого обязательно придётся что-нибудь купить. Сервис ориентирован на бизнес пользователей, а не на частных клиентов, для них существует тот же Google Drive. На сегодняшний день он входит в TOP 3 в своей нише, поэтому его пример наиболее показателен.

Как происходит обновление ПО в случае облака? Существует два варианта из тех, что я встречал:
Вариант 1 — компания уведомляет своих клиентов о небольшом окне downtime длительностью не более 1-2 часов. Причём все понимают, что так как сервис в первую очередь ориентирован на бизнес, то такое окно, как правило, планируется в ночь с субботы на воскресенье или с воскресенья на понедельник.
Вариант 2 — сервис обновляется без downtime, просто однажды входя в систему пользователь получает баннер с подсказками о новых функциях (или удалённых старых).

Как бы то ни было, вариант 1 или вариант 2, проблемы возникают следующие:
1. Планирование обновления системы не зависит от пользователя системы;
2. Пользователь не знает заранее как функции будут добавлены, а какие исключены;
3. Зачастую об обновлении и новом функционале пользователь узнаёт по факту его свершения.

Если с первым пунктом ещё можно смириться, то второй и третий заставляют задуматься: а как рискует бизнес получая обновление функционала используемого им сервиса? Как это может отразится на его частных бизнес-процессах(БП)? И, главное, что делать, если реализуемый БП либо его часть на SaaS сервисе вдруг выйдет из строя?

В случае с локальным ПО всё решается несколько проще, у бизнеса (а точнее у ИТ в его лице) существует как минимум две опции:
1. Тестирование новой версии ПО в изолированной среде (тестовой зоне) с целью отработки основных сценариев;
2. Откат на старую версию ПО, если в новой обнаружены критические для бизнеса недочёты. Благо повсеместное проникновение виртуализации позволяет осуществить этот процесс за несколько минут.

Возвращаясь к моему примеру. В используемом нами Excel-подобном сервисе была такая функция — ведение дискуссий по строке таблицы. Её особенностью было то, что в рамках дискуссии можно было организовать несколько веток обсуждения. Подписчики получали каждый свои уведомления и как-то это работало, люди пользовались. Для нас лично данный функционал был не востребован, поэтому я на него не обращал никакого внимания.

В один прекрасный день компания решила обновить сервис и упростила пользователям жизнь, переименовав дискуссии в комментарии и сделав их все одноуровневыми. То есть теперь на каждую строку таблицы можно вести только одну ветку обсуждения куда сваливается всё. Больше того, все старые дискуссии были преобразованы к этому новому виду и назад уже дороги нет. Разумеется, после обновления все пользователи получили уведомления о столь прекрасной и удобной функции. И ознакомились они с ним, конечно же, в понедельник, когда пришли на работу. Оказалось, что многие пользователи (компании) всерьёз применяли ветки дискуссий для каких-то своих внутренних процессов. Для них данный функционал был бизнес-критичным. Что они получили после обновления — сломанный бизнес-процесс. У кого-то он был чисто внутренним, а у кого-то на него было завязано обслуживание клиентов. Об этом всём я узнал прочитав community форум после очередного обновления, где люди в красках описывали, как они выстраивали свою работу на предыдущей версии сервиса и почему они не могут работать также теперь.

Что компания, которая использует данный SaaS сервис, может сделать с этим? Только адаптироваться к новым правилам игры, причём по живому. Где гарантия того, что одно из последующих обновлений не сломает что-нибудь ещё? Такой гарантии никто не даст. И это только пример довольно простого табличного сервиса. В случае с более сложными системами, такими как CRM, можно себе представить с чем можно столкнуться. Думали ли о таких клиентах компания-производитель SaaS? Возможно, но посчитали их количество ничтожным и сам функционал не столь важным.

В результате компании, использующие данный сервис, столкнулись лицом к лицу сразу с двумя проблемами, о которых я говорил выше:
1. Новая версия сервиса ломает функционал, который был доступен ранее. Клиент узнаёт об этом только по факту обновления системы.
2. Откат на старую версию ПО невозможен. В худшем случае данные уже переработаны в новый вид и вернуть их старом возможно только восстановлением резервной копии.

Сервисы SaaS не подконтрольны клиентам и их работа не прогнозируема. Они не могут использоваться как ключевые для реализации существенных БП компании. В силу объективных причин компания производитель SaaS не может удовлетворить 100% требований всех своих клиентов, а значит, часть клиентов непременно столкнутся с ограничениями и им придётся решать, готовы они с ними мириться либо нет. Обновление ПО в SaaS — это процедура, скрытая от клиентов, за ней могут последовать необратимые изменения в работе сервиса, а также изменения в хранимых клиентских данных. Хуже всего то, что клиент узнает об этом только по факту проведённого обновления системы и вернуться назад он уже не сможет.

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

Учитывая всё вышесказанное, работа с SaaS сервисами выглядит скорее как некое временное решение для небольших и динамично растущих компаний, в которых БП ещё не жестко сформулированы и SaaS сервис добавляет некоторую степень автоматизации, в случае потери которой компания вполне может справится ручным трудом и миграция на другую платформу не сильно затратна. Можно предвидеть множество положительных отзывов об использовании SaaS, но сталкивался ли реально кто-нибудь с проблемами в обновлениях? Если пока нет, то, возможно поэтому опыт использования облака сплошь положителен?
Поделиться с друзьями
-->

Комментарии (12)


  1. kir_vesp
    18.08.2016 19:41
    +1

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


  1. Zonzen
    18.08.2016 23:45

    >Трудно представить себе хотя бы один день современного человека занятого в ИТ без использования, например, Gmail.
    Я занят в IT, никаких gmail и прочего чужого сервиса.


    1. Denis18
      19.08.2016 12:27

      Gmail — это один из примеров облака, для меня он самый известный. В более общем смысле — skype, what'sapp, viber… — все мессенджеры, соц. сети (да, их тоже используют в работе). А как же телефон? Мобильный телефон вполне себе аналог облака, где сеть ОПСоСа — облако, а абоненты — пользователи, которые платят за сервис.


      1. azsx
        19.08.2016 13:44

        Если настроить почтовый сервер и внутренний мессенджер на офисном сервере — то некоторые плюсы в данном решении есть.


        1. Denis18
          19.08.2016 13:50

          А с внешним миром как коммуницировать? Например мы используем упопянутый SaaS сервис не только для внутренних задач, но и ведём проекты совместно и с представителем вендора и с клиентом. Ещё один пример облака очень популярного в enterprise и телекоме — webex, как минимум чтобы не замыкаться только на внутренних пользователях.


          1. azsx
            19.08.2016 14:33

            в данном примере я скорее сторонний наблюдатель нежели представитель компании, попавшей в зависимость от сервиса.

            мы используем упопянутый SaaS сервис не только для внутренних задач, но и ведём проекты совместно и с представителем вендора и с клиентом.

            Как так?
            Вы поймите, есть два метода решения задач. Первый — переложить решение на кого-нибудь. Например, на облако. Второй, сказать администратору (программисту) какого результата вы ждете, когда он решит вашу задачу внутри вашей фирмы. Мне интересно, почему и кто в организации вместо решения задач локально у себя выбирает решение в облаках. И чем аргументирует свой выбор.
            webex, как минимум чтобы не замыкаться только на внутренних пользователях.

            Так как конкретные задачи мне не известны, которые вы решаете этим сервисом, могу наугад Вам предложить рассмотреть вариант раздачи потокового видео или vnc в web пробросить. Кстати, у Вас кто принимал решение, что webex — это лучший вариант для Вас?


            1. Denis18
              19.08.2016 15:35

              Я полагал, что вывод моей статьи довольно прозрачен — я не агитирую за повсеместное использование облаков. Даже напротив, обрисовываю вполне реальную ситуацию которая не лежит на поверхности.
              С другой стороны, не считаю облака абсолютным злом и рассматриваю возможность их применения в ряде задач с точки зрения баланса риск/решаемые задачи.
              Предлагая другую крайность — «давайте посадим программиста он нам быстро напишет CRM систему, ведь все стандартные совсем нам не подходят, у нас уникальный БП», Вы обязательно сталкиваетесь с множеством других проблем, начиная от постановки задачи на разработку заканчивая сопровождением системы. И это всё уже за рамками темы SaaS.
              Webex я привёл как пример ежедневно используемого сервиса, если мы его используем, это не значит что мы являемся инициатором его применения. Бывает так, что ваши партнеры (крупные международные компании находящиеся во всех часовых поясах) пользуются такими облачными решениями навроде webex потому, что им это реально необходимо и это удобно. Ну а вы сами, как партнёр, пользуетесь сервисом вместе с ними просто потому что это удобно. Поднять свой аналог webex в inhouse, например BBB? Да наверное можно, только для чего?


  1. azsx
    19.08.2016 11:05

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


    1. Denis18
      19.08.2016 12:23

      Дело в том, что в данном примере я скорее сторонний наблюдатель нежели представитель компании, попавшей в зависимость от сервиса. На примере других компаний, изучив их истории была сформулирована данная статья. Как и почему они построили свои БП так как сделали — я не знаю. Н по-моему вполне логично использовать сервис на всю катушку, если он оплачен. Если компания использует сервис не для собственного развлечения, а для реальной работы, то проблемы в работе сервиса очень быстро становятся проблемами работы бизнеса компании.


  1. AlexandreFrolov
    19.08.2016 11:43

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

    Что касается обновлений, то это, конечно, у всех по разному. Мы, например, относимся к этому с осторожностью, обновления выпускаем в виде патчей с возможностью отката на предыдущую версию.

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

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

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

    Решение тут за предпринимателем — есть ли у него средства на создание своего ИТ отдела, доверяет ли он своим ИТ-сотрудникам, или же таких средств нет, и разумнее воспользоваться SAAS-сервисом. С учетом того, что свои инсайдеры могут оказаться опаснее сотрудников провайдера SAAS.


    1. Denis18
      19.08.2016 12:19

      Спасибо за развёрнутый комментарий! А как вы управляете патчами/разными версиями сервиса? Возможна ли ситуация, когда разные аккаунты пользуются разными версиями платформы?


  1. AlexandreFrolov
    19.08.2016 12:27

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

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

    Собственно, мы начинали уже давно с индивидуальных проектов, и только потом уже собрали клонирующего робота, поэтому возможность кастомизации отдельных проектов заложена изначально. В том числе переноса на выделенные серверы или кластеры серверов. Но это уже, конечно, на заказ…