- сервисы
Документировать сервер — важная, но объемная монотонная задача. Системные администраторы часто откладывают ее на завтра, потом на послезавтра, а иногда и вовсе игнорируют, доверяя инструментальным методам документирования. К сожалению, такой подход не работает для бизнеса на стадии запуска и в командах, где виртуальный сервер используется как временное решение. Именно для таких ситуаций мы и предлагаем нижеследующий план документирования сервера.
Паспорт сервера
Первая часть плана — паспорт сервера. Для физического сервера в нем описывается аппаратная часть, установленное ПО и предоставляемые сервисы, отмечаются сетевые подключения и условия гарантийного ремонта на случай выхода из строя. Для виртуального достаточно указать:
- параметры RAM, vCPU, тип дисков со свободным местом,
- RAID или LVM,
- входит ли сервер в домен и если да, то в какой.
Базовая и детализированная документация
Базовой считается документация, если она пишется для сбора основных данных по ИТ-отделу. Руководству может быть достаточно имени сервера, операционной системы и выполняемых задач. Коллегам и будущим коллегам нужна более детальная информация, которая поможет разобраться в запускаемых службах, проанализировать статистику сбоев, отыскать данные о резервных копиях. При детализированной документации сервера должны быть отражены следующие пункты:
- имя/название,
- тип, допустим VDS,
- операционная система и пакет обновлений,
- роль в компании (почтовый сервер, файловый сервер и пр).,
- домен, если есть,
- IP адрес,
- расположение (физическое и логическое),
- режим обновления (кто, когда и с какой регулярностью),
- план резервного копирования и инструменты его выполнения,
- конфигурация и настройки безопасности,
- установленные бизнес-приложения, которые запускаются на сервере,
- через какой сетевой протокол администрируется сервер.
В следующей части прописываются задачи. По каждой регулярной задаче расписывают планировщики: для Linux делают crontab с комментариями, для Windows — файл TaskExport.txt. Для кластеризованных приложений указывается тип приложения, адреса и типы ноды. Для систем мониторинга составляется список отслеживаемых сервисов с частотой получения исходных данных, описывается алгоритм сбора, идентичность результата повторной проверки.
Отдельная часть документирования сервера посвящается обновлением Windows и Linux. Здесь нужен специальный блок с датой установки последнего обновления и его нюансами. Если какие-то обновления ломают систему, их указывают с описанием последствий.
Учетные записи, доступы и безопасность
Нельзя просто взять и прописать аутентификацию по файлам /etc/passwd или составить список всех учетных записей пользователей. По каждой из них у администратора должна быть информация: имя, домен, членство в группах, задачи, уровень прав.
Для хранения доступов можно использовать приложение для хранения паролей. При этом копии имеет смысл резервировать в менеджере паролей, например, Kaspersky Password Manager. Резерв нужен на тот случай, если общая система будет недоступна.
Чтобы легко разобраться с правами учетных записей, при документировании сервера на Windows можно настроить гранулярные права и задействовать роли в AD. На Linux документировать настройки прав помогают утилиты командной строки:
- adduser — создание пользователя,
- usermod — изменение данных для входа пользователя,
- chsh -s /bin/rbash — изменение командной оболочки,
- mkdir /home/limiteduser/bin — создание новых каталогов
- chattr +i ограничение доступа к каким-либо важным файлам или возможностям системы.
При проведении антивирусной проверки в документе отмечается результат и дата следующего контроля.
Для рабочих доменов сохраняются имя, TTL, тип и значение DNS-записей. Для SSL-сертификатов — весь набор реквизитов, включая стоимость, издателя, данные контактного лица. Для регулярных выгрузок указывается основная информация по типу, назначению и адресатам. Если интернет-магазин или сервис услуг делает рассылки по e-mail базам, лучше завести раздел с информацией по публикуемым данным и отмечать там назначение рассылок и список адресатов. Или сделать ссылку на отдельную статью, где можно посмотреть назначение документации и базу, если она объемная.
Резервирование
В блоке «Резервирование» документация по серверу должна описывать что, чем и насколько регулярно резервируется. И обязательно где, чтобы при сбое можно было достать копии и заново поднять виртуальные машины. В идеале это должно выглядеть так:
«Частота копирования — каждую пятницу в 23:00. Инструментом N в S3 Nubes».
В дополнениях хорошо бы дописать, когда откатывались на последнюю резервную копию и по какой причине.
Если следовать плану, в итоге получается достаточно объемный документ, требующий приличного объема ручной работы. Поддерживать его сложнее, чем мониторить сервер и контролировать актуальность документации с помощью инструментов Ansible, Terraform или Puppet. Однако в этой публикации мы не противопоставляем инструментальное документирование ручному. Мы задаем направление и показываем базовый план документирования сервера, чтобы стартапы и бизнес на начальных этапах работы видели опорные пункты процесса. План помогает быстро сориентироваться, что, зачем и с какой регулярностью фиксировать, при этом даже начинающий администратор сможет поддерживать систему в рабочем состоянии.