Аварии в дата-центрах: причины, легендарные сбои и как их избежать

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

И знаете, какой самый главный парадокс? Современный бизнес так сильно зависит от технологий, что вопрос уже не в том, случится ли авария, а в том, готовы ли мы к ней. В статье разберемся, какие факторы чаще всего приводят к сбоям и какие уроки извлечены из самых громких инцидентов. Мы поговорим не о сухой теории, а о том, что происходит на самом деле, когда «все сломалось», и как этого избежать.

В мире IT-инфраструктуры есть свой фольклор — истории о сбоях, которые стали притчей во языцех и до сих пор служат наглядными уроками. Каждая такая история — это не просто новостной заголовок, а детальный разбор, который показывает, насколько хрупка на самом деле может быть многомиллионная инфраструктура.

В 2018 году мощный разряд молнии в Техасе стал причиной одного из самых громких сбоев в истории Microsoft Azure. Казалось бы, молния — это же природный катаклизм. Что тут можно поделать? Но дьявол, как всегда, кроется в деталях.

Температура в одном из залов начала расти так быстро, что оборудование, чтобы защитить себя, начало экстренно отключаться. Но даже этот защитный механизм не сработал достаточно быстро: часть серверов, сетевого оборудования и блоков питания просто «сгорела», не успев завершить штатный шатдаун.

И это было только начало. Восстановление заняло 21 час, что стало «самым долгим сбоем в истории VSTS». Но ирония ситуации в том, что даже сайт статуса Azure, который должен был информировать клиентов, тоже был недоступен, и команде пришлось общаться с пострадавшими пользователями через Twitter.

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

А вот это уже классический анекдот, который, к сожалению, является чистой правдой. В 2010 году рядом с дата-центром Yahoo в Санта-Кларе белка решила, что питающие кабели — это отличная закуска. Она их перегрызла, вызвав замыкание и отключение половины дата-центра.

Если бы ЦОД использовал по-настоящему резервированные линии, идущие от разных подстанций и по разным физическим маршрутам, то белка просто не смогла бы нанести такой ущерб. 

В 2017 году British Airways пережила настоящий IT-апокалипсис, который стоил компании более 100 миллионов долларов и оставил 75 000 пассажиров без рейсов. Изначально CEO компании заявил, что причиной был «мощный скачок напряжения», который якобы вывел из строя даже резервные системы.

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

Свои легенды есть и у нас. Например, пожар в московском ЦОД OST в 2019 году, который ранее считался одним из самых надежных в России. Там короткое замыкание в проводке, ведущей к кондиционерам, повредило систему охлаждения и обесточило один из залов. В результате 780 виртуальных машин стали недоступны на несколько часов.

Еще один пример — крупный сбой в одном из ЦОД «Яндекса» в марте 2025 года. Там причиной стала неисправность на питающей подстанции, которая одновременно отключила обе независимые линии электропередачи.

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

Если спросить любого специалиста по ЦОД, что выходит из строя чаще всего, он, не задумываясь, ответит «электричество». По данным Uptime Institute, проблемы с питанием — самая частая причина серьезных сбоев, которая стоит за 36% всех аварий.

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

Вторая по частоте причина простоев — это перегрев. По данным исследований, на проблемы с охлаждением приходится около 13% всех аварий. Но не нужно думать, что от перегрева серверы просто начинают «тормозить».

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

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

Риск возгораний в ЦОД вполне реален. Чаще всего пожары возникают из-за коротких замыканий, перегрева оборудования или проблем с проводкой. Но здесь есть своя специфика: если при обычном пожаре мы используем воду, то в ЦОД это исключено, так как она уничтожит оборудование. 

Для тушения в ЦОД используют так называемые «чистые агенты», например, газы типа Inergen или Novec 1230. Они работают по принципу снижения концентрации кислорода в помещении до уровня, при котором горение становится невозможным (около 12,5%), но при этом этот уровень остается безопасным для человека, который может находиться в помещении. 

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

• Грызуны и насекомые. Они устраивают короткие замыкания, перегрызают кабели и строят гнезда в самых неподходящих местах.

• Вода. Прорывы водопроводных труб или банальные протечки с крыши случаются чаще, чем хотелось бы.

• Вибрации. Строительные работы по соседству могут вызывать вибрации, которые со временем повреждают оборудование и линии связи.

• Стрельба. Есть примеры, когда оптоволоконные кабели становились мишенью для скучающих охотников. 

