Паспорт IT-инфраструктуры офиса: из чего он состоит и как сделать так, чтобы им пользовались

Паспорт IT-инфраструктуры — это документ на 20–40 страниц, по которому новый человек за день понимает, что стоит в офисе, как оно связано, кто за что отвечает и что делать при аварии. Ниже девять блоков паспорта, скрипты для сбора данных, выбор места хранения и правила, не дающие ему протухнуть.

Что такое паспорт IT-инфраструктуры и чем он отличается от инвентаризации

Паспорт IT-инфраструктуры — это короткий документ, по которому человек, впервые увидевший ваш офис, за один день понимает три вещи: что у компании стоит, как это связано между собой и кто отвечает за каждый кусок. Не опись железа и не рисунок сети, а их связка с ответственными, сроками и регламентами. Когда мы берём офис на ИТ-обслуживание, паспорт — первое, что я прошу показать. И в большинстве случаев показывать нечего: есть таблица в Excel трёхлетней давности, пара схем в Visio и память одного администратора.

Чем паспорт отличается от инвентаризации? Инвентаризация отвечает на вопрос «что у нас есть»: серийные номера, инвентарные номера, кто за каким компьютером сидит. Это плоский список, и он нужен бухгалтерии не меньше, чем админу. Про то, как такой список собрать без ручного обхода кабинетов, я уже писал в разборе про инвентаризацию IT-активов. Паспорт отвечает на другие вопросы: почему сеть разбита именно так, на каком сервере живёт 1С и от чего она зависит, куда уходят резервные копии, кому звонить, если упал интернет в субботу. Инвентаризация — это один из блоков паспорта, а не весь документ.

Читателей у паспорта четверо, и документ надо писать с оглядкой на каждого. Первый — ваш будущий администратор или подрядчик, которому предстоит разбираться в чужом хозяйстве. Второй — директор, которому нужно понимать, на чём держится бизнес, и принимать решения о деньгах. Третий — вы сами через год, когда забудете, почему так настроили. Четвёртый — проверяющий: страховая, аудитор, клиент, который задаёт анкету по безопасности. Для офиса до 50 рабочих мест не нужен паспорт по стандарту на сто страниц с рисками и матрицами. Нужен документ, который открывают в момент проблемы и находят ответ за две минуты. Если паспорт для этого не годится, его никто не будет вести.

Что записать в паспорт: девять блоков, без которых он бесполезен

Я собираю паспорт из девяти блоков. Порядок не случаен: сверху то, что нужно в аварии, снизу то, что нужно при плановых работах. Любой блок можно сократить до одной страницы, но выкидывать целиком я не советую: каждый из них однажды спасал меня на проектах. Ниже сводная таблица, дальше по каждому блоку — что именно писать и чего не писать.

Теперь о том, что я вкладываю в самые ходовые блоки. В сети самое ценное — не схема кабелей, а решения: почему выбраны именно эти подсети, где граница между гостевым Wi-Fi и рабочей сетью, какие правила межсетевого экрана нельзя трогать без согласования. Адреса и маски перечисляются таблицей, но к каждому диапазону нужна строка «зачем он нужен». В серверах я пишу не только модель и роль, но и зависимость: сервер приложений 1С ходит в такой-то SQL, тот живёт на таком-то хосте, а хост питается от такого-то ИБП. Именно эта цепочка нужна, когда в серверной щёлкнул автомат.

• Сеть: схема, подсети и VLAN с пояснением назначения, DHCP и DNS, провайдеры, каналы, номера договоров и телефоны поддержки.
• Серверы: роль, ОС и версия, расположение, зависимости, гарантия, плановая дата замены.
• Домен и доступы: структура OU, группы, где лежит менеджер паролей, порядок выдачи и отзыва прав.
• Копии: что и куда копируется, где хранится внешняя копия, когда последний раз проверяли восстановление.
• Сроки: сертификаты, домены, лицензии, гарантии, договоры с подрядчиками — у каждого дата и ответственный.

Как собрать данные за вечер, а не за месяц

Самая частая причина, по которой паспорт не появляется, — ощущение, что его нужно собирать вручную две недели. На деле больше половины сведений вытягивается скриптами, а руками остаётся то, чего в системах нет: назначение, владелец, договорные номера. Начинать я советую с домена: если у вас Active Directory, список компьютеров с операционной системой и адресом можно получить одной командой и сразу выгрузить в CSV для таблицы.

Get-ADComputer -Filter * -Properties OperatingSystem, IPv4Address, LastLogonDate |
    Select-Object Name, OperatingSystem, IPv4Address, LastLogonDate |
    Export-Csv -Path .\ad-computers.csv -NoTypeInformation -UseCulture

