как вы документируете сеть?

<p>я не уверен, как задать этот вопрос, так как я не в поле. допустим, вы администратор сети и уходите с работы. как новый парень знает, с чего начать?</p>

<p>это зависит, помимо прочего, от размера сети, количества пользователей, количества узлов (компьютеров, серверов, принтеров и т.д.) и численности вашего ит-персонала.</p><p>это также зависит от вашей цели. вы документируете сеть для целей обучения и обслуживания, страхования/предотвращения потерь и т.д.?</p><p>лично я документирую свои сети таким образом, что я знаю, что могу получить любую недостающую информацию на основе того, что <em>is</em> задокументировано. с практической точки зрения, есть смысл уменьшить отдачу, когда ваша документация становится слишком детальной.</p><p>хорошее эмпирическое правило, которое я использую, заключается в том, что в известном месте должна быть достаточно тщательная документация, чтобы, если сегодня вечером меня ударит автобус, другой администратор сможет сохранить работоспособность базовой сети, пока он/она заполняет недостающие фрагменты над следующие несколько дней/недель.</p><p>вот краткий обзор того, что я считаю наиболее важным в одной из моих сетей. для справки: это магазин для windows, в котором около 100 пользователей и 5 офисов.</p><ul> <li>учетные данные администратора для всех серверов. очевидно, что это должно быть в безопасности.</li> <li>ip-адреса и имена netbios для любого узла в сети со статическим ip-адресом, включая серверы, рабочие станции, принтеры, брандмауэры, маршрутизаторы, коммутаторы и т.д.</li> <li>основная информация об оборудовании сервера, такая как метки обслуживания или эквивалент, общая емкость диска, общая память и т.д.</li> <li>основные роли каждого сервера, такие как контроллер домена, файловый сервер, сервер печати, сервер терминалов и т.д.</li> <li>расположение резервных копий лент/дисков.</li> <li>информация о номерах учетных записей и учетных данных для таких служб, как поставщики голосовых услуг и данных удаленного офиса.</li> <li>внешний dns для сайтов и маршрутизации.</li> </ul><p>если бы в настройке или рабочем процессе было что-то странное, что не было бы сразу очевидно для нового администратора, я бы также написал краткое "краткое" об этом.</p>

<p>я считаю, что лучше всего включить все следующее:</p><ul> <li>проза: общий обзор в форме абзаца, который помогает с начальной общей картиной, а также может описать эволюцию с течением времени</li> <li>таблицы: табличные списки, с адресной, экологической или машинной (желательно все вышеперечисленное)</li> <li>диаграммы: обязательно нужны диаграммы с несколькими уровнями детализации. в любой приличной сети просто невозможно разумно захватить все это на одной странице и сделать ее легко усваиваемой. вам нужна одна диаграмма на глобальном уровне с инфраструктурными устройствами (маршрутизаторы, коммутаторы, конечные точки туннеля и т.д.), а другая - для вычислительных ресурсов, предоставляемых каждым из этих маршрутизаторов или конечных точек.</li> </ul><p>дополнительные примечания о диаграммах ... географическое распределение - это простой способ сегментировать, но вам также нужны логические представления, основанные на функции установки. кроме того, маркируйте как сумасшедшие, полностью используя шрифты и цвета.</p>

<p>наиболее эффективный и тщательный способ запустить этот процесс - создать его из сценария аварийного восстановления, например здание загорелось, и все, что у нас есть, это резервные копии за пределами площадки. что нам нужно сначала купить, и как это нужно будет настроить?</p><p>кайл уже дал отличные детали, но я обнаружил, что подход dr помогает мне разбирать вещи по одному.</p>

<p>где я работаю - мы столкнулись с той же проблемой, когда я впервые начал здесь. по мере увеличения количества серверов и сервисов вы найдете все больше устаревшей документации, и с этим неизбежно возникает необходимость для персонала не доверять документации, по крайней мере технической документации по именам серверов, группам серверов, сетям и т.д.</p><p>мы начали разработку проекта с открытым исходным кодом под названием <a href="http://projects.autonomy.net.au/hotwire">hotwire</a> , чтобы решить эту проблему ...</p><ul> <li>система инвентаризации (серверы, сети и т.д.)</li> <li>сборки сервера - rhel kickstart, suse autoyast, (todo: debian preseed, solaris jumpstart)</li> </ul><p>объединяя систему инвентаризации с системой сборки, мы гарантируем, что то, что находится в базе данных, согласуется с тем, что находится в наших центрах обработки данных, потому что теперь мы должны сначала ввести данные в инвентаризацию, чтобы иметь возможность строить серверы ,.</p><p>клиентская программа (funcwire) затем устанавливается на все серверы (как часть процесса сборки), которая затем динамически следит за аппаратным обеспечением сервера, о чем сообщает <a href="http://projects.autonomy.net.au/python-dmidecode">python-dmidecode</a> , и что находится в инвентаре, так что если что-то изменится, администраторы узнают об этом немедленно.</p><p>затем мы интегрировали нашу вики-систему так, чтобы каждый сервер, стойка, проект, модель оборудования и т.д. в hotwire связывались непосредственно с соответствующей вики-страницей.</p><p>следовательно, мы "задокументировали" наши серверы/сеть/и т.д., используя hotwire + вики (здесь мы используем слияние, но подойдет любая приличная вики). (обратите внимание, что после того, как серверы построены - hotwire не изменяет их каким-либо образом - текущее управление осуществляется через cfengine).</p>

