Главная » Хабрахабр » Кому НЕ надо переезжать в облако и почему

Кому НЕ надо переезжать в облако и почему

И последний из них был о том, что далеко не всегда в облако вообще надо что-то переносить. В прошлый раз я говорил о мифах при переносе ИТ-инфраструктуры в облако. На нём хочу остановиться подробнее, потому что здесь часто путают историю с «нам сложно организационно» и «нам это не нужно по техническим причинам».

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

Я видел софт, который писался 15 лет назад, 20 лет назад и даже 25 лет назад. Более сложная ситуация — это когда железо кто-то купил 20 лет назад (я сейчас не шучу), а оно ещё нужно. Точнее, нужно что-то, совместимое с ним. А это, например, реестр в госструктуре на мейнфрейме или код банка, привязанный к микроинструкциям конкретной линейки процессоров или специфическим функциям ОС. Тот, кто его писал, давно уже умер или не работает. Документация только для эксплуатации. Исходников нет. Если повезёт.

Кстати, многим проектировщикам (особенно на VDI) нужны видеокарточки. Так вот, если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте.
В общем, почти всё не x86 (включая современные IBM POWER) — это путь к собственной железной инфраструктуре или сложным гибридам, когда основные сервисы в своём серверном узле или дата-центре, а внешние «маркетинговые» — снаружи в облаке. Проблемы с нестандартными ядрами и старыми ОС. Видеокарточки как раз в облаке есть, с ними проблем минимум.

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

Поэтому виртуализация часто откладывается и начинается интеграция. В этот момент вам достаётся много железа от другой информационной системы — и странно его выкидывать.

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

Последний для них значительно более страшен, так как, если первые два выдают предписания и накладывают штрафы, то ЦБ РФ имеет более широкие полномочия. Например, в общении с одним крупным банком, а точнее, с его безопасниками, выяснилось следующее: банки и другие кредитные организации регулируются, в части защиты информации не только ФСБ и ФСТЭК, но и более значимым для них регулятором, которым является ЦБ РФ. Именно там сказано, что «Информация, содержащая банковскую тайну, должна размещаться на оборудовании, принадлежащем кредитной организации». Так вот в регламенте ЦБ РФ, под аббревиатурой СТО БР, имеется положение, которое ставит под сомнение любую возможность размещение банков в облаках. Получается, что только периферийные системы в минимальном объеме могут быть размещены в облаке. То есть все, что содержит банковскую тайну должно размещаться на оборудовании банка, а это все бизнес-системы банка, которые составляют 90% от всех его ИТ. В открытых источниках есть информация о размещении в облаках некоторых банков. Есть смелые люди, которые трактуют условия, не дожидаясь разъяснения ЦБ или другого регулятора, но по факту на это мало кто решается. И никаких проблем насколько известно у них не было. Например, Телекомерцбанк, всеми своими системами располагается в облаке, а также банк Открытие использует облака для части своих систем. И все же для большинства таких предприятий ИТ не управляет требованиями (они приходят сверху), поэтому остаётся только одно — подчиняться.

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

Ситуаций две: Требования по ИБ касаются и вполне «гражданских» компаний, то есть коммерческого сектора.

  • Требования устанавливает головная компания, например, в Европе, и филиалу в России остаётся только подчиниться. Какими бы тупыми ни были эти требования — они закон. И надо делать так, как там написано.
  • Есть большая группа компаний, которая занимается чем-то важным. Например, добывает алмазы или плавит руду. У них есть очень жёсткие требования по ИБ. Внутри группы компаний есть куда более «приземлённые», например, кондитерское производство или какие-то простые магазины. Они наследуют эти требования по безопасности, поскольку для них отдельно никто ничего делать не будет. Остаётся только подчиниться. Опять же, какими бы тупыми ни были эти требования — они закон. И надо делать так, как там написано. Я знаю ситуацию, когда руководитель похожей компании не видел ИТ-директора холдинга никогда в жизни и работал от него в двух тысячах километров. Это нормально.

Ещё одна серьёзная причина не переходить в коммерческое облако — это масштабный сервис. Когда софт начинает чуть лучше работать на специфических виртуальных машинах с конкретным соотношением памяти к процессору, а ядер нужно при этом несколько тысяч или даже несколько десятков тысяч, лучше строить своё облако. Со всеми накладными расходами получится дешевле при определённом масштабе. Мы сейчас говорим про соцсети, поисковые машины, финансовые структуры и обо всём том, что само для себя разрабатывает прикладной уровень. Они максимально используют всё то, что они могут получить с оборудования. Они могут переписывать ОС для сетевых устройств и часто тестируют новые архитектуры. Никто в облаке делать такого не даст, естественно.

Мы не знаем, поскольку дальше гипервизора не видим, что происходит на машинах облака. Последняя объективная причина для средних и крупных компаний не переходить в облако — это стоимость лицензий. Почему не касаюсь малых — у них либо нет такого прикладного ПО и СУБД, либо они используют бесплатные решения, либо просто воруют лицензии.

Например, обязывают пользователя покупать отдельную лицензию на каждый физический процессор, который установлен в облаке провайдера. Но есть вендоры, которые предъявляют требования к лицензированию, которые по факту просто блокируют использование их продуктов в облаке.

