17 ноября в 13:00 по восточному времени США Ars Technica проведёт прямой эфир о том, как атаки дронов на дата-центры могут изменить привычную для бизнеса модель облачных сервисов. Для российских IT-команд это не экзотический сценарий из раздела физической безопасности: отказ площадки быстро превращается в проблему доступности приложений, данных, платежей и репутации.
Как сообщает Ars Technica, дискуссия будет посвящена последствиям ударов беспилотников по инфраструктуре дата-центров и тому, что это означает для жизни в облаке. Из опубликованного анонса не следуют подробности программы, состав участников или конкретные кейсы, поэтому заранее приписывать обсуждению выводы и рецепты было бы лишней журналистской бодростью.
Сам факт такой темы хорошо показывает сдвиг в восприятии облака. Долгое время его продавали прежде всего как способ не думать о «железе»: команда арендует мощности, провайдер отвечает за стойки, питание, сеть и резервирование. Но облачная абстракция не отменяет физический мир. У сервисов есть конкретные здания, вводы электропитания, каналы связи, системы охлаждения, маршруты доставки оборудования и люди, которые должны получить доступ на объект.
Для разработчика инцидент на площадке обычно выглядит буднично и неприятно: растёт задержка, не открывается база данных, срабатывают тайм-ауты, очередь сообщений не разгребается после восстановления. Для компании картина шире. Если критичный сервис размещён в одном регионе или зависит от одного поставщика идентификации, DNS, платежей либо доставки контента, повреждение физической инфраструктуры может затронуть даже те компоненты, которые формально находятся в другом дата-центре.
Именно поэтому разговор об атаках дронов на дата-центры не стоит сводить к вопросу о прочности стен. Важнее архитектура зависимостей. Резервная копия полезна лишь тогда, когда её можно восстановить в независимой среде; второй кластер мало спасает, если он использует ту же учётную запись, тот же канал администрирования или ту же контрольную плоскость. Мультиоблако тоже не работает по факту покупки второго контракта: его приходится проектировать, тестировать и поддерживать, а значит — платить не только деньгами, но и инженерным временем.
Практический вывод для IT-директоров и владельцев продуктов здесь довольно земной. Полезно заранее ответить на несколько неудобных вопросов: какие сервисы действительно нельзя останавливать; сколько времени бизнес переживёт без каждого из них; в каком регионе хранятся данные; кто и как переключает нагрузку; можно ли провести восстановление без доступа к основной площадке. Не менее важен регулярный тест этих ответов. Документ с красивой схемой отказоустойчивости не заменяет учения, на котором команда пытается поднять сервис из резервной копии и обнаруживает, что нужный ключ доступа лежит в недоступном секрет-хранилище.
Угроза физического воздействия меняет и язык переговоров с провайдерами. Вместо общего вопроса «у вас есть резервирование?» стоит разбирать границы ответственности: какие сценарии покрывает договор, как устроено географическое разделение, что происходит при недоступности сети или персонала, какие данные о сбое клиент получит и в какие сроки. Для стартапа это может означать более скромную задачу — не построить космический корабль из трёх облаков, а честно определить допустимый простой и автоматизировать восстановление самого ценного контура.
Прямой эфир Ars Technica интересен не обещанием готовой защиты, а правильно поставленным вопросом: облако остаётся удобным до тех пор, пока организация понимает, где заканчивается чужая инфраструктура и начинается её собственный риск. Чем заметнее становятся физические угрозы, тем меньше устойчивость будет зависеть от модного названия облачного тарифа и тем больше — от проверенной инженерной дисциплины.
