Когда речь заходит о потерях в инфраструктуре, обычно представляют что-то заметное — отказ, простой, инцидент. То есть событие, которое невозможно проигнорировать.
Но в реальности всё устроено гораздо менее драматично. Самые устойчивые потери не ломают сервисы и не попадают в отчеты как проблемы. Они просто присутствуют в системе и постепенно становятся частью «нормы».
Особенно это начинает ощущаться в какой-то момент у тех, кто отвечает за бюджет. Вроде бы мощности есть, оборудование закупается, ресурсы распределяются — а ощущение что это помогает не появляется. Наоборот, кажется, что инфраструктура становится тяжелее, сложнее и дороже.
И вот здесь DCIM неожиданно оказывается полезен не только как инструмент мониторинга, но и как способ посмотреть на инфраструктуру с финансовой точки зрения.
Один из самых частых сценариев — это так называемые «зомби-серверы». Формально с ними всё в порядке. Они стоят в стойках, числятся в системах, к ним, возможно, даже есть какое-то историческое описание.
Но если посмотреть на них через данные DCIM, возникает странное ощущение. Сервер стабильно включен, потребляет энергию, греется — то есть физически ведет себя как обычный рабочий узел. При этом его профиль почти не меняется. Нет характерных колебаний нагрузки, нет реакции на время суток, нет ощущения, что он участвует в каком-то процессе.
DCIM, конечно, не делает выводов за человека и не выносит вердикт «этот сервер не нужен». Но он очень наглядно показывает: поведение этого узла не похоже на поведение систем, которые реально участвуют в работе.
А дальше уже начинается нормальная инженерная работа — разобраться, что это за сервер и зачем он вообще существует.
В одной инфраструктуре как раз обратили внимание на несколько таких систем. Они выделялись не потому, что создавали проблемы, а потому что выглядели слишком «спокойными». Ровное энергопотребление, минимум изменений — как будто они живут отдельно от остальной инфраструктуры.
На уровне ИТ это никого не беспокоило. Серверы есть, не падают, жалоб на них нет.
Когда начали разбираться, картина оказалась довольно знакомой. Часть этих систем когда-то действительно выполняла важные задачи, но давно их не делает. Часть дублировала сервисы, которые уже перенесли в другие контуры. И почти все они до сих пор существовали по одной простой причине — их просто не стали выключать.
«На всякий случай» — формулировка, которая в таких историях встречается чаще всего.
В результате после аккуратной ревизии освободили мощности, снизили потребление и, что не менее важно, упростили саму инфраструктуру. Потому что любой лишний элемент — это не только расходы, но и потенциальный источник неопределенности.
Есть и другая, менее очевидная история — избыточные резервы.
Резервирование — вещь правильная и необходимая. Но только до тех пор, пока оно осмысленно и контролируемо. На практике часто происходит следующее: под конкретную задачу закладывается запас по мощности или размещению. Со временем задача меняется, а запас остается.
Более того, он начинает жить своей жизнью. На него ориентируются новые решения, его учитывают в планировании, но никто уже не помнит, под что он изначально создавался.
В какой-то момент возникает странная ситуация. Формально ресурсов не хватает — всё занято. Но если посмотреть на реальные данные, становится видно, что значительная часть мощности просто не используется.
В одной площадке регулярно возвращались к вопросу нехватки мощности. Новые проекты упирались в ограничения, обсуждалось расширение.
При этом данные DCIM показывали довольно неожиданную картину. Существенная часть мощности была закреплена за системами, которые давно не использовали ее в полном объеме. Но поскольку это нигде не пересматривалось, ресурсы продолжали считаться занятыми.
Получалась почти парадоксальная ситуация: мощности вроде бы нет, но при этом она есть — просто «застряла» в старых распределениях.
Когда это стало видно, удалось перераспределить ресурсы и отложить инвестиции в расширение. Без каких-то сложных проектов — просто за счет того, что картину посмотрели не на уровне отчетов, а на уровне реального потребления.
На первый взгляд всё это выглядит как разговор исключительно про эффективность. Но довольно быстро становится понятно, что здесь есть и вторая сторона.
Любая инфраструктура, в которой есть элементы с непонятным назначением, становится менее прозрачной. Сложнее понять, что происходит, сложнее контролировать изменения, сложнее быть уверенным, что всё работает именно так, как задумано.
И в этом смысле «лишние» или «забытые» ресурсы — это не только про затраты. Это еще и про риск. Потому что именно в таких зонах чаще всего возникают проблемы, которые никто не ожидал.
Финансовые потери в инфраструктуре редко выглядят как проблема. Они скорее выглядят как привычка. Что-то оставили «на всякий случай», что-то не стали пересматривать, что-то просто не трогали, потому что и так работает.
DCIM в этой истории полезен тем, что возвращает разговор в плоскость фактов. Он не оценивает решения и не подменяет собой людей, но очень четко показывает, где поведение системы отличается от ожидаемого.
И этого оказывается достаточно, чтобы начать задавать правильные вопросы.
А дальше, как правило, находятся и деньги, и риски, и возможности что-то сделать проще и понятнее.
В следующей статье посмотрим на еще одну чувствительную зону — человеческий фактор. Потому что даже самая аккуратно спроектированная инфраструктура начинает вести себя неожиданно, когда в нее активно вмешиваются люди.