Привет всем! Меня зовут Гриша Капцов, я работаю в Отделе координации и поддержки продуктовых команд в МТС 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. Проведите ревизию зоны ответственности. Для этого можно взять простой шаблон — например, таблицу, составить список ключевых процессов, систем и задач, а потом для каждой зоны отметить:
кто основной исполнитель;
есть ли дублеры;
есть ли документация и когда она обновлялась;
комментарий — например, где именно узкое место, какие знания концентрируются у одного человека, что мешает их делегировать.
Советую не забывать про комментарии, так как в нужный момент именно они становятся основой для плана по снижению рисков.
А тут пример, как это все оформляется:
Зона ответственности | Владелец | Дублер | Документация (ссылка + дата) | Комментарий | Оценка Bus Factor |
Резервное копирование | Иван | — | Нет | Сильный риск. Ключевые знания сосредоточены у одного человека, требуется распределение задач. | 1 |
Конфигурация Kafka | Лена | Петя | Частично | Актуализировать. Документация есть, но устарела; нужно обновление инструкций и ссылок. | 2 |
Финансовые отчеты | — | — | Да — Ссылка (Последнее обновление месяц назад) | Автоматизировано. Процесс задокументирован и частично автоматизирован, риски минимальны. | 4 |
Если один инженер знает, как развернуть критичный сервис, а остальная команда — нет, то показатель Bus Factor этой зоны равен 1. Если знанием владеют трое, Bus Factor уже равен 3 — и риски снижаются в разы. То есть Bus Factor измеряется количеством сотрудников, которые могут поддерживать ключевой процесс или систему без потери производительности. Но при высоком уровне автоматизации показатель может превышать 3, даже если фактически вовлечено меньше сотрудников. Это происходит потому, что устойчивость обеспечивается не людьми, а автоматическими механизмами.
Как оценивать значения Bus Factor:≤ 1 — допустимо только для стартапов;
= 2 — для команд в активном росте;
≥ ½N (но не меньше 3) — для зрелых и стабильных продуктов.
Bus Factor | Описание | Пример |
1 | Критическая зона — все знания у одного человека. Если его нет, процесс останавливается. | Ручной деплой у единственного инженера. |
2 | Есть дублер, но не полная взаимозаменяемость. | Два специалиста знают процесс, но инструкции не обновляются. |
3 | Комфортный уровень: минимум три человека владеют знаниями и могут подхватить задачи без потерь. | Команда поддержки из трех человек с актуальными runbook-ами. |
4+ | Устойчивый уровень: процессы задокументированы, автоматизированы, знания распределены. | Потеря отдельного сотрудника не влияет на работоспособность. CI/CD, автобэкапы, обновленные инструкции, независимость от конкретных людей. |
Целевые значения зависят от зрелости продукта. На ранних стадиях 1–2 владельца знаний — норма. Для зрелых систем и сервисов целевым считается показатель 3 и выше: это значит, что хотя бы три человека могут поддерживать ключевые процессы.
Важно помнить: цифры, которые вы получили один раз, вдолгую не работают. Считать нужно регулярно, например, раз в полгода или при 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.
Кто отвечает: руководители, HR и тимлиды.
Артефакт: политика по knowledge sharing, список внутренних воркшопов, запись о включении KT в оценку эффективности.
Важно: делайте обмен знаний регулярным и видимым. Премируйте тех, кто активно растит дублеров.
Шаг 7. Периодически проводите «симуляции потерь». Устраивайте учения, где один из владельцев «временно недоступен» (table-top exercises, black-box drills или отключение доступа на 24–48 часов), и проверяйте, насколько быстро команда подхватывает процессы. После учения проводите blameless post-mortem и обновляйте runbook.
Кто отвечает: SRE, тимлид или офицер по непрерывности бизнеса.
Артефакт: отчет по учению с выводами: time-to-recovery, пробелы в документации, план исправлений.
Запомните, что это не стресс-тест. Заранее опишите ценность практики сотрудникам и проводите ее в контролируемой среде.
Как запустить процесс передачи знаний
Не просто посчитать Bus Factor, но и превратить метрику в инструмент поможет чек-лист:
Запуск процесса передачи знаний и актуализации документации | ||
Задача | Ответственный | Срок |
Провести ревизию зон ответственности | Тимлид и сеньоры | 1 неделя |
Назначить дублеров | Тимлид и HR | 1 неделя |
Обновить ключевую документацию | Вся команда | 2 недели |
Внедрить регулярную ротацию | Тимлид и спринт-планинг | Постоянно |
Провести чек самодиагностики | Команда | Сейчас |
Подготовить шаблоны инструкций | DevOps и документатор | 3 дня |
Сделать презентацию про Bus Factor | Тимлид и HR | По итогам работы |
Не спринт, а марафон
После проведения опроса в нашей компании мы начали внутренние инициативы по снижению Bus Factor. В нескольких трайбах уже провели сессии обмена знаниями, выделили зоны с показателем 1, завели внутренние базы инструкций и назначили «дублирующие» роли. В результате вырос средний балл уверенности в замещении — с 7,1 до 7,8. Но мы готовы к тому, что это небыстрый процесс, его нельзя выполнить за месяц и отложить на дальнюю полку.
По сути, отслеживание Bus Factor — это подход к работе, который требует постоянного внимания. Зато если им заниматься, разница между «у нас устойчиво» и «все рухнуло» не будет одним человеком.
Если у вас есть свои примеры и инструменты, как выстоять против сценария «один попал под автобус (спокойно, это образно), и мир остановился», — пишите в комментариях. Давайте соберем нормальный подход, который действительно снижает риски, а не просто позволяет проставить галочки в документообороте.
Напоследок — инструмент самодиагностики. Задайте себе эти вопросы, чтобы оценить ситуацию в вашей команде прямо сейчас:
Насколько вы уверены, что хотя бы два человека могут выполнять каждую критичную задачу?
У вас есть актуальные инструкции по ключевым операциям?
Новичок может войти в курс дела без сопровождения?
Ключевые доступы централизованы и есть минимум у двух сотрудников?
Есть план «что делать», если кто-то исчезнет?
Задачи ротируются между участниками команды?
Регулярно ли вы обновляете техническую документацию?
Сервис можно починить без участия конкретного человека?
Вы делаете knowledge sharing по команде?
Насколько легко автоматизировать текущие ручные процессы?
У каждого человека есть хотя бы один «дублер»?
Вы проводите внутренние учения и имитации потерь?
Насколько устойчив ваш oncall (дежурный) режим?
Вас не пугает отпуск, декрет или уход коллеги?
Документация лежит в доступном месте, а не в голове?
За каждый ответ начислите себе баллы — от 1 до 10. Например, если на первый вопрос я отвечаю «не уверен», у меня 1 балл. Если «абсолютно уверен» — 10. А если «сомнительно, но окей» — 5. Ответив на все вопросы, подсчитайте баллы.
Интерпретация:
• 110–150 баллов: все отлично! Команда устойчива.
• 80–109: есть риски, но их можно управляемо устранить.
• <80: срочно займитесь устранением «бутылочных горлышек».
