Bus factor — co to jest, jak go policzyć i jak podnieść w zespole IT

Bus factor to minimalna liczba osób z zespołu, które musiałyby nagle zniknąć — odejść z firmy, zachorować, „wpaść pod autobus” — żeby projekt utknął, bo nikt inny nie ma potrzebnej wiedzy albo dostępów. Im wyższy bus factor, tym lepiej: wartość 1 oznacza, że cały projekt wisi na jednej osobie.

Pojęcie funkcjonuje też jako truck factor, a w łagodniejszej wersji jako lottery factor (ktoś wygrywa na loterii i przestaje przychodzić do pracy). Niezależnie od nazwy chodzi o to samo: ile osób dzieli Cię od sytuacji, w której nikt nie umie wdrożyć poprawki, odnowić certyfikatu albo wyjaśnić, dlaczego system działa tak, a nie inaczej.

Bus factor w praktyce: przykłady z życia zespołu

Najłatwiej zrozumieć tę miarę na typowych scenariuszach, które zna większość firm IT:

• Tylko jedna osoba wie, jak zbudować i wdrożyć aplikację, bo proces „siedzi w jej głowie” i w skryptach na jej laptopie.
• Hasło do panelu rejestratora domen, konta chmurowego albo serwera produkcyjnego zna wyłącznie administrator, który właśnie poszedł na trzytygodniowy urlop.
• Moduł rozliczeń napisał przed laty jeden programista. Reszta zespołu omija go szerokim łukiem, bo „lepiej tego nie dotykać”.
• Integrację z systemem partnera zna osoba, która utrzymuje kontakt z ich działem IT i nigdzie tego nie zapisała.

W każdym z tych przypadków bus factor danego obszaru wynosi 1. Problem zwykle wychodzi na jaw w najgorszym momencie: w nocy podczas awarii, w trakcie urlopu albo po złożeniu wypowiedzenia.

Głośnym przykładem ze świata open source jest biblioteka xz utils. W 2024 roku wykryto w niej celowo wprowadzony backdoor (CVE-2024-3094). Projekt przez lata utrzymywał w praktyce jeden przemęczony opiekun, co ułatwiło atakującemu stopniowe przejęcie roli współopiekuna. To pokazuje, że niski bus factor to nie tylko ryzyko przestoju, ale też bezpieczeństwa.

Jak policzyć bus factor zespołu krok po kroku

Bus factor nie jest jedną liczbą „dla zespołu” wziętą z powietrza. Liczy się go dla konkretnych obszarów, a wynik całości wyznacza najsłabsze ogniwo.

1. Wypisz krytyczne obszary. Nie tylko moduły kodu, ale też: wdrożenia (CI/CD), infrastruktura, bazy danych, dostępy i hasła, kontakty z dostawcami, wiedza domenowa (np. jak liczone są faktury).
2. Przy każdym obszarze zapisz osoby, które potrafią go samodzielnie utrzymać: naprawić błąd, wdrożyć zmianę, odtworzyć z kopii zapasowej. Samo „kiedyś patrzyłem w ten kod” się nie liczy.
3. Policz osoby dla każdego obszaru. To bus factor tego obszaru.
4. Weź minimum. Bus factor projektu to najmniejsza wartość z listy — jeśli jeden krytyczny obszar ma 1, cały projekt ma 1.

Przykładowa macierz dla małego zespołu może wyglądać tak:

Bus factor tego projektu wynosi 1, mimo że w zespole jest pięć osób. Taka tabela od razu pokazuje, gdzie inwestować czas: tu w przekazanie wiedzy o wdrożeniach i w drugie konto administracyjne.

Wskazówka: Prosty test sprawdzający: „Czy zespół poradzi sobie przez dwa tygodnie bez tej osoby, bez dzwonienia do niej?”. Jeśli odpowiedź brzmi „nie”, bus factor tego obszaru wynosi 1.

Jak sprawdzić bus factor w repozytorium Git

