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