Человеческий фактор в ЦОДе: как DCIM помогает замечать то, что делают люди

Константин Струлев, директор компании «Цодум» — о том, почему инфраструктура ЦОД постепенно расходится с проектом, кто в этом виноват и как DCIM помогает вовремя заметить изменения.

Почему самые неожиданные изменения — это не про технологии

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

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

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

Когда временное перестает быть временным

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

А дальше происходит привычная история. Задача закрыта, все переключились на следующее, а временное решение остается. Сначала о нем помнят, потом — уже не все, а через какое-то время оно просто становится частью инфраструктуры.

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

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

Кейс: оборудование, которое оставили на потом

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

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

В итоге нашли довольно простую причину. Несколько месяцев назад туда временно подключили оборудование для тестовой задачи. Сделали быстро и без лишних процедур — потому что «всё равно скоро уберем».

Задачу действительно закрыли. А вот оборудование осталось. Более того, оно оказалось включено в общий контур и продолжало жить своей жизнью.

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

Когда изменения накапливаются незаметно

Есть и другая история, еще более тонкая. Это когда никто ничего «лишнего» не добавляет, но система всё равно меняется.

Инженер что-то улучшил, чтобы было удобнее. В другом месте чуть поправили конфигурацию. Где-то упростили подключение. Каждое изменение само по себе логично и оправдано.

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

Причем никто этого специально не планировал.

Когда подрядчик делает “как лучше”

Отдельная история — это работа подрядчиков.

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

Проблема в том, что “как лучше” не всегда совпадает с тем, как задумывалась конкретная инфраструктура.

Кейс: система, которая стала «немного другой»

В другом ЦОД после работ подрядчика всё выглядело корректно. Оборудование установлено, подключено, сервисы работают.

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

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

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

Без данных DCIM это выглядело бы как “всё нормально”. С данными — стало видно, что “нормально, но по-другому”.

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

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

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

Где-то изменилась нагрузка, где-то — распределение, где-то — сама «форма» работы системы. Не как событие, а как факт.

И в этот момент появляется возможность задать простой, но очень важный вопрос: это действительно то, что мы хотели получить, или система незаметно ушла в сторону?

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

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

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

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

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

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