В прошлый раз я говорил о мифах при переносе ИТ-инфраструктуры в облако. И последний из них был о том, что далеко не всегда в облако вообще надо что-то переносить. На нём хочу остановиться подробнее, потому что здесь часто путают историю с «нам сложно организационно» и «нам это не нужно по техническим причинам».
Первая причина — кто-то уже успел купить железо. Очень часто бывает так, что в организацию приходит новый ИТ-директор и видит следующую картину: полгода назад его предшественник уже купил оборудование, оно ещё на поддержке и гарантии и будет работать года три стабильно. Естественно, в этой ситуации надо строить всё на нём просто по экономическим причинам.
Более сложная ситуация — это когда железо кто-то купил 20 лет назад (я сейчас не шучу), а оно ещё нужно. Точнее, нужно что-то, совместимое с ним. Я видел софт, который писался 15 лет назад, 20 лет назад и даже 25 лет назад. Тот, кто его писал, давно уже умер или не работает. А это, например, реестр в госструктуре на мейнфрейме или код банка, привязанный к микроинструкциям конкретной линейки процессоров или специфическим функциям ОС. Исходников нет. Документация только для эксплуатации. Если повезёт.
Так вот, если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте.
В общем, почти всё не x86 (включая современные IBM POWER) — это путь к собственной железной инфраструктуре или сложным гибридам, когда основные сервисы в своём серверном узле или дата-центре, а внешние «маркетинговые» — снаружи в облаке. Кстати, многим проектировщикам (особенно на VDI) нужны видеокарточки. Видеокарточки как раз в облаке есть, с ними проблем минимум. Проблемы с нестандартными ядрами и старыми ОС.
Следующая история привязки к имеющемуся оборудованию — это слияние-поглощение компаний. Представьте себе, что через месяц вы поглощаете компанию почти такого же размера, как ваша, только конкурента. Там есть своя ИТ-команда, свой ИТ-директор, своё железо и свои процессы. И они будут подчиняться вам. И всё это вместе через три месяца должно работать как одна система. Размер геморроя и запах горелых дедлайнов можете представить сами.
В этот момент вам достаётся много железа от другой информационной системы — и странно его выкидывать. Поэтому виртуализация часто откладывается и начинается интеграция.
Бравые сотрудники ИБ — это следующая причина того, что иногда не надо ехать в облако. Есть те, кто по регламенту ИБ вообще не может переезжать в виртуализованную среду, даже в частные облака. Есть те, кто может в теории, но это сложно и слишком смело. Речь в первую очередь про банки, потому что их стандарты безопасности писались довольно давно и частично привязаны к железу.
Например, в общении с одним крупным банком, а точнее, с его безопасниками, выяснилось следующее: банки и другие кредитные организации регулируются, в части защиты информации не только ФСБ и ФСТЭК, но и более значимым для них регулятором, которым является ЦБ РФ. Последний для них значительно более страшен, так как, если первые два выдают предписания и накладывают штрафы, то ЦБ РФ имеет более широкие полномочия. Так вот в регламенте ЦБ РФ, под аббревиатурой СТО БР, имеется положение, которое ставит под сомнение любую возможность размещение банков в облаках. Именно там сказано, что «Информация, содержащая банковскую тайну, должна размещаться на оборудовании, принадлежащем кредитной организации». То есть все, что содержит банковскую тайну должно размещаться на оборудовании банка, а это все бизнес-системы банка, которые составляют 90% от всех его ИТ. Получается, что только периферийные системы в минимальном объеме могут быть размещены в облаке. Есть смелые люди, которые трактуют условия, не дожидаясь разъяснения ЦБ или другого регулятора, но по факту на это мало кто решается. В открытых источниках есть информация о размещении в облаках некоторых банков. Например, Телекомерцбанк, всеми своими системами располагается в облаке, а также банк Открытие использует облака для части своих систем. И никаких проблем насколько известно у них не было. И все же для большинства таких предприятий ИТ не управляет требованиями (они приходят сверху), поэтому остаётся только одно — подчиняться.
Ещё более интересная ситуация в оборонной сфере. Там требования как раз можно выполнить и они довольно однозначные, но это исполнение обойдётся настолько дорого, что проще как раз построить свой дата-центр или серверный узел. Оборонные НИИ строят внутренние кластеры. Это в целом очень целесообразно — с учётом, что в облаке каждому сотруднику техподдержки, утрируя, пришлось бы прописывать допуск и невыезд лет на пять. Просто за то, что он обслуживает сервер, не видя в целом ничего, кроме его адреса. Секретность и гостайна — это вообще история не для публичных облаков.
Требования по ИБ касаются и вполне «гражданских» компаний, то есть коммерческого сектора. Ситуаций две:
- Требования устанавливает головная компания, например, в Европе, и филиалу в России остаётся только подчиниться. Какими бы тупыми ни были эти требования — они закон. И надо делать так, как там написано.
- Есть большая группа компаний, которая занимается чем-то важным. Например, добывает алмазы или плавит руду. У них есть очень жёсткие требования по ИБ. Внутри группы компаний есть куда более «приземлённые», например, кондитерское производство или какие-то простые магазины. Они наследуют эти требования по безопасности, поскольку для них отдельно никто ничего делать не будет. Остаётся только подчиниться. Опять же, какими бы тупыми ни были эти требования — они закон. И надо делать так, как там написано. Я знаю ситуацию, когда руководитель похожей компании не видел ИТ-директора холдинга никогда в жизни и работал от него в двух тысячах километров. Это нормально.
Ещё одна серьёзная причина не переходить в коммерческое облако — это масштабный сервис. Когда софт начинает чуть лучше работать на специфических виртуальных машинах с конкретным соотношением памяти к процессору, а ядер нужно при этом несколько тысяч или даже несколько десятков тысяч, лучше строить своё облако. Со всеми накладными расходами получится дешевле при определённом масштабе. Мы сейчас говорим про соцсети, поисковые машины, финансовые структуры и обо всём том, что само для себя разрабатывает прикладной уровень. Они максимально используют всё то, что они могут получить с оборудования. Они могут переписывать ОС для сетевых устройств и часто тестируют новые архитектуры. Никто в облаке делать такого не даст, естественно.
Последняя объективная причина для средних и крупных компаний не переходить в облако — это стоимость лицензий. Почему не касаюсь малых — у них либо нет такого прикладного ПО и СУБД, либо они используют бесплатные решения, либо просто воруют лицензии. Мы не знаем, поскольку дальше гипервизора не видим, что происходит на машинах облака.
Но есть вендоры, которые предъявляют требования к лицензированию, которые по факту просто блокируют использование их продуктов в облаке. Например, обязывают пользователя покупать отдельную лицензию на каждый физический процессов, который установлен в облаке провайдера.
Пример. Есть один сервак на 48 ядер. Вы даёте при настройке ВМ 8 ядер и собираетесь лицензироваться по ним. Вендор говорит: а давайте вы оплатите лицензию на все 48 ядер, а то вдруг решите расширить ВМ. Это было раньше. В облаках ещё интереснее: если там 100–200 серверов, а ядер 4 тысячи штук — платите за все. А то вдруг вы мигрируете с одного ядра на другое по ходу пьесы. Надо же и за него заплатить тоже!
Промежуточный вариант предлагает Microsoft, он требует от провайдера, чтобы мы платили за количество ядер, но клиенты потом могут свободно запускать на этих серверах любое количество виртуальных машин с ОС (то есть платим один раз), это существенно более реальная схема для провайдера. Тут принципиальная разница.
Теперь давайте перейдём к необъективным причинам.
Стереотипная корпоративная культура — это фактор «я не верю в облака». Когда это именно «я не верю», это необъективный фактор и скоро невидимая рука рынка заставит поверить. Другое дело, когда это требование службы СБ или регулятора либо головного офиса в Европе — это мы обсуждали выше. Тогда это объективный фактор, даже если вы лично с ним не хотите согласиться. Мы так и заканчиваем встречу: «Хорошо, давайте вернёмся к вопросу 22 марта 2021 года в 14:00. Запланируем встречу?»
Есть люди, которые бюджетируются только на капитальные затраты, без операционных. Это требование часто можно обойти, потому что можно купить облако как CAPEX, заплатив сразу за период. Даже есть целая куча внешних компаний, которые занимаются такими операциями для многих структур.
Госструктуры, кстати, часто говорят о разных статьях бюджета, но в реальности перераспределять средства между статьями возможно. Действительно, сложно, но возможно, если заняться этим заранее при планировании нового финансового года.
Иногда можно просто перераспределить бюджет — и всё будет хорошо. И чаще всего ИТ-директор этим управляет.
Кто-то столкнулся с облаком, которое плохо работает. У нас в России, например, есть одна крупная облачная структура, которая падает, как озимые, каждые два месяца. Люди их тысячу раз уже прокляли, но те продолжают заключать контракты и падать. Амазон тот же тоже падает из-за штормов на побережье США или молний в дата-центры, но предлагает много точек в разных географических местах. Мораль — надо выбирать правильного поставщика. Второй вопрос — многие ошибаются на архитектуре. Построить архитектуру сложно. Нужно резервироваться, тестироваться, нужно подходить к оценке рисков и критичные узлы многократно резервировать. Это требует профессионализма. Вот мой коллега из эксплуатации рассказывает, как это выглядит в реальном мире.
История простая: когда вы платёжный агрегатор и тысячи транзакций в сутки проходят через вас, а размещение только в одном регионе Амазона — возможно, кто-то идиот. Потому что простой сервиса грозит убытками за полгода и надо размещаться в двух разных облаках или хотя бы на двух точках Амазона. Есть модель рисков — с ней надо работать.
Многие верят, что сделают ЦОД, построят частное облако, будут перепродавать другим и окупят результаты. Серьёзно, я знаю пару примеров. Люди боятся на уровне маразма, что кто-то ворует их данные, что в облаке есть админы и они обязательно будут читать трафик и воровать данные.
Про админов уже разбирали: дальше гипервизора просто никто не видит. Если заела паранойя — шифруйте всё и не держите ключи шифрования на серверах облака. Мы просвещаем своих заказчиков относительно таких архитектур и рекомендуем их. Это, конечно, наложит издержки, но можно шифровать только критичное.
Самый большой страх здесь в том, что, когда суд попросит выгрузить данные, провайдер облака должен подчиниться. Это иногда случается. Ответ очень прост: если кто-то будет «кошмарить» ваш бизнес, то начнётся это не с ИТ. Начнётся с проверок, задержки товара и так далее. Если всё это перейдёт в сладкую стадию борьбы в ИТ — с отъёма оборудования. Приехать и забрать железный сервер куда проще, чем выгрузить данные из облака: люди, которые профильно этим занимаются, прекрасно осведомлены, что ряд современных технологий позволяет скрытым образом так или иначе искажать данные, выгружаемые с сервера на внешний носитель.
Что эффективнее — что главбуха посадят в КПЗ и он всех сдаст? Или что при обыске оборудование из офиса заберут? Или что заставят облачного провайдера через облако выдать? Практика показывает, что третий сценарий менее вероятен, чем первые два. В третьем ещё надо взаимодействовать с третьим юрлицом, делать официальные запросы и так далее. Опять же, есть шансы получить набор данных без ключей. И ещё одно: не бывает так, что заказчик не знает про выгрузку данных из облака. Если мы не говорим про форс-мажор на госуровне, то это же не просто письмо, а либо санкция суда, либо аргументированный запрос правоохранителей (и то только тех, кто имеют на это полномочия). И заказчик обычно в курсе, что такие вещи против него идут уже полгода. Просто представьте: нужно узнать, какие данные необходимы, где находятся, нужно добиться официального решения. Если заказчик не в курсе, это очень странная история. А сервер из офиса уже давно бы забрали.
В общем, при обсуждении инфраструктуры наша задача в том, чтобы разобраться, что мешает переезду. Если это объективная причина — «до встречи через 5 лет». Если нет — начинается работа психолога и финансиста. И ещё того парня, который отвечает за ликбезы про двадцать первый век — вот, например, пост про то, с какой неграмотностью мы сталкиваемся.
Автор: Никита Дергилёв
