Обратный билет из облака. Когда имеет смысл возвращать нагрузки в собственный контур

Облако необходимо. Вопрос в том, что куда положить

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

Проблема в том, что желание держать свое у себя есть у многих, а возможность построить и поддерживать облако самостоятельно есть не у всех. И под возможностью я понимаю прежде всего компетенции. Людей, которые умеют развернуть платформу, считать ее экономику и поддерживать ее годами. Если таких специалистов в штате нет, остается вторая дорога, частное облако, которое эксплуатирует вендор.

Сам же спор про «облако или свое» кажется мне бесполезным. Эффективнее проверить каждую нагрузку по пяти критериям:

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

А еще дополнительно — готова ли компания оказывать сервис сама или эту часть разумнее отдать вендору? Начну с денег, потому что они обычно задают тон разговору.

Масштаб и предсказуемость нагрузки

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

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

Сравнение «сервер против виртуальной машины» здесь мало что дает. Я предпочитаю считать стоимость полезной работы, то есть делить все затраты на инфраструктуру за период на количество реально выполненных нагрузок. В затраты входят СХД, сеть, лицензии, электричество, охлаждение, дежурства, обновления и запас мощности. Условный пример. Компания купила контур под пик в 1000 единиц, а средняя загрузка держится на 350. Платит она за 1000, а полезную работу получает на 350. При высокой и ровной утилизации свой контур себя оправдывает, при скачущей стоимость полезной работы быстро растет.

У возврата нагрузок есть и вторая сторона. Все, что раньше жило в облаке, переезжает в собственную инсталляцию, и она быстро растет. Компании, которые строят облачную инфраструктуру сами, обычно собирают ее из компонентов открытого кода (open source), отдельно для виртуализации, хранения данных, сети и оркестрации. На пилоте такая сборка работает, но на большом масштабе далеко не каждый компонент ведет себя так же стабильно. К тому же лицензия у open source может быть бесплатной, а вот инженерные часы на обновления, совместимость версий и регресс стоят денег. Чем крупнее инсталляция, тем заметнее эта строка в бюджете. Снять ее можно, если вместо самостоятельной сборки взять готовую российскую облачную платформу.

Стратегическая критичность и катастрофоустойчивость

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

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

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

Наша Astra Cloud Platform может разворачивать и частные, и публичные облака. В случае аварии на одной площадке сервисы продолжают работать на других. Октябрьские события показали необходимость наличия «запасной» инфраструктуры.

Регуляторные требования

Еще один частый аргумент в пользу своего контура звучит как «так требует регулятор». Требования действительно влияют на выбор, только самостоятельное строительство регуляторика чаще усложняет, чем упрощает. Многое зависит от того, что именно предстоит защищать.

Сложнее всего с объектами КИИ. Для значимых объектов иностранное ПО под запретом, а переход на российские программные и аппаратные решения закреплен нормативно. Облако, собранное своими силами из открытого ПО, этим требованиям не соответствует. Значит, понадобятся отечественная платформа и оборудование, а также СЗИ/СКЗИ. Считать их стоит сразу, еще на этапе бизнес-кейса. Дополнительно все нужно заранее проектировать и защищать — без команды ИБ-специалистов этого сделать не получится.

Для государственных, медицинских и других информационных систем планку задают приказы ФСТЭК России №117 и №21. Своими силами путь к аттестату занимает больше года, ведь нужно составить модель угроз, подобрать сертифицированные средства защиты, написать регламенты и пройти испытания. Можно быстрее, если разместить систему в уже аттестованной инфраструктуре вендора. Мы в Astra Cloud предлагаем «Защищенное аттестованное облако», потому что знаем, сколько стоит проект по аттестации во временном и денежном эквиваленте.

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

Компетенции и сервисная модель

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

Компетенции под обеспечение сервиса можно растить годами, а можно взять у тех, кто этот путь уже прошел. Astra Cloud помогает заказчикам выстроить оптимальную модель потребления ресурсов, от развертывания облачной платформы и обучения команды до расчета экономики и поддержки. Причем неважно, будет ли это облако, гибрид или частный контур.

По факту получаем

Так что же выбрать? Ответ на вопрос из первой части статьи складывается из нескольких критериев.

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

«Своя рубаха ближе к телу», безусловно, но шить ее тоже надо уметь.