Команда требует модуль ActiveDirectory (он ставится вместе со средствами администрирования RSAT). Параметр -UseCulture берёт разделитель из региональных настроек, поэтому русская версия Excel откроет файл по столбцам, а не одной кашей. С кодировкой есть ловушка. Модуль ActiveDirectory чаще всего запускают в Windows PowerShell 5.1, а там Export-Csv по умолчанию пишет в ASCII, и кириллица в описаниях и именах превращается в вопросительные знаки. Поэтому в 5.1 я всегда добавляю -Encoding UTF8 (файл получается с BOM, и Excel его читает корректно). В PowerShell 7 по умолчанию используется utf8NoBOM, и для Excel лучше явно указать -Encoding utf8BOM.

Вторая выгрузка — серверы и их серийные номера. Для этого подходит Get-CimInstance с классом Win32_BIOS: он отдаёт производителя, серийный номер и версию BIOS по данным SMBIOS. С удалённым компьютером командлет работает через протокол WsMan, так что на целевых машинах должен быть включён удалённый доступ и у вас должны быть права администратора. Если серверов немного, проще пройтись циклом и собрать всё в одну таблицу.

$rows = foreach ($s in 'srv-dc01', 'srv-1c01', 'srv-files01') {
    Get-CimInstance -ClassName Win32_BIOS -ComputerName $s |
        Select-Object @{Name='Server';Expression={$s}}, Manufacturer, SerialNumber, SMBIOSBIOSVersion
}
$rows | Export-Csv -Path .\servers-bios.csv -NoTypeInformation -UseCulture

Имена в примере условные, подставьте свои. Для версии операционной системы на одной машине удобно Get-ComputerInfo -Property '*version': командлет есть в Windows PowerShell 5.1 и выше и работает только на Windows. Список неактивных компьютеров из первой выгрузки получается фильтром по LastLogonDate, например через Where-Object, а затем решением, кого убирать из домена. Отдельно предупреждаю: серийник серверного железа от производителя иногда не заполнен или забит заглушкой, поэтому цифры из SMBIOS сверяйте с наклейкой на корпусе.

Что скрипты принципиально не дадут? Назначение, владельца и договорную часть. Узнать из системы, что за коммутатор стоит в подсобке и кто платил за гарантию, нельзя, это надо вписать руками при первом заполнении. Здесь я делаю так: выгрузка заполняет «скелет» таблиц, а затем мы проходим по нему с директором и главным бухгалтером, добавляя три колонки — «ответственный», «зачем нужно», «до какой даты оплачено». Это занимает полдня, и из мёртвого списка получается рабочий документ. Для сетевых устройств отдельным шагом идёт выгрузка конфигураций, и мы уже разбирали, как организовать резервное копирование настроек сетевого оборудования: ссылка на папку с копиями идёт в паспорт, а сами настройки туда не копируются.

Где хранить паспорт: документ, вики или NetBox

Формат хранения — вопрос, на котором застревают чаще, чем на содержании. Я спокойно отношусь к любому варианту, если соблюдены три условия: паспорт доступен, когда вся инфраструктура лежит, у него есть история правок и у него один владелец. Сравнение по трём типичным вариантам выглядит так. | Вариант | Плюсы | Минусы | Когда подходит | |---|---|---|---| | Документ и таблицы в общей папке | Старт за вечер, понятно любому, легко распечатать | Нет связей между объектами, версии правит человек | Офис до 30–40 мест, один-два администратора | | Вики (страницы по блокам) | Правки по страницам, поиск, права доступа | Нужен сервер, который сам может упасть вместе с инфраструктурой | Несколько человек ведут документ | | NetBox | Связи между объектами, пользовательские поля, журнал изменений | Надо внедрять и наполнять, нужен администратор | Много устройств, нужна единая база IP и стоек |

Про NetBox я подробно писал отдельно, и в этой статье не повторяюсь: как его развернуть, наполнить и подключить к мониторингу, разобрано в материале про документирование инфраструктуры в NetBox. Здесь важнее другое: NetBox не заменяет паспорт, а становится его машиночитаемой частью. По документации NetBox администраторы могут добавлять собственные поля к встроенным объектам, а данные хранятся вместе с объектом и доступны через REST API. Шаблоны экспорта на основе Jinja2 позволяют получить таблицу в нужном вам формате, не обязательно CSV. Журнал изменений фиксирует, кто и когда менял объект, и к изменению можно добавить пояснение до 200 символов, например номер заявки. А журналирование (journaling) хранит человеческие заметки к объекту и, в отличие от записей журнала изменений, не истекает.

