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



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

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

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

    Так вот, если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Техносерв

    79,00

    Компания

    Поделиться публикацией
    Комментарии 19
      –4
      Так вот, если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте.


      О, еще один сторонник платежных ядер на дельфи. А что будете делать, если любимый элемент инфраструктуры, написанный стадом баранов при царе Горохе, внезапно упадет?
        +4
        Так как раз не сторонник, сам понимаю и на опыте сталкивался с проблемами таких унаследованных архитектур. Но, к сожалению, переписать их на что-то современное заказчик часто не готов, и проект этот, действительно, не самый простой, требует и денег и времени. А что делать — срочно искать того, кто хоть что-то помнит про этот продукт и после устранения аварии снова идти к руководству за бюджетом на переписывание ПО ))
          +10
          О, еще один сторонник платежных ядер на дельфи.


          Дельфи — это еще очень современно, по сравнению с такой штукой, как COBOL. А вроде ядра крупнейших банков, типа того же ДжиПи, написаны на КОБОЛе. Или там процессинг… могу ошибаться, но я часто слышал за КОБОЛ в подобном контексте.

          написанный стадом баранов


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

            Вообще, не люблю подход — «все кто работал тут до меня — баран». Особенно, когда это делается безосновательно.
              0
              Visa с MC на мейнфреймах, а в куче российских банков RPG под AS/400.
                0

                Была статья на хабре про меинфреймы на COBOL'е. Но на практике сейчас это мало где встречается. Причем некоторые банки постсоветского пространства обгоняют в технологическом развитии европейские и американские. Сейчас много где уже Си и производные. Но дело осложняется тем, что для взаимодействия с платежными системами (мастеркард и виза, например), банк должен обладать программным обеспечением, которое сертифицировано у этих самых платежных систем (у более маленьких с требованиями попроще). И если процессинговое ядро лицензировано платежной системой (да хоть на COBOL'е), то просто так взять его и переписать — не возможно. Вернее переписать можно, но ПС откажутся работать до лицензирования нового ПО.

                0
                А вы что то против делфи имеете или просто за компанию поливаете начитавшись этих ваших интернетов?
                +4
                Прям интересно стало, что за падающая каждые два месяца крупная облачная структура.
                  0
                  Крок?
                  Говорят тут тёрли комментарии с жалобами в их блоге из-за «нарушения NDA», но всего один раз и довольно давно.
                  0
                  А еще роскомнадзор может заблокировать айпи ваших облаков и VPN.
                    +3
                    Что может РКН теперь знает весь рынок.
                    0
                    Ещё более интересная ситуация в оборонной сфере. Там требования как раз можно выполнить и они довольно однозначные, но это исполнение обойдётся настолько дорого, что проще как раз построить свой дата-центр или серверный узел.

                    Почему прямо не написать, что российские облака ещё не доросли до уровня Azure и AWS с «государственными регионами»?
                      +1
                      Многие провайдеры в России как раз с этого начинали. Посмотрите на ТОП-5 провайдеров в России, у каждого заявлен как минимум аттестованный сегмент. Плюс, конечно, все делают виртуальные частные облака. Сложного тут как раз ничего нет, моё личное мнение, нужно как раз вырастать в хороший автоматизированный публичный сервис, а не концентрироваться на гос. сегменте.

                      Другое дело, что в зависимости от классификации информации и модели угроз и действий нарушителя будет сильно меняется набор технических средств, которые придётся использовать в таком сегменте. И в этом случае, вы абсолютно правы. Ничего кардинально сложного нет, но с какого-то момента экономическая целесообразность вызывает вопросы.
                        0
                        Спасибо за пояснение, упустил момент с национальной криптографией.
                        Американским сервисам должно быть проще — бюджеты проектов отличаются на порядки и хотя бы часть инфраструктуры можно использовать для обычных клиенты.
                      +2
                      если кто-то говорит, что это можно взять, отреверсить и переписать на современном языке, — плюньте ему в лицо, наступите на спину и попрыгайте

                      А кто-нибудь знает подлинные истории успеха, когда сильные духом и богатые свободным временем чуваки взяли и переписали с условных перфокарт на условную Java нечто такое, что всем вокруг казалось вечным и непереписываемым в принципе? Место действия значения не имеет, но желательно чтобы история была хотя бы этого десятилетия.
                        0
                        Несколько лет назад я участвовал в проекте, когда в одну систему сводили несколько разных систем. В том числе замещали сравнительно старые системы, которые были разработаны ещё во времена MS DOS. По сути за три с лишним года просто написали всё заново. Сложно, долго, очень тяжело в процессе внедрения, когда замещаешь старые системы, но точно стоит того. Одна из самых сложных задач в этом процессе была — перенос и очистка старых данных в новую систему.
                          0
                          Так а с каким результатом-то в итоге прошла такая миграция? Вышли в большой плюс по освободившимся деньгам/времени/ресурсам или сейчас, спустя время, можно уверенно заявить, что оно того геморроя не стоило?
                            0
                            В конечном счёте стоило, так как развивать легаси уже физически не представлялось возможным. Но от хорошей жизни таким точно заниматься не будешь. То есть я бы точно в будущем не пошёл на такой проект из соображений «станет поудобнее» или «пора обновляться». Только если очень хорошая очевидная выгода по TCO, даже с учётом многократной перезакладки по рискам. Или если старую систему больше действительно невозможно поддерживать.
                        0
                        СТО БР
                        СТО БР ИББС, если конкретнее.

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое