Список контактов на случай аварии: хостер, регистратор, банк — и кто их знает

MAATRIX

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

Почему в аварию каждая минута поиска — это минута простоя

Авария почти никогда не случается в удобное время. Классический сценарий: ночь, выходной, отпуск ответственного за инфраструктуру человека. Первый, кто это заметил — дежурный разработчик, менеджер или сам владелец бизнеса — открывает мониторинг, видит красный статус и упирается в вопрос «а что дальше». Дальше начинается поиск: как называется хостинг, под каким аккаунтом там всё зарегистрировано, есть ли номер договора, как вообще связаться с поддержкой быстрее, чем через форму обратной связи с ответом «в течение 24 часов».

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

Третий типичный тупик — деньги. Сервер отключили за неуплату, потому что автоплатёж не прошёл (карта истекла, банк заблокировал операцию, лимит исчерпан), а разбираться, кто вообще должен оплатить счёт и с какой карты, приходится в моменте, когда сайт уже не работает. Всё это — не гипотетические сценарии, а типовой ход реальных инцидентов, где технической проблемы на десять минут хватало, а организационной неразберихи — на несколько часов простоя. Похожий разбор с единственным человеком, у которого были все пароли, — в статье «админ ушёл со всеми паролями».

Список контактов на случай аварии закрывает именно организационную часть простоя — ту, которая не зависит от того, насколько быстро вы умеете чинить nginx или Docker. Это не техническая мера, а страховка от потерянного времени.

Что обязательно должно быть в списке

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

Важный принцип: список — это указатели, а не хранилище паролей. Сами пароли и ключи должны лежать в менеджере паролей или защищённом хранилище, а список аварийных контактов ссылается на конкретную запись («логин от панели хостера — см. запись Hosting/Panel в Vaultwarden»), а не дублирует секрет открытым текстом.

Контакты хостера и регистратора — что писать конкретно

Для хостера или провайдера сервера в списке должны быть не просто «support@example.com», а данные, которые реально ускоряют разговор с поддержкой:

• полное название компании и номер договора или ID аккаунта — большинство служб поддержки в первую очередь просят именно это;
• прямой канал для срочных обращений, если он есть отдельно от общей формы (у части провайдеров это выделенный номер или приоритетная очередь тикетов для действующих клиентов);
• способ подтверждения личности — кодовое слово, ИНН компании, e-mail, привязанный к аккаунту (без этого поддержка не станет обсуждать доступ к серверу даже с владельцем бизнеса на линии);
• отдельно — кто именно из команды технически общался с этим хостером раньше и знает нюансы (например, что у провайдера есть отдельная эскалация для L2-инцидентов).

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

• на кого физически или юридически зарегистрирован домен (эта информация важна и для передачи домена — подробности в статье про перенос домена к другому регистратору);
• дату окончания регистрации и включён ли автопродление;
• где хранится код авторизации (auth-code) на случай экстренного переноса к другому регистратору;
• NS-записи и где физически управляется DNS, если это не тот же регистратор.

Отдельная грабля — путать контакт технической поддержки хостинга с контактом регистратора домена. Это разные компании, разные логины и разные процедуры восстановления доступа, и в панике легко потерять время, обращаясь не туда.

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

Блокировка сервера из-за не прошедшего автоплатежа — рутинная, но неприятная причина простоя: сама услуга исправна, а доступ закрыт из-за просроченного счёта. В список нужно занести не номер карты и не CVV, а организационную информацию:

• какая карта или счёт привязаны к автоплатежу за конкретный сервис (без номера карты — только «карта банка N, оканчивается на XXXX, у кого физически»);
• кто в команде имеет право и техническую возможность оплатить счёт немедленно (у кого есть доступ к интернет-банку или к криптокошельку, если оплата идёт в криптовалюте);
• резервный способ оплаты на случай, если основной не прошёл — вторая карта, счёт компании, крипто-кошелёк как запасной канал (это особенно актуально при оплате зарубежных серверов из России, где карта может не пройти по независящим от вас причинам — детали в статье как оплатить сервер в Великобритании из России картой и криптой);
• на кого оформлен договор и куда приходят счета — на юрлицо, ИП или физическое лицо, чтобы не терять время на выяснение, кто должен согласовывать оплату.