Моя позиция такая: для офиса до сорока рабочих мест NetBox зачастую избыточен, и я не вижу смысла заводить его только ради паспорта. Достаточно двух файлов — текстового документа с описанием и таблицы с активами — и общей папки с включёнными версиями. А вот когда в офисе несколько подсетей, стойка, десятки устройств и несколько человек, которые меняют настройки, NetBox оправдывает себя: связи между объектами уже не удержать в голове. Что бы вы ни выбрали, копия паспорта должна лежать там, куда вы доберётесь при отказе серверов: на ноутбуке администратора, в облачном хранилище, на флешке в сейфе. Паспорт, который открывается только при работающем домене, в аварии не поможет.

Как не дать паспорту устареть: владелец, триггеры и ревизия

Любой паспорт устаревает, и тому есть простая причина: его заполняют один раз, а инфраструктура меняется ежедневно. Поэтому я всегда закладываю в процесс три механизма. Первый — владелец документа. Один человек, а не «ИТ-отдел», и в случае с малым офисом это обычно администратор или подрядчик. Второй — триггеры: список событий, при которых паспорт обязательно обновляется. Третий — календарная ревизия, на которой мы сверяем документ с реальностью независимо от событий.

Триггеры у меня одинаковые во всех проектах. Закупили или списали оборудование. Сменили провайдера или перенесли сервис в другое место. Уволился или пришёл сотрудник — в этом случае связка с чек-листом приёма и увольнения сотрудников удобна тем, что часть пунктов паспорта обновляется автоматически. Истёк или продлён сертификат, лицензия, домен. И главное правило: заявка на изменение не считается закрытой, пока соответствующая строка в паспорте не исправлена. Мы вшиваем этот пункт в шаблон закрытия заявки, и это работает лучше любых напоминаний.

Ревизию я назначаю раз в квартал и ограничиваю двумя часами. За это время мы проходим по девяти блокам, сравниваем выгрузки из домена и мониторинга с таблицами и проверяем даты: что истекает в ближайшие 90 дней. Один раз в год добавляется проверка восстановления из резервной копии, и результат вписывается в блок 6. Если паспорт приходится обновлять с нуля каждые полгода, значит, он слишком подробный: уберите всё, что меняется чаще раза в месяц, и оставьте ссылку на систему, где это актуально. Это же снижает зависимость от одного человека: подробнее о том, чем она опасна, я писал в статье про уход системного администратора.

Кейс: паспорт для краудфандинг-платформы на 41 рабочее место

Условный клиент — краудфандинг-платформа «Народный проект», 41 рабочее место. Инфраструктура обычная для такого размера: два физических сервера с виртуализацией, одно сетевое хранилище, три управляемых коммутатора, один межсетевой экран и четыре точки Wi-Fi. До нас был один штатный администратор, ушедший к другому работодателю, и от него остались три таблицы с разной степенью актуальности. Задача звучала так: за неделю получить документ, по которому директор и любой подрядчик поймут, как всё устроено, и без которого нельзя подписывать договор на обслуживание.

Сбор занял пять рабочих дней и около 26 часов суммарно. Первый день ушёл на выгрузки из домена и серверов по описанным выше скриптам, второй — на обход серверной и подсобок с сверкой наклеек. Третий день мы сидели с директором и бухгалтером и заполняли колонки «зачем нужно», «ответственный» и «оплачено до». На четвёртый день собрали схемы и тексты, на пятый — отдали документ на вычитку и положили копии в облачное хранилище и на ноутбук администратора. Итог: паспорт на 31 страницу из девяти блоков и две таблицы-приложения. Хранение выбрали простое: общая папка с версиями плюс копия вне периметра. NetBox обсудили, но решили вернуться к нему при росте числа устройств.

Результат не заставил себя ждать. Через три месяца вышел из строя один из коммутаторов, и подрядчик заменил его по паспорту: схема, подсети и ссылка на свежую копию конфигурации коммутатора были под рукой, поэтому восстановили связь за 1 час 20 минут, хотя раньше аналогичная работа уходила на полдня из-за поиска, что куда воткнуто. Новый штатный специалист на второй день работал с заявками самостоятельно. Квартальные ревизии занимают по два часа, и после каждой фиксируем в документе, что изменилось. Дорогостоящих вложений не потребовалось: основные затраты — наше время и время директора.

• Объём: 41 рабочее место, 2 сервера, 1 NAS, 3 коммутатора, 1 межсетевой экран, 4 точки Wi-Fi.
• Срок: 5 рабочих дней, около 26 часов.
• Результат: паспорт на 31 страницу, 9 блоков, копия вне инфраструктуры.
• Поддержка: ревизия раз в квартал, 2 часа.

Частые вопросы