Пн–Пт: 09:00-18:00
Документация ИТ-инфраструктуры компании: что должно быть описано и зачем это бизнесу
Серверы работают, сотрудники подключаются к корпоративным системам, резервные копии создаются – кажется, что с ИТ-инфраструктурой все в порядке.
Проблема возникает, когда увольняется системный администратор, происходит серьезный сбой или компания решает сменить ИТ-подрядчика. В этот момент может выясниться, что схема сети существует только в голове одного специалиста, пароли хранятся неизвестно где, а никто точно не знает, какие системы зависят от конкретного сервера.
Хорошая ИТ-документация нужна не для того, чтобы описать каждый кабель и каждую настройку. Ее задача гораздо практичнее: другой квалифицированный специалист должен иметь возможность понять устройство инфраструктуры, поддерживать ее и восстановить критичные системы без помощи человека, который настраивал их изначально.
Разберем, что именно для этого должно быть задокументировано.
Проблема возникает, когда увольняется системный администратор, происходит серьезный сбой или компания решает сменить ИТ-подрядчика. В этот момент может выясниться, что схема сети существует только в голове одного специалиста, пароли хранятся неизвестно где, а никто точно не знает, какие системы зависят от конкретного сервера.
Хорошая ИТ-документация нужна не для того, чтобы описать каждый кабель и каждую настройку. Ее задача гораздо практичнее: другой квалифицированный специалист должен иметь возможность понять устройство инфраструктуры, поддерживать ее и восстановить критичные системы без помощи человека, который настраивал их изначально.
Разберем, что именно для этого должно быть задокументировано.
1. Реестр ИТ-систем и оборудования
Первый документ – реестр того, чем вообще располагает компания.
В него стоит включить физические серверы, виртуальные машины, системы хранения данных, сетевое оборудование, облачные ресурсы, основные бизнес-приложения и другое критичное оборудование.
Для каждого объекта достаточно зафиксировать основные сведения: назначение, расположение, ответственного, срок поддержки и связанные с ним системы.
В него стоит включить физические серверы, виртуальные машины, системы хранения данных, сетевое оборудование, облачные ресурсы, основные бизнес-приложения и другое критичное оборудование.
Для каждого объекта достаточно зафиксировать основные сведения: назначение, расположение, ответственного, срок поддержки и связанные с ним системы.
Например:
SRV-01 – сервер 1С – офис компании – ответственный ИТ-отдел – резервное копирование ежедневно.
VM-CRM-01 – CRM – облачная инфраструктура – ответственный ИТ-отдел – критичность высокая.
SRV-01 – сервер 1С – офис компании – ответственный ИТ-отдел – резервное копирование ежедневно.
VM-CRM-01 – CRM – облачная инфраструктура – ответственный ИТ-отдел – критичность высокая.
Такой реестр решает сразу несколько задач. Компания понимает, какими ИТ-активами располагает, что необходимо обслуживать и какие элементы инфраструктуры являются критичными.
Без него даже простая задача вроде планирования замены оборудования превращается в ручную инвентаризацию.
Без него даже простая задача вроде планирования замены оборудования превращается в ручную инвентаризацию.
2. Схема ИТ-инфраструктуры
Реестр показывает, что есть у компании, а схема ИТ-инфраструктуры – как все это связано между собой.
На схеме стоит показать серверы, виртуальные среды, сетевое оборудование, интернет-каналы, облачные сервисы, VPN и основные связи между системами.
Необязательно отображать каждую рабочую станцию. Важнее показать зависимости, от которых зависит работа бизнеса.
На схеме стоит показать серверы, виртуальные среды, сетевое оборудование, интернет-каналы, облачные сервисы, VPN и основные связи между системами.
Необязательно отображать каждую рабочую станцию. Важнее показать зависимости, от которых зависит работа бизнеса.
Например:
Интернет → межсетевой экран → корпоративная сеть → сервер приложений → база данных.
Интернет → межсетевой экран → корпоративная сеть → сервер приложений → база данных.
Если сервер приложений использует отдельное хранилище, а сотрудники подключаются к нему через VPN, это также должно быть видно на схеме.
Такая документация особенно полезна при аварии. Если перестала работать CRM, специалист сразу видит, от каких серверов, сетевых соединений и баз данных она зависит, вместо того чтобы восстанавливать архитектуру по факту сбоя.
Такая документация особенно полезна при аварии. Если перестала работать CRM, специалист сразу видит, от каких серверов, сетевых соединений и баз данных она зависит, вместо того чтобы восстанавливать архитектуру по факту сбоя.
3. Документация локальной сети
Отдельно стоит описать сеть компании.
Минимальная документация локальной сети включает схему подключения основных устройств, используемые подсети и VLAN, адреса критичного оборудования, VPN-соединения, Wi-Fi-сети и интернет-каналы.
Например, если у компании два офиса соединены VPN, должно быть понятно, какое оборудование создает туннель, какие сети доступны между площадками и какой интернет-канал используется.
Без такого описания замена обычного маршрутизатора может неожиданно привести к недоступности части корпоративных систем.
Особенно важно документировать нестандартные настройки. Чем сильнее конфигурация отличается от типовой, тем меньше вероятность, что новый специалист сможет быстро разобраться в ней самостоятельно.
Минимальная документация локальной сети включает схему подключения основных устройств, используемые подсети и VLAN, адреса критичного оборудования, VPN-соединения, Wi-Fi-сети и интернет-каналы.
Например, если у компании два офиса соединены VPN, должно быть понятно, какое оборудование создает туннель, какие сети доступны между площадками и какой интернет-канал используется.
Без такого описания замена обычного маршрутизатора может неожиданно привести к недоступности части корпоративных систем.
Особенно важно документировать нестандартные настройки. Чем сильнее конфигурация отличается от типовой, тем меньше вероятность, что новый специалист сможет быстро разобраться в ней самостоятельно.
4. Описание серверной инфраструктуры
Для каждого критичного сервера необходимо понимать не только его характеристики, но и его роль.
Документация должна отвечать на несколько простых вопросов: какие сервисы работают на сервере, какие системы от него зависят, где находятся данные, как выполняется резервное копирование и что необходимо сделать при отказе.
Документация должна отвечать на несколько простых вопросов: какие сервисы работают на сервере, какие системы от него зависят, где находятся данные, как выполняется резервное копирование и что необходимо сделать при отказе.
Например, недостаточно написать:
«Сервер №2 – Windows Server».
Полезное описание выглядит иначе:
«SRV-02 – сервер базы данных CRM. На нем работает PostgreSQL. Резервное копирование выполняется ежедневно в 23:00 в отдельное хранилище. При отказе сервера CRM становится недоступна».
«Сервер №2 – Windows Server».
Полезное описание выглядит иначе:
«SRV-02 – сервер базы данных CRM. На нем работает PostgreSQL. Резервное копирование выполняется ежедневно в 23:00 в отдельное хранилище. При отказе сервера CRM становится недоступна».
Второй вариант позволяет новому администратору сразу оценить последствия проблемы и понять порядок восстановления.
5. Доступы и административные учетные записи
Одна из наиболее чувствительных частей ИТ-документации – административные доступы.
При этом хранить все пароли непосредственно в Word или Excel вместе с описанием инфраструктуры не стоит.
При этом хранить все пароли непосредственно в Word или Excel вместе с описанием инфраструктуры не стоит.
В документации лучше фиксировать, какие административные учетные записи существуют, для чего они используются и где безопасно хранятся соответствующие учетные данные.
Сами пароли разумнее размещать в корпоративном менеджере паролей с разграничением прав.
Отдельно необходимо описать доступы к облачной инфраструктуре, доменам, DNS, хостингу, корпоративной почте, VPN, системам резервного копирования и другим внешним сервисам.
Компания должна иметь возможность получить административный доступ ко всей своей инфраструктуре независимо от конкретного сотрудника или подрядчика.
Отдельно необходимо описать доступы к облачной инфраструктуре, доменам, DNS, хостингу, корпоративной почте, VPN, системам резервного копирования и другим внешним сервисам.
Компания должна иметь возможность получить административный доступ ко всей своей инфраструктуре независимо от конкретного сотрудника или подрядчика.
6. Резервное копирование и восстановление
Запись «резервное копирование настроено» практически бесполезна.
Для критичных систем необходимо зафиксировать:
что копируется → куда → как часто → сколько хранятся копии → кто отвечает → как восстановить данные.
Например:
База 1С → ежедневная копия в 23:00 → отдельное хранилище → срок хранения 30 дней → ответственное лицо – системный администратор.
Но главное – инструкция по восстановлению.
что копируется → куда → как часто → сколько хранятся копии → кто отвечает → как восстановить данные.
Например:
База 1С → ежедневная копия в 23:00 → отдельное хранилище → срок хранения 30 дней → ответственное лицо – системный администратор.
Но главное – инструкция по восстановлению.
Если резервные копии существуют, но никто кроме одного администратора не знает, как из них восстановить систему, компания все равно остается зависимой от конкретного человека.
Поэтому процедуру восстановления стоит не только описать, но и периодически проверять на практике.
Поэтому процедуру восстановления стоит не только описать, но и периодически проверять на практике.
7. Подрядчики, лицензии и внешние сервисы
Современная ИТ-инфраструктура редко полностью находится внутри компании.
Облачный провайдер предоставляет виртуальные серверы, другой подрядчик обслуживает 1С, третий – телефонию, отдельный сервис используется для резервного копирования.
Для каждого такого сервиса стоит зафиксировать поставщика, контакты поддержки, номер договора, срок действия, дату продления и ответственного внутри компании.
То же касается лицензий.
Например, если лицензия на критичное ПО истекает через два месяца, это должно быть видно из документации заранее, а не в день, когда система перестанет работать.
Особенно важно проверить, чтобы критичные сервисы были оформлены на компанию, а не на личную почту или банковскую карту системного администратора.
Облачный провайдер предоставляет виртуальные серверы, другой подрядчик обслуживает 1С, третий – телефонию, отдельный сервис используется для резервного копирования.
Для каждого такого сервиса стоит зафиксировать поставщика, контакты поддержки, номер договора, срок действия, дату продления и ответственного внутри компании.
То же касается лицензий.
Например, если лицензия на критичное ПО истекает через два месяца, это должно быть видно из документации заранее, а не в день, когда система перестанет работать.
Особенно важно проверить, чтобы критичные сервисы были оформлены на компанию, а не на личную почту или банковскую карту системного администратора.
8. Регламент работы с ИТ-инфраструктурой
Документация должна описывать не только текущее состояние инфраструктуры, но и основные действия с ней.
Например:
Новый сотрудник: кто создает учетную запись, какие доступы выдаются, кто их согласовывает.
Увольнение: кто блокирует учетную запись, VPN и корпоративную почту.
Сбой: кому сообщают об инциденте и кто отвечает за восстановление.
Изменение инфраструктуры: кто согласовывает установку нового оборудования или изменение сетевой конфигурации.
Резервное копирование: кто контролирует выполнение и как часто тестируется восстановление.
Новый сотрудник: кто создает учетную запись, какие доступы выдаются, кто их согласовывает.
Увольнение: кто блокирует учетную запись, VPN и корпоративную почту.
Сбой: кому сообщают об инциденте и кто отвечает за восстановление.
Изменение инфраструктуры: кто согласовывает установку нового оборудования или изменение сетевой конфигурации.
Резервное копирование: кто контролирует выполнение и как часто тестируется восстановление.
Такой регламент особенно важен, если инфраструктурой занимается несколько сотрудников или внешний подрядчик: критичные действия перестают зависеть от личных договоренностей.
Документация должна обновляться вместе с инфраструктурой
Главная проблема ИТ-документации – она быстро устаревает.
Компания один раз проводит аудит, получает подробную схему на 50 страниц, а через год половина серверов и адресов в ней уже не соответствует действительности.
Поэтому полезнее иметь пять простых и актуальных документов, чем один идеальный, но устаревший технический паспорт.
Практический подход – обновлять документацию одновременно с изменением инфраструктуры.
Добавили сервер – внесли его в реестр и схему. Изменили VPN – обновили сетевую документацию. Подключили новый облачный сервис – добавили владельца, договор и административный доступ.
Документирование становится частью изменения, а не отдельным проектом, который проводится раз в несколько лет.
Компания один раз проводит аудит, получает подробную схему на 50 страниц, а через год половина серверов и адресов в ней уже не соответствует действительности.
Поэтому полезнее иметь пять простых и актуальных документов, чем один идеальный, но устаревший технический паспорт.
Практический подход – обновлять документацию одновременно с изменением инфраструктуры.
Добавили сервер – внесли его в реестр и схему. Изменили VPN – обновили сетевую документацию. Подключили новый облачный сервис – добавили владельца, договор и административный доступ.
Документирование становится частью изменения, а не отдельным проектом, который проводится раз в несколько лет.
Как понять, достаточно ли документации
Есть простой способ проверки.
Представьте, что завтра системный администратор или действующий ИТ-подрядчик перестал выходить на связь.
Новый специалист должен суметь по существующей документации:
Если для выполнения этих действий необходимо звонить предыдущему администратору и спрашивать, «как здесь все устроено», документация ИТ-инфраструктуры фактически не выполняет свою функцию.
Представьте, что завтра системный администратор или действующий ИТ-подрядчик перестал выходить на связь.
Новый специалист должен суметь по существующей документации:
- понять общую схему инфраструктуры;
- найти критичные серверы и системы;
- определить зависимости между ними;
- получить необходимые административные доступы;
- разобраться в устройстве локальной сети;
- найти резервные копии и восстановить данные;
- связаться с внешними подрядчиками;
- понять, какие лицензии и сервисы необходимо продлевать.
Если для выполнения этих действий необходимо звонить предыдущему администратору и спрашивать, «как здесь все устроено», документация ИТ-инфраструктуры фактически не выполняет свою функцию.
Вывод
ИТ-документация нужна бизнесу не ради формального порядка.
Это способ снизить зависимость от конкретных сотрудников и подрядчиков и сократить время восстановления при сбоях. Сам подход соответствует общей логике действующих стандартов: документация должна содержать информацию, необходимую для эксплуатации и сопровождения систем, а описание инфраструктуры – учитывать ее элементы, взаимодействия и обслуживание.
Минимальный комплект для большинства компаний достаточно практичен: реестр ИТ-систем, схема инфраструктуры и локальной сети, описание критичных серверов, реестр административных доступов, порядок резервного копирования и восстановления, список внешних сервисов и основные регламенты.
При этом главный показатель качества документации – не ее объем.
Если квалифицированный специалист, который раньше не работал с компанией, может открыть документы, понять устройство инфраструктуры и начать ее обслуживать без постоянных вопросов предыдущему администратору, документация выполняет свою задачу.
Это способ снизить зависимость от конкретных сотрудников и подрядчиков и сократить время восстановления при сбоях. Сам подход соответствует общей логике действующих стандартов: документация должна содержать информацию, необходимую для эксплуатации и сопровождения систем, а описание инфраструктуры – учитывать ее элементы, взаимодействия и обслуживание.
Минимальный комплект для большинства компаний достаточно практичен: реестр ИТ-систем, схема инфраструктуры и локальной сети, описание критичных серверов, реестр административных доступов, порядок резервного копирования и восстановления, список внешних сервисов и основные регламенты.
При этом главный показатель качества документации – не ее объем.
Если квалифицированный специалист, который раньше не работал с компанией, может открыть документы, понять устройство инфраструктуры и начать ее обслуживать без постоянных вопросов предыдущему администратору, документация выполняет свою задачу.
Хотите быть уверены, что резервное копирование сработает в критический момент и защитит ваши данные от потери?