Привет, Хабр! Меня зовут Роман Путилов. Последние восемь лет я занимаюсь облачной инфраструктурой. SRE-процессы, SLA «пять девяток», регулярные инциденты и постмортемы – часть моей работы, а не только новостная повестка.
За последние годы несколько крупных инцидентов в облаках показали, что одна ошибка может вырубить сразу несколько глобальных сервисов. На кейсах VK, ЕГРН, Яндекса, AWS, Google Cloud и CrowdStrike я разбираю, ведет ли консолидация инфраструктуры к цифровой катастрофе – идеальному шторму, где простая ошибка и несколько неудачных совпадений окажут такой разрушительный эффект, от которого уже нельзя будет оправиться.
Будет полезно SRE, архитекторам, IT- и ИБ-руководителям.
Погрузимся в хронику инцидентов с облачными сервисами за последние 7 лет.
«ВКонтакте»
16 февраля 2018 года, с 15:00 на экранах миллионов россиян перестает загружаться главная страница социальной сети «ВКонтакте». Попытки открыть ленту новостей приводят к сообщению: «К сожалению, раздел временно недоступен. Мы уже работаем над устранением неисправностей». В это же время пользователи по всей стране жалуются на проблемы с другими онлайн-сервисами.
Как выяснится позже, причиной сбоя стал мгновенный скачок напряжения в петербургском дата-центре Xelent, где размещались серверы «ВКонтакте»: переход на резервное электропитание сопровождался 24-миллисекундным провалом напряжения, из-за чего перезагрузилось сетевое оборудование соцсети. Буквально мгновенный скачок привел к крупнейшей на тот момент аварии: около 10% инфраструктуры «ВКонтакте» вышло из строя, соцсеть оставалась частично недоступной практически полдня.
ЕГРН
20 августа 2018 года авария еще масштабнее: из-за сбоя в одном из центров обработки данных «Ростелекома» на 66 часов остановилась работа Единого государственного реестра недвижимости. Регистрационные действия по всей стране встали, пока команды в авральном режиме переносили системы на резервные площадки. Полностью восстановить работу Росреестра удалось лишь к 3 сентября. За простой государственных сервисов «Ростелекому» грозят многомиллионные штрафы, инцидент попадает в новости и обсуждается на самом высоком уровне.
«Яндекс»
30 марта 2023 года в одном из основных дата-центров «Яндекса» происходит то, что инженеры называют событием «раз в несколько десятилетий». Авария на питающей подстанции обесточивает сразу две независимые линии электропитания центра обработки данных. Срабатывают генераторы, но всплеск нагрузки приводит к каскадному отказу значительной части оборудования. Некоторые сервисы «Яндекса» оказываются недоступны. Инженерам приходится шаг за шагом восстанавливать инфраструктуру.
Google Cloud
12 июня 2025 года, около полудня по тихоокеанскому времени начинается идеальный шторм в глобальном интернете: сбой в облачной платформе Google Cloud цепной реакцией выводит из строя множество популярных онлайн-сервисов по всему миру.
В течение часа пользователи фиксируют одновременную недоступность Spotify, Discord, Snapchat, Twitch, ряд сервисов Google. Тысячи жалоб стремительно появляются на Downdetector. И хотя инженеры Google уже через пару часов начинают восстановление сервисов, пользователи по всему миру наглядно убеждаются: одновременный сбой одного облачного провайдера способен «погасить» значительную часть интернета.
Складывающаяся картина напоминает путь к цифровому апокалипсису: мы сознательно собираем инфраструктуру тысяч компаний в несколько точек концентрации, увеличивая цену любой ошибки до масштаба «минус кусок интернета».
Но так ли это на самом деле или это естественный эволюционный процесс, в котором слабые решения и провайдеры вымрут, а уцелевшие станут настолько жестко закаленными, что уронить их с каждым годом будет все сложнее?
Давайте разбираться.
Рост доверия к облакам и реальность сбоев
Облачные технологии — уже не экзотика, а повседневная часть IT-ландшафта. Еще 10 лет назад компании скептично относились к переносу критичных систем в облако, опасаясь потери контроля и простоев. Сегодня ситуация изменилась.
Индекс доверия к облачным сервисам неуклонно растет на протяжении последнего десятилетия. По разным опросам, большинство IT-руководителей уверены в надежности облаков и готовы доверять им свои ключевые приложения. По данным O’Reilley, свыше 90% организаций уже используют облако. Более того, топ-менеджеры отмечают и объективные плюсы: около 60% руководителей считают, что переход в облако улучшил безопасность и устойчивость их систем – безопасность вообще называют главным преимуществом облачных решений.
К середине 2020-х свыше половины компаний размещают больше половины своих рабочих нагрузок в облаке, а отказ от облаков рассматривают лишь единицы: менее 5% планируют возвращать системы на собственные площадки.
При этом статистика показывает, что абсолютное число публично известных инцидентов не уменьшается. Согласно данным Uptime Institute, профессиональные облачные и хостинг-провайдеры сегодня ответственны за все большую долю общих сбоев в IT-инфраструктуре.
Если облака действительно надежны, почему крупные аварии случаются все чаще?
Чем больше компаний консолидируют критичные системы у нескольких провайдеров, тем выше ставка в каждом инциденте. Одна ошибка инженера, один баг при обновлении или редкий двойной отказ питания превращается из локальной аварии в проблему целого рынка. Если продолжать этот тренд без эволюции практик и архитектур, финал действительно будет напоминать анархию, только в цифровом виде.
Так чему же нас учат аварии у крупных провайдеров? Давайте внимательнее рассмотрим показательные инциденты, часть из которых упоминали в начале и попробуем разобраться, как они повлияли на отдельных провайдеров и отрасль в целом.
Разбор инцидентов: от отказа питания до багов ПО
Кейс 1: сбой электропитания обесточил соцсеть
Я уже описал историю февральского сбоя 2018 года, когда из-за кратковременного перебоя электроснабжения в ЦОД Xelent на 18 часов частично погасла соцсеть «ВКонтакте». Что примечательно, непосредственно авария, то есть скачок напряжения при переключении на резервное питание, длилась считанные миллисекунды, но этого хватило, чтобы вывести из строя сетевые коммутаторы и нарушить работу 10% оборудования. Инженеры дата-центра оперативно восстановили подачу энергии и перезагрузили технику, но последствия сбоя устранялись еще долго.
Впоследствии специалисты Xelent подробно разобрались в причинах: как рассказал директор филиала Андрей Елисеев, была модернизирована схема резервирования, чтобы учитывалось влияние даже самых кратких провалов напряжения и переключение на резервное питание проходило гладко для чувствительных устройств.
Схемы питания, которые еще можно было терпеть в одиночной серверной, оказываются хрупкими, когда на площадке консолидированы миллионы пользователей. При такой плотности клиентов слабые варианты резервирования просто не выживают – их заменяют более дорогие и более параноидальные решения, которые для обычного ЦОД кажутся излишеством.
Но Xelent решился на этот сложный шаг – улучшеная схема электропитания, пересмотренные регламенты и процессы обслуживания сделали невозможными подобную аварию в будущем.
Кейс 2: CEPH vs ЕГРН
20 августа 2018 года происходит сбой на программно-определяемом хранилище на базе решения с открытым исходным кодом Ceph. Сбой приводит к 66 часам простоя работы Единого государственного реестра недвижимости. Регистрационные действия по всей стране встали, пока команды в авральном режиме переносили системы на резервные площадки.
Недонастроенный OSS-стек под нагрузкой масштаба страны оказался слишком хрупким, чтобы его можно было сделать единственной опорой для государственного реестра. После этой истории к программно-определяемому хранению стали относиться заметно осторожнее: либо доводить такие решения до индустриального качества с жестким тестированием и регламентами приемки и обслуживания, либо учитывать, что решение может упасть и быть готовым к этому – иметь планы восстановления данных и работоспособности смежных систем.
Обязательное резервирование не только хранения, но и вычисления теперь является стандартом для государственных информационных систем, а для длительного хранения приоритет отдается в сторону современных аппаратных решений для хранения.
Кейс 3: «невозможная» авария в энергосистеме
Конец марта 2023-го принес сюрприз для инженеров Yandex Cloud. Авария на городской электроподстанции, питающей один из крупнейших дата-центров компании, привела к одновременному отказу двух независимых вводов питания – событие из разряда крайне маловероятных. Дата-центр был оснащен резервными дизель-генераторами и ИБП, но они не были рассчитаны на отключение одновременно двух вводов.
Этот инцидент, помимо мощной тренировки служб эксплуатации и проверки регламентов на прочность, мотивировал «Яндекс» подняться на федеральный уровень резервации электроэнергии: компания заключила договор с несколькими федеральными операторами и подключила свои дата-центры к двум независимом на федеральном уровне подстанциям.
Дата-центр, спроектированный не только под линейный отказ одного ввода, а под сценарии с одновременной потерей нескольких независимых источников питания – уровень паранойи, который никогда не стал бы стандартом в мире одиночных серверных. Он окупается только тогда, когда от стабильности инфраструктуры зависят сотни чужих бизнесов.
Кейс 4: атака на облако и три упавших дата-центра
17 марта 2024 года в инфраструктуре российского провайдера MTS Cloud произошел беспрецедентный сбой. Причем затронуты оказались одновременно три географически разнесенных дата-центра: в Москве, Петербурге и даже площадка в Казахстане. Для клиентов это выглядело как полномасштабный отказ облака: виртуальные машины и сервисы перестали отвечать.
Первоначально в качестве причин рассматривали все – от масштабного сбоя в магистральной сети до ошибок обновления ПО. Спустя сутки MWS частично восстановил работу, но полностью последствия устраняли более 24 часов. В кулуарах индустрии заговорили о кибератаке: по инсайдерской информации, наиболее вероятной версией стала целенаправленная атака на облачную инфраструктуру, спровоцировавшая отключение сразу нескольких площадок. Инцидент привел к безвозвратному уничтожению некоторых данных, компрометации данных зафиксировано не было.
Официальных деталей компания не раскрыла, однако инцидент дал понять: облака стали мишенью злоумышленников, и информационная безопасность должна быть не мертвым регламентом, а работающим инструментом, который регулярно тестируется.
Результат – усиление мер безопасности. После случившегося MTS Cloud и другие провайдеры начали проводить внеплановые аудиты безопасности, внедрили дополнительные системы мониторинга и противодействия.
Для всех крупных облачных провайдеров – это болезненный, но неизбежный отбор: те, кто не научатся держать удары такого масштаба и не смогут прозрачно объяснять, что произошло и как они это исправили, будут постепенно вымываться из списка надежных поставщиков.
Кейс 5: человеческий фактор и падение интернета
Классический пример ошибки, приведшей к масштабному сбою – легендарная авария Amazon S3 28 февраля 2017 года.
Инженеры AWS устраняли небольшую проблему с системой биллинга хранилища S3 в регионе Northern Virginia. Согласно официальному отчету Amazon, при отладке оператор по привычному сценарию запустил скрипт для отключения нескольких серверов, но из-за опечатки в параметрах скрипт удалил целую группу критически важных серверов, ответственных сразу за два суб-сервиса S3.
В мгновение ока облачное хранилище лишилось значительной части инфраструктуры, что вызвало цепную реакцию: зависли операции чтения и записи объектов, остановился сервис размещения новых данных. S3 прекратил обслуживание запросов почти на 4 часа, а вместе с ним легли и многие зависящие от S3 сервисы AWS в этом регионе – от запуска новых виртуальных машин до Lambda.
В отчете компания признала сбой и раскрыла план действий: во-первых, модифицированы инструменты администраторов, теперь они не позволят вывести слишком большой объем серверов разом (добавлены предохранители и замедлители). Во-вторых, команда S3 форсировала работы по дальнейшему дроблению системы на изолированные модули (cells), чтобы даже полный перезапуск индекса или другого подсервиса не парализовал все хранилище. В-третьих, иронично выяснилось, что панель статуса AWS зависела от S3 и тоже упала, мешая быстро информировать клиентов – после инцидента страницу статуса перевели на отдельную распределенную систему, не зависящую от одного региона.
Amazon публично извинился перед клиентами и подчеркнул, что усилит тестирование и процедуры, чтобы подобная человеческая ошибка не могла повториться.
На уровне индустрии – как точка, после которой root-доступ к большим системам перестал быть тем, чем был раньше. Без жестких предохранителей на админские операции и без cell-архитектуры подобные решения в условиях консолидации просто не выживут: одна опечатка в параметре больше не имеет права валить пол-интернета.
Кейс 6: баг в ПО, положивший Windows по всему миру
Если предыдущий кейс – пример человеческой оплошности, то следующий можно назвать аварией на ровном месте: сбой, заранее практически непредсказуемый. Речь о крупнейшем в истории IT-инциденте, произошедшем 19 июля 2024 года, когда неудачное обновление безопасности от компании CrowdStrike фактически вывело из строя миллионы компьютеров под управлением Windows по всему миру.
CrowdStrike Falcon – популярный агент кибербезопасности, устанавливаемый на корпоративные ПК и серверы, получил обычное автоматическое обновление сигнатур, которое вдруг оказалось не совсем обычным. Из-за логической ошибки разработчиков новый защитный модуль стал конфликтовать с ядром Windows, мгновенно вызывая печально известный «синий экран смерти» (BSOD).
Поскольку агент Falcon работал с высокими привилегиями в системе, сбой проявился стремительно и массово: банки, авиакомпании, госпитали – по всему миру офисные системы одновременно начали перезагружаться и падать.
По оценкам страховщиков, прямой ущерб только для компаний из списка Fortune 500 превысил 5,4 млрд долларов.
Что это было? Программная ошибка в обновлении, прошедшем внутреннее тестирование CrowdStrike. Когда волна BSOD начала катиться по клиентам, компания отозвала патч, но было поздно, многие машины уже устанавливали фатальное обновление.
Последовавшее расследование выявило пробел в процессе разработки: сбойный модуль просочился через автоматическую систему валидации, потому что в инструменте проверки содержимого был баг – он не распознал ошибку в конфигурационном файле обновления.
CrowdStrike честно опубликовала подробный 12-страничный отчет о причинах и баг в процессе поставки обновлений исправила: теперь верификация контента усилена, а заказчики получили возможность отложить развертывание патчей.
Главный урок. Даже рутинное обновление безопасности способно вызвать коллапс, если упущен скрытый дефект, поэтому критически важны многоуровневое тестирование и механизм быстрого отката.
Инцидент стал тревожным звоночком для всей отрасли: он показал, насколько глубоко современные компании полагаются на сторонние софтверные компоненты, и подтолкнул многих пересмотреть собственные политики обновления ПО.
Если для отдельной компании это просто неудачный апдейт, то на уровне экосистемы – сигнал, что процессы обновления глобальных security-агентов должны быть ближе к авиастроению, чем к классическому антивирусу. Когда безопасность половины планеты сконцентрирована в руках нескольких агентов, эволюционно выживут только те, кто строит свои пайплайны обновлений с такой же паранойей, как авиаконструкторы.
Кейс 7: QuotaGate в Google Cloud – когда невидимые зависимости всплывают наружу
Вернемся к событию, с которого начинался наш рассказ, – массовому сбою Google Cloud в июне 2025 года. На первый взгляд ситуация выглядела загадочно: одновременно отказали такие разрозненные вещи, как музыка в Spotify, чат Discord, стримы Twitch, битовые поля Cloudflare и даже Google Home у пользователей умных домов. Разве все они сидят на одном виртуальном сервере? В каком-то смысле – да: чуть позже Google официально подтвердил, что все эти сервисы объединяла зависимость от одного облачного компонента. Первопричиной стал сбой в системе управления идентификацией (IAM) Google Cloud.
Произошло следующее: скрипт автоматического обновления квот (то ли для API, то ли для аккаунтов) внес ошибочные изменения в конфигурацию, которые мгновенно распространились по дата-центрам Google по всему миру. В результате любые запросы на аутентификацию и доступ между сервисами начали отклоняться по всей инфраструктуре – фактически облако разучилось выдавать сервисам разрешения на связь друг с другом.
Cloudflare, например, сообщила, что у нее отказало центральное хранилище одного из сервисов, завязанное на GCP. Для конечных пользователей это проявилось как одновременный сбой множества несвязанных платформ, ведь глубоко внутри все они опирались на облачные API Google.
Инженеры Google довольно быстро нашли решение: они отключили проблемный механизм квот, фактически откатили систему авторизаций на предыдущую версию. Это позволило восстановить работу большинства сервисов в течение примерно 2 часов.
Однако в одном из регионов (us-central1) ситуация осложнилась: из-за наплыва запросов там перегрузилась база данных политик доступа, поэтому полный возврат к норме занял больше времени.
В итоге, к вечеру того дня Google объявил об успешном восстановлении почти всех функций, а на следующий день выпустил краткий отчет (PIR) с признанием проблемы. В нем компания подробно объяснила причину – «неверное автоматизированное обновление конфигурации квот» – и заверила, что встроит дополнительные проверки, чтобы подобные ошибки не повторились.
Индустрия получила важный урок про опасность скрытых межсервисных зависимостей. Google, со своей стороны, доработал процесс деплоя конфигураций, добавив многоуровневое подтверждение для глобальных изменений, а крупные клиенты сделали выводы о необходимости распределять свои сервисы между несколькими облаками, дабы сбой одного поставщика не уронил все сразу.
Кто не падал, тот не поднимался
Если сложить все истории вместе, картинка получается пугающая: все больше бизнесов завязано на несколько крупных поставщиков, а цена одной ошибки растет в геометрической прогрессии. При прямолинейном продолжении этого тренда, без эволюции практик и архитектур, цифровой идеальный шторм вполне реалистичен.
Те инциденты, которые я рассмотрел выше, – разные по природе, масштабу и последствиям – объединяет одно: каждый сбой выявил уязвимое место, о котором раньше не подозревали. Уникальный двойной отказ питания, баг в давно отлаженном сценарии, атака нового масштаба, такие проблемы могут появиться только при эксплуатации на больших масштабах.
Хорошая новость в том, что облачные провайдеры серьезно относятся к каждому инциденту. В индустрии давно укоренена практика root cause analysis – тщательного разбора корневых причин инцидентов и принятия мер для недопущения рецидива. Каждая авария становится уроком, после которого вносятся изменения: улучшается резервирование, переписываются процедуры, дорабатываются инструменты администраторов, усиливается тестирование. Иными словами, после каждого падения облако становится надежнее.
Почему же крупных аварий становится больше? В облачных инфраструктурах масштаб инцидента пропорционален масштабу облака. Больше сервисов переезжают в облака, больше проектов начинают развиваться там сразу – больший коэффициент аварий проходится на облако. Но плюс в том, что все больший опыт извлекается из устранения каждой.
Облачные сервисы достигли высокой надежности, но не абсолютной. Сбои будут происходить. Но, как ответил мне CTO одного облака на вопрос, как им удалось так поднять SLA сервисов: «Мы просто чаще падали. Но с каждым разом поднимались все быстрее – и с каждым разом нас все сложнее уронить».
На длинной дистанции это похоже на живую эволюцию. Слабые конфигурации, уязвимые цепочки обновлений, неудачные схемы резервирования и даже целые провайдеры, не прошедшие проверку временем, постепенно вымываются из экосистемы. Остаются только те, кто научился переживать удары нового масштаба, добавляя себе еще один слой брони. Это не отменяет риска системной ошибки или «черного лебедя», но делает сценарий полной цифровой анархии заметно менее вероятным, чем казалось после первых падений.