Жизнь в «облаках»: зачем это нужно бизнесу | Технологии | Forbes.ru
$57.43
67.48
ММВБ2063.7
BRENT57.90
RTS1132.02
GOLD1274.98

Жизнь в «облаках»: зачем это нужно бизнесу

читайте также
+7 просмотров за суткиНе просто мессенджер: почему оценка сервиса Slack превысила $5 млрд +9 просмотров за суткиПочему рано или поздно весь ИТ-бизнес будет в «облаке»? +8 просмотров за суткиПросто добавь IT: как внедрить облачные технологии в консервативный бизнес +1 просмотров за суткиФискальное облако на пальцах: мечты и реальность онлайн-касс +1 просмотров за суткиВойна технологий. Как Google и Microsoft пытаются догнать Amazon на триллионном рынке облачных хранилищ Точка зрения: как российский сервис видеонаблюдения Ivideon покоряет мир Своя точка зрения Музыкальный YouТube: SoundCloud — уникальный проект или очередной пузырь? 27-летний предприниматель бросил вызов Oracle и Microsoft. Что получилось? Как основатель «1С» построил бизнес с выручкой в $1 млрд «Главный конкурент облачных сервисов — табличка в Excel» Российский бизнес не любит облачные сервисы. В чем причина? Как одесский программист отвоевал клиентов у монополистов связи США «Мы готовим новый продукт для рынка США. Он будет облачным» Что думает топ-менеджер Microsoft о стартапах в России

Жизнь в «облаках»: зачем это нужно бизнесу

Сергей Таран Forbes Contributor
Фото Charles Platiau / Reuters
На реальных примерах и кейсах разбираемся, зачем и как компании работают с поставщиками облачных услуг

Так называемые облачные технологии и системы давно стали чем-то обыденным для бизнеса, стремящегося максимально эффективно выстраивать информационные взаимодействия внутри компании и с ее клиентами. Летом 2017 года о переносе важных ИТ-систем в облака объявили такие крупные компании, как МТС-банк, «Глобус», «Национальная медицинская сеть» и др. Покажем на примерах, как это работает и зачем нужно. 

Причина первая: гарантированный доступ

Чуть больше месяца назад Рокетбанк разместил в соцсетях следующее сообщение: «Наши карты не работают уже несколько часов. Нашли проблему: повреждение оптоволоконного кабеля, идущего к дата-центру банка. Для исправления потребуется несколько часов. Извините нас, пожалуйста. Скоро всё будет ок!»

Не знаю, в чем были сложности у Рокетбанка, но этот случай напомнил мне историю пятилетней давности с компанией Inventive Retail Group — ритейлером, специализирующимся на цифровых гаджетах (кейс компании «Онланта», которую возглавляет автор – Forbes).

Управление розничной сетью, как и у Рокетбанка, происходило из серверного помещения в главном офисе компании, расположенном в ЦАО. Информационная система обеспечивала обмен данными о товарных запасах: она позволяла доставлять товары в необходимом количестве, не создавая избытка на складе в магазине.

Система также управляла программой лояльности клиентов. Менеджмент Inventive Retail Group был вполне доволен ситуацией — пока однажды во время дорожно-ремонтных работ рядом с офисом экскаватор ковшом не перерубил волоконно-оптический канал связи.

Восстановить коммуникации – дело не одного часа. Ремонт шел более суток. Все это время торговая сеть не имела связи с информационной системой. Возник перекос в поставке товаров: магазины не получали товар в соответствии с текущим спросом. Покупатели хотели приобрести те или иные модели – но оказывалось, что их не успели подвезти. В результате Inventive Retail Group получил серьезные убытки.

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

Кроме того, облако, как и положено, обеспечено производительными каналами связи, причем с защитой от DDoS-атак. Больше проблем с доступом у торговой сети не было.

Причина вторая: эластичность

К облачному решению Inventive Retail Group пришла не сразу. После инцидента она задумала разместить информационную систему во внешнем дата-центре, где несколько телеком-операторов смогут обеспечить надежную связь.

Ритейлер намеревался использовать собственные вычислительные ресурсы: серверное оборудование, размещенное во внешнем центре обработки данных (ЦОД) — так называемый colocation.

А это означало переезд оборудования. Плюс покупка нового серверного оборудования — ведь по мере развития торговой сети ресурсы системы должны были увеличиваться.

Ритейлер запросил у разработчиков своей информационной системы расчёт параметров серверов, и те представили предложение: для надежной работы информационной системы потребуется закупить комплекс серверов общей стоимостью 7 млн рубей.

ИТ-директор Inventive Retail Group от такой цены схватился за голову. И обратился к сторонним экспертам для анализа предложения – в том числе к нашим специалистам.

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

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

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

Причина третья: надежность

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

