Задача решаема и при наличии ОТ даже почти бесплатно.
Первое, что надо сделать — выписать все замеченные сервисы, и для бизнеса (SLA) и междусобойные (OLA). Так удастся в дальнейшем выявить и обработать потребителей.
Затем напротив каждого пункта (сервиса) перечислить известные ресурсы, его обеспечивающие. Тоже всё просто, идти от железа вверх до ОСи и конечной прикладухи. Сеть или жизнеобеспечение тут учитывать рано, т.к. они в итоге всё равно делятся на всех и чтобы поделить правильно, надо отдельно мерить нагрузки, контуры вращения информации, её классифицировать, в общем, возиться…
Кстати, эти два шага в любой майндмеп проге удобно сделать.
На выходе получаем прообраз Р-С модели, но он пока неуправляем. Тут методов фактически нет: все ресурсы, создающие сервис суть активы, по ним придётся создать и вести учёт. Что может дискавериться — выбрать софт, которым — и регулярно дискаверить (аналог бухгалтерской инвентаризации), что не ловится автоматическим образом, но важно видеть — снимать слепки руками.
Даже автоматически собираемая конфигурация — уверен — большей части ресурсов для большей же части сервисов из каталога существенно разгрузит и даст время на разбор труднодоступных ресурсов.
Проводите первичное наполнение CMDB, увязываете найденное с каталогом в ОТ и вуаля: осталось привязать потребителей и картина становится почти готовой.
Capacity не ведут без учета конфигураций, это еще со второго ITIL'а было очевидно.
По вопросам о ресурсах непонятно, о каких речь. Файловых? Тут если есть деньги можно хороших тулзов купить, ключевое словосочетание data governance, а вообще методически вы сейчас видите т.н. unstructured data, а цель — сделать из них structured. Это большой проект, не меньше capacity, а по подходу почти идентичный: посчитать, классифицировать, выявить потребителей, пожурналировать пользование и затем, набрав фактических данных, пересобрать структуру папок/ACL и правил работы с ними.
По последнему вопросу: лезть в тему внутренних SLA/OLA (есть еще и underpinning contracts, UC) сразу в ваш нынешний момент времени не советую. К учету должны привыкнуть, вы должны понять, что любые неавторизованные изменения конфигураций или использования ресурсов умеете ловить и насколько прозрачно и быстро.
Как только изменения получится отслеживать хотя бы в течение ближайших суток — можно начинать подстрекательство: сообщать потребителю сервиса и виновнику о том, что в сервис пришла нагрузка и его допустимая емкость почти исчерпаны. Они сами разберутся несколько раз, а потом устанут и попросят единый порядок. Вот тогда уже и можно будет расписывать все эти агрименты.
Как-то так…
