Bus factor равен единице: как перестать быть единственным, кто знает пароли

MAATRIX

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

Что такое bus factor и почему это не про катастрофы

Термин звучит как чёрный юмор, но его придумали не для того, чтобы пугать. Bus factor — это метрика устойчивости системы, а не прогноз конкретного несчастья. Речь не о том, что с человеком обязательно что-то случится, а о том, что система, зависящая от доступности ровно одного человека, хрупкая по конструкции — независимо от того, произойдёт что-то плохое или нет.

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

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

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

Инвентаризация: что реально живёт в одной голове

Первый шаг — не чинить, а честно посчитать масштаб. Практическое упражнение занимает час-полтора и делается одним человеком (тем самым, у которого bus factor равен единице) в формате списка, а не документа для показа руководству.

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

Домены и DNS. У какого регистратора куплен домен, на чей email оформлена регистрация, кто может зайти в панель регистратора и в DNS-зону. Если ответ «только я» — это первая позиция в списке рисков, потому что домен — самое чувствительное звено: без него не работают ни сайт, ни почта на нём.

Хостинг и облачные аккаунты. Панель провайдера сервера, аккаунты облачных сервисов (S3-хранилища, CDN, почтовые релеи), доступ к биллингу — на чью карту оформлена оплата и кто может её сменить.

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

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

«Как это вообще работает». Общая картина инфраструктуры целиком — то, что в голове складывается в цельную схему, а на бумаге не существует нигде. Отдельный человек может знать, как устроена конкретная часть, но никто, кроме автора, не видит связей между частями.

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

Минимально достаточный документ вместо исчерпывающей документации

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

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

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

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

Резервный доступ для доверенного второго человека

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

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

Что стоит настроить конкретно:

• Второй логин в панели хостинга с правами администратора, а не только на чтение — если провайдер позволяет несколько пользователей аккаунта, это делается один раз за десять минут.
• Второй набор SSH-ключей, добавленный в ~/.ssh/authorized_keys на всех критичных серверах, у доверенного второго человека — руководителя, партнёра, доверенного подрядчика. Ключ может годами не использоваться, это нормально: важен сам факт, что он есть и рабочий, а не то, что им пользуются постоянно.
• Доступ к регистратору домена и DNS — либо второй пользователь аккаунта, либо как минимум контактный email, который контролируют два человека, а не один личный ящик.
• Доступ к платёжному аккаунту или как минимум понимание, кто может его восстановить — через какую карту, на чьё имя оформлена подписка.
• Проверенная работоспособность, а не предположение о ней. Резервный доступ, который никогда не проверялся, с достаточной вероятностью не сработает в нужный момент — истёкший ключ, забытый пароль от второго аккаунта, устаревшая привязка 2FA. Раз в квартал стоит фактически войти под резервными учётными данными и убедиться, что это работает, а не значится работающим только на бумаге.

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

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

Менеджер паролей вместо блокнота и личных заметок

Отдельная и частая форма bus factor — не отсутствие пароля у второго человека, а то, что пароли вообще существуют только в виде личных заметок: файла на рабочем столе, заметки в телефоне, памяти браузера на конкретном ноутбуке. Даже если формально «второй доступ есть», найти его в момент, когда нужно, может быть невозможно — искать негде.

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

Практические варианты:

Независимо от выбора, для задачи снижения bus factor важны три настройки, а не сам факт использования менеджера:

1. Организация, а не личные аккаунты. Пароли компании должны принадлежать организации в менеджере, а не личному аккаунту сотрудника — иначе при его уходе вы снова получаете bus factor, равный единице, просто в новой обёртке.
2. Аварийный доступ (emergency access). У большинства менеджеров есть функция, которая передаёт доступ доверенному контакту после подтверждения (обычно с задержкой в несколько дней на случай отмены) — это ровно механизм на случай недоступности владельца записи, настроенный один раз заранее.
3. Разграничение, а не «все видят всё». Не каждому сотруднику нужен пароль от платёжного аккаунта; но у одного-двух ответственных лиц должен быть доступ к полному набору критичных записей, а не только к тем, которыми они пользуются ежедневно.

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

Почему это не про недоверие и не про страх увольнения

Разговор о резервном доступе часто воспринимается болезненно — и тем, у кого просят «поделиться паролями», и тем, кто просит. Первому может казаться, что ему не доверяют или готовят замену; второму — что он лезет в чужую зону ответственности. Обе интерпретации мимо цели: снижение bus factor — это не про то, что конкретно может случиться с конкретным человеком, а про базовую устойчивость системы, которая нужна вне зависимости от причины. Болезнь, отпуск, смена приоритетов внутри компании, обычная перегрузка — результат один и тот же, если работа зависит от доступности ровно одного человека. Разговор о резервном доступе — это не «на случай, если ты нас подведёшь», а «на случай, если жизнь случится с кем угодно из нас, включая тебя».

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

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