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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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