<p>я использую mikrotik dude для автоматического планирования, это замечательное приложение, учитывая, что оно бесплатное. он также может отслеживать текущее состояние. <a href="http://www.mikrotik.com/thedude.php">чувак веб-страница</a> </p>

<p>ответ кайла - отличный совет. хотя, по крайней мере, вы могли бы уйти с перечисления:</p><ul> <li>серверы (включая имена хостов, ip-адреса и роли)</li> <li>сетевое оборудование (коммутаторы, маршрутизаторы, межсетевые экраны)</li> <li>архивы мастер-паролей (доменные пароли, пароли администратора)</li> <li>грубый документ с изложением сетевых политик и любых странных настроек (включая здесь любые выбросы, такие как машины, которые не являются частью домена (ов))</li> </ul>

<p>кайл ноланд и другие постеры много рассказали о том, как документировать. мы работаем над созданием стандартного веб-программного обеспечения (размещенного вами внутри), которое позволит сетевым и системным администраторам документировать свою сеть.</p><p>на момент написания этой статьи (апрель 2012 г.) у нас есть следующие аспекты, касающиеся программного обеспечения:</p><ul> <li>документация по центру обработки данных.</li> <li>сведения об устройстве (включая сведения о hw/os)</li> <li>управление ip-адресами</li> <li>отображение зависимости приложения</li> <li>отношения устройств - от зданий до виртуалов/блейдов.</li> </ul><p>вы можете прочитать больше <a href="http://www.device42.com/">здесь</a> , и мы будем благодарны за ваш отзыв.</p>

<p>для получения дополнительных руководств о том, как/что документировать, есть <a href="http://www.networkdocumentation.com/">networkdocumentation.com</a> .</p><p>для некоторых хороших примеров см. <a href="http://www.ratemynetworkdiagram.com">ratemynetworkdiagram.com</a> . например этот <a href="http://www.ratemynetworkdiagram.com/?i=10200">довольно хорошо</a> , а этот --- <a href="http://www.ratemynetworkdiagram.com/?i=1318">классно</a> ;).</p>

<p>подход к документированию сети как разработчик подходит к разработке системы ...</p><ul> <li> <p>рассмотрите требования - это было хорошо отмечено выше, но учтите, что воз собирается проконсультироваться с doc-o и для чего назначения. аудиторы будут искать и читать другие артефакты, чем одноранговый sysadmin.</p> </li> <li> <p>ведение документации - многие люди упомянули ценность диаграмм и карт, и как визуальный мыслитель я от всего сердца согласен. но эти вещи могут быть признаны недействительными одним актом добавления/удаления хоста. подумайте о "правильном" уровне документа, который ваша группа может поддерживать.</p> </li> <li> <p>дата все и включите заметки о том, почему вы настроили сеть так, как вы сделали. многие, многие забывают указать дату, но date предоставляет указатель на историю сети. незаменим для решения проблем, и это уменьшает внутреннюю устаревание большинства сетевых диаграмм.</p> </li> <li> <p>перенесите документацию в "процессы" - во многих случаях надежные и тщательно продуманные процедуры сборки/развертывания в конечном итоге оптимизируют "сетевую документацию", поскольку подробности конфигурации и наименования компьютеров лучше описаны в процедурах.</p> </li> </ul><p>ключевые выводы: подход к документации как "система"; он должен обеспечивать ценность с первого дня и несет с собой неотъемлемую ответственность за его поддержание.</p>

<p>на нашем сайте мы используем несколько систем для документирования наших собственных сетей и сетей клиентов. мы попробовали и потерпели неудачу с помощью множества методов/инструментов, которые не масштабировались, но теперь мы вполне готовы к следующему:</p><ul> <li> <a href="http://www.dokuwiki.org/dokuwiki">dokuwiki</a> для подсказок, подробного описания конфигураций и</li> <li>таблицы (patchport/mac/ip/hostname/role/admin-lookup для всех устройств, сети/vlan/vpn, обзор оборудования и т.д.)</li> <li>rss для распространения изменений на вики-страницах</li> <li>visio (лучшая компания, которую когда-либо покупали m $) рисовать диаграммы всего</li> <li>keepass for passwords, включая логины для тикет-систем поставщиков</li> <li> <a href="http://racktables.org/">racktables</a> для документирования расположения и исправления устройств</li> <li>система билетов, доступная для клиентов</li> <li>whatsup gold и другие инструменты для мониторинга и отчетности</li> <li>списки рассылки, чтобы держать людей в курсе</li> </ul><p>если кто-то имеет дело с большим количеством ip-сетей, <a href="http://www.phpip.net">phpip</a> может быть подходящим решением ipam.</p>