Есть один сервак на 48 ядер. Пример. Вендор говорит: а давайте вы оплатите лицензию на все 48 ядер, а то вдруг решите расширить ВМ. Вы даёте при настройке ВМ 8 ядер и собираетесь лицензироваться по ним. В облаках ещё интереснее: если там 100–200 серверов, а ядер 4 тысячи штук — платите за все. Это было раньше. Надо же и за него заплатить тоже! А то вдруг вы мигрируете с одного ядра на другое по ходу пьесы.

Тут принципиальная разница. Промежуточный вариант предлагает Microsoft, он требует от провайдера, чтобы мы платили за количество ядер, но клиенты потом могут свободно запускать на этих серверах любое количество виртуальных машин с ОС (то есть платим один раз), это существенно более реальная схема для провайдера.

Теперь давайте перейдём к необъективным причинам.

Когда это именно «я не верю», это необъективный фактор и скоро невидимая рука рынка заставит поверить. Стереотипная корпоративная культура — это фактор «я не верю в облака». Тогда это объективный фактор, даже если вы лично с ним не хотите согласиться. Другое дело, когда это требование службы СБ или регулятора либо головного офиса в Европе — это мы обсуждали выше. Запланируем встречу?» Мы так и заканчиваем встречу: «Хорошо, давайте вернёмся к вопросу 22 марта 2021 года в 14:00.

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

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

И чаще всего ИТ-директор этим управляет. Иногда можно просто перераспределить бюджет — и всё будет хорошо.

Люди их тысячу раз уже прокляли, но те продолжают заключать контракты и падать. Кто-то столкнулся с облаком, которое плохо работает. У нас в России, например, есть одна крупная облачная структура, которая падает, как озимые, каждые два месяца. Мораль — надо выбирать правильного поставщика. Амазон тот же тоже падает из-за штормов на побережье США или молний в дата-центры, но предлагает много точек в разных географических местах. Построить архитектуру сложно. Второй вопрос — многие ошибаются на архитектуре. Это требует профессионализма. Нужно резервироваться, тестироваться, нужно подходить к оценке рисков и критичные узлы многократно резервировать. Вот мой коллега из эксплуатации рассказывает, как это выглядит в реальном мире.

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

Люди боятся на уровне маразма, что кто-то ворует их данные, что в облаке есть админы и они обязательно будут читать трафик и воровать данные. Многие верят, что сделают ЦОД, построят частное облако, будут перепродавать другим и окупят результаты. Серьёзно, я знаю пару примеров.

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

Это иногда случается. Самый большой страх здесь в том, что, когда суд попросит выгрузить данные, провайдер облака должен подчиниться. Начнётся с проверок, задержки товара и так далее. Ответ очень прост: если кто-то будет «кошмарить» ваш бизнес, то начнётся это не с ИТ. Приехать и забрать железный сервер куда проще, чем выгрузить данные из облака: люди, которые профильно этим занимаются, прекрасно осведомлены, что ряд современных технологий позволяет скрытым образом так или иначе искажать данные, выгружаемые с сервера на внешний носитель. Если всё это перейдёт в сладкую стадию борьбы в ИТ — с отъёма оборудования.

Или что при обыске оборудование из офиса заберут? Что эффективнее — что главбуха посадят в КПЗ и он всех сдаст? Практика показывает, что третий сценарий менее вероятен, чем первые два. Или что заставят облачного провайдера через облако выдать? Опять же, есть шансы получить набор данных без ключей. В третьем ещё надо взаимодействовать с третьим юрлицом, делать официальные запросы и так далее. Если мы не говорим про форс-мажор на госуровне, то это же не просто письмо, а либо санкция суда, либо аргументированный запрос правоохранителей (и то только тех, кто имеют на это полномочия). И ещё одно: не бывает так, что заказчик не знает про выгрузку данных из облака. Просто представьте: нужно узнать, какие данные необходимы, где находятся, нужно добиться официального решения. И заказчик обычно в курсе, что такие вещи против него идут уже полгода. А сервер из офиса уже давно бы забрали. Если заказчик не в курсе, это очень странная история.

Если это объективная причина — «до встречи через 5 лет». В общем, при обсуждении инфраструктуры наша задача в том, чтобы разобраться, что мешает переезду. И ещё того парня, который отвечает за ликбезы про двадцать первый век — вот, например, пост про то, с какой неграмотностью мы сталкиваемся. Если нет — начинается работа психолога и финансиста.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Будущее рабочих мест. Главное из отчета Всемирного экономического форума

Согласно отчёту Всемирного экономического форума The Future of the Jobs 2018 уже через четыре года 75 миллионов рабочих мест будут упразднены, но их заменят другие 133 млн. Но страх того, что «роботы заменят людей», все ещё не соответствует реальности. Формулировка ...

Полезные советы по использованию HyperLynx DDR Wizard для анализа QDR4

Quad Data Rate (QDR-IV) является стандартом высокопроизводительной памяти для сетевых применений и идеально подходит для нового поколения сетевых устройств, коммуникационного оборудования и вычислительных систем. Этот блок способен обработать все одноразрядные ошибки памяти, в том числе, вызванные космическими лучами и альфа-частицами. ...