Стали разбираться, кто виноват в происшедшем. Оказалось, что случилась поломка собственного сервера: ИТ-служба компании не позаботилась о том, чтобы резервировать оборудование и данные. А если это не сделано, гарантируемое дата-центром кондиционирование, электропитание, надежные каналы связи не дадут никакого эффекта.

Довольно многие компании попадают в эту ловушку. Они заключают договор о colocation с внешними дата-центрами, сертифицированными по международному стандарту TierIII (уровень надежности 99,98%), но не отдают себе отчета в том, что она справедлива только для так называемого нижнего уровня обеспечения надежности - инженерной инфраструктуры. TierIII не гарантирует сохранность данных и доступность бизнес-приложений.

Надёжность должна обеспечиваться на четырёх уровнях. Первый - инженерная инфраструктура ЦОД. Второй – вычислительная инфраструктура: серверы, сетевое оборудование, системы хранения данных. Третий уровень – программная платформа (операционная система, СУБД), на которой работает прикладное ПО. И четвертый — само прикладное ПО.

Каждый из этих уровней вносит вклад в суммарную надёжность, и может полностью перечеркнуть усилия по обеспечению надежности на трёх других. Чтобы суммарная надежность была 99,98%, такой уровень надежности должен обеспечиваться на каждом из четырёх уровней.

Получить такую надежность можно только в облаке. Надежность и доступность в облаке увеличивается, во-первых, за счет резервирования каждого из элементов инфраструктуры: серверов, сетевого оборудования, СХД и т.д.

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

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

Причина четвертая: второе плечо

Телерадиокомпания «Мир» располагает колоссальным – порядка 500 терабайт – видеоархивом, который постоянно необходим для работы. Популярность телеканала формируется во многом за счет оперативности и полноты информации в информационных программах, следовательно, необходим быстрый и надежный доступ к видео- и аудиоархиву для их подготовки.

Архив быстро рос, и отсутствие его резервирования создавало целый комплекс рисков – от недоступности по разным причинам необходимых видеоматериалов при подготовке сюжетов до утери данных. Для повышения надежности хранения и доступности данных, а также производительности системы стала остро актуальной задача создания «второго плеча» видеоархива.

В качестве возможных вариантов рассматривались: приобретение и установка необходимого оборудования в ЦОДе компании или приобретение услуги хранения видеоархива в облаке. Сложность задачи состояла в том, что хранение, обработка и передача видеоконтента предъявляет жесткие требования к пропускной способности каналов связи.

ТРК «Мир» выбрала вариант с размещением резерва видеоархива в облаке как более экономичный и отказоустойчивый (стала нашим клиентом, аналогичный кейс – с телекомпанией Life, был у наших коллег – компании «Инфосистемы Джет»).

Почему? Во-первых, облачный провайдер предоставил высокоскоростные каналы связи до площадки заказчика. Во-вторых, облачное решение обеспечило повышение общей производительности системы за счет распараллеливания работы с данными.

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

Причина пятая: персональные данные

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

Компания, после некоторых раздумий, приняла решение передать свое хранилище персональных данных в облако одного из наших коллег по рынку. И успешно прошла новую проверку регулятора - просто предъявив договор с облачным провайдером.

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

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

Облака надежные и «гаражные»

В своем недавнем совместном исследовании компании Huawei и IDC пришли к выводу, что облака станут основным направлением на рынке корпоративных коммуникаций. Исследование компании Oracle показывает, что ощущения перешедших в облака в основном позитивны. На Западе они используются, в том числе, в оборонной индустрии, а также правительственными организациями.

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

Еще один момент: преимущества облачных решений можно получить только если работать с надежным облачным провайдером. Увы, надежные не все. В 2014 году облачный провайдер Cloudmouse опубликовал на своем сайте заявление: «Уважаемые пользователи, в результате аппаратного сбоя были утеряны все данные виртуальных машин, включая их бекапы. И как следствие, мы вынуждены были удалить все виртуальные машины в облаке. На данный момент, мы нашли точку сбоя и исправили ее. В дальнейшем подобная ситуация уже не повторится, так как мы нашли источник проблем и приняли меры».

Как правильно выбрать облачного провайдера? На рынке публичных облаков – то есть общедоступных для больших групп потребителей, представлены как международные провайдеры (Azure, Amazon, Google, IBM), так и российские. Уровень цен у надежных облачных провайдеров примерно одинаков.

Преимущество международных облаков – большой объем ресурсов, развитые автоматизированные сервисы. Но есть две проблемы. Первая – поддержка пользователей в основном через запросы на сайтах, то есть, как правило, не в реальном времени, отсутствие «нестандартного» или «индивидуального» подхода.

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

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

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

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

-стоит проанализировать технологические решение: как построено облако, как реализована система резервирования и отказоустойчивости.

-следует изучить SLA. Как измеряется доступность? Есть ли гарантии по производительности? Отвечает ли провайдер за деградацию сервиса?

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