Лидеры мнений

Супербоул: Плейбук по резервированию облачных вычислений

mm
Добавьте Unite.AI в избранные источники в Google

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

Есть немногие области, где это более верно, чем в облаке. Будь то AWS, поддерживающий стриминг Peacock или операции команды Seattle Seahawks – или, например, Google Cloud, поддерживающий Олимпийские игры 2028 года или Microsoft Azure, обеспечивающий работу Премьер-лиги – облако имеет решающее значение для проведения любого крупного спортивного события.

Если ваша компания участвует в какой-либо активности, связанной с Супербоулом в 2026 году, вы, скорее всего, уже подумали о плане облачных вычислений на день игры (и если вы этого не сделали, то, скорее всего, уже слишком поздно). Но если вы рассматриваете возможность участия в Супербоуле 2027 года или просто хотите улучшить свои облачные вычисления, эта статья для вас.

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

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

Первый удар: Основы облачных вычислений

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

Но в то же время ясно, что любая основная инфраструктура может выйти из строя – даже в критические моменты, когда, можно предположить, провайдеры инфраструктуры работают сверхурочно, чтобы обеспечить идеальную работу. Помните (не связанный с облаком) крах Coinbase в 2022 году или проблему с электроснабжением на Супербоуле в 2013 году? Или, если говорить об облачных вычислениях, вспомните, что крупный простой Azure в прошлом году произошел за несколько часов до запланированного выпуска квартальных отчетов в октябре прошлого года.

Иными словами: предполагайте, что ваш провайдер облачных вычислений будет работать хорошо в эту субботу – но всегда готовьтесь к худшему. И с учетом этого давайте рассмотрим две основные проблемы, которые вызывают большинство проблем с облачными вычислениями.

Наплыв данных: Обработка беспрецедентного объема

Облака поддерживают операции Супербоула, где требования к данным никогда не были выше. Например, в прошлом году FOX поделился информацией, что для поддержки прямой трансляции Супербоул 2025 года сервисы потокового вещания доставили контент 15,5 миллионам пиковых одновременных зрителей и потребовали примерно 135 Тбит/с – по сравнению с 3,4 миллионами пиковых одновременных зрителей и 15 Тбит/с в 2020 году.

Конечно, что важно помнить здесь, так это то, что рост использования данных произошел потому, что объем данных взорвался во всем мире – как по объему, так и по типам данных, которые вводятся в картину. Этот тренд увеличивает сложность управления данными – и, как сообщает Uptime Institute, эта сложность, в свою очередь, представляет новые угрозы простоя.

Одним из источников этой новой сложности, конечно, является ИИ.

Второй квартал: Революция ИИ

В последние несколько лет этот стресс с данными в основном генерируется (и управляется) новым элементом: ростом ИИ. Хотя конкретных данных об ИИ в Супербоуле нет, быстрый взгляд на экосистему НФЛ показывает множество приложений ИИ, затрагивающих почти каждый аспект игры. Чтобы получить представление о том, как ИИ используется, рассмотрим следующие футбольные разработки ИИ за последний год:

  • Игра – Система просмотра боковой линии НФЛ, разработанная Microsoft, которая использует планшеты с ИИ для отслеживания игры и управления хuddle, была обновлена с помощью GitHub Copilot для фильтрации игр по критериям, таким как даун и расстояние, игры с очками и пенальти, для быстрого анализа формаций, расшифровки покрытий и принятия более обоснованных решений.

  • Трансляция – ESPN представил реальные данные и вероятности игр в режиме реального времени, сделанные возможными благодаря Next Gen Stats и TruPlay ИИ.

  • Фэнтези-лиги – НФЛ запустил помощника фэнтези-ИИ в своем новом приложении NFL Pro, разработанном в партнерстве с AWS AI, Next Gen Stats и NFL Fantasy.

  • Ставки – Приложение для ставок FanDuel представило функцию чата для спортивных ставок на основе ИИ для руководства игроками в ставках на NFL и NBA в марте этого года.

