что значит облако в компе
Облако — что это и зачем?
Недавно мы запустили сервис ABBYY Cloud OCR SDK, работающий на облаке Windows Azure и попутно набрали 100500 опыта. Например, узнали, что многие используют слово «облако» и слышали, что «облака – это модно», но очень немногие понимают, что такое облако и главное – зачем делать сервис именно в облаке. Слово «облако» повсеместно используется и, похоже, начало обрастать городскими легендами.
Посмотрите, например, вот это видео:
Не много потеряете, если просто сосредоточитесь на том, что блондинка хорошо выглядит и у нее приятный голос.
Рассмотрим подробно, что такое публичное облако, зачем может иметь смысл использовать его для работы ПО и правда ли, что «скоро все будет в облаках».
Невиданные возможности для ваших клиентов
Для начала – чем для клиента сервис «в облаке» отличается от сервиса «не в облаке».
Считается, что «облачный» сервис обладает уникальным свойством – доступностью для любых пользователей. Облака тут ни при чем. Наш сервис работает в облаке, выглядит для пользователя как обычный веб-сайт (часть запросов даже выдает обычные на вид веб-страницы), в нем, например, есть пользовательский кабинет, который выглядит как обычные веб-страницы.
Для сравнения посмотрите на Stack Exchange (наиболее известен благодаря сайту Stack Overflow) или Яндекс.Почту – они для пользователя выглядят точно так же. Они тоже доступны любым пользователям и откуда угодно. Там тоже веб-сервер, который тоже принимает запросы по HTTP, там тоже все равно, какая операционная система у клиента, какая архитектура у его машины, на каком языке написаны его программы.
Можно встретить утверждения, что благодаря облачности сервиса «данные пользователей доступны им откуда угодно». Да, пользователи сервиса могут закачивать изображения на наш сервис откуда угодно и получать результаты тоже откуда угодно. Кстати, пользователи Stack Exchange или Яндекс.Почты тоже могут работать с этими сервисами откуда угодно – задавать вопросы, получать ответы, отправлять и получать письма.
Функционально облачный сервис не отличается для пользователя ничем. Что в облаке, что не в облаке, на каком-то IP-адресе стоит сервер (обычно веб-сервер), который принимает и обрабатывает запросы. Если нет настроек, ограничивающих доступ к серверу с конкретных диапазонов IP-адресов и клиент сам не сидит за параноидальным фаерволом, то сервис доступен откуда угодно и с какого угодно устройства. Облачность тут никак не сказывается.
Облачные сервисы для облачных сервисов
Также считается, что сервис в облаке делают для того, чтобы с ним могли взаимодействовать другие сервисы в облаке – что-то из серии «для использования разработчиками облачных сервисов», как недавно написали авторы одного пресс-релиза. В особо бредовых презентациях можно встретить картинки с утыканным колышками наивно схематичным облаком – это облако, в нем сервисы, и они там взаимодействуют.
Посмотрим на это с точки зрения нашего сервиса. Цель разработки нашего сервиса – предоставить программно доступный из любой точки мира сервис – чтобы сторонние разработчики, которым в их программах не хватает оптического распознавания текста, могли разработать ПО, которое использует наш сервис для распознавания. Например, программу для смартфона, которая фотографирует чек, извлекает из него данные и сохраняет их в программу для бюджетирования на том же смартфоне. Капитан Очевидность подсказывает: смартфон не в облаке. Наш сервис не только для «разработчиков облачных сервисов», он для разработчиков любых программ, которые готовы использовать сторонний сервис для распознавания текста. В облаке те программы работают или нет – не имеет принципиального значения, а нашему сервису просто все равно.
Считается, что облачный сервис – это обязательно сервис для обслуживания многочисленных внешних запросов. Обычно да, но не обязательно. Никто не мешает вам запустить на вашем сервисе разложение простых чисел на множители, исходные данные для него хранить где-нибудь снаружи, чтобы сервис их сам оттуда брал, а результаты заливал на внешний ftp-сервер.
Облачная архитектура облачных сервисов
Далее – считается, что сервис, работающий в облаке, принципиально по-другому устроен, его разработка требует принципиально другой архитектуры по сравнению с сервисом, работающим не в облаке. Некоторые отличия действительно есть, но они второстепенны.
Представьте, что вам нужно сделать веб-сервис, который принимает от пользователя изображения, складывает их в очередь на обработку (потому что распознавание занимает некоторое время), обрабатывает, после обработки дает пользователю ссылку на скачивание результата. Как бы вы сделали его? Скорее всего, вы бы создавали во внутреннем хранилище (скорее всего, базе данных) «задание» для каждого принятого изображения, давали ему уникальный идентификатор, отдельным потоком или отдельным процессом распознавали изображение, потом на очередной запрос «как дела у задания такого-то» возвращали ссылку на результат. Это совершенно очевидная архитектура для такого сервиса, и облачность тут тоже ни при чем.
Считается, что в облаке используется «облачная операционная система». Обычно это просто допиленная «обычная операционная система». В Windows Azure это Windows Server 2008 R2 со слегка перетянутыми гайками (например, временная папка очень маленькая). Вся «облачность» в такой среде создается дополнительными сервисами – например, долговременным хранилищем данных, не привязанным к машине, на которой работает пользовательский сервис.
Некоторое время назад мы рассказывали, что теперь FineReader Engine поддерживает работу в Windows Azure. Эта доработка не потребовала полного переписывания всего FRE, просто учли ограничения платформы, немного под них доработали, протестировали, обновили документацию, взяли на себя обязательство дальше поддерживать. Кропотливая и важная работа, но не более того.
Беспрецедентная надежность
Еще считается, что облачный сервис непременно более надежен, потому что там же есть облачный провайдер облачного облака, предлагающий много девяток после запятой. Тут девятки отдельно, надежность отдельно.
Прежде всего, нужно читать мелкий шрифт в соглашении о девятках (SLA – Service Level Agreement). Там указано точно, что эти девятки означают, какие конкретно свойства сервиса они затрагивают, какова ответственность провайдера.
Обычно ответственность провайдера не больше, чем те относительно небольшие деньги, которые вы ему заплатили, а пока ваш сервис не работает, ваша компания может терять гораздо большие деньги и нести ущерб репутации. Да, провайдер ответит, но вам от этого может не полегчать.
Похожий пример из жизни: в среднем раз в год в здании на секунду отключается электроснабжение, так что перезагружаются компьютеры. С точки зрения поставщика электроэнергии – это жалкая секунда в год (сколько там девяток?), а с вашей точки зрения – это потеря нескольких минут работы каждым сотрудником, потому что ему нужно будет ждать, пока загрузится ОС, запустятся все программы, потом вспоминать, на чем он остановился. Девяток много, а вам от этого не легче.
Соглашение может гарантировать доступность каких-то конкретных сервисов (например, что виртуальные машины, на которых работает ваше ПО, будут работать и подключены к сети) – может возникнуть ситуация, когда надолго откажет, например, второстепенный с виду сервис управления этими виртуальными машинами – они будут продолжать работать, а запустить новые или перенастроить их вы не сможете. Вам-то как раз надо было увеличить пропускную способность сервиса в сто раз, чтобы принять пиковую нагрузку от очень важной и щедро оплаченной только что начавшейся рекламной кампании. Провайдер даже соглашение не нарушил, потому что в соглашении об этом второстепенном на вид сервисе ничего не говорится.
От размещения в облаке сервис не становится гарантированно более или менее надежным. Риски никто не отменяет, просто риски становятся другими.
Так что это?
Теперь, когда мракобесия стало меньше, вернемся к вопросу, что такое публичное облако. Это сервис с дистанционным управлением, который предоставляет вам вычислительные мощности и хранилища данных с оплатой по мере использования. Вы используете мощности для работы вашего ПО (вашего сервиса), а хранилища – для хранения данных, с которыми это ПО (ваш сервис) работает.
У вас может быть разный уровень контроля над предоставляемыми мощностями. Например, вам могут выделить виртуальную машину с конкретной ОС и закрепить ее за вами и дать вам к ней удаленный доступ, чтобы вы сами настроили ее как вам нужно и дальше оставить ее в вашем распоряжении. Или (как в Windows Azure) вы можете загрузить специальный архив с исполняемым кодом вашего сервиса и конфигурационный файл, в котором указано «запустить вот это на 5 машинах по 2 ядра каждая», служебная инфраструктура облака сама найдет подходящие виртуальные машины, развернет, запустит и настроит на них ОС, потом развернет там ваш архив и передаст управление в точку входа (фиксированная функция типа main()), и будет следить, не сломалось ли что, в случае чего перезапустит ваш сервис на той же или (при сбое машины) на другой машине. В первом случае вы больше контролируете, во втором у вас больше дополнительных плюшек.
В чем прибыль?
Прибыль в гибкости и делегировании обязанностей. Вам нужно увеличить число машин, на которых работает ваш сервис? Несколько щелчков мышью, ожидание в районе 10 минут – и вам уже нашли новые виртуальные машины, запустили на них ваш сервис. Надо убавить? То же самое.
То же самое с хранилищем. Нужно хранилище – несколько щелчков мышью, и вам его предоставили и дали адрес и ключи доступа к нему. Хранилище обычно резиновое, оплата зависит от реально используемого объема.
Провайдер может, например, предоставлять сервер баз данных – тоже «где-то» и тоже с оплатой по используемому объему. В Windows Azure это SQL Azure, основанный на специально настроенном и допиленном SQL Server 2008.
Нужно попробовать новую фичу и есть риск сломать сервис? Можно сделать так. Создаете еще одно хранилище и еще одну базу данных. Настраиваете ваш сервис на новое хранилище и новую базу, разворачиваете на дополнительно выделенных виртуальных машинах. Попробовали, освободили машины, если в хранилище и базе много данных, можно их тоже удалить, чтобы не платить за них.
У нас автоматическая сборка в конце разворачивает наш сервис прямо в облако на специально выделяемую для этого виртуальную машину и выполняет там тесты. При каждой сборке машина выделяется заново, после сборки освобождается, так что в выходные и ночью, когда правок кода нет, мы за нее не платим. Код тестируется в точно таком же окружении, в каком он будет потом работать.
Такая гибкость очень удобна. Это светлая сторона облака, за которую оно в первую очередь и ценно. Надо – берете в аренду, не надо – прекращаете аренду, и то, и другое требует нескольких щелчков мышью (или программного запроса) и не очень долгого ожидания.
Это удобно для компании любого размера. Не надо проводить через бухгалтерию закупку каждой железки, не надо закупать оборудование про запас, можно добиться гораздо меньшего простоя мощностей и гораздо большей гибкости в управлении.
Плюс вы перекладываете часть обязанностей на провайдера. Сервера вы больше не покупаете, стойки не собираете, электрическим подключением не занимаетесь, место под оборудование вам не нужно, вы можете даже ОС не настраивать (зависит от облака). Обратите внимание, речь именно о перекладывании обязанностей, но не ответственности, об этом подробнее ниже.
Как обычно, есть и темная сторона
Темная сторона облака в том, что на многие вещи нельзя повлиять. Если верить блогу команды Stack Exchange, их сервис работает не в облаке, а на собственном оборудовании, именно потому, что их не устраивает уровень контроля, который предоставляется провайдерами облаков.
Например, виртуальные машины стандартные и вы можете даже не знать характеристик реального железа. Скорее всего, когда в Windows Azure вы разворачиваете сервис на одном одноядерном узле, вам на самом деле дают виртуальную машину, которая работает в каком-нибудь 16-ядерном сервере под HyperV. Может быть, можно там что-нибудь подкрутить и на ровном месте получить 15-процентный прирост производительности, но вы ничего не можете с этим сделать.
Если вы параноик или связаны жесткими требованиями закона или договора, вас может не устраивать, что вы вообще очень мало контролируете железо. Например, вы закачали туда документы с коммерческой тайной, они скопировались на кучу жестких дисков, вы никак не можете повлиять на их гарантированное удаление. Да, провайдер вам обещает, но вы не сможете это проверить.
То же самое касается надежности. Вы не можете быть уверены, что стойки в один прекрасный момент, например, не зальет конденсатом из оторвавшейся трубки системы кондиционирования. Если бы ваш сервер был в офисе или в colocation, то вы могли бы сделать что-нибудь, пусть даже на вид безумное, типа отвода воды из пространства над вашим оборудованием. Здесь вы ничего сделать не сможете – вы не контролируете, где стоит оборудование, хорошо ли оно там закреплено и не бегают ли по нему мыши. Все безумные события, которые вы могли бы предусмотреть (или не предусмотреть и чувствовать угрызения по поводу плохо сделанной работы), теперь полностью вне вашего контроля.
Безумные события бывают самые разные. Вот примеры реальных сбоев в датацентрах.
FAIL. Автомобиль врезался в опору ЛЭП рядом с датацентром, оборвались и упали на землю провода высокого напряжения перед подстанцией, питающей датацентр. Начался переход на резервное питание. От проводов, лежавших на земле, ток стекал в землю, в датацентре защитные схемы среагировали на утечку тока в землю и отключили весь датацентр.
Другой FAIL. Предположительно из-за удара молнии вышел из строя трансформатор, питающий датацентр, начался переход на резервное питание. По какой-то причине не удалось синхронизировать генераторы (скорее всего, не было питания на оборудовании, выполняющем синхронизацию), датацентр не смог перейти на резервное питание, все оборудование отключилось.
Обратите внимание, мы знаем об этих случаях потому, что они затронули сотни и тысячи пользователей облаков. Сколько аналогичных событий происходит с серверами, стоящими в офисах, мы просто не знаем.
Конечно, что-то подобное может произойти и с серверами в офисе, но в таком случае в этом будет доля вашей вины – могли предусмотреть, а не предусмотрели. Вам будет стыдно за плохо сделанную работу. В случае, когда оборудование стоит «где-то там», таких возможностей нет, вы вынуждены верить провайдеру.
Это не плохо, просто нужно это четко понимать. Размещая сервис в облаке, вы передаете провайдеру значительную часть обязанностей, но не ответственность за жизнеспособность вашего сервиса. Облачный не значит автоматически более надежный и не значит автоматически менее надежный. Вам все равно нужна оценка рисков, для критически важных сервисов понадобится дублирование в разных датацентрах и перераспределение нагрузки. Очень может случиться, что когда вы учтете все расходы на дублирование и синхронизацию данных между датацентрами, ценник вас расстроит.
Снова облачная архитектура облачных сервисов
Напоследок – об особых требованиях к облачным сервисам. Такие требования есть – нужно быть готовым, что в любой момент что угодно может сломаться. Если вы любите крайности, то можете как Netflix сделать сервис, который в произвольные моменты ломает что-нибудь в вашем сервисе. Особенно нужно быть готовым к эпизодическим кратковременным сбоям. Например, иногда будет ненадолго пропадать связь с SQL Azure – ваш код должен не паниковать и не ломаться, а подождать немного и попробовать еще раз.
Просто вспомните, что обычно раздражает пользователей в программах – всевозможные «не удалось найти сервер, вот 18 пунктов, которые стоит проверить» в распределенной системе абсолютно нормальны, ваш сервис должен пробовать сам с этим справиться, потом пробовать еще несколько раз. Пользователь после сообщения браузера «нет ответа сервера» обычно нажимает F5, так и ваш сервис должен просто попробовать повторить действие. Для этого важно, чтобы повторное выполнение любого действия не наносило вреда – это называется умным словом идемпотентность. Если вы не учтете эту особенность, то ваш сервис будет в самый неподходящий момент выходить из строя из-за какой-нибудь ерунды.
Аналогично сервис должен быть готов к тому, что его могут в любой момент остановить – на всех узлах или на некоторых – и затем запустить снова, при этом не должно происходить повреждения данных, потеря самых новых данных должна быть минимальной, после перезапуска сервис должен быть в состоянии продолжить работу как будто ничего не произошло. Такое происходит, например, при автоматической установке обновлений ПО в Windows Azure – узлы по очереди останавливаются, затем сервис запускается на узле с уже обновленным ПО.
Требования существенные, но выполнимые, просто Мерфи будет чаще приходить к вашему сервису. От вас зависит, превратится ли небольшой FAIL в былинный отказ.
Облако – это не куча слов «масштабируемое», «доступность», «миграция», «производительность», «тенденция», употребленных в произвольном порядке в маркетинговом тексте. Это просто модель владения вычислительными мощностями. В определенных случаях эта модель очень удобна.
Кстати, у нас есть сервис для разработчиков, работающий в облаке.
Дмитрий Мещеряков,
департамент продуктов для разработчиков
Как вести бизнес через облачные сервисы
Облачные сервисы — это онлайн-программы и другие инструменты, которые помогают удаленно управлять бизнес-процессами. За счет «облаков» компании могут автоматизировать работу, сэкономить и лучше защитить свои данные
Дарья Кугакова
Руководитель отдела маркетинга RocketSales
Что такое облачные сервисы
Облачные сервисы, или «облака», — это сеть мощных компьютеров — серверов, которые позволяют клиентам пользоваться своими ресурсами через интернет: хранить файлы и обмениваться ими, работать в онлайн-офисах, производить вычисления.
В узком смысле облачные сервисы — это онлайн-программы, которые помогают организовать удаленную работу и решать бизнес-задачи. Сотрудники получают доступ к общей базе данных из любой точки мира и могут управлять проектами. Каждый работник видит результат в реальном времени, может вносить комментарии, правки и выполнять персональные или совместные задачи. Пример облачного сервиса — Google Документы.
Облачные сервисы приходят на смену классическим «коробочным» офлайн-программам, которые устанавливают на отдельные компьютеры. Пример «коробки» — Microsoft Office.
Облачная сеть состоит из узлов хранения информации, которые называются дата-центрами. Это целые здания, заполненные огромными шкафами с серверным оборудованием. Они расположены по всему миру и связаны через интернет. Строят и обслуживают оборудование облачные провайдеры. Они же распределяют ресурсы «железных» серверов на отдельные виртуальные машины и сдают их в аренду.
Пользователи подключаются к облачным серверам через интернет и через них отправляют и получают информацию, используют программы и другие онлайн-инструменты для работы.
Кому полезны облачные сервисы
Облачные сервисы подходят для любого бизнеса — от ИП без сотрудников и стартапов до госструктур и международных корпораций.
Во время пандемии многим компаниям пришлось перейти на удаленный формат работы и использовать для этого облака.
Огромное и сложное производство работало на классических офлайн-программах. Когда началась пандемия, компьютеры остались в офисах. Сотрудники не имели к ним доступа, и работу парализовало на несколько дней. Спасти ситуацию помогло быстрое внедрение облачных программ с удаленным доступом.
Обратный пример — компании, которые уже несколько лет пользуются «облаками». Во время локдауна их сотрудники перешли на удаленку за один день, и рабочий процесс не пострадал.
За счет «облаков» компании могут автоматизировать работу и получать больше прибыли. Вот примеры того, в чем могут помочь облачные сервисы.
Настройка бизнес-процессов. Через CRM-систему менеджер получает заявку, запрашивает информацию на складе, заказывает в бухгалтерии счет и отправляет его клиенту.
Внутренняя и внешняя отчетность. Руководитель ведет учет времени и показателей работы, юристы хранят и согласовывают документы, бухгалтеры выставляют счета и отправляют налоговые декларации.
Учет товаров. Кладовщики контролируют продукцию на складе и отправляют данные менеджерам.
Коммуникация в команде. Сотрудники общаются через платформу управления проектами, корпоративную почту, мессенджеры и видеосвязь, совместно работают над документами, назначают встречи через корпоративный календарь.
«Облака» дают компаниям возможность сконцентрироваться на бизнес-процессах, а решение технических задач по настройке и поддержке офисных программ передать внешним специалистам и оплачивать по подписке.
Какие бывают облачные сервисы
Есть три типа облачных сервисов:
Частное облако принадлежит одной компании и работает на ее оборудовании. Им пользуются только сотрудники. Вся информация остается внутри, ее проще контролировать и защищать. Но частное облако могут позволить себе только крупные компании, потому что оно дорогое в использовании: нужно покупать или арендовать оборудование, самим обслуживать и администрировать его.
Публичное облако содержит и обслуживает провайдер, который сдает разным клиентам вычислительные мощности в аренду. Бизнес может закупить ровно столько ресурсов, сколько нужно для работы и хранения файлов. Это удобно и выгодно. Когда мы говорим об использовании облачных сервисов, мы чаще всего имеем в виду именно публичные облака.
Гибридное облако — когда часть работы находится в публичном облаке, а другая — в частном облаке или вообще на физических носителях. Такое бывает, например, в процессе постепенного перехода компании от традиционной инфраструктуры к облачной.
Какие задачи могут решать облачные сервисы
Глобально есть три самых популярных вида услуг, которые предоставляют облачные сервисы:
IaaS — инфраструктура как услуга, когда бизнес арендует виртуальные вычислительные ресурсы и хранилища. Например, клиент может пользоваться виртуальным компьютером на MacOS со своего Windows-устройства, чтобы использовать программы, которые есть только для Мака. При этом поддержкой и обслуживанием «железа» занимается провайдер.
PaaS — платформа как услуга. Прежде всего, это продукты для разработчиков, например программы для создания и тестирования приложений, виртуальные базы данных, системы машинного обучения и обработки больших данных.
SaaS — программное обеспечение как услуга — это готовые к использованию приложения и сервисы, не требующие установки, обслуживания и обновления со стороны пользователя. Примеры: amoCRM, Asana, Google Drive.
Для большинства бизнесов пригодятся именно SaaS — решения, потому что основная аудитория IaaS и PaaS — это системные администраторы и разработчики, а не конечные пользователи вроде менеджеров.
Облачные программы для бизнеса, которые упростят работу
CRM-система amoCRM — помогает выстраивать и контролировать поэтапную работу компании, ставить задачи менеджерам, отслеживать взаимодействия с клиентами, проводить аналитику продаж.
Платформа для управления проектами Asana — помогает распределять задачи и контролировать их выполнение, комментировать и обсуждать действия по проекту.
IP-телефония Sipuni — помогает назначить колл-центру единый многоканальный номер, записывать и анализировать разговоры, вести статистику, связать звонки с общей CRM-системой.
Пакет офисных программ Google Workspace — позволяет совместно использовать документы и другие файлы, объединить почту, календарь и другие сервисы Google в единую систему.
Тайм-трекер Time Doctor — помогает следить за рабочим временем сотрудников на удаленке, если у них оплата по часам.Интеллектуальные карты Miro и MindNode — помогают создавать прототипы, проводить креативные мозговые штурмы, рисовать схемы и шаблоны.
Графические редакторы Figma, Sketch — для дизайна, создания и обработки изображений.
Мессенджеры Skype, Zoom, Slack, Telegram, WhatsApp — для общения и переписки.
Конструкторы Tilda, WebFlow и Readymag — для создания сайтов.
Все эти программы доступны по подписке и не требуют сложного внедрения или разработки.
Зачем переходить на облачные системы
У облачных сервисов по сравнению с «коробочными» тяжело найти недостатки. У них много преимуществ:
Сборка и настройка под задачи клиента. Универсальных облачных решений нет, каждый бизнес может попробовать и сравнить разные сервисы и выбрать те, что ему больше подходят. Подключить нужные услуги и отключить ненужные можно за несколько кликов. Когда компания выберет свой набор инструментов, их можно связать в единую систему и настроить под свои нужды. Раньше интеграция могла стоить несколько миллионов рублей, но сейчас есть сервисы типа Zapier, которые помогают интегрировать что угодно быстро и недорого.
Есть виджет, который интегрирует CRM-систему с Google Диском. Менеджер может за пару кликов создать по шаблону папку клиента, заполнить ее нужными документами и отправить ссылку на нее через мессенджер — все это внутри одного окна CRM.
Постоянные улучшения. Один из главных плюсов облаков в том, что профессиональные и довольно дорогие команды аналитиков, программистов, тестировщиков и менеджеров каждый день работают над улучшением функций и удобства использования своих сервисов. Разработчики платформ думают наперед и собирают обратную связь. Даже если сейчас в наборе функций не хватает, с большой вероятностью это скоро появится.
Компании не хватало некоторых возможностей таск-менеджера Asana, и она попросила своих программистов дописать эти функции. А через пару месяцев разработчики Asana сами добавили их в очередном обновлении.
«Коробочные» сервисы, наоборот, неповоротливые, реже обновляются и хуже интегрируются между собой.
Удаленный доступ. Работать с облачными сервисами можно из любого места, где есть стабильный скоростной интернет. Несколько сотрудников могут одновременно вести задачу и видеть изменения в онлайн-режиме.
«Коробочные» программы доступны только с конкретного устройства — если сотрудник не может приехать в офис, он не сможет выполнить работу.
Экономичность. Может показаться, что пользоваться облачными сервисами дорого — нужно постоянно платить за подписку, когда коробочное решение купил — и пользуешься. Но если сравнить стоимость покупки и обслуживания «коробочных» программ с общей суммой расходов на подписку на облака — разница чаще не в пользу офлайн-решений.
«Коробочные» программы сами по себе стоят дорого, ведь вроде бы они покупаются раз и навсегда. Но в реальности их обычно нужно дорабатывать, и для этого приходится привлекать разработчиков и оплачивать их работу. Часто базовые программы не приспособлены для внедрения виджетов и сторонних обновлений — интеграции требуют много времени, а значит, много расходов на оплату часов работы программистов.
Ну и главное, на чем экономит бизнес. Провайдер покупает дорогостоящее оборудование и обслуживает его, а клиент платит только за фактическое использование виртуальных машин. Бизнесу не нужно покупать лицензии на программы, дополнительно нанимать системных администраторов и разработчиков — он платит только за ресурсы, которыми пользуется. А когда перестает пользоваться — перестает платить.
Безопасность облачных сервисов: а вдруг все удалится?
О безопасности мы решили написать отдельно: с одной стороны, это главное опасение пользователей, а с другой — еще одно преимущество облаков.
Есть мнение, что коробочные сервисы надежнее: в интернете могут украсть базу, а «коробка» установлена в компьютере, и никто туда не доберется. В реальности это не совсем так. Рассмотрим две угрозы безопасности — внешнюю и внутреннюю.
Защита облаков от внешних угроз. Провайдеры вкладывают огромные деньги в безопасность, потому что они не могут рисковать своей репутацией. Когда бизнес подключается к облачному сервису, ему гарантируют защиту и конфиденциальность информации.
Дата-центры и серверы облаков защищены от несанкционированного проникновения, перегрева, пожара и других угроз. Администраторы регулярно тестируют и обновляют оборудование, чтобы оно работало исправно и данные пользователей не пострадали.
Специалисты в области информационной безопасности постоянно проверяют систему на уязвимости и обновляют защиту с использованием эффективных и дорогостоящих технологий шифрования данных.
Небольшие компании не могут тратить столько денег на безопасность, поэтому облачная инфраструктура защищена лучше, чем данные на компьютерах в офисе.
Защита внутри компании. Облачные программы можно настроить так, что сотрудники будут видеть только те сделки и тех клиентов, с которыми они работают. Для этого есть специальные виджеты. Это повысит безопасность клиентской базы и снизит вероятность утечки информации через недобросовестного менеджера.
С помощью CRM-системы можно равномерно распределять самых платежеспособных клиентов между менеджерами, чтобы все випы не попадали к одному сотруднику, который может их увести за собой в случае увольнения.
В наборе программ Google Workspace можно за несколько кликов дать сотруднику все нужные права и доступы, например к гугл-диску и документам, и так же легко разом их закрыть, если сотрудник уволился или вызывает подозрения.
Когда бизнес ведет учет в Excel, Word, Блокноте и других подобных программах, настраивать и ограничивать доступ сотрудников сложно, а заметить кражу данных практически невозможно.
Как перейти на облачные сервисы
Переход к облачным сервисам можно разделить на несколько этапов:
Анализ и аудит. Начинать нужно с аудита и аналитики бизнес-процессов. Можно провести их самостоятельно, но лучше обратиться к профессионалам, которые знают, что нужно делать. Бизнес-аналитики и технические специалисты помогут определить, для чего стоит использовать облака, каких целей можно будет достичь, с чего стоит начинать.
Специалисты изучат бизнес-процессы, пообщаются с сотрудниками, которые будут пользоваться программами, выявят недостатки, которые мешают развитию, и на основании этого выстроят архитектуру. Начинать нужно с того, что больше всего болит, от чего компания теряет клиентов и прибыль.
Если компания пока маленькая, можно провести такой аудит самостоятельно: разложить бизнес-процессы на этапы. Для этого разберитесь:
Таких вопросов может быть гораздо больше в зависимости от сложности и специфики вашего бизнеса. Когда вы построите последовательную схему процесса, вы поймете, какие облачные сервисы могут быть вам полезны для автоматизации работы.
Выбор провайдера и специалистов по внедрению. Крупному бизнесу, использующему облачные серверы, нужен провайдер. При выборе провайдера наиболее важны три фактора: хорошая репутация, большой набор услуг и географическая близость дата-центров к целевым рынкам заказчика — это влияет на скорость работы сервисов. Например, если вы ведете бизнес в России, тяжелая база данных будет быстрее перегоняться через российские серверы, чем через американские или индийские.
Чтобы выбрать специалистов по внедрению облачных сервисов, нужно изучить их кейсы, отзывы, цены, провести переговоры и узнать о специализации исполнителя: например, лучше разрабатывает программы и виджеты, а — непосредственно внедряет решения.
Если у вас небольшой бизнес и нужно подключить всего пару облачных программ, это можно сделать своими силами или через службу поддержки самих сервисов. Например, у разработчиков ПО для магазинов цветов «Посифлора» есть отдел внедрения, который помогает клиентам разобраться в программе и правильно ее настроить.
Внедрение и обучение сотрудников. Обычно набор облачных сервисов базируется на CRM-системе, которая помогает вести продажи на всех этапах и строить долгосрочные отношения с клиентами. Она делает работу структурированной и регламентированной, позволяет учитывать все потребности и нюансы.
Клиент оставил заявку — менеджер сразу видит уведомление и берет в работу, связывается с заказчиком и последовательно двигает задачу по этапам воронки продаж. Система сама подсказывает, что делать дальше: например, «Позвоните клиенту и выявите потребность».
Важно показать сотрудникам, как облачные сервисы делают их работу проще и комфортнее. Для этого нужно разобраться в программах и научить всех правильно ими пользоваться. В таком случае сотрудники будут не просто отмечаться ради регламента, а реально пользоваться системой.
Настройка, оптимизация, интеграция. После внедрения программ нужно настроить систему работы облачных сервисов, которая будет учитывать особенности компании. Например, можно интегрировать виджет для учета рабочего времени сотрудников с платформой по управлению проектами. Настроить автоматическую отправку записей разговоров с клиентами в облачное хранилище, подключить рассылку для клиентов о степени готовности заказа через мессенджеры.
Доработка программы под задачи бизнеса. Облачную инфраструктуру нужно постоянно корректировать под текущие задачи. Например, если у компании меняется бизнес-процесс продаж, его нужно перестроить и в CRM-системе. То есть мало один раз внедрить сервис, нужно его сопровождать. Сопровождением систем занимаются те же компании, что и их внедрением.