Próbowałem wziąć urlop w marcu 2024 roku. Trwał cztery dni.

Drugiego dnia odpowiedziałem na "jedno szybkie pytanie" na Slacku. Trzeciego dnia siedziałem w hotelowym lobby, rozwiązując problem produkcyjny – problem z naszymi serwerami działającymi na żywo, z którymi mają kontakt klienci. Czwartego dnia mój partner powiedział: "Po prostu wróć do pracy. To nie są wakacje." Miał rację.

Problemem nie był mój zespół. Byli kompetentni. Problemem było to, że mój mózg był jedyną kopią połowy operacji firmy. Procedura wdrażania? W mojej głowie. Ścieżka eskalacji klienta? W mojej głowie. Jak zrestartować usługę rozliczeniową, gdy się zawiesza? Też w mojej głowie. Nie byłem niezastąpiony, bo byłem geniuszem. Byłem niezastąpiony, bo niczego nie zapisałem.

Sześć miesięcy później, we wrześniu 2024 roku, wziąłem dwa pełne tygodnie wolnego. Bez laptopa. Bez Slacka. Bez "szybkich rozmów". Nic się nie zepsuło.

Oto, co zrobiłem w ciągu tych sześciu miesięcy.

Krok 1: Znajdź swój bus factor

"Bus factor" – ponury, ale użyteczny wskaźnik: ile osób w twoim zespole musi zniknąć, zanim proces przestanie całkowicie funkcjonować? Jeśli odpowiedź to "jeden", a ta osoba to ty, nie masz systemu. Masz sytuację zakładnika.

Wymieniłem każde powtarzające się zadanie, które posiadam, i zadałem jedno pytanie: "Jeśli zniknę jutro, kto mógłby to zrobić?"

Zadanie Bus factor Kto jeszcze wie?
Wdrażanie produkcji 1 (ja) Nikt
Problemy z rozliczeniami klientów 1 (ja) Nikt
Reakcja na monitorowanie serwera 1 (ja) Nikt
Planowanie sprintu 2 Współprzewodniczący
Przeglądy kodu 3 Każdy starszy deweloper
Rozmowy kwalifikacyjne 2 Współprzewodniczący

Trzy kluczowe procesy z bus factorem 1. Trzy rzeczy, które całkowicie by się zatrzymały, gdybym złapał zatrucie pokarmowe. To nie są operacje. To pokaz jednej osoby w przebraniu zespołu.

Koncepcja pochodzi z kultury oprogramowania open-source, gdzie projekty żyją lub umierają w zależności od liczby współpracowników. Wpis na Wikipedii o bus factorze wymienia przykłady z dużych firm technologicznych – ten sam problem, na większą skalę.

Krok 2: Pisz runbooki, nie dokumentację

To rozróżnienie ma znaczenie. Dokumentacja wyjaśnia, jak coś działa. Runbook – dokument procedury operacyjnej, przepis krok po kroku na obsługę konkretnej sytuacji – wyjaśnia, co robić.

Dokumentacja: "Usługa rozliczeniowa wykorzystuje webhooki Stripe (automatyczne powiadomienia, które Stripe wysyła, gdy wystąpi zdarzenie płatności) do przetwarzania płatności. Zdarzenia są kolejkowane w Redis i przetwarzane przez pracownika rozliczeń."

Runbook: "Kiedy rozliczenia są zablokowane: 1) Sprawdź długość kolejki w Redis: redis-cli llen billing_queue. 2) Jeśli kolejka > 100, zrestartuj pracownika rozliczeń: systemctl restart billing-worker. 3) Jeśli restart nie wyczyści kolejki w ciągu 5 minut, sprawdź pulpit Stripe dla nieudanych webhooków."

Widzisz różnicę? Dokumentacja wymaga zrozumienia. Runbook wymaga wykonania instrukcji. Każdy, kto potrafi wpisywać komendy w terminalu – tekstowym interfejsie, w którym wprowadzasz polecenia bezpośrednio – może się posłużyć runbookiem. Nie muszą rozumieć, dlaczego Redis (szybka pamięć podręczna często używana jako kolejka wiadomości) jest używany. Muszą wiedzieć, co wpisać.

