k1sap1d
Зарегистрирован: 01 янв 1970, 03:00 Сообщения: 37
|
Назрел вопрос разработки некоего внутреннего стандарта\подхода к документации на сеть. Необходим для облегчения взаимодействия и понимания между небольшой группой сетевых администраторов. Имеем на входе 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 у цыски, но не нашел какой либо конкретно информации по нему.
Поэтому хотелось бы услышать ваши подходы к документации и критику в адрес своего предложения:)
|
k1sap1d
Зарегистрирован: 01 янв 1970, 03:00 Сообщения: 37
|
согласен, но если не делать с точностью то последнего пользователя и сеть не обладает постоянно динамикой, т.е. в ней не каждый день подключают по 10-ку свичей, подход с ведением документации вполне оправдан.Да же оправданно резервное хранение документации в бумажном виде, ибо с случае серьезных аварий она надежной любой системы.
|