Привет всем! Меня зовут Гриша Капцов, я работаю в Отделе координации и поддержки продуктовых команд в МТС Web Services. В прошлом посте рассказывал, как мы с командой прокачали свой навык повелевания хаосом. А сегодня хочу обсудить ситуации, когда один «незаменимый» сотрудник становится угрозой. 

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

Ситуация может показаться гипотетической, но в сфере ИТ-эксплуатации это ежедневный риск, просто не всегда реализующийся. У вас может быть сильная команда и крутые инженеры, но при этом — один человек на зону знаний, отсутствие структурированной документации и полная слепота к ключевым уязвимостям. 

Предотвратить такие сценарии можно, если отслеживать «фактор автобуса», или Bus Factor — показатель зависимости проекта от отдельных членов команды. Ниже я расскажу, почем�� эта метрика особенно критична для эксплуатационных команд и как ее измеряем мы. Давайте назовем кейс «This is эксплуатация!».

Почему супергерои — это угроза

Метрика Bus Factor показывает, сколько людей в команде должны исчезнуть — уволиться, уйти в отпуск, заболеть и так далее, чтобы все процессы остановились. Чем меньше эта цифра, тем выше вероятность, что проект окажется парализованным. 

Давайте на примере. Допустим, в команде из четырех человек тайными знаниями обладает только один. Если он внезапно исчезнет со связи, проект встанет. Но если «в теме» было два или три сотрудника — все будет в порядке.

Эксплуатационные команды в этом плане сорвали джекпот, только со знаком минус. Bus Factor у нас часто равен единице, и вот почему:

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

• Знания копятся годами и передаются устно.

• При найме мы делаем приоритет на технические навыки, а не на культуру передачи знаний.

• Люди в эксплуатации часто не ротационные: «если работает — не трогай».

Давайте честно. Метрика Bus Factor — не про абстракции, а про реальные инциденты, которые просто еще не случились. Вот несколько реальных примеров, с которыми я сталкивался за годы своей карьеры:

• Ушел единственный DevOps-инженер, который знал конфигурацию отказоустойчивости кластера. Кластер упал при обновлении, подняли только через 36 часов. Никто не знал, как переключать реплики.

• Специалист по Oracle уволился, не передав доступы к мониторингу. При росте нагрузки база не масштабировалась — SRE смотрели на сломанный Grafana-дашборд с неизвестной логикой.

• Новая команда поддержки не могла найти документацию по старому сервису. Каждое обращение от клиентов шло по 5–8 часов: сотрудники буквально изобретали логику API заново.

• Инженер заболел, но только у него был договор с подрядчиком на оборудование. Закупки встали на 2 недели.

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

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

Как измерять и отслеживать Bus Factor — наш кейс

Как эксплуатационная команда, мы подошли к теме Bus Factor не с то��ки зрения HR, а с позиции боли бизнеса. Поясню: в первом случае речь идет о риске выгорания и потери знаний, а во втором — о риске остановки процессов, из-за чего компания не сможет достичь цели. Иными словами, одинаково больно и людям, и системе: одни теряют устойчивость, другие — эффективность. 

Уход незаменимого человека — это не вопрос «если», это вопрос «когда». 

Чтобы проверить, насколько проблема низкого показателя Bus Factor актуальна конкретно для нас, мы опросили сотрудников из разных трайбов и ролей. Результаты показали, что компании удалось выстроить процессы документации и обмена знаниями. И все-таки почти в каждой второй команде есть узкие места — например, только 30% опрошенных знают, что делать в случае ухода ключевого сотрудника. Так что отсутствие единого и понятного плана действий остается серьезной уязвимостью. Причем руководители чаще отмечают, что «незаменимые» специалисты в команде есть, и выше оценивают влияние проблемы, чем сотрудники без управленческих функций.

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

Дальше покажу подробную инструкцию, которая помогает нам отслеживать Bus Factor и распространять знания между сотрудниками. Пользуйтесь на здоровье!

Гайд, как определить Bus Factor и сделать свою команду более устойчивой

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

• кто основной исполнитель;

• есть ли дублеры;

• есть ли документация и когда она обновлялась;

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

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

Важно помнить: цифры, которые вы получили один раз, вдолгую не работают. Считать нужно регулярно, например, раз в полгода или при performance review. А еще — учитывать не только итоговое число, но и контекст: какие зоны самые уязвимые и где риск максимален. После ревизии легко увидеть участки с Bus Factor = 1 и приоритеты для улучшения.

Шаг 2. Назначьте владельцев и дублеров для каждой зоны. Дублер нужен минимум один. Запишите роли ответственных, кто в статусе «backup», и добавьте сроки передачи знаний.

• Кто отвечает: тимлид, руководитель продукта или HR — по согласованию ролей и загрузки.

• Артефакт: обновленная таблица с колонками «Владелец», «Дублер 1», «Дублер 2», «Дата обучения и стендапа».

Практика: сделайте shadow-период (1–2 недели), когда дублер выполняет задачи под контролем владельца. Такие «эксперименты» помогут сделать команду более устойчивой. 