PagerDuty, firma, która zbudowała cały swój biznes wokół odpowiedzi na incydenty, opublikowała solidny przewodnik na temat pisania runbooków, który opiera się na tej samej zasadzie: optymalizacja pod kątem działania, a nie zrozumienia.

Napisałem runbooki dla wszystkich trzech procesów z bus factorem 1. Każdy zajął 30–60 minut. Oto format:

Runbook: Wdrażanie Produkcji

Kiedy używać:
Podczas łączenia z główną gałęzią i wdrażania do produkcji.

Wymagania wstępne:
- Dostęp SSH do serwera produkcyjnego (zapytaj IT jeśli go nie masz)
- Dostęp do kanału #deploys na Slacku

Kroki:
1. Połącz PR z główną gałęzią
2. Poczekaj na przejście testów CI (GitHub Actions, ~5 min)
3. SSH do serwera: ssh [email protected]
4. Uruchom: bash /srv/app/deploy.sh 
5. Sprawdź stan zdrowia: curl -s http://localhost:8080/health | jq .
6. Jeśli kontrola zdrowia się nie powiedzie: bash /srv/app/rollback.sh
7. Opublikuj wynik w #deploys

Jeśli coś pójdzie nie tak:
- Skrypt wdrażający zawiedzie → sprawdź logi w /var/log/deploys/
- Kontrola zdrowia zwraca 503 → sprawdź, który subsystem zawiódł w odpowiedzi JSON
- Nie można SSH → skontaktuj się z IT, sprawdź VPN
- Wycofanie się nie powiedzie → zadzwoń do Captaina. Nie Slack. Telefon.

Eskalacja:
Jeśli utkniesz dłużej niż 15 minut, zadzwoń do Captaina. Telefon, nie Slack.

Żadna teoria. Żadne diagramy architektury. Po prostu: "kiedy to się dzieje, zrób to."

Krok 3: Tydzień cienia

Pisanie runbooków to za mało. Musisz je przetestować na prawdziwych ludziach.

Przeprowadziłem "tydzień cienia" – tydzień, podczas którego byłem dostępny, ale nie dotykałem żadnego z trzech procesów samemu. Ktoś inny postępował według runbooka. Obserwowałem.

Rezultaty:

  • Runbook wdrożeniowy: Zadziałał za pierwszym razem. Członek zespołu znalazł literówkę w kroku 4 (zła ścieżka do pliku). Naprawiono w dwie minuty.
  • Runbook rozliczeniowy: Niepowodzenie na kroku 3. Napisałem "sprawdź pulpit Stripe", ale nigdy nie wyjaśniłem, jak się zalogować. Dane uwierzytelniające znajdowały się w moim osobistym menedżerze haseł, a nie we wspólnym. Dodano wspólny dostęp – problem rozwiązany.
  • Runbook monitorowania: Częściowo działał. Kroki były poprawne, ale interfejs narzędzia monitorującego zmienił się od czasu napisania dokumentu. Zaktualizowano zrzuty ekranu.

Każdy pojedynczy runbook wymagał co najmniej jednej korekty. To normalne. Kiedy piszesz z pamięci, pomijasz kroki, które wydają się "oczywiste", ponieważ wykonałeś je 500 razy. Tydzień cienia ujawnia te luki, zanim będą miały znaczenie o 3 nad ranem w sobotę.

Zespół SRE Google – grupa odpowiedzialna za utrzymanie infrastruktury Google – omawia tę zasadę w swojej darmowej książce Site Reliability Engineering: dokumentacja, która nie została przetestowana w rzeczywistych warunkach, to fikcja.

Krok 4: Spotkanie przeniesienia wiedzy

Dla każdego runbooka zorganizowałem 30-minutową sesję przeniesienia wiedzy. Nie szkolenie – przeniesienie. Szkolenie uczy umiejętności. Przeniesienie uczy kontekstu.

