Каждый день мы слышим о приостановке или прекращении деятельности ИТ-компаний на территории Российской Федерации. Особенность сегодняшней ситуации в том, что с рынка уходит энтерпрайз, то есть те, кто обслуживает крупные компании, государственный сектор и так далее. Среди них уже есть или в любой момент могут оказаться и крупнейшие облачные провайдеры – Microsoft Azure, AWS, GCP и другие.
В недавней статье, посвященной спасению ИТ-инфраструктуры в кризис (и написанной еще до ухода некоторых компаний), мы среди прочего говорили о важности перехода на российскую облачную инфраструктуру. Сегодня мы подробнее поговорим о рисках, связанных с хранением данных и работой приложений в инфраструктуре, и разберем некоторые конкретные сценарии действий.
Если у вас on-premise инфраструктура
Допустим, вы используете собственную инфраструктуру и вас никак не касаются проблемы иностранных компаний. В этом случае вы (или ваш поставщик) всё равно покупаете оборудование и комплектующие за рубежом, что делает вашу инфраструктуру уязвимой уже в среднесрочной перспективе.
Основной риск: ваш поставщик не сможет выполнить гарантийные обязательства/обязательства по SLA
Даже если у вас в контракте прописано, что вы получаете обновление оборудования и комплектующих раз в N времени или обслуживаете его по гарантии, рассчитывать на это не стоит. Провайдер заплатит штраф (если ему не удастся признать будущую ситуацию на рынке и в стране форс-мажором) и понесет репутационные риски, но не сможет предоставить вам то, что нужно, так как не сможет это получить. Если у вас контракт с компанией, которая поддержала санкции (например, Dell, HPE, Cisco и т.д), они не дадут вам запчасти, даже если они у них есть.
Решение
Миграция в облако. Еще недавно мы рекомендовали «закупить самостоятельно всё, что только можно, хотя бы расходники», но по недавним данным всё, что можно было купить, уже купили. Поэтому экономически целесообразнее может быть сразу начать переход в облако. Про особеннности размещения в облаке мы еще поговорим, но сейчас важно отметить, что нужно выбирать кого-то из крупнейших провайдеров, т.к. маленькие и средние могут оказаться в том же положении, что и вы, из-за перебоев с поставками и отсутствия обновлений.
Надеяться на аренду оборудования также не следует: это только отодвигает неизбежный исход и увеличивает количество бессмысленных телодвижений.
Риск №2: Ваше «железо» может быть отключено
Оборудование, связанное с некоторыми производителями (например, CISCO), может просто перестать работать, если лицензия на ПО прекращает действовать по истечении срока.
Есть очень маленькая вероятность того, что во время очередного обновления производитель ограничит функциональность частично или полностью, это довольно серьезный шаг, пока никто так не делал, однако исключать это нельзя.
Решение
Рассмотреть оборудование поставщиков из стран, которые не вводят санкции. Например, Huawei (whatever).
Риск №3: Ваша система станет уязвимой без обновлений
Как мы помним, обновления нужны не только для того, чтобы что-то было быстрее, выше и сильнее, но и для того, чтобы исправлять проблемы и защищать вас от вновь выявленных угроз. Даже если вас никто не отключает через backdoor, а лицензия действует, через полгода без обновлений может накопиться серьезное количество критичных уязвимостей.
Решение
см. предыдущие пункты.
Если у вас Azure/AWS/GCP/другое облако от иностранного гиперскейлера
Основной риск: внезапное прекращение работы
Несмотря на то, что пока что (по состоянию на 17 марта) все гиперскейлеры работают, никто не гарантирует, что это не закончится завтра и достаточно внезапно для того, чтобы не успеть сделать всё правильно. Ждать нет смысла, совсем.
Что с этим делать
Если у вас там файлы – сделайте локальную реплику и следите за её обновлением. Если там бэкапы – можно оставить, но обязательно организуйте вторую площадку для хранения бэкапов где угодно в РФ (у крупного провайдера, который никуда не исчезнет). Сделайте бэкапы, попробуйте восстановиться, проверьте данные после восстановления.
Если у вас там виртуальные машины – подготовьте локальную инфраструктуру для переноса (есть много разных вариантов: от бэкапа всех машин и разворота локально до бэкапа данных и разворота в пустую машину локально). Проверяйте, что у вас получилось.
Коротко: если у вас есть протестированный и уже развернутый DR-сетап в российском облаке и/или есть вторая площадка, в которую вы можете мигрировать, вы молодец, если нет, срочно исправляйте.
Риск №2: отключение от дополнительных сервисов
Одним из приятных преимуществ пользования AWS и Azure было наличие огромного количества дополнительных сервисов (у AWS их около 260), которые в большинстве своем не имеют аналогов у российских провайдеров (у российских провайдеров их значительно меньше – правда, нельзя исключать, что они начнут активно восполнять эти пробелы сейчас).
Если эти сервисы играют значительную роль в ваших процессах, вам пора думать, как с наименьшими потерями от них отказаться.
Риск №3: что-то проверенное пойдет не так
Не полагайтесь на бэкапы, как на единственное решение проблемы с восстановлением данных. Для критичных систем этого мало, нужно продумывать DR-сценарии и регулярно тестировать их. Требования к DR-решению могут отличаться в зависимости от бизнес-задач.
Как мы говорили, даже если вы не уходите от зарубежного гиперскейлера «прямо сегодня», озаботьтесь тем, чтобы ваш DR у российского провайдера работал.
Если у вас есть зарубежные каналы передачи данных
Риск: проблемы с сетью
Если у вашей компании есть зарубежные филиалы и вы зависите от них с точки зрения топологии сети, если фаерволы, DNS-сервера или другие ключевые узлы сети находятся вне периметра РФ, вы можете столкнуться с серьезными проблемами с вашей сетью (в случае физической изоляции российского сегмента интернета).
Отдельно нужно сказать, что, если у вас иностранный провайдер, вы можете столкнуться с такой же проблемой.
Что с этим делать
Создайте резервное решение или измените архитектуру. То же самое работает и в случае, если у вас иностранный провайдер.
Дисклеймер
Переход в облако – не приговор не подразумевает «пожизненного контракта». В отличие от покупки физических серверов, вам не нужно ждать условных четырех лет, чтобы они отработали своё, и мучиться, если этот вариант вам не подходит.
Можно пробовать мигрировать, если не получилось, возвращаться, работать над ошибками и пробовать снова. Нужно изначально делать миграции по частям (имеются в виду итерационные изменения, рассчитанные на относительно небольшие части ИТ-ландшафта)
Такой подход (особенно в сочетании со speed over perfection) позволит получить быстрый результат за короткий промежуток времени и при правильном выборе целевого приложения для миграции получить измеримую выгоду – или с финансовой, или с технологической точек зрения.
Мы не можем давать рекомендаций по выбору провайдера или типа миграции в облако: каждый случай индивидуален, и пока что на этот выбор не влияет текущая ситуация. Если у вас есть решение, позволяющее вам использовать локальные ресурсы в РФ, будь то интернет-провайдер или приватное/публичное/гибридное облако, вам не нужно ничего перепридумывать. Разумеется, невозможно с точностью предсказать, что будет завтра, но мы планируем выпускать новые материалы по мере получения новых вводных.
Кстати, если у вас есть, что добавить, пишите комментарии здесь или задавайте вопросы в telegram-канале, если информации было недостаточно!