Плюс, есть множество способов, которыми ИИ питает игру задолго до дня игры – от партнерства НФЛ с AWS по вопросам безопасности и планирования игр до использования Microsoft Azure AI Foundry для поддержки более умных выборов на драфте. Неудивительно, что гиганты ИИ заключают сделки с НФЛ – включая Cisco, который имеет партнерство по инфраструктуре ИИ с несколькими франшизами НФЛ, включая New England Patriots.

В день игры новый ИИ добавляет к новой сложности и объему данных, упомянутым выше. В долгосрочной перспективе он представляет еще один тип нестабильности облака – который я объясню дальше.

Слепая сторона: Скрытая угроза ИИ для надежности облака

Помимо требований к очень специфическому управлению данными, ИИ также является потенциальной причиной следующей волны хрупкости облака. После двух крупных простоев AWS и Azure в прошлом году исследователь Forrester Lee Suster предупредил, что эти сбои “не были изолированы – они являются предвестником того, что произойдет” – и что ИИ является ключевым ускорителем опасностей. Как пишет Сустер:

Гиперскалеры отвлекают инвестиции от устаревших сред x86 и ARM, отдавая приоритет центрам обработки данных, ориентированным на GPU, для рабочих нагрузок ИИ, в то время как стареющая инфраструктура выходит из строя из-за растущей сложности. Мы считаем, что эта стратегия будет иметь некоторые значительные последствия в виде как минимум двух крупных многодневных сбоев в 2026 году.

ИИ становится все более важным – и создает бизнес-условия, которые делают облака менее надежными, чем они были раньше. Это еще одна причина, по которой ИИ заставляет игроков ИТ перейти в оборону. Некоторые ключевые стратегии ниже.

Победоносная защита: Необходимые меры по защите облака

Чтобы защитить свои облачные операции и сохранить бизнес-непрерывность, убедитесь, что:

  • Разверните обнаружение аномалий на основе ИИ и непрерывное тестирование на устойчивость. Используйте машинное обучение, чтобы обнаружить проблемы до того, как они повлияют на пользователей. Регулярно имитируйте сбои – региональные сбои, ухудшение обслуживания – в производственных средах, чтобы проверить, что ваши системы восстановления действительно работают.

  • Устраните единую точку отказа с помощью активных многокloud-развертываний. Запускайте производство на нескольких провайдерах и регионах одновременно, каждый из которых обрабатывает живой трафик. Используйте реальное перенаправление трафика и географическую избыточность, чтобы направлять пользователей на основе текущих условий, что позволяет осуществлять восстановление после аварии намного быстрее, независимо от того, где произошел сбой.

Ключевым моментом второго пункта является построение систем, которые не зависят от одного провайдера. Не работайте только в нескольких облаках – работайте над真正щей избыточностью и гибкостью облака. Вот три шага, которые следует помнить, чтобы добиться этой гибкости:

  • Придерживайтесь инструментов, которые работают во всех облаках. Например, используйте Kubernetes вместо сервисов контейнеров, родных для провайдера, Okta или Keycloak вместо AWS Cognito для аутентификации, Terraform вместо сервисов, специфичных для провайдера, таких как AWS CloudFormation, когда речь идет об инфраструктуре как код.

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

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

Финальный свисток: Построение вашей чемпионской инфраструктуры

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

Харshit Омар является сооснователем и техническим директором FluidCloud, где он строит будущее облачной инфраструктуры, позволяя бизнесу бесшовно мигрировать, реплицировать и оптимизировать рабочие нагрузки в мультиоблачных средах. Ранее он был первым инженером в Accurics, где он возглавлял основные усилия по разработке своей политики и облачной безопасности.

С глубокими знаниями в области Go, Kubernetes, Terraform и облачной безопасности, Харshit провел более десяти лет, проектируя устойчивые системы на платформах AWS, Azure и GCP.

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