Призраки инфраструктуры: кто ответит за сервер, у которого нет владельца

Инцидент открыт 30 минут назад. Сервер prod-db-07 лежит.

Поле «владелец» в системе — прочерк. Оператор пишет в рабочий чат:

Оператор: Коллеги, кто-нибудь знает, чей это prod-db-07?
— …
(в чате тихо)

Эскалировать некуда: нет ответственного, и некому принять решение — ребутить, менять или списывать. SLA горит. Минуты простоя капают.

Так происходит, когда система управления ИТ-активами (ITAM) и ITSM живут раздельно: сервисные процессы фиксируют инциденты, а учёт активов — владельцев, и между ними нет автоматической связи. Каждое увольнение, реорганизация или закрытый без обновления статуса тикет плодит новых «призраков» — активы, которые физически работают, но юридически никому не принадлежат.

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

Ничейный сервер: откуда берутся призраки

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

У этого явления есть несколько родственных форм:

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

Теневой актив — куплен в обход учёта. Устройство или подписка, заведённые мимо централизованного учёта: ITAM о его существовании вообще не знает — а значит, не патчит, не продлевает и не считает. Всплывает внезапно — при аудите, инциденте или когда за него приходит счёт. Про теневое ПО и стек, который реально живёт в инфраструктуре — отдельно

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

Как появляются такие активы:

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

• Отдел расформировывают или реорганизуют — серверы и лицензии переходят по наследству, но никто формально не берёт их на баланс.

• Инцидент закрывают в ITSM, но статус и владелец актива в ITAM не обновляются автоматически — системы синхронизируются вручную или не синхронизируются вовсе.

Скорее всего, prod-db-07 из вводной сцены — типичный второй или третий случай: отдел расформировали или инцидент закрыли, не обновив данные в CMDB.

По данным исследования SimpleOne, каждая пятая компания ведёт учёт ИТ-активов вручную в Excel, а 80% оценивают зрелость своих ITAM-процессов не выше 3 из 5.

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

Проблема в рассинхроне ITAM↔ITSM

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

Потери от этого разрыва измеримы, и это не только часы простоя:

• Часы даунтайма — время, потраченное не на устранение неисправности, а на поиск владельца и согласование действий.

• Задублированные закупки — компания заказывает новое оборудование, не зная, что похожий актив уже простаивает на складе или у другого отдела.

• Лицензии, которыми никто не пользуется — подписки продолжают оплачиваться, потому что фактического использования никто не видит на стороне ITSM.

Пятница, 23:47 Дежурный инженер получает алерт: prod-db-07 не отвечает

Открывает ITSM — поле «владелец» пустое.

Открывает CMDB — последний известный ответственный уволился в ноябре.

Пишет в чат дежурных — тишина.

Звонит тимлиду инфраструктуры — тимлид не знает, что это за сервер.

Звонит DBA — DBA говорит «это не мой, я свои знаю».

Открывает мониторинг — сервер обслуживал три микросервиса, один из них — авторизация в мобильном приложении. 40 000 пользователей не могут залогиниться. Служба поддержки принимает восьмой звонок за минуту.

00:12 Инженер находит в почте уволившегося коллеги письмо двухлетней давности: «Серёг, я поднял базу на prod-db-07, пароль root/root, потом поменяю». Не поменял. Серёга уволился. Инженер ребутит сервер под root/root. Сервер поднимается. Авторизация работает.

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

Постмортем писать некому — владельца нет. Утром CTO спросит, почему упало.

Ответ будет один. Призрак.

Сколько стоит один призрак

Вернёмся к prod-db-07 из начала статьи.

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

Cost = T_поиск × (C_инж + C_бизнес), где у нас:

• T_поиск — сколько минут потрачено на «чей это сервер», а не на починку;

• C_инж — стоимость поднятых по тревоге инженеров в час (loaded, с налогами и overhead);

• C_бизнес — стоимость простоя сервиса в час.

Важный момент, который обычно теряют: во время поиска сервис лежит так же, как во время ремонта. С известным владельцем авария была бы на 20 минут короче — значит, к времени инженеров прибавляется полная стоимость бизнес-простоя за этот же интервал. Инженерное время — это меньшая часть счёта.

Возьмём осторожные значения для нашего prod-db-07:

• T_поиск = 20 мин (0,33 ч);

• C_инж = 3 человека (дежурный + тимлид + DBA) × 3 000 ₽/ч loaded = 9 000 ₽/ч;

• C_бизнес = 50 000 ₽/ч (для сервиса с внешними юзерами — консервативно).

Cost = (20/60) ч × 59 000 ₽/ч ≈ 19 700 ₽ (инженеры 3 000 + бизнес 16 700)

Из них на инженеров — 3 000 ₽. Остальные 16 700 ₽ — это бизнес, который лежал лишние 20 минут только потому, что база данных владельцев не встретилась с базой инцидентов.

При пяти инцидентах в квартал — около 390 000 ₽ в год. И это нижняя граница: у критичного внешнего сервиса C_бизнес не 50 000, а 200 000+ ₽/ч, и тогда счёт уходит в миллионы.

Частота растёт вместе со сценарием не случайно: чем хуже учёт, тем чаще ничейный сервер вообще доживает до аварии.

Как остановить появление новых призраков

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

Начнём с того, как вообще найти призрака, которого в учёте нет. Для этого есть дискаверинг: платформа сканирует сеть и инфраструктуру и показывает то, что реально работает, — сопоставляя это с тем, что числится в учёте.

На стыке всплывают две категории: активы, которых нет в базе вообще (теневые), и записи, у которых протух владелец или связь с КЕ (призраки и CI-призраки). Дискаверинг не назначит ответственного за вас — но переведёт сервер из «мы не знали, что он есть» в «вот он, вот когда выпал из учёта, вот с чем был связан». Дальше — уже дело живого решения.

Когда ITAM и ITSM работают как единое целое:

• Инцидент сам подтягивает владельца из учётной системы в момент открытия заявки — оператору не нужно писать в чат «чей это сервер»;

• Закрытие инцидента синхронно обновляет статус актива — данные не расходятся с реальностью на следующий день;

• Даже без указанного владельца видна история — последний ответственный, отдел, дата, когда актив выпал из учёта. Это заметно быстрее, чем опрос коллег в чате;

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

Такой подход закрывает ничейный сервер и CI-призрак за счёт синхронизации ITAM и ITSM. С теневыми активами он не справится: для них нужен отдельный контроль закупок и подключения нового оборудования к учёту.

Та же логика работает и на входе: выдал сотруднику новый актив — владелец фиксируется сразу, и устройство не начинает путь к статусу «призрак».

***

Сколько у вас серверов без владельца прямо сейчас — вы узнаете об этом от аудитора в плановую проверку или ночью, когда такой сервер упадёт под нагрузкой?