Bus factor: что будет с бизнесом, если единственный админ завтра пропадёт

MAATRIX

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

Первые часы: всё держится на чистом везении

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

Совпадение простое: недоступность единственного администратора и любой инцидент, который в норме решается за пятнадцать минут его вмешательства. Диск заполнился логами. Истёк сертификат, который должен был обновиться автоматически, но не обновился. Хостинг-провайдер перезагрузил хост на плановое обслуживание, а сервис не поднялся сам после рестарта. DDoS-атака или просто резкий всплеск легитимного трафика положил один из компонентов. Ни одна из этих причин не связана с отсутствием админа — они происходят независимо от него, с некоторой фоновой частотой, характерной для любой боевой инфраструктуры. Вопрос не «случится ли инцидент», а «совпадёт ли он по времени с окном недоступности».

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

Первые сутки-двое: поиск доступов, которых может не быть

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

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

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

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

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

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

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

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

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

Каскад: продления и платежи, которые требовали именно его

Отдельный и особенно болезненный класс проблем — операции, которые физически завязаны на конкретного человека, а не на компанию как юридическое лицо. Домен зарегистрирован на его личный email. Оплата хостинга списывается с его личной карты, привязанной к его личному аккаунту в панели биллинга. Продление SSL-сертификата (если оно не полностью автоматизировано через Let's Encrypt с корректно настроенным cron) требует захода в панель, куда у него единственного есть доступ.

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

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

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

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

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

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

Отдельная категория риска — партнёры с техническими интеграциями (API-ключи, вебхуки). Если их канал связи с вами ломается именно в этот период, разбираться тоже некому — а претензия по SLA предъявляется компании, а не лично отсутствующему администратору.

Ложные допущения, которые не выдерживают проверки

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

• «У нас есть бэкапы, поэтому мы не потеряем данные». Может быть правдой и одновременно бесполезной правдой, если само хранилище бэкапов доступно через ту же панель, куда некому зайти. Бэкап, до которого нельзя добраться, не отличается от его отсутствия в момент, когда он реально нужен.
• «У нас есть IT-отдел или подрядчик на аутсорсе, они разберутся». Разберутся — но не мгновенно: разбор незнакомой системы объективно занимает время независимо от квалификации того, кто его проводит. «Есть кому позвонить» и «есть кто-то, кто прямо сейчас понимает вашу инфраструктуру» — разные утверждения, и разница видна именно в кризис.
• «У партнёра/сооснователя есть доступ на всякий случай». Доступ, который не проверялся месяцами, с достаточной вероятностью не сработает: истёкший ключ, забытый пароль, привязка 2FA к устройству, которого уже нет. Непроверенный резервный доступ — это не доступ, а предположение о нём.
• «У нас маленький бизнес, это не про нас». Размер бизнеса не влияет на то, привязан ли критичный доступ к одному человеку — маленькие компании как раз чаще держат всю инфраструктуру на одном специалисте, без ресурсов на дублирование. Риск здесь обратно пропорционален размеру.

Что делать заранее, пока время на вашей стороне

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

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

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