Облако принято считать универсальным способом сделать инфраструктуру гибче и эффективнее. Но что если именно для вашей системы переход в облако окажется ошибкой? Обсуждаем с экспертами, где облако действительно даёт преимущество крупному бизнесу, а где лучше сохранить систему в своём контуре.
- 1. Введение
- 2. Переход крупного бизнеса в облако: риски или мифы
- 3. Доверие и партнёрство с провайдером
- 4. Преимущества и ограничения облачной инфраструктуры
- 5. Искусственный интеллект и облако
- 6. Отказоустойчивость и георезервирование
- 7. Регуляторика и облако
- 8. Выводы
Введение
О взаимодействии между облачным провайдером и бизнесом во время инцидентов мы уже поговорили: разобрали, что происходит при сбое сервиса, как распределяются зоны ответственности и что должно быть закреплено в договоре. Отдельно обсудили, как выбирать облачного провайдера — на какие критерии смотреть и что влияет на надёжность его сервисов.
Поговорим теперь о том, как крупный бизнес выбирает модель инфраструктуры. Где облачный провайдер и энтерпрайз находят точки соприкосновения, а где диалог невозможен? Что действительно мешает договориться, а что существует только в виде стереотипов?
Рисунок 1. Участники подкаста AM Live
В подкасте на площадке AM Live приняли участие:
- Светлана Старостина, руководитель инфраструктуры «ДОМ.РФ Банка». Более 25 лет в информационных технологиях (ИТ). Руководила командами численностью в 800 человек. Занималась миграцией систем, построением георезервирования. Работала с критически значимыми банковскими системами, проходила аудиты, в том числе Банка России. В её энтерпрайз-практике было всегда не менее трёх площадок. Проект Светланы по внедрению инфраструктуры виртуальных рабочих столов (VDI) получил премию Global CIO.
- Станислав Попов, директор по развитию облачных и инфраструктурных продуктов «МегаФона ПроБизнес». В сфере облачной инфраструктуры — 13 лет. Ранее работал в IBS и «Ростелекоме», имеет в своём портфеле более 30 продуктов и свыше 50 долгосрочных энтерпрайз-проектов для финансового сектора, ретейла, энергетики и добывающей промышленности.
Ведущая и модератор эфира — Олеся Афанасьева, генеральный продюсер и специальный корреспондент «АМ Медиа».
Переход крупного бизнеса в облако: риски или мифы
Для крупного бизнеса выбор между облаком и собственной инфраструктурой зависит от требований к безопасности. Для компаний, работающих с государственными структурами, эти требования могут быть строже. Но и частному бизнесу приходится учитывать риски, если в облако переносятся важные данные или критически значимые системы. В таких случаях последствия сбоя или потери данных могут оказаться серьёзнее возможной экономии.
Компании опасаются следующих сценариев:
- утечки конфиденциальных данных из облачной инфраструктуры;
- потери или повреждения данных из-за сбоя, ошибки или некорректной настройки;
- недоступности облачной инфраструктуры, из-за чего останавливаются критически значимые для бизнеса процессы;
- потери контроля над инфраструктурой после её передачи внешнему провайдеру.
Последний пункт особенно важен. При переходе в облако часть инфраструктуры выходит из-под прямого контроля компании. Поэтому возникает вопрос: действительно ли вместе с этим бизнес получает дополнительные риски или меняется только способ управления ими?
Станислав Попов отметил, что такая ситуация была на рынке 15 лет назад. Тогда переход в облако действительно мог восприниматься как обмен капитальных затрат на дополнительные риски. Компания экономила на собственной инфраструктуре, но не всегда могла получить сопоставимый уровень контроля и защиты. За последние годы требования к облачным провайдерам заметно выросли. Теперь от них требуется учитывать интересы сразу нескольких сторон: обеспечивать уровень защиты, которого ожидает заказчик, соблюдать требования регуляторов и отвечать за качество и безопасность собственных сервисов.
Это повлияло на объём ресурсов, которые провайдеры вкладывают в инфраструктуру:
- георезервирование и отказоустойчивость;
- необходимый уровень защиты данных;
- контроль и предотвращение утечек;
- выполнение требований регуляторов;
- постоянный контроль качества и доступности сервисов.
Поэтому сегодня сам факт размещения инфраструктуры у внешнего провайдера ещё не говорит о том, что уровень риска выше.
Особенности работы с облаком
Светлана Старостина вспомнила историю знакомства с центром обработки данных (ЦОД) одного облачного провайдера. Выяснилось, что часть его инфраструктуры не имела дизель-генераторов. Использовалась другая схема защиты, которую считали достаточной. Эта информация была опубликована на сайте провайдера. Позже на одном из объектов одновременно отключились две питающие подстанции. Простой составил около трёх часов, а полное восстановление заняло примерно сутки. Провайдер ссылался на то, что сервисы были георезервированы, но клиентам необходимо было самостоятельно использовать мультизональную защиту.
Этот случай показал важную особенность работы с облачной инфраструктурой. Провайдер может серьёзно относиться к безопасности данных, резервированию и предотвращению утечек, но отдельные решения в архитектуре всё равно могут не совпадать с ожиданиями заказчика. Поэтому при выборе облака недостаточно оценивать только заявленный уровень защиты или условия компенсации за простой.
Почему часть систем остаётся в собственном контуре
Наличие рисков не означает, что крупный бизнес отказывается от облаков. Компании могут распределять системы между собственным контуром и облачной инфраструктурой в зависимости от требований к ним. Критически важные системы и данные оставляют в собственном контуре, а менее чувствительные задачи переносят в облако. На такое распределение влияют регуляторные требования, стоимость инфраструктуры, требования к производительности и доступности систем.
Регуляторные ограничения. В некоторых отраслях требования к хранению и обработке данных ограничивают возможность передавать отдельные системы внешнему оператору. При этом перечень таких ограничений постепенно сокращается. То, что несколько лет назад нельзя было разместить в облаке, сегодня уже доступно. Например, появились облака аттестованные и с сертифицированными средствами защиты информации (СЗИ), что расширило возможности размещения систем в облачной инфраструктуре.
Экономия. Стоимость облака часто сравнивают с ценой собственного оборудования на горизонте пяти или семи лет. Но такое сравнение не учитывает все расходы на собственную инфраструктуру. Оборудование нужно эксплуатировать, обновлять и обслуживать. Необходимы специалисты, которые занимаются серверами, виртуализацией и прикладными системами. Эти расходы возникают на протяжении всего срока эксплуатации и должны учитываться при расчёте стоимости владения.
Стоимость облака зависит от того, сколько задач компания передаёт провайдеру. Если провайдер предоставляет только вычислительные ресурсы и хранилище, часть работы по настройке и обслуживанию остаётся на стороне компании. Готовые платформы и приложения стоят дороже, но требуют меньше собственных ресурсов для управления. Например, при стабильной и постоянно высокой нагрузке владеть собственным оборудованием может быть экономически оправданно для компании. Если же нагрузка меняется и инфраструктуру приходится регулярно расширять или сокращать, преимущество на стороне облаков.
Контроль. Если часть функций передаётся провайдеру, компания уже не может самостоятельно контролировать все процессы. При этом она всё равно отвечает за результат и должна учитывать, как провайдер организует работу инфраструктуры.
Технические ограничения. Инфраструктура крупных компаний складывается годами и включает в себя самые разные системы. Современные микросервисы, контейнеры и DevOps-процессы могут соседствовать со специализированным оборудованием и приложениями, для которых нет облачной замены.
«Поэтому сейчас не всё из того, что есть у крупного бизнеса, можно перенести в облако. Но этот список постепенно расширяется: то, что ещё несколько лет назад не могло переехать, сегодня уже вполне может там работать», — говорит Светлана Старостина.
Светлана Старостина, руководитель инфраструктуры «ДОМ.РФ Банка»
Доверие и партнёрство с провайдером
Культура управления изменениями и инцидентами, разбор причин сбоев — всё это внутренние процессы провайдера. Заказчик не видит эти процессы изнутри и не может управлять ими так же, как собственной инфраструктурой. Поэтому при выборе поставщика ему приходится разбираться, как организована эта работа.
Крупный бизнес всё чаще запрашивает такую информацию ещё до заключения договора. Провайдер описывает применяемые методологии и регламенты, порядок действий в разных ситуациях, зоны ответственности сотрудников. По этим данным заказчик может оценить, насколько организация сервиса соответствует его требованиям. На этом же этапе происходит знакомство с сервисной командой: специалистами, которые отвечают за обслуживание и взаимодействие с клиентом. Они рассказывают о своём опыте и подходах к работе. Раньше такое знакомство часто происходило уже после заключения договора, когда сервис переходил к провайдеру.
Открытость этих процессов не означает, что провайдер исключает все возможные сбои. Ошибка при изменении конфигурации, недостаточное тестирование или проблема во взаимодействии сотрудников может привести к остановке сервиса. Поэтому заказчику важно понимать не только устройство инфраструктуры, но и порядок действий при возникновении проблем.
Для критически важных услуг крупные компании могут привлекать внешних поставщиков, если самостоятельно обеспечивать их нецелесообразно. Например, вместо строительства собственных оптоволоконных линий компания может арендовать их у операторов связи. При этом компания выбирает двух разных провайдеров и проверяет, чтобы их маршруты не зависели от одной и той же инфраструктуры. Но и здесь полностью исключить одновременный сбой всё равно нельзя. Можно подключить и третьего провайдера, но тогда затраты на резервирование начинают заметно расти. Поэтому компания ищет баланс между уровнем отказоустойчивости и стоимостью такой схемы.
Так формируется более практичный подход к доверию: компания не предполагает, что у провайдера не бывает ошибок, а заранее оценивает, как он работает с ними. Чем выше цена простоя, тем больше внимания уделяется этим вопросам ещё до начала сотрудничества.
Преимущества и ограничения облачной инфраструктуры
Облачная инфраструктура даёт компании больше свободы при выборе и тестировании новых технологий:
- Быстрый запуск тестовых проектов. Не требуется заранее закупать оборудование и разворачивать собственную инфраструктуру.
- Снижение затрат на эксперименты. Компания может проверить технологию до закупки оборудования и программного обеспечения.
- Доступ к новым технологиям. Провайдер самостоятельно обновляет инфраструктуру и добавляет новые сервисы.
- Доступ ко внешней экспертизе. Компании не нужно формировать отдельную команду под каждую новую технологию.
- Быстрая замена решений. Если технология не подходит, её можно заменить без длительной перестройки собственной ИТ-среды.
Свобода выбора новых технологий в облаке зависит от требований импортозамещения. Зарубежные решения могут быть интересны крупному бизнесу, но компания не всегда может использовать их в своей инфраструктуре.
Один из примеров — использование искусственного интеллекта (ИИ). Технологии в этой области быстро развиваются, а содержание собственных моделей требует вычислительных ресурсов. В отдельных государственных организациях закупка оборудования для ИИ ограничена требованиями к происхождению техники и программного обеспечения. В этих случаях облачный провайдер может предоставить необходимые вычислительные ресурсы без самостоятельной закупки оборудования или же сами ИИ-сервисы. В результате компания получит доступ к новым технологиям без расширения инфраструктуры, а провайдер будет обновлять вычислительные ресурсы и сервисы по мере развития технологий.
Зеркальный взгляд на облака
Ведущая подкаста Олеся Афанасьева предложила участникам поменяться местами: посмотреть на облачную модель с позиций друг друга и назвать самый сильный аргумент второй стороны.
Крупный бизнес. Станислав, поставив себя на место крупного бизнеса, отметил, что одним из сильных аргументов против перехода в облако является потеря контроля над инфраструктурой. Часть работ выполняют специалисты провайдера, на которых компания не может влиять так же, как на собственных сотрудников. Если проблема связана с их действиями, внутри компании проще изменить процессы, распределить роли или усилить контроль. При работе с провайдером таких возможностей меньше. Поэтому первый критерий при выборе облака — безопасность.
Риск также можно снизить за счёт более тесного взаимодействия с провайдером. В отношениях «покупатель — поставщик» компания получает готовую услугу и не всегда понимает, как провайдер организует работу с её инфраструктурой. В партнёрской модели провайдер лучше знает бизнес компании, её ИТ-ландшафт и причины использования конкретных сервисов. За счёт этого взаимодействие становится более прозрачным, а компании будет проще понимать, как проходит работа с её инфраструктурой.
Провайдер. Светлана, рассматривая ситуацию со стороны провайдера, назвала два сильных аргумента Станислава: наличие собственной лаборатории исследований и разработок (R&D) и скорость внедрения. Второй аргумент важен не во всех случаях, но там, где инфраструктурные задачи нужно решать оперативно, провайдер может сделать это быстрее, чем компания при самостоятельном управлении.
Искусственный интеллект и облако
ИИ уже используется в бизнесе, но проекты, которые дают реальный бизнес-эффект, если верить экспертам, чаще остаются в контуре компании. Для обучения модели нужен большой массив данных, который обычно находится внутри. Переносить такие данные в облако только ради обучения готовы не все.
Со временем эта ситуация может измениться, и тогда часть ИИ-задач будет переходить к сервис-провайдерам.
- Первая причина — стоимость оборудования. Для большинства компаний закупка необходимого объёма вычислительных ресурсов слишком дорога. Исключением могут быть компании, которые способны самостоятельно инвестировать в такую инфраструктуру. Для сервис-провайдеров ИИ, в свою очередь, становится новым крупным рынком.
- Вторая причина — высокая скорость развития ИИ-технологий. Новые модели и результаты тестов появляются постоянно, поэтому выбранная сегодня технология через несколько месяцев может уступить другой. Компания рискует потратить время, деньги и вычислительные ресурсы на обучение модели, которая вскоре окажется менее эффективной. Из-за этого выбор технологии становится отдельной задачей.
Сервис-провайдеры постепенно могут превращаться в своего рода маркетплейсы ИИ-технологий. В личном кабинете заказчик сможет выбирать разные модели, базы данных, Kubernetes и другие сервисы в зависимости от своих задач. Это позволит менять используемые технологии без необходимости самостоятельно закупать под них инфраструктуру. Ведь часть моделей, доступных сегодня, через несколько месяцев может исчезнуть.
На развитие рынка влияет и регулирование: требования к персональным данным, государственным информационным системам, критической информационной инфраструктуре и ИИ меняются. Сервис-провайдерам придётся адаптировать свои услуги к новым требованиям. По мере развития ИИ они могут занять более значимую роль на этом рынке. Их преимущество будет связано с доступом к вычислительным ресурсам, возможностью быстро менять набор предлагаемых технологий и способностью адаптироваться к изменениям рынка и регулирования.
Но, как советует Станислав Попов, внедрять ИИ сейчас стоит осознанно и с пониманием ожидаемого бизнес-эффекта. Часть компаний рассматривает такие проекты как способ не отстать от рынка или выполнить формальные требования, но после внедрения измеримый экономический эффект удаётся получить далеко не всегда.
«Реальных кейсов, где ИИ даёт заметный бизнес-эффект, который можно измерить в деньгах, пока немного. Даже заявленные показатели экономии требуют осторожной оценки. Иногда расчёты используют для публичных коммуникаций, например заявляя об экономии нескольких миллионов рублей за счёт сокращения затрат на персонал. Такие цифры могут быть неточными или не отражать реальный экономический эффект от внедрения», — считает эксперт.
Станислав Попов, директор по развитию облачных и инфраструктурных продуктов «МегаФона ПроБизнес»
Светлана Старостина отметила, что при оценке эффекта от внедрения ИИ чаще говорят о генеративном искусственном интеллекте. В России есть много кейсов применения других технологий ИИ, например машинного зрения. Такие решения используются в разных отраслях и дают измеримый эффект. Например, в компании «ДОМ.РФ Банк» они применяются для контроля за строительством. Система позволяет отслеживать ход работ и выявлять отклонения от плановых показателей без постоянного участия сотрудников. Это сокращает время, которое сотрудники тратят на контроль строительства.
Олеся Афанасьева вспомнила, как в одной агрофирме директор по информационной безопасности (CISO) обратил внимание на данные, которые собирались с помощью систем видеонаблюдения для задач безопасности. Система фиксировала, например, находится ли охранник на месте и что он делает, а также другие процессы: сколько машин загружено зерном и сколько времени они находятся в пути. Он увидел, что эти данные можно использовать для задач маркетинга. Этот пример показывает, что экономический эффект от ИИ может возникать не только в рамках первоначальной задачи, для которой технологию внедряли.
Отказоустойчивость и георезервирование
Участники подкаста привели два случая, показывающих, как проблемы у провайдера или его партнёров могут повлиять на доступность сервисов.
- Первый кейс связан со сбоем биллинга у крупного российского облачного провайдера. Биллинг начал работать некорректно и списывать с клиентов лишние средства. В результате возникли проблемы с оплатой, хотя сама инфраструктура продолжала работать. Этот случай показывает, что отказоустойчивость зависит не только от состояния самой инфраструктуры.
- Второй случай произошёл с российским хостинг-провайдером, который выступал субпровайдером у более крупного игрока. У клиента было несколько виртуальных серверов, которые внезапно стали недоступны. Причиной стало решение зарубежного дата-центра отключить серверы, связанные с российским провайдером. Клиент не получил своевременной информации от поддержки и узнал о произошедшем из новостей.
Оба примера показывают, что ЦОДы сами по себе остаются уязвимыми объектами с точки зрения инженерной инфраструктуры. При проектировании старых объектов многие из сегодняшних рисков трудно было предвидеть. Крупные операторы ЦОДов учитывают эти риски и принимают дополнительные меры для защиты инфраструктуры: резервирование на разных уровнях вплоть до ручного запуска резервного оборудования. Но полностью исключить отказ невозможно.
Количество публичных инцидентов в облачных сервисах не обязательно означает, что они происходят чаще, чем в частной инфраструктуре. Облачные сервисы просто более заметны: у них много клиентов, а любой серьёзный сбой затрагивает сразу большое количество организаций. Поэтому такие инциденты получают больше огласки и быстрее становятся известны рынку.
Отказоустойчивость связана не только с предотвращением сбоев, но и со скоростью восстановления после них. Тестирование аварийного восстановления (disaster recovery, DR) позволяет эмулировать сбои, проверить работу собственной инфраструктуры и цепочки поставщиков. В идеальном варианте в такие проверки включают и клиентов, чтобы протестировать весь путь сервиса до пользователя. Если резерв ни разу не проверяли на практике, его наличие на схеме ещё не означает, что он действительно работает.
Сервис-провайдеры исторически развивали такие практики: от резервных копий и отдельных систем хранения до репликации и георезервирования. Для сервисов, которые должны работать 24×7, резервирование между разными ЦОДами становится базовым требованием. Благодаря этому часть сбоев пользователи вообще не замечают: отказ одного элемента компенсируется резервным. Поэтому оценивать отказоустойчивость стоит по тому, влияет ли сбой на бизнес. Отдельные технические сбои неизбежны; задача провайдера — сделать так, чтобы они не нарушали работу клиента, отметил Станислав Попов.
Регуляторика и облако
В финансовом секторе регулирование пока скорее сдерживает передачу критически важных процессов в облако. Требования Банка России предусматривают, что передача таких процессов на аутсорсинг требует отдельной оценки рисков и соблюдения специальных условий. При этом организация сама определяет, какие операции и процессы для неё являются критически важными.
Это не означает полного запрета на использование облаков. Некоторые облачные провайдеры подтверждают соответствие своей инфраструктуры требованиям серии ГОСТ Р 57580, что может упростить выполнение части требований финансовой организацией. Возможность переноса конкретного процесса в облако зависит от его характера, обрабатываемых данных и применимых регуляторных требований. При этом подтверждённое соответствие инфраструктуры установленным требованиям не снимает ответственности с самой организации. Если в облаке размещаются персональные данные, системы КИИ или другие регулируемые информационные системы, заказчик продолжает отвечать за соблюдение предъявляемых к ним требований.
По оценке экспертов, провайдер может взять на себя значительную часть работы — около 80 %: предоставить подготовленную инфраструктуру, СЗИ и необходимые документы. Организации остаётся настроить собственную часть защиты и выполнить относящиеся к ней требования регулятора. Для компаний из отраслей, которые только начинают подпадать под требования в области ИБ, такая модель может быть особенно удобной. Вместо самостоятельного создания инфраструктуры и найма специалистов они могут использовать облачную инфраструктуру, соответствие которой необходимым требованиям уже подтверждено. Чем больше отраслей будет подпадать под регулирование, тем более востребованным может становиться такой подход.
Существуют и области, которые пока недостаточно чётко урегулированы. В финансовом секторе, например, остаются вопросы о возможности размещения в облаке отдельных видов данных, в том числе связанных с банковской тайной. В подобных ситуациях крупные компании обычно выбирают консервативный подход и до получения дополнительных разъяснений могут отказываться от размещения таких данных в облаке.
Выводы
Обсуждение показало, что универсального ответа на вопрос о выборе между собственной инфраструктурой, облаком и гибридной моделью нет. Для систем с непредсказуемым спросом или сезонными пиками облако может быть более рациональным вариантом: ресурсы можно увеличивать по мере необходимости и при этом не содержать собственные мощности, которые большую часть времени будут простаивать. Для критически важных систем, тесно связанных с внутренними данными, напротив, участники обсуждения рекомендуют сохранять инфраструктуру в собственном контуре.
Отдельно стоит учитывать резервирование. Если основная система работает на собственной инфраструктуре и при отказе её нужно быстро восстановить, резервная площадка должна максимально соответствовать основной. Если же система уже размещена в облаке, резерв можно организовать в другом ЦОДе. Поэтому выбор модели инфраструктуры определяется не самим типом размещения, а конкретными требованиями системы, данными, характером нагрузки и сценарием восстановления после отказа.
