Если говорить о технической документации для использования внутри компании, то первое, что приходит на ум, это описание сетей и серверов. Как правило, принцип «одна компания – один сервер» уже мало где практикуется. Парки пользовательских машин увеличиваются, а вместе с ними растёт и количество используемых серверов. Уже никого не удивляет необходимость разделять почтовый и веб-серверы, находящиеся во внешней сети, и файл-сервер, не имеющий доступ наружу.
Точно так же, как увеличиваются и усложняются серверные парки организаций, увеличиваются и размеры сетей. Появляется большое количество активного и пассивного сетевого оборудования, нуждающегося в некотором уходе и внимании системного администратора. На пограничных соединениях появляются специализированные устройства, маршрутизаторы и firewall. Структура локальной сети может стать совсем запутанной, если вовремя не внести систему и порядок в неё.
Архитектура сети
Первое, что интересует каждого системного администратора, приходящего на новое место работы, это архитектура сети, которой ему предстоит заниматься. И далеко не всегда он может получить исчерпывающую информацию. Очень часто приходится слышать что-то вроде «тут у нас хабы/свитчи, тут розетки, а вон там провода». Это, конечно, крайне далеко от действительно полезной информации.
Поэтому, создавая документацию на сеть, стоит подходить к этому так, как будто вы хотите заново узнать то, чем владеете.
Ниже я перечислю те пункты, которые, на мой взгляд, наиболее интересны были бы мне, как новому сотруднику компании:
n соответствие розеток к портам патч-панелей;
n соответствие подключения портов патч-панелей к портам сетевого оборудования;
n описание подключения на свитчах пользователей;
n описание подключения на свитчах серверов и соединений между свитчами;
n описание маршрутизации между сетевым оборудованием;
n таблица используемых IP-адресов рабочими станциями;
n графическая схема сети.
Разумеется, описать соответствие розеток с патч-панелями можно только в тех случаях, когда последние есть. Хочется верить, что в вашей компании они уже давно и успешно используются.
Описание подключения портов патч-панелей и свитчей необходимо вести в виде рабочего журнала, который дополняется и обновляется по мере переключений. Это нужно для полной ясности – что к чему подключено и как взаимодействует.
Под описанием подключения пользователей на свитчах подразумевается ваша схема разнесения рабочих станций по сетевому оборудованию. Предположим, что у вас в компании есть отдел дизайнеров, использующих в работе отдельный файл-сервер. (Отдельный, потому что размеры графических файлов весьма велики, и желательно их отделить от файлов обычных пользователей, чтобы последние не жаловались на чрезмерно долгое ожидание ответа сервера.)
Помимо использования файл-сервера для хранения своих наработок, дизайнеры зачастую обмениваются файлами большого размера между собой. Логично было бы подключить их на отдельный свитч.
Помимо самих предполагаемых дизайнеров, стоит на тот же свитч подключить и их файл-сервер, чтобы количество промежуточных соединений было минимальным. Это может оказаться весьма критичным для работы сети. (К слову, если фантазия на дизайнерах закончилась, то можно предположить разработчиков, использующих выделенный сервер баз данных.) Знать, к какому свитчу подключены серверы, полезно для анализа нестабильной и (или) медленной работы сети.
Если у вас используется «интелектуальное» сетевое оборудование и особенным образом настроена маршрутизация, это также стоит описать. В будущем это может пригодиться для анализа работы сети. Или, например, при переезде компании в новый офис. К слову сказать, зачастую быстро и правильно (эффективно) переподключить всё оборудование на новом месте без чёткой документации практически невозможно. А следовательно, возникают дополнительные простои в работе компании и общий дискомфорт от «неправильно» работающей сети.
Табличка в виде «Пользователь – IPадрес» (как вариант, можно добавить ещё и название рабочей станции) также не покажется лишней, когда количество сотрудников компании превысит 10-20 человек. Выдача IP-адреса новой рабочей станции не должна становиться для вас головной болью, а требуется для этого всего-навсего вести таблицу соответствий. Разумеется, задача может быть решена через DHCP-сервер, выдающий по MAC-адресам IP-адрес клиентам. Но если за пользователем закреплено несколько адресов или же по каким-то соображениям динамическая выдача адресов не используется, табличка окажется очень кстати. (Да и остальным она будет не лишней для более наглядного представления.)
Наглядно понять структуру всегда проще. Поэтому последнее, что хотелось бы упомянуть, – это графическая схема сети. Разумнее всего это делать на плане офиса. Здесь можно указать, как проложены кабели, где находится кроссировочный шкаф, где в комнатах установлены розетки и сколько их (причем не будет лишним указать не только розетки локальной сети, но и электрические). На этот же план можно нанести массу другой не менее полезной информации.
Разумеется, можно не ограничиваться перечисленными пунктами и дополнить свои. Но и перечисленного вполне достаточно для детального знакомства с вашей сетью.
Схема доступа в Интернет
Закончив описание локальной сети, дополните документ описанием схемы доступа в глобальную сеть. Опишите настройки вашего шлюза и firewall (например, если сделан проброс портов на внутренние адреса). Если у вас используется система переключения на резервный канал в случае падения основного, – расскажите и об этом тоже.
Информация о серверах
Что происходит на серверах и как они работают – это второй вопрос, интересующий любого системного администратора. Список информации, которую стоит указать:
n аппаратная часть;
n установленное программное обеспечение;
n предоставляемые сервисы;
сетевые подключения.
Аппаратную часть полезно знать для планирования увеличения ресурсов существующих серверов. Да и при обосновании предложений по закупкам нового оборудования лучше всего опираться на то, что имеется и почему имеющегося не хватает для удовлетворения потребностей компании.
Необходимость знать установленное программное обеспечение, думаю, ни у кого не вызовет вопросов. Вы должны чётко знать, что работает на ваших серверах и как оно используется. Это нужно по многим причинам, одна из которых – слежение за анонсами обнаружения уязвимостей, выпусков патчей и так далее. Чем больше вы знаете о своём «хозяйстве», тем эффективнее можете им управлять и использовать в работе. Наверное, каждый системный администратор «находил» на одном (а то и нескольких) сервере «забытые» сервисы.
Логичным продолжением описания ПО станет описание предоставляемых сервисов. Другими словами, чёткое изложение, какую роль в работе сети играет тот или иной сервер, кого он обслуживает и за что отвечает. Может быть, в момент составления такой структуры вы поймёте, что тот или иной сервис было бы неплохо перенести на другой сервер.
Под сетевым подключением подразумевается IP-адрес сервера, а если он находится во внешней сети, то и открытые во внешний мир сервисы. Если вам потребуется срочно ограничить сетевую активность на определённых портах, то по составленному документу вы чётко будете знать, что делать. Конечно, каждый системный администратор скажет, что уж он-то точно знает, где находятся какие сервисы. Поверьте на слово, временами все знания имеют свойство вытесняться более новой и свежей информацией. Поэтому лучше всё же это занести в документацию, тем более что много времени это не займёт.
Описание сервисов и их конфигурационных файлов
После того как вы описали сервера «в целом», пришло время описать более подробно используемые сервисы. Я не призываю вас рассказывать на десятках страниц работу вашего доменного леса. Однако каждый, кто хоть раз настраивал (например) почтовую систему на операционной системе Linux, знает, какое количество возможных вариантов может быть. Начиная от выбора MTA, заканчивая скриптовыми обвязками, настройками авторизации, схем используемых баз данных и так далее.
Поэтому было бы не лишним описать для начала настройки ключевых сервисов в отдельном документе. Я бы рекомендовал использовать для этого систему вроде NPJ (читайте о ней в журнале «Системный администратор» №11 за 2005 год). Причин для этого несколько, и все они сводятся к одному – удобству.
Если вы начинаете вести документацию по сети, то рано или поздно у вас может появиться желание дополнить её описаниями того, что вы настраивали. Например, это может быть описание настройки вашей почтовой системы. Давайте перечислим, что в это описание может войти:
n настройки MTA;
n настройки IMAP и POP3;
n система авторизации;
n описание антиспам системы;
n описание антивируса;
n описание системы авто-ответов (отсутствующих пользователей);
n описание листов рассылок.
Это те пункты, которые мне пришли сразу на ум, стоило подумать о нашей почтовой системе. Почему это полезно? Давайте предположим, что у вас не осталось копий ваших конфигурационных файлов, а сервер ввиду (например) выхода из строя жёсткого диска больше не функционирует. Конечно, рано или поздно вы вспомните все настройки, которые некогда на нём делали или же настроите альтернативную конфигурацию. Но сколько уйдёт на это времени?
Или другой вариант возможного развития событий. Вы сменили место работы, и возникла необходимость построения почтовой системы. Зачем заново изобретать велосипед, когда можно открыть некогда сделанное описание и буквально чуть ли не «по шагам» повторить. Удобно? Я считаю, что да.
Антивирусы и центры обновлений
Описывая серверы не забудьте упомянуть об используемых антивирусах. Это могут быть отдельные клиентские программы на каждом компьютере или корпоративные версии программ. Где серверное приложение занимается скачиванием обновлений и распространений их среди клиентских машин. Удобно, быстро и экономно.
А может быть, вы используете центры обновлений не только антивирусов. Их тоже стоит описать. Хотя бы чтобы помнить об их существовании и не забывать за ними следить. (Я говорю «помнить», потому что сам не раз забывал о них сразу после установки и настройки.)
Система резервного копирования
Когда вы закончили описывать сервера вашей компании, самое время описать используемую систему резервного копирования. Указать, какой из компьютеров за это отвечает, какое программное и аппаратное обеспечение для этого использует. Стоит также задокументировать и выстроенную вами схему хранения резервных копий.
Рисунок 1. «Рабочая» структура документации одной из компаний
Рисунок 2. Оглавление описания серверной группы
Итог
Разумеется, не все рассмотренные пункты являются минимально необходимыми при создании первых технических документов в вашей компании. Однако ведение документации на сеть и серверы только выглядит громоздкой и сложно реализуемой задачей. На самом деле по мере заполнения существующих пробелов вы поймёте, насколько это полезно и удобно вам же самим. Нет ничего более приятного, чем работать с сетью, о которой вы всё знаете и в любой момент можете дать ответ на любой вопрос. Главное – не останавливаться на достигнутом, а также не забывать следить за актуальностью составленных документов.
