Skip to content
Сбой облака: почему платформу не спасает даже железо
21 октября 14:14 7 Просмотров Новости

Сбой облака: почему платформу не спасает даже железо

Сбой облака: почему платформу не спасает даже железо

В середине октября Yandex Cloud на несколько дней ушёл в ограниченный режим, оставив без связи около 64 000 клиентов. Пока инженеры дата-центров чинили физическое железо, бизнес в панике пытался поднять виртуальные машины и базы данных своими силами. Оказалось, что обещанная «невидимость» инфраструктуры работает только до первой серьёзной аварии.

Инженеры Yandex Cloud проверяют серверные стойки в дата-центре при тусклом аварийном освещении

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

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

Яндекс попытался сгладить углы. Компания договорилась с Selectel, K2Cloud и VK Cloud об упрощённом онбординге и гибких финансовых условиях, чтобы клиенты могли мигрировать без лишней бюрократии. Правда, на месте это выглядело иначе: один из знакомых админов рассказывал, что они потратили полдня на споры о том, какой именно регион выбрать, пока у них на столе остывал третий стакан кофе. В итоге переезд занял не дни, а почти неделю, и половину сервисов пришлось поднимать вручную.

Экран монитора с логами ошибок Kubernetes и открытым чатом команды DevOps во время аварийного восста

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

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

Рынок отреагировал мгновенно.

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

Никита Карпов

Никита Карпов

Главный редактор

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

Поделиться

Похожие публикации