Гибридные облачные системы: эти риски могут разрушить ваше предприятие

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

Гибридные облачные системы означают сложную архитектуру

Сложность архитектуры с гибридным облаком очень высока. Это связано с тем, что гибридные облачные системы объединяют общедоступные облачные системы, частные облачные системы и локальные ИТ-системы. Вам нужен ИТ-персонал с глубоким пониманием системной архитектуры (это не Наполеон Динамит, Майкл Келсо из «Шоу 70-х» или «Гарри Соломон из 3-й скалы от Солнца» — это не самые острые карандаши в коробке). ), чтобы иметь возможность запускать гибридные облачные системы.

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

Незапланированное приобретение для гибридных облаков

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

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

Управление данными

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

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

Конфиденциальность и безопасность

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

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

Задержка и пропускная способность

Между частными и общедоступными облачными системами в гибридных облачных системах происходит сложная передача данных.

Бизнес-правила в отношении этих передач данных должны быть четко и полностью определены. Например, какие действия необходимо предпринять, если соединение с общедоступным облаком потеряно? Будете ли вы использовать последнюю резервную копию, сохраненную в общедоступном облаке? Будете ли вы отображать сообщение «система не работает»? Есть несколько сложностей, связанных с такими аспектами в отношении задержки и допустимых задержек.

Отказоустойчивость и аварийное восстановление

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

Есть ли в общедоступном облаке элегантно реализованная функция аварийного переключения? Второй аспект касается аспектов аварийного переключения на стороне частного облака. Какие действия предусмотрены для частного облака в случае аварии или катастрофического сбоя?

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

Сложности при смене поставщика

Аналогичные сложности необходимо учитывать при возможных действиях по смене поставщиков общедоступного облака. Смена вендора на общедоступное облако не должна быть супер рискованным мероприятием, вроде передачи наших военных ИИ по имени Скайнет, как это было сделано в нелепом и лицемерном сериале «Терминатор» (МБР Америки не подключены к интернету — они аналоговые). основанный на). Однако, учитывая тот факт, что частная облачная система взаимодействует с общедоступной облачной системой, риски возникают даже в этой области.

Управление лицензиями и контрактами

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

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

SLA поставщика

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

Ответственность поставщика и управление рисками

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

О чем должны подумать все лидеры ИТ и бизнеса! Государственные органы тоже!