Назрел вопрос разработки некоего внутреннего стандарта\подхода к документации на сеть.
Необходим для облегчения взаимодействия и понимания между небольшой группой сетевых администраторов.
Имеем на входе 3-4 относительно небольших сети 500-3000 пользователей, в каждой из которых зоопарк железа\линий связи\идеологий решения проблем и свой сетевой админ средней руки (знания где то между CCNA и CCNP).Чтобы хоть как то понимать что происходит у других хочется начать с общего подхода к документации.
Собственно у меня возникла идея попытаться разбить документацию аналогично с уровнями OSI, но в схемах указывать отсылки к ниже\выше стоящему уровню для общей связанности.В итоге сформировал примерно следующий список документов с примерным содержанием:
1)Территориальный план на карте местности(здания) с точной привязкой к место положению, отражаются:
а)узлы связи(помещения,здания)
б)линии связи (оптика, медь, РРЛ и т.д.) с указанием кол-ва пар, типа линии, точных характеристик линии
2)Физический план (L1 OSI)
а)Условно обозначаются узлы связи
б)детально описываются все железки (вплоть до SFP модулей и media- конверторов)
в)детальное описание каждой линии связи с указание портов подключения как на оборудовании, так и на различных патч\кросс панелях.
3)Коммутационный план L2
а) условно обозначаются линии связи
б)условно обозначаются узлы связи (помещения, здания и т.д.)
в) детально описываются используемые vlan-ы (номер, адресация) с привязкой к портам оборудования
г) детально описываются порты оборудования (режим trunk\access, наличие под интерфейсов, привязанные адреса)
3)Общий маршрутизационный план L3
А) условно обозначаются железки, линии связи, и их местоположение
б)детально описываются логические интерфейсы оборудования с указанием примененных к ним механизмов обработки трафика
в) общее описание механизмов обработки трафика (ACL, NAT, PBR и т.д.) задействованных на железке.
4) Индивидуальный план работы приложения\сервиса L4. Составляется для каждого сервиса или приложения отдельно, либо для группы однотипных.
а) условно обозначение железок и линий и интерфейсов
б)Детальное описание механизмов воздействующих на трафик приложения\сервиса. С точностью до строчек конфига и порядком обработки.

Я не сумел найти каких либо стандартов описания подобных вещей, поэтому пришлось изобрести велосипед:)
ГОСТ 34-ой серии подходит для разработки ПО, но не для сетей. Натыкался на отсылки на некий модуль CTI в курсе CCNP у цыски, но не нашел какой либо конкретно информации по нему.

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

Любая документация не будет соответствовать действительности. Нужен онлайн подход.

Например ipswitch или Prime Infrastructure

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

удачи