Мнимая отказоустойчивость: как DCIM показывает, что резервирование не работает так, как вы думаете

Когда всё выглядит надежно — на схеме

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

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

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

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

И это «немного» обычно выясняется не в самый удобный момент.

Почему резервирование со временем «размывается»

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

Но инфраструктура не стоит на месте. В ней постоянно что-то меняется. Добавляются новые системы, перераспределяются нагрузки, оптимизируются подключения.

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

Причем это происходит почти незаметно. На уровне документации всё может выглядеть по-прежнему правильно.

Кейс: резерв есть, но нагрузка уже не там

В инфраструктуре ЦОД ХХХ схема резервирования считалась надежной и проверенной. Две линии питания, балансировка, всё по классике.

При этом при анализе данных DCIM обратили внимание на одну деталь. Нагрузка между линиями распределялась не так, как ожидалось. Одна линия стабильно была нагружена заметно сильнее другой.

Сначала это выглядело как особенность текущей конфигурации. Но чем дальше смотрели, тем понятнее становилось, что это уже устойчивая картина.

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

В результате схема «два равнозначных контура» осталась на бумаге. А в реальности один из них стал существенно более нагруженным.

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

Никакой аварии не произошло. Но сама модель риска уже изменилась.

Когда резервирование есть, но не проверено

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

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

«Раз не падало — значит всё хорошо».

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

Кейс: система, которая «должна была выдержать»

В ЦОД УУУ была уверенность, что инфраструктура спокойно выдержит отказ одного из элементов питания. Это было заложено в проекте и не вызывало сомнений.

Но при детальном анализе DCIM обнаружили, что в текущей конфигурации часть оборудования фактически зависит от одного контура больше, чем предполагалось.

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

На бумаге всё выглядело корректно. В реальности поведение системы уже отличалось.

И если бы отказ произошел, последствия могли быть значительно шире, чем ожидалось.

Самое неприятное в таких историях — это не ошибка, а уверенность. Уверенность в том, что всё работает так, как было задумано.

Что в этом видит DCIM

DCIM в таких ситуациях полезен тем, что показывает не схему, а фактическое поведение.

Не как должно распределяться питание, а как оно распределяется. Не как должна вести себя система, а как она ведет себя сейчас.

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

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

Почему это важно

Отказоустойчивость — это не свойство, которое один раз заложили и забыли. Это состояние, которое нужно регулярно проверять.

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

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

И иногда этого достаточно, чтобы вовремя заметить, что резервирование у вас есть. Просто работает оно уже немного по-другому.

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