Полезная практика — настроить сам автоплатёж максимально надёжно (подробно об этом — в статье про настройку автоплатежа за VPS), но даже при настроенном автоплатеже список контактов должен содержать план Б на случай, если карта истекла или банк её всё же отклонил. Не полагайтесь на то, что «одна и та же карта всегда сработает» — у зарубежных провайдеров карты блокируются по формальным причинам, а разбираться с этим лучше не в момент, когда сервер уже недоступен.

Кто за что отвечает: матрица ролей команды

Список контактов бесполезен, если непонятно, кому конкретно звонить по конкретной проблеме. Работает простая матрица «роль → зона ответственности → основной контакт → резервный контакт»:

Ключевое правило — у каждой роли должен быть резервный контакт. Единственный человек, который «всё знает», — это системный риск: он в отпуске, в самолёте, уволился или просто не берёт трубку в 3 часа ночи, и вся организация встаёт. Похожий разбор ситуации, когда доступ был завязан на одного человека, — в статье «пароля от панели не было ни у кого — пять часов простоя». Если в команде увольняется человек с критичными доступами, процесс отзыва и передачи стоит формализовать отдельно — это разобрано в статье про доступы уволенного сотрудника в первые 30 минут.

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

Где хранить список: доступно в критический момент, но не в открытом виде

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

Рабочая схема — три уровня хранения:

1. Основная копия — в общем защищённом хранилище с разграничением доступа. Практичный вариант — общая (organization) папка в менеджере паролей, например Vaultwarden или Bitwarden, доступная 2-3 доверенным людям с разными ролями (не одному). Про развёртывание и резервное копирование такого менеджера — в статье про Vaultwarden, бэкап и восстановление паролей. Сами секреты (пароли, API-ключи) хранятся как записи менеджера, а список контактов ссылается на них по названию записи, а не дублирует значения.

1. Зашифрованная резервная копия вне основной системы. Если менеджер паролей недоступен (например, из-за той же аварии инфраструктуры, где он развёрнут), нужна offline-копия. Простой вариант — зашифрованный файл на нескольких устройствах доверенных людей:

# создать зашифрованную копию списка контактов
gpg --symmetric --cipher-algo AES256 emergency-contacts.md
# получится emergency-contacts.md.gpg — можно хранить в облаке или на флешке
# расшифровка при необходимости:
gpg --decrypt emergency-contacts.md.gpg > emergency-contacts.md

Пароль от такого архива стоит передать доверенным людям лично (голосом, при встрече), а не тем же каналом, где лежит сам файл.

1. Физическая копия для самого критичного минимума. Для 3-5 по-настоящему критичных пунктов (root-доступ к серверу, доступ к аккаунту хостера, код авторизации домена) имеет смысл держать бумажную распечатку в сейфе офиса или у директора — это последний рубеж на случай, если недоступна вся цифровая инфраструктура одновременно, включая менеджер паролей.

Список нужно не только сохранить, но и обновлять — устаревший список контактов почти так же бесполезен, как его отсутствие. Разумная практика — пересматривать его раз в квартал вместе с общим аудитом доступов (см. статью про ревизию доступов раз в квартал) и после каждого значимого события: смены хостера, смены банка, увольнения или найма человека с критичными доступами. Простое техническое напоминание в календаре или крон-задача на отправку письма ответственному раз в три месяца снимает риск, что документ просто забудут актуализировать:

# напоминание об актуализации списка контактов — раз в квартал, 1 числа в 9:00
0 9 1 1,4,7,10 * mail -s "Актуализировать список аварийных контактов" ops@example.com < /dev/null

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