Второй человек с доступом: зачем он нужен, даже если вы работаете один

MAATRIX

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

Зачем это нужно, даже если вы работаете один

Первая реакция на идею «дать кому-то доступ» — «зачем, я и один справляюсь». Справляетесь, пока ничего не сломалось в неудобный момент. Но дело не только в аварийном сценарии.

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

• Снимает часть когнитивной нагрузки. Когда вы единственный, кто знает пароль от регистратора домена, вы держите его в голове (или в заметках телефона) постоянно — это фоновый стресс, который накапливается. Когда кто-то ещё знает, где искать, — вы можете об этом не думать.
• Даёт возможность реально отключиться. Отпуск, где вы каждые два часа проверяете, не упал ли сайт, — не отпуск. Если у доверенного человека есть доступ хотя бы к панели мониторинга и списку контактов хостера, вы можете физически уехать без ноутбука.
• Работает как проверка на адекватность. Когда решения о сервере, бэкапах или платежах принимает один человек, никто не задаёт вопрос «а ты уверен?». Второй человек, даже без права действовать самостоятельно, — это тот, кому вы иногда описываете план вслух, и в процессе объяснения сами находите дыры.

Здесь важно разделить два разных документа в вашей голове. Риск единственной точки отказа — тема статьи про bus factor, равный единице: там про то, что произойдёт, если вы пропадёте, и как это стоит бизнесу. Здесь — не про катастрофу, а про то, что завести второго человека полезно и без всякой катастрофы, просто чтобы жить нормально.

Кого выбрать на роль второго человека

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

Партнёр по жизни или бизнесу. Супруг(а), деловой партнёр, совладелец. Плюс — максимальный уровень доверия и мотивация не подвести. Минус — часто нулевая техническая база: человек может держать конверт с паролями, но не сможет им воспользоваться сам, если потребуется реальное действие (зайти по SSH, переставить DNS-запись). Это не всегда минус — иногда роль «хранителя ключа» важнее роли «того, кто умеет их применить».

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

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

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

Какой доступ дать — и какой не давать

Главная ошибка — выдать второму человеку либо слишком мало (бесполезно в кризис), либо слишком много (root на всё, что у вас есть, «на всякий случай»). Правильный объём — минимально достаточный для конкретных сценариев, которые вы заранее продумали.

Разделите доступ на три уровня и решайте по каждому отдельно:

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

Практическая реализация аварийного уровня — не отправлять пароли в мессенджер (это разобрано отдельно в статье про менеджер паролей для команды), а использовать функцию экстренного доступа, которая есть в большинстве менеджеров паролей. Например, в Bitwarden и его self-hosted форке Vaultwarden есть встроенная функция Emergency Access: вы добавляете доверенного контакта, задаёте период ожидания (например, 48 или 72 часа), и если контакт запрашивает доступ, а вы не отклоняете запрос за этот срок, он автоматически получает доступ к вашему хранилищу или его части. Это снимает главную проблему ручного конверта с паролями — устаревание: конверт легко забыть обновить после смены пароля, а функция экстренного доступа работает с актуальным хранилищем в реальном времени.

Если вы такое хранилище поднимаете на своём сервере, порядок настройки описан в статье про установку и настройку Vaultwarden на VPS.

Отдельный момент — не путайте «второго человека с доступом» с «вторым администратором сервера». Если технарь получает доступ, дайте ему отдельного пользователя с ограниченным sudo, а не общий root-логин — подход из статьи про то, как раздать доступ команде без выдачи root, применим и к команде из одного постоянного человека плюс одного резервного.

Как формализовать договорённость без юриста

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

Минимальный формат — один документ на одну страницу, который можно составить самому за полчаса:

СОГЛАШЕНИЕ О РЕЗЕРВНОМ ДОСТУПЕ
Дата: __________
Стороны: [Ваше имя] и [Имя доверенного человека]

1. Доверенный человек получает доступ к:
   - [список: например, Emergency Access в Bitwarden,
     контакты хостера, доступ к почте для восстановления]

2. Доступ используется только в случае:
   - недоступности [Вашего имени] более 72 часов, ИЛИ
   - явного письменного запроса от [Вашего имени]

3. Доверенный человек обязуется:
   - не использовать доступ для иных целей
   - сообщить [Вашему имени] или второму доверенному лицу
     о факте использования доступа в течение 24 часов

4. Договорённость пересматривается: раз в 6 месяцев
   или при смене состава доступов

Подписи: __________  __________

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

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

Если отношения с человеком со временем становятся более формальными — он переходит от «резервного контакта» к «подрядчику, который регулярно что-то делает на сервере» — на этом этапе действительно стоит перейти к полноценному договору или NDA. Разбор пунктов, которые в таком договоре нужны именно для доступа подрядчика к серверу, — в статье про NDA про доступ подрядчика к серверу.

Психологический барьер: почему трудно поделиться контролем

Технически всё, что описано выше, занимает пару часов. На практике многие соло-предприниматели этого не делают годами — и дело не в лени, а в психологии.

Три типичные причины, которые стоит назвать честно:

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

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

Страх, что доступ используют не так, как договаривались. Это единственный из трёх страхов, который решается не психологически, а технически — ограничением объёма доступа (см. раздел выше) и выбором человека, с которым конфликт интересов маловероятен. Если этот страх не проходит применительно к конкретному человеку — это сигнал, что выбран не тот человек, а не повод отказываться от идеи целиком.

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

Как поддерживать доверие в рабочем состоянии

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

Три привычки, которые держат договорённость живой:

• Проверка раз в квартал. Не полноценные учения, а короткий разговор: «всё ещё актуально, ничего не поменялось?». Если вы сменили хостера, добавили новый сервер или сменили менеджер паролей — доверенный человек должен об этом узнать в тот же месяц, а не через год.
• Одна реальная проверка доступа в год. Попросите доверенного человека один раз действительно попробовать выполнить сценарий: зайти в аварийный доступ менеджера паролей (не подтверждая заявку, а именно проверив, что кнопка работает), найти карту серверов, позвонить в поддержку хостера от вашего имени по заранее согласованному сценарию. Разница между «доступ настроен» и «доступ работает» выясняется только на практике.
• Обновление при любом изменении состава. Сменился телефон доверенного человека, вы завели новый криптокошелёк для оплаты сервера, поменялся email для восстановления — каждое из этих изменений обесценивает старую договорённость, если её не обновить. Проще всего привязать обновление к событию, а не к дате: правило «поменял пароль от корневого аккаунта — в тот же день обновил запись у второго человека» работает надёжнее, чем ежегодная ревизия по календарю.

Если вы захотите системно навести порядок в списке всех доступов, а не только для одного резервного человека, это отдельная и более объёмная задача — с неё разумно начать вообще, прежде чем выбирать, кому и что доверить. Логика такой ревизии разобрана в статье про bus factor, равный единице: сначала инвентаризация всего, что у вас есть, потом — кому из этого давать резервный доступ.

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