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

Необходимость знать установленное программное обеспечение, думаю, ни у кого не вызовет вопросов. Вы должны чётко знать, что работает на ваших серверах и как оно используется. Это нужно по многим причинам, одна из которых – слежение за анонсами обнаружения уязвимостей, выпусков патчей и так далее. Чем больше вы знаете о своём «хозяйстве», тем эффективнее можете им управлять и использовать в работе. Наверное, каждый системный администратор «находил» на одном (а то и нескольких) сервере «забытые» сервисы.

Логичным продолжением описания ПО станет описание предоставляемых сервисов. Другими словами, чёткое изложение, какую роль в работе сети играет тот или иной сервер, кого он обслуживает и за что отвечает. Может быть, в момент составления такой структуры вы поймёте, что тот или иной сервис было бы неплохо перенести на другой сервер.

Под сетевым подключением подразумевается IP-адрес сервера, а если он находится во внешней сети, то и открытые во внешний мир сервисы. Если вам потребуется срочно ограничить сетевую активность на определённых портах, то по составленному документу вы чётко будете знать, что делать. Конечно, каждый системный администратор скажет, что уж он-то точно знает, где находятся какие сервисы. Поверьте на слово, временами все знания имеют свойство вытесняться более новой и свежей информацией. Поэтому лучше всё же это занести в документацию, тем более что много времени это не займёт.

Описание сервисов и их конфигурационных файлов

После того как вы описали сервера «в целом», пришло время описать более подробно используемые сервисы. Я не призываю вас рассказывать на десятках страниц работу вашего доменного леса. Однако каждый, кто хоть раз настраивал (например) почтовую систему на операционной системе Linux, знает, какое количество возможных вариантов может быть. Начиная от выбора MTA, заканчивая скриптовыми обвязками, настройками авторизации, схем используемых баз данных и так далее.

Поэтому было бы не лишним описать для начала настройки ключевых сервисов в отдельном документе. Я бы рекомендовал использовать для этого систему вроде NPJ (читайте о ней в журнале «Системный администратор» №11 за 2005 год). Причин для этого несколько, и все они сводятся к одному – удобству.