Шаг 3. Документируйте процессы. Для каждой ключевой зоны подготовьте краткий runbook: цель, триггеры инцидента, пошаговая инструкция (шаги восстановления), команды и скрипты, контакты и SLA. Обязательно укажите «проверку после выполнения» и куда ложится лог и результат.

• Кто отвечает: владелец зоны + документатор, технический писатель; ревью — дублер и тимлид.

• Артефакт: шаблон runbook (файл в репозитории или Confluence/Notion) + ссылка в карте зон.

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

Шаг 4. Ротируйте задачи и чередуйте роли. Внедрите практику ротации (shadow tasks, pair-oncall, временные assignments) — не формально, а с проверкой компетенций. Планируйте, чтобы каждый владелец провел хотя бы 1–2 перекрытия со своим дублером в квартал.

• Кто отвечает: тимлид.

• Артефакт: расписание ротаций в спринт-плане / календарь, запись о проведенных сессиях и чек-лист для проверки навыков.

Совет: донесите до команды, что ротация — это позитивная практика, что она про развитие и апскил. Если сотрудники не поймут ценности, вовлеченность будет низкая.

Шаг 5. Автоматизируйте все, что возможно. Проанализируйте повторяющиеся ручные операции: если команда делает шаг более двух раз вручную ― это явный приоритет на автоматизацию. Деплой, бэкапы, мониторинг и стандартные recovery-скрипты — все это сюда. 

• Кто отвечает: DevOps, SRE или команда разработки совместно с владельцем процесса.

• Артефакт: pipeline в CI/CD, автоматические runbooks (скрипты), playbook для аварийных сценариев.

Проверка: уменьшение числа ручных шагов сразу снижает зависимость от «знающего человека» и сокращает recovery time.

Шаг 6. Внедрите культуру «если меня завтра не будет…». Формализуйте обсуждения Bus Factor в ��етроспективах, one-to-one и performance review. Поощряйте сотрудников, которые делятся опытом, включите передачу знаний в KPI и MBO.

1. Кто отвечает: руководители, HR и тимлиды.

2. Артефакт: политика по knowledge sharing, список внутренних воркшопов, запись о включении KT в оценку эффективности.

Важно: делайте обмен знаний регулярным и видимым. Премируйте тех, кто активно растит дублеров.

Шаг 7. Периодически проводите «симуляции потерь». Устраивайте учения, где один из владельцев «временно недоступен» (table-top exercises, black-box drills или отключение доступа на 24–48 часов), и проверяйте, насколько быстро команда подхватывает процессы. После учения проводите blameless post-mortem и обновляйте runbook.

• Кто отвечает: SRE, тимлид или офицер по непрерывности бизнеса.

• Артефакт: отчет по учению с выводами: time-to-recovery, пробелы в документации, план исправлений.

Запомните, что это не стресс-тест. Заранее опишите ценность практики сотрудникам и проводите ее в контролируемой среде.

Как запустить процесс передачи знаний

Не просто посчитать Bus Factor, но и превратить метрику в инструмент поможет чек-лист:

Не спринт, а марафон

После проведения опроса в нашей компании мы начали внутренние инициативы по снижению Bus Factor. В нескольких трайбах уже провели сессии обмена знаниями, выделили зоны с показателем 1, завели внутренние базы инструкций и назначили «дублирующие» роли. В результате вырос средний балл уверенности в замещении — с 7,1 до 7,8. Но мы готовы к тому, что это небыстрый процесс, его нельзя выполнить за месяц и отложить на дальнюю полку. 

По сути, отслеживание Bus Factor — это подход к работе, который требует постоянного внимания. Зато если им заниматься, разница между «у нас устойчиво» и «все рухнуло» не будет одним человеком. 

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

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

• Насколько вы уверены, что хотя бы два человека могут выполнять каждую критичную задачу?

• У вас есть актуальные инструкции по ключевым операциям?

• Новичок может войти в курс дела без сопровождения?

• Ключевые доступы централизованы и есть минимум у двух сотрудников?

• Есть план «что делать», если кто-то исчезнет?

• Задачи ротируются между участниками команды?

• Регулярно ли вы обновляете техническую документацию?

• Сервис можно починить без участия конкретного человека?

• Вы делаете knowledge sharing по команде?

• Насколько легко автоматизировать текущие ручные процессы?

• У каждого человека есть хотя бы один «дублер»?

• Вы проводите внутренние учения и имитации потерь?

• Насколько устойчив ваш oncall (дежурный) режим?

• Вас не пугает отпуск, декрет или уход коллеги?

• Документация лежит в доступном месте, а не в голове?

За каждый ответ начислите себе баллы — от 1 до 10. Например, если на первый вопрос я отвечаю «не уверен», у меня 1 балл. Если «абсолютно уверен» — 10. А если «сомнительно, но окей» — 5. Ответив на все вопросы, подсчитайте баллы. 

Интерпретация:
• 110–150 баллов: все отлично! Команда устойчива.
• 80–109: есть риски, но их можно управляемо устранить.
• <80: срочно займитесь устранением «бутылочных горлышек».