Антипаттерн: вся инфраструктура держится на одном человеке

MAATRIX

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

Что такое bus factor и почему единица — это не шутка про автобус

Термин пришёл из разработки: bus factor (иногда — truck factor) отвечает на вопрос "сколько человек должно одновременно исчезнуть из проекта, чтобы работа встала". Если ответ "один" — bus factor равен единице, и это не абстрактная метрика для методичек, а диагноз конкретной организации прямо сейчас.

Применительно к инфраструктуре bus factor = 1 означает буквально: есть один человек, без которого компания не может:

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

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

Как компания незаметно приходит к bus factor = 1

Это никогда не решение осознанно — к такому состоянию приходят постепенно, и на каждом шаге логика выглядит разумной.

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

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

• часть логики живёт в скриптах на самом сервере, а не в git — их писали "на скорую руку" и не думали закоммитить;
• cron-задачи запускают что-то важное (ротацию бэкапов, синхронизацию, чистку логов), но зачем именно такое расписание — нигде не описано;
• архитектурные решения ("почему две базы, а не одна", "почему очереди на RabbitMQ, а не на Redis") принимались устно и нигде не зафиксированы;
• доступ к DNS-регистратору, панели хостинга, CDN и биллингу оформлен на личную почту того самого человека — аккаунт заводился в первый день, и с тех пор было "не до того", чтобы переоформить.

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

Что происходит, когда этот человек становится недоступен

Недоступность бывает трёх видов, и они по-разному бьют по компании.

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

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

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

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

Знания в голове — самый дорогой актив, которого не существует на бумаге

Часто фокус разговора про bus factor смещается на пароли: мол, если у второго человека будет root — проблема решена. Это необходимое, но не достаточное условие. Пароль даёт доступ, а не понимание.

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

Это разница между явным (explicit) и неявным (tacit) знанием. Явное можно записать в документ и передать за пять минут чтения. Неявное — то, что накапливается через непосредственный опыт эксплуатации системы, — годами живёт только в памяти того, кто её трогал руками, и не злонамеренно скрывается, просто никогда не было повода его формализовать, пока всё работало.

Отсюда ключевой вывод: единая точка отказа здесь — не сервер и не база данных, для которых у вас наверняка есть резервирование, а человек, через которого проходит принятие решений и понимание системы. Технический SPOF (single point of failure) вы, скорее всего, уже устраняете — RAID, реплики, резервные каналы связи. Человеческий SPOF в большинстве компаний не устраняется никак, потому что его сложнее заметить: он не выдаёт ошибку 500, он просто молча растёт, пока не станет критичным в худший момент.

Документация: минимальный набор, который реально спасает

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

Практический минимум для инфраструктуры компании:

• Инвентарь серверов и сервисов — что и где крутится: хостнейм, IP, назначение, провайдер, регион, VPS-план. Без него даже человек с root-доступом не будет знать, какие серверы вообще существуют.
• Карта доступов — кто и куда имеет доступ, где искать пароли/ключи/токены API (не сами секреты, а ссылка на менеджер паролей или vault).
• Архитектурная схема — даже нарисованная от руки диаграмма "что с чем общается" закрывает большую часть вопросов новичка быстрее, чем час устных объяснений.
• Runbook’и на 5–7 самых частых сценариев — что делать, если упал сайт, не приходит почта, кончилось место на диске, не проходит деплой. Конкретные команды, а не общие слова.
• Порядок деплоя — как выкатывается код в прод: шаги, кто/что запускает, откуда брать переменные окружения.

Формат может быть предельно простым — не нужен enterprise-инструмент. Репозиторий с markdown-файлами в git прекрасно работает и даёт версионирование бесплатно:

infra-docs/
  inventory.md
  access-map.md
  architecture.md
  runbooks/
    restart-web-stack.md
    db-failover.md
    dns-emergency.md
  deploy.md

Если хочется более удобной навигации, чем голый markdown в репозитории, self-hosted wiki на своём VPS (Wiki.js, BookStack, Outline) закрывает этот вопрос — данные остаются под вашим контролем, а не в бесплатном тарифе стороннего SaaS. Что именно фиксировать по каждому серверу конкретно — разобрано отдельно в статье про документацию сервера.

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

Доступы и права: убираем зависимость от одного логина

Документация закрывает знания, но не закрывает доступ — это отдельная задача, и решать её нужно параллельно.

Именные учётки вместо одной общей. Если у вас до сих пор один пароль root, который знает "тот самый человек", — это тот же bus factor, только на уровне аутентификации. Каждому, кто регулярно работает с сервером, — свой пользователь, свой SSH-ключ, sudo с нужной гранулярностью. Подробно с командами разобрано в статье как раздать доступ команде без выдачи root.

Общий менеджер паролей, а не личный. Секреты, которые нужны больше чем одному человеку — доступ к панели хостинга, регистратору домена, CDN, платёжному шлюзу, — не должны жить в личном Bitwarden/1Password единственного администратора "для удобства". Self-hosted Vaultwarden с организацией и коллекциями по системам даёт нужное: доступ выдаётся ролям, есть журнал, кто и когда открывал секрет, а отзыв доступа при уходе человека — это удаление его из организации, а не смена всех паролей вручную.

Аккаунты сервисов — на компанию, не на личную почту. Регистратор домена, хостинг-панель, CDN, платёжный провайдер должны быть заведены на корпоративный email с несколькими администраторами, а не на личный gmail того, кто настраивал инфраструктуру в первый день. Это чаще всего забывают проверить, пока не возникает необходимость восстановить доступ, а владелец аккаунта недоступен.

Аварийный доступ (break-glass) — отдельно от повседневного. Даже при именных учётках полезно иметь запечатанный пароль root или мастер-ключ в сейфе/менеджере паролей с ограниченным доступом двух-трёх человек — на случай, если штатная схема сама окажется недоступна. Обязательное условие — ротация после каждого вскрытия, иначе аварийный доступ незаметно превращается в ещё один постоянный пароль, о котором забыли.

Таблица ниже — типичная разница "было / стало" для организации без и с распределённым доступом:

Bus factor-аудит: как регулярно проверять риск

Разовая доработка документации и доступов снижает риск на момент, когда она сделана, но инфраструктура продолжает меняться. Bus factor нужно проверять периодически, а не закрыть вопрос раз и навсегда.

Практическая схема — раз в квартал (для быстрорастущей команды — раз в месяц) пройтись по критичным компонентам инфраструктуры и честно ответить на три вопроса по каждому:

Пустые ячейки в такой таблице — это и есть карта реального риска компании прямо сейчас, гораздо честнее, чем ощущение "у нас вроде всё под контролем".

Отдельно стоит по-настоящему проверять, а не только документировать на бумаге — устраивать учебную тревогу: человек, не являющийся основным ответственным за систему, пробует по runbook’у выполнить типовую задачу (перезапустить сервис, накатить бэкап на тестовый стенд, найти лог). Справился без звонка коллеге — процесс работает. Застрял — вы нашли пробел до того, как его нашёл реальный инцидент.

Здесь же стоит держать в голове организационный аспект: человек, годами бывший единственным носителем знаний, иногда неосознанно сопротивляется их передаче — это ощущается как потеря уникальной ценности. Полезно явно проговорить обратное: снижение bus factor не обесценивает его роль, а снимает с него личную ответственность быть на связи 24/7, включая отпуск и больничный.

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