Struktura:

  1. Przejdźcie wspólnie przez runbook (10 min) – osoba podąża za każdym krokiem, a ja obserwuję. Pomagam tylko jeśli utkną.
  2. Wyjaśnij "dlaczego" za krytycznymi krokami (10 min) – nie wymagane do wykonania, ale pomaga przy podejmowaniu decyzji. "Zrestartujemy pracownika rozliczeń przed badaniem, ponieważ przestój kosztuje nas $X na minutę. Najpierw szybkość, potem przyczyna."
  3. Q&A (10 min) – ich pytania ujawniają, co dokładnie zapomniałem udokumentować.

Po spotkaniu, oni przejmują ten proces. Nie "pomoc przy procesie". Przejmują go. Ja staję się backupem, nie główną osobą.

Krok 5: Test urlopowy

Dwa miesiące po tygodniu cienia, wziąłem trzydniowy długi weekend bez laptopa. Żadnych awarii. Żadnych "szybkich pytań". Runbooki się sprawdziły.

Miesiąc później, cały tydzień wolnego. Jeden drobny problem: runbook monitorujący nie obejmował konkretnego przypadku krawędziowego – pełnego dysku na niestandardowej partycji. Osoba dyżurująca improwizowała poprawnie i dodała ten przypadek do runbooka później. System poprawił się sam bez udziału mojej osoby. To znak, że działa.

Miesiąc później: pełne dwa tygodnie. Zero incydentów wymagających mojego zaangażowania. Zespół wysłał mi zdjęcie tablicy z napisem: "Dzień 9: Capitan jeszcze nie zadzwonił. Myślimy, że system działa."

Część, o której nikt nie mówi

Pisanie się z procesów wydaje się być jak uczynienie samego siebie zbędnym. Tak jest. O to chodzi.

Ale to wyzwala coś niekomfortowego – część twojej tożsamości związana z byciem "osobą, która wie wszystko." Osobą, do której ludzie dzwonią. Osobą, która ratuje sytuację.

Muszę być szczery: dziwnie się poczułem, kiedy wdrożenia odbywały się bez mojej obecności. Kiedy problemy z rozliczeniami rozwiązywały się bez mojej wiadomości. Kiedy alarm serwerowy zadzwonił, a ktoś inny zajął się tym w ciągu 8 minut. Część mnie chciała być potrzebna.

Oto co dostałem w zamian: wolność. Nie tylko wolność wakacyjną – codzienną wolność. Przestałem być wąskim gardłem – pojedynczym punktem, w którym wszystkie decyzje się piętrzą. Praca, która kiedyś czekała na moje zatwierdzenie, teraz odbywała się w czasie rzeczywistym. Zespół poruszał się szybciej. Skupiłem się na decyzjach, które rzeczywiście wymagały mojego osądu, zamiast na zadaniach, które wymagały tylko mojej pamięci.

Twoja lista działań

Od marca 2026 roku powtórzyłem ten proces w trzech różnych organizacjach. Schemat powtarza się za każdym razem. Jeśli nie możesz wziąć dwóch tygodni wolnego bez awarii, nie masz systemu – masz nawyk bycia zajętym.

Oto twoja lista kontrolna:

  1. Przeprowadź audyt swojego bus factoru – wypisz każde powtarzające się zadanie, oznacz, kto jeszcze może to wykonać
  2. Napisz runbooki dla wszystkiego z bus factorem = 1 (zaplanowane 30–60 minut na każdy)
  3. Przeprowadź tydzień cienia – ktoś inny wykonuje, ty obserwujesz i poprawiasz dokumenty
  4. Przeprowadź spotkania przeniesienia wiedzy – 30 minut na proces, strukturalne
  5. Przetestuj podczas prawdziwego urlopu – najpierw długi weekend, potem tydzień, potem dwa

Napisz runbook. Zrób tydzień cienia. Weź urlop.

Wrócisz wypoczęty, a zespół będzie bardziej kompetentny niż gdy wyjeżdżałeś. To nie jest bycie zbędnym. To dobra inżynieria.