Historia repozytorium nie powie wszystkiego (wiedza o infrastrukturze czy kontaktach nie jest w commitach), ale świetnie pokazuje, kto jest jedynym autorem kodu. Jeśli nie masz pewności, czym Git różni się od platformy, na której trzymasz repozytorium, zajrzyj do tekstu Git a GitHub — czym się różnią.

Ranking autorów w całym repozytorium:

git shortlog -sne --no-merges

Kto zmieniał konkretny katalog lub plik w ostatnim roku:

git log --since="1 year ago" --no-merges --format='%an' -- src/billing/ | sort | uniq -c | sort -rn

Pliki, które w ostatnim roku edytowała tylko jedna osoba (prosty skrypt do uruchomienia w katalogu repozytorium):

git ls-files | while read -r f; do
  n=$(git log --since="1 year ago" --format='%ae' -- "$f" | sort -u | wc -l)
  [ "$n" -eq 1 ] && echo "$(git log -1 --format='%an' -- "$f")  $f"
done

Wyniki traktuj jako sygnał, a nie wyrok. Ktoś mógł zrobić dużą refaktoryzację i „przejąć” autorstwo setek plików, a ktoś inny zna moduł świetnie, choć rzadko commituje. Badacze stosują do tego bardziej zaawansowane metody, np. ważony udział w autorstwie pliku, ale zasada jest ta sama: usuwasz kolejnych najważniejszych autorów i sprawdzasz, kiedy większość kodu zostaje „osierocona”.

Na GitHubie i GitLabie pomocny jest też plik CODEOWNERS. Jeśli przy krytycznych ścieżkach widnieje jedna osoba, masz gotową listę miejsc z bus factorem równym 1.

Dlaczego niski bus factor jest groźny

Konsekwencje są bardziej przyziemne niż „projekt upada”:

• Przestoje i opóźnienia — awaria w module, którego nikt poza autorem nie rozumie, trwa godziny zamiast minut.
• Wąskie gardło — wszystkie zmiany w danym obszarze czekają na jedną osobę, nawet jeśli jest dostępna. Tempo zespołu spada do tempa tej osoby.
• Wypalenie — „niezastąpiony” specjalista nie może spokojnie wziąć urlopu, dostaje telefony w weekendy i w końcu odchodzi, co realizuje najgorszy scenariusz.
• Ryzyko bezpieczeństwa — dostępy skupione u jednej osoby to problem zarówno przy jej odejściu, jak i przy przejęciu jej konta.
• Utrata wiedzy domenowej — kod można przeczytać, ale powody decyzji („dlaczego ten rabat liczy się dwa razy”) giną razem z człowiekiem.

Jak zwiększyć bus factor: praktyki, które działają

Celem nie jest, żeby każdy znał wszystko. Wystarczy, że każdy krytyczny obszar ma co najmniej dwie, a najlepiej trzy osoby, które sobie z nim poradzą.

Code review przez różne osoby

Przegląd kodu to najtańszy sposób rozpraszania wiedzy. Ustal, że zmian w danym module nie zatwierdza zawsze ta sama osoba, a w CODEOWNERS przy krytycznych ścieżkach wpisuj co najmniej dwie osoby lub cały zespół. Recenzent, który kilka razy przeszedł przez moduł rozliczeń, w razie awarii nie zaczyna od zera.

Programowanie w parach i rotacja zadań

Przydzielaj zadania z „obcych” obszarów celowo, najlepiej w parze z dotychczasowym ekspertem. Pair programming i mob programming są wolniejsze na krótką metę, ale to jedna z najskuteczniejszych metod transferu wiedzy ukrytej, której nikt nie zapisze w dokumentacji.

Dokumentacja, która odpowiada na „jak” i „dlaczego”

Dokumentacja nie musi być obszerna — ma być aktualna i trafiać w potrzeby osoby, która przejmuje temat. Najbardziej opłacają się:

