Главная/Блог/Серверы и инфраструктура

Что должно быть задокументировано, чтобы уход админа не стал катастрофой

Серверы и инфраструктура Автор: Дмитрий Рогачев 6 минут
Что должно быть задокументировано

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

Проблема вылезает не в день увольнения. Она вылезает через две недели после — когда что-то ломается, а спросить уже некого.

Момент, когда выясняется, что ничего не записано

Это не всегда драма с заявлением на стол. Чаще прозаичнее: человек уехал в отпуск, слёг с температурой, ушёл в другой проект. Инфраструктура про отпуск не знает и падает по своему расписанию.

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

Дальше — то, что должно быть записано. Не идеальный список из методички, а тот минимум, без которого чужой человек не сможет разобраться в вашей инфраструктуре.

Доступы: кто владелец и где ключи

Самый важный раздел и самый запущенный.

Нужен список всех учётных записей с административными правами: серверы, маршрутизатор, корпоративная почта, хостинг, панель домена, 1С, антивирус, облачные сервисы. По каждой — не сам пароль в файле, а где он хранится, кто владелец и как его получить. Общее хранилище паролей с разграничением прав решает это лучше, чем таблица на файловом сервере, и стоит недорого.

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

Здесь же должна лежать процедура отзыва доступов при увольнении — какие учётные записи блокируются, какие ключи удаляются, кто это проверяет. Про отзыв доступа к VPN мы уже писали отдельно; та же логика касается всего остального.

Схема сети и что где стоит

Схема отвечает на вопрос, который в аварии задают первым: «а откуда вообще приходит интернет».

В ней должно быть видно, какое оборудование стоит физически и где именно, куда идут кабели, какие провайдеры подключены и какие у компании внешние адреса. Отдельно — что произойдёт, если основной канал пропадёт: есть ли резервный, переключается он сам или руками.

Схема ИТ-инфраструктуры офиса
Схема не обязана быть красивой. Достаточно, чтобы по ней было понятно, что откуда идёт

Схема не обязана быть красивой. Достаточно, чтобы человек, впервые вошедший в серверную, понял, что из этих коробок что делает.

Серверы и сервисы: что на чём работает

По каждому серверу — физический он или виртуальный, какая система, за что отвечает и насколько критичен. По каждому важному сервису — на каком сервере он живёт: 1С, файловое хранилище, почта, контроллер домена, базы.

И главное, что почти никогда не записывают: зависимости. Что перестанет работать, если выключить вот этот сервер. Ответ на этот вопрос есть только у того, кто всё настраивал, — и именно он нужен в момент, когда решают, что перезагружать первым.

Резервные копии: где лежат и как восстановиться

Резервное копирование обычно описано со стороны копирования: что, куда и по какому расписанию. Это половина работы.

Вторая половина — как из этой копии восстановиться. Куда разворачивать, в каком порядке, сколько это займёт, где лежит ключ шифрования. Копия, к которой потерян ключ, — это просто занятое место на диске.

Инструкция должна быть написана так, чтобы по ней смог пройти человек, который эту систему копирования не настраивал. Проверяется это только пробным восстановлением; почему копии часто оказываются нерабочими, мы разбирали в отдельной статье.

Домены, лицензии и подписки

Этот раздел отличается от остальных тем, что здесь ничего не ломается. Оно просто перестаёт работать в назначенный день.

Домен — у какого регистратора, до какого числа оплачен, на кого оформлен. SSL-сертификат — когда истекает и кто продлевает. Лицензии на серверные системы, 1С, антивирус — где хранятся ключи и до какой даты они действуют. Подписки на почту и облачные сервисы — с какой карты списывается оплата и что будет, когда у карты закончится срок.

Домен, за который забыли заплатить, отключает сайт и корпоративную почту одновременно. Восстановление после этого занимает уже не минуты.

Что делать, когда всё легло

Аварийный раздел пишется для человека, который в панике и открывает документ первый раз.

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

Здесь же — кто принимает решения. В аварии главная задержка обычно не техническая: все ждут, пока кто-нибудь разрешит остановить работу склада на два часа.

Документация, которая не протухнет через полгода

Главная проблема любых записей не в том, что их нет. В том, что они устаревают, и по ним начинают принимать неверные решения.

Работают три вещи. Одно место — не переписка, не три файла у разных людей, не папка на рабочем столе. Документация в почте у трёх сотрудников означает, что документации нет. Обновление в момент изменения, а не раз в год: поменяли адресацию — поправили сразу, иначе не поправят никогда. И ответственный — конкретный человек, для которого это часть работы, а не то, чем занимаются, когда появится время.

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

Проверить готовность просто. Попросите человека, который эту инфраструктуру не настраивал, найти по вашим записям, где хранятся резервные копии и как перезапустить сервер с 1С. Не получилось — документации нет, есть файл с таким названием.

Если сейчас всё держится на одном человеке, а записей нет, начинать стоит не с покупки системы для документации, а с ревизии. Бесплатный аудит показывает, что у вас есть на самом деле: какие серверы и что на них работает, как устроена сеть, что копируется и какие лицензии действуют. Это ещё не описание, но половина фактов для него.

Полное описание составляется при приёмке инфраструктуры на обслуживание и остаётся у заказчика: это ваша инфраструктура и ваше знание, а не способ привязать клиента к подрядчику. Кто ведёт его дальше — вы или мы — вопрос договорённости, а не условие.

Дмитрий Рогачев, Основатель ITHOUSE
Дмитрий Рогачев
Основатель ITHOUSE

Занимается ИТ-инфраструктурой с 2011 года. Под управлением компании более 25 организаций на постоянном обслуживании, самое долгое сопровождение длится 15 лет. Сертифицированный консультант VK Tech по VK WorkSpace.

Посмотрим, что у вас есть на самом деле

Бесплатный аудит: пройдём по серверам, сети, копиям и лицензиям, соберём описание инфраструктуры и покажем, где всё держится на одном человеке. Описание остаётся у вас в любом случае.

Получить бесплатный аудит