Если бы меня спросили, кто самый страшный враг любого дата-центра, я бы ответил, не задумываясь: человек. По данным Uptime Institute, человеческий фактор — это прямая или косвенная причина 66-80% всех серьезных инцидентов. Вдумайтесь в эту цифру: две трети всех аварий так или иначе связаны с людьми. 

И это не всегда банальная халатность. Типичные ошибки персонала делятся на две категории.

• Несоблюдение регламента. В 58% случаев персонал просто не следовал существующей инструкции. 

• Неправильный регламент. В 45% случаев сама процедура была изначально неверной или неполной.

Примеры из практики:

• случайное отключение сетевого или питающего кабеля;

• неправильная настройка системы или случайное удаление виртуальной машины; 

• активация аварийного выключателя EPO (Emergency Power Off), когда это было не нужно.

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

Но не все так плохо. Чтобы защитить свой бизнес, нужно мыслить, как архитектор крепости — строить многоуровневую защиту, чтобы провал на одном уровне не стал фатальным.

Когда мы говорим о резервировании, мы используем букву N. Что она значит? Это минимальное количество оборудования, которое нужно для работы ЦОД на полной нагрузке.

• Схема N+1 — самый базовый уровень. Представьте, что у вас есть 4 ИБП (N=4) и еще один, пятый, про запас. Если один из четырех выйдет из строя, запасной возьмет его нагрузку. Это как иметь запасное колесо в машине. Дешевле и проще, но защищает только от одного сбоя.

• Схема 2N — уже совсем другой уровень. Это значит, что у вас есть два полностью независимых комплекта оборудования. Если один комплект (например, 4 ИБП) выйдет из строя, второй комплект из 4 ИБП продолжит работать. Это как иметь две одинаковых машины, работающих параллельно. Надежнее, но и дороже.

Настоящая отказоустойчивость требует, чтобы линии шли по разным физическим маршрутам и от разных источников. 

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

Помимо использования «чистых агентов», в ЦОД применяются и другие меры. Например, системы раннего обнаружения дыма (системы автоматической пожарной безопасности), способные отличить реальный пожар от газовой утечки в системе охлаждения. 

Резервирование касается не только физической инфраструктуры. IT-системы тоже должны быть защищены. Здесь на помощь приходят два понятия:

• RTO (Recovery Time Objective) — как быстро нужно восстановить работу после сбоя;

• RPO (Recovery Point Objective) — какой объем данных мы готовы потерять.

Мониторинг — наши глаза и уши в дата-центре. Он позволяет следить за температурой, состоянием ИБП, нагрузкой на оборудование и может оповестить о проблеме до того, как она превратится в катастрофу. 

А вот следующий уровень — это предиктивная аналитика на основе ИИ. Современные системы могут анализировать исторические данные и показания датчиков, чтобы предсказать отказ оборудования еще до того, как он случится. Это позволяет заменить вышедший из строя компонент в плановом порядке, а не в пожарном. 

Даже самая надежная крепость может пасть. И вот тут на первый план выходит не технология, а люди и процессы.

У каждого ЦОД должен быть четкий план реагирования, где расписана каждая минута после инцидента. Типовой план включает:

1. Обнаружение. Инцидент фиксируется (звонок в диспетчерскую, автоматическое оповещение).

2. Оповещение. Ответственные сотрудники получают уведомление, и каждый знает свою роль.

3. Сдерживание. Команда работает над локализацией проблемы, чтобы она не распространилась дальше.

4. Устранение и восстановление. Когда проблема локализована, начинается ее устранение и восстановление сервисов. 

В моменты сбоя главный враг — это тишина. Если клиенты ничего не знают, они начинают нервничать, звонить в поддержку и распускать слухи. Лучшее, что можно сделать — это общаться:

• мгновенно (как только вы узнали о проблеме, немедленно сообщите об этом клиентам, даже если еще не знаете причину);

• регулярно (давайте обновления, даже если они сводятся к «мы все еще работаем»);

• честно (признайте вину, если она есть, но без лишних эмоций и пустых обещаний. Не обещайте исправить все через 15 минут, если это не так. Клиенты ценят честность).

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

В рамках такого анализа собирается вся хронология событий и данные мониторинга и ищутся ответы на вопросы:

• что пошло не так,

• почему не сработала защита,

• что можно сделать, чтобы этого больше не повторилось.

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

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

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

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

Технологии для этого уже существуют. Вопрос лишь в том, готовы ли мы их применять. Те, кто строит многоуровневую защиту, выигрывают. Остальные — теряют данные, деньги и клиентов.