• runbooki — instrukcje krok po kroku na typowe sytuacje: wdrożenie, rollback, odnowienie certyfikatu, odtworzenie bazy z kopii,
• ADR (Architecture Decision Records) — krótkie notatki o tym, jaką decyzję podjęto i dlaczego,
• README w każdym repozytorium z instrukcją uruchomienia projektu lokalnie.

Praktyczne rady, jak pisać takie dokumenty, znajdziesz w artykule 5 wskazówek dla lepszej dokumentacji technicznej.

Automatyzacja i infrastruktura jako kod

Wiedza zapisana w skrypcie CI/CD, playbooku czy pliku Terraform jest dostępna dla każdego, kto ma dostęp do repozytorium. Ręczna konfiguracja serwera „wyklikana” przez jedną osobę — nie. Jeśli zaczynasz od automatyzacji konfiguracji serwerów, dobrym punktem startu jest Ansible. Warto też jasno rozdzielić pojęcia wdrożenia i wydania w zespole — o tym w tekście deploy a release: różnice.

Dostępy i hasła w sejfie, nie w głowie

Każde konto krytyczne (chmura, domeny, DNS, płatności, konsola administracyjna) powinno mieć co najmniej dwie osoby z uprawnieniami albo procedurę dostępu awaryjnego (break-glass). Hasła trzymaj we współdzielonym menedżerze haseł zespołu, a w większych organizacjach w systemie klasy PAM (Privileged Access Management).

Uwaga: Podnoszenie bus factora nie może oznaczać rozdawania wszystkim pełnych uprawnień. Dwie osoby z dostępem administracyjnym i kontrolowana procedura awaryjna to rozsądny kompromis; dwadzieścia osób z hasłem roota — już nie.

Dyżury i urlopy jako test

Rotacyjne dyżury (on-call) wymuszają, żeby kilka osób umiało reagować na incydenty. Podobnie działa zasada, że ekspert w czasie urlopu jest naprawdę niedostępny: braki w wiedzy wychodzą wtedy w kontrolowanych warunkach, a nie w czasie kryzysu.

Bus factor w projektach open source

W otwartym oprogramowaniu problem jest jeszcze wyraźniejszy. Wiele bibliotek, na których stoją tysiące aplikacji komercyjnych, utrzymuje jedna lub dwie osoby po godzinach. Wybierając zależność do projektu, warto więc sprawdzić nie tylko liczbę gwiazdek, ale też:

• ilu aktywnych opiekunów (maintainerów) ma projekt i kto zatwierdza zmiany,
• kiedy był ostatni release i jak szybko zamykane są zgłoszenia bezpieczeństwa,
• czy projekt jest pod opieką fundacji lub firmy (np. Apache, Linux Foundation, CNCF), co zwykle oznacza więcej niż jedną osobę z uprawnieniami do wydań.

Jeśli Twoja firma krytycznie zależy od takiej biblioteki, najprostsze sposoby podniesienia jej bus factora to wsparcie finansowe opiekunów lub oddelegowanie własnego programisty do regularnego udziału w projekcie.

Od czego zacząć w swoim zespole

Nie trzeba od razu wdrażać wszystkiego. Na start wystarczą trzy kroki:

1. W ciągu jednego spotkania zbuduj macierz obszarów i osób jak w tabeli powyżej. Zaznacz wszystkie obszary z wartością 1.
2. Dla każdego z nich wyznacz drugą osobę i zaplanuj konkretne działanie: wspólne wdrożenie, przegląd kodu, spisanie runbooka, nadanie drugiego dostępu administracyjnego.
3. Wracaj do macierzy co kwartał albo przy każdej zmianie w składzie zespołu.

Bus factor to jedna z niewielu miar ryzyka, którą da się poprawić bez budżetu, samą organizacją pracy. Zespół, w którym nikt nie jest niezastąpiony, działa szybciej, a jego członkowie mogą spokojnie chorować i brać urlopy.