<p>обычно у вас есть несколько разных уровней детализации, похожих на абстракции в документации по разработке программного обеспечения. вы также документируете общие практики/процедуры/настройки устройства. административные пароли в зависимости от обстоятельств.</p><p>в идеальной ситуации почти все, что может понадобиться следующему человеку, легко доступно и задокументировано между вашим руководством и процедурными документами + схемами компоновки сети.</p><p>руководящие и процедурные документы, на мой взгляд, должны быть централизованы, где бы ни находились все документы по ит, а сетевые диаграммы могут иметь собственную структуру папок для нескольких мест.</p><p>в случае многих спутниковых сайтов, таких как walmart/targer/home depot, у вас будет общий документ для всех филиалов, а затем некоторые подробные документы всей корпорации о соединениях в главном офисе, а затем вы сможете погрузиться в документы локальной сети офиса.</p>

<p>я предлагаю <a href="http://opennetadmin.com">http://opennetadmin.com</a> . это многое из того, что люди предложили в других комментариях.</p>

<p>карта и документация вашей сети может стать хорошим способом передачи необходимой информации. ms visio - это инструмент для построения диаграмм, но он статичен и на него приходится тратить много времени. я обнаружил, что netbrain - это идеальный инструмент для построения сетевых диаграмм. он может мгновенно документировать сеть, а документацию можно экспортировать в visio или word. я могу настроить содержимое, которое я хочу, при документировании моей сети. индивидуальное содержание включает в себя: </p><ol> <li>содержимое инвентаря, такое как серийный номер, версия ос и т.д. </li> <li>содержание, связанное с дизайном, такое как динамическая маршрутизация, qos, фильтрация трафика </li> <li>содержание, связанное с трафиком… </li> <li>содержимое файла конфигурации </li> <li>схема</li> </ol><p>вы можете попытаться <a href="http://www.netbraintech.com/instant-trial">задокументировать свою сеть</a> на сайте.</p>

<p>как уже упоминалось, это зависит от ряда факторов ...</p><p>моя цель состояла в том, чтобы иметь достаточную документацию, чтобы я мог (по крайней мере, концептуально) передать все это коллеге и сказать: "увидимся через 3 недели" и знать, что все важные детали были там.</p><ul> <li>пароли для всех серверов и устройств (коммутаторы, принтеры и т.д.)</li> <li>пароли для любых сайтов, требующих регистрации - isp, регистрация доменного имени, гарантии на оборудование, центры сертификации и т.д.</li> <li>карта используемых ip-адресов - внутренний, внешний, dmz, блоки dhcp и т.д.</li> <li>подробная информация о каждом сервере: стандартные данные, такие как серийный номер, количество диска, оперативной памяти и т.д., но мы также вели постоянный журнал всего, что было сделано с коробкой, начиная с замечаний по установке (o/s и app. install), потом буду конфигурацию и последующие изменения.</li> </ul><p>мне никогда не удавалось сделать это полностью, но я стремился документировать все основные рутинные процессы - как настроить серверы, как и что контролировалось, настройка и удаление аккаунта, резервное копирование и т.д.</p>

<p>обычно это не документируется, но если вы добры, вы обычно делаете это в таких программах, как visio или эквивалент с открытым исходным кодом. наиболее важной информацией является то, какое оборудование к чему подключено, и пароли для любой консоли управления. остальное обычно можно угадать.</p>

<p>в моей предыдущей карьере в качестве ит-менеджера моя папка для документации включала диаграмму visio для всех устройств, список распределений диапазонов ip-адресов, все ключи продукта для windows/office/acrobat, инструкции по установке на новых компьютеры с пошаговыми инструкциями, как выполнить полную инвентаризацию оборудования до уровня компонентов и, наконец, список телефонов экстренной помощи, но не в последнюю очередь: техническая поддержка интернет-провайдера, техническая поддержка производителя маршрутизатора и т. д.</p>

<p>я использую такие инструменты, как microsoft visio или whatsup gold, чтобы наметить топологию сети, если это поможет.</p>

<p>ms visio - это хороший способ документировать сеть, но это не бесплатное решение. gliffy - это хороший продукт, если вы хотите снизить расходы.</p><p>типичные сетевые диаграммы показывают, как информация течет через ваши устройства (и обычно выходит в интернет). таким образом, на вашей диаграмме должна быть информация о том, где находятся ваши компьютеры, принтеры, wap, ip-телефоны (если применимо), коммутаторы и маршрутизаторы и как они подключены. ip-адреса также могут быть включены с именем вашего устройства. это полезно, если вы хотите взглянуть на диаграмму для получения информации на лету.</p>