Я спробував піти у відпустку в березні 2024-го. Вистачило на чотири дні.
На другий день відповів на 'одне швидке питання' в Slack. На третій — сидів у лобі готелю і дебажив проблему на проді — баг на живих серверах, якими користуються клієнти. На четвертий день партнерка сказала: 'Просто повертайся на роботу. Це не відпустка'. Вона мала рацію.
Проблема була не в команді. Вони справлялись. Проблема була в тому, що мій мозок зберігав єдину копію половини процесів компанії. Процедура деплою? В моїй голові. Ескалація клієнтських проблем? В моїй голові. Як перезапустити біллінг-сервіс, коли він зависає? Теж в моїй голові. Я був незамінним не тому, що геніальний. А тому, що нічого не записав.
Через шість місяців, у вересні 2024-го, я пішов у відпустку на повних два тижні. Без ноутбука. Без Slack. Без 'швидких дзвінків'. Нічого не зламалось.
Ось що я зробив за ці шість місяців.
Крок 1: Визнач свій bus factor
'Bus factor' — похмура, але корисна метрика: скільки людей у команді мають зникнути, щоб процес повністю зупинився? Якщо відповідь 'одна' і ця одна — ти, у тебе не система. У тебе заручницька ситуація.
Я виписав усі регулярні задачі, за які відповідаю, і поставив одне питання: 'Якщо я зникну завтра — хто це зробить?'
| Задача | Bus factor | Хто ще знає? |
|---|---|---|
| Деплой на прод | 1 (я) | Ніхто |
| Біллінгові проблеми клієнтів | 1 (я) | Ніхто |
| Реакція на моніторинг серверів | 1 (я) | Ніхто |
| Планування спринтів | 2 | Ко-лід |
| Код-рев'ю | 3 | Будь-який сеньйор |
| Співбесіди | 2 | Ко-лід |
Три критичні процеси з bus factor = 1. Три речі, які повністю зупиняться, якщо я отруюсь шаурмою. Це не операційна діяльність. Це театр одного актора в костюмі команди.
Концепція прийшла з культури open-source, де проєкти живуть або вмирають залежно від кількості контриб'юторів. У статті Вікіпедії про bus factor є приклади з великих техкомпаній — та сама проблема, більший масштаб.
Крок 2: Пиши runbooks, а не документацію
Ця різниця має значення. Документація пояснює, як щось працює. Runbook — операційна інструкція, покроковий рецепт для конкретної ситуації — пояснює, що робити.
Документація: 'Біллінг-сервіс використовує Stripe webhooks (автоматичні повідомлення, які Stripe надсилає при платіжних подіях) для обробки платежів. Події потрапляють у чергу Redis і обробляються біллінг-воркером.'
Runbook: 'Коли біллінг завис: 1) Перевір довжину черги Redis: redis-cli llen billing_queue. 2) Якщо черга > 100, перезапусти біллінг-воркер: systemctl restart billing-worker. 3) Якщо перезапуск не очистив чергу за 5 хвилин — перевір дашборд Stripe на предмет невдалих webhooks.'
Бачиш різницю? Документація вимагає розуміння. Runbook вимагає виконання інструкцій. Будь-хто, хто може вводити команди в термінал — текстовий інтерфейс, де ти вводиш команди напряму — може слідувати runbook. Не потрібно розуміти, навіщо тут Redis (швидка in-memory база даних, яку часто використовують як чергу повідомлень). Потрібно знати, що вводити.
PagerDuty, компанія, яка побудувала весь бізнес навколо реагування на інциденти, опублікувала хороший гайд з написання runbooks, який описує той самий принцип: оптимізуй для дій, а не для розуміння.
Я написав runbooks для всіх трьох процесів з bus factor = 1. Кожен зайняв 30–60 хвилин. Ось формат:
Runbook: Production Deploy
Коли використовувати:
При мержі в main і деплої на прод.
Необхідні умови:
- SSH-доступ до прод-сервера (запитай в IT, якщо немає)
- Доступ до Slack-каналу #deploys
Кроки:
1. Змерж PR в main
2. Дочекайся, поки CI-перевірки пройдуть (GitHub Actions, ~5 хв)
3. SSH на сервер: ssh [email protected]
4. Запусти: bash /srv/app/deploy.sh
5. Перевір хелсчек: curl -s http://localhost:8080/health | jq .
6. Якщо хелсчек впав: bash /srv/app/rollback.sh
7. Напиши результат в #deploys
Якщо щось пішло не так:
- Деплой-скрипт впав → дивись логи в /var/log/deploys/
- Хелсчек повертає 503 → перевір, яка підсистема впала в JSON-відповіді
- Не можеш підключитись по SSH → зверніся в IT, перевір VPN
- Ролбек не працює → дзвони Капітану. Не в Slack. Телефоном.
Ескалація:
Якщо застряг більше ніж на 15 хвилин — дзвони Капітану. Телефоном, не в Slack.
Ніякої теорії. Ніяких архітектурних діаграм. Просто: 'коли це трапляється — роби це'.
Крок 3: Тіньовий тиждень
Написати runbooks недостатньо. Їх потрібно протестувати на живих людях.
Я провів 'тіньовий тиждень' — тиждень, протягом якого я залишався на зв'язку, але не торкався жодного з трьох процесів. Хтось інший слідував runbook. Я спостерігав.
Результати:
- Runbook деплою: Спрацював з першого разу. Колега знайшов друкарську помилку в кроці 4 (неправильний шлях до файлу). Виправили за дві хвилини.
- Runbook біллінгу: Зламався на кроці 3. Я написав 'перевір дашборд Stripe', але не пояснив, як залогінитись. Креди лежали в моєму особистому менеджері паролів, а не в спільному. Додав спільний доступ — проблему вирішено.
- Runbook моніторингу: Спрацював частково. Кроки були правильні, але інтерфейс інструменту моніторингу змінився з моменту написання. Оновив скріншоти.
Кожен runbook потребував мінімум одного виправлення. Це нормально. Коли пишеш по пам'яті — пропускаєш кроки, які здаються 'очевидними', бо ти їх робив 500 разів. Тіньовий тиждень виявляє ці прогалини до того, як вони стануть критичними о 3 ночі в суботу.
Команда Google SRE — група, яка відповідає за безперебійну роботу інфраструктури Google — описує цей принцип у своїй безкоштовній книзі Site Reliability Engineering: документація, яка не протестована в реальних умовах — це художня література.
Крок 4: Передача знань
Для кожного runbook я провів 30-хвилинну сесію передачі знань. Не навчання — передача. Навчання дає навички. Передача дає контекст.
Структура:
- Пройтись по runbook разом (10 хв) — людина виконує кожен крок, а я дивлюсь. Не допомагаю, поки не застрягне.
- Пояснити 'чому' за критичними кроками (10 хв) — для виконання не обов'язково, але допомагає приймати рішення. 'Ми перезапускаємо біллінг-воркер до розслідування, бо даунтайм коштує $X за хвилину. Спочатку швидкість, потім причина.'
- Запитання і відповіді (10 хв) — їхні запитання показують, що саме ти забув задокументувати.
Після зустрічі процес належить їм. Не 'допомагають з процесом'. Володіють ним. Я стаю бекапом, а не основним виконавцем.
Крок 5: Тест відпусткою
Через два місяці після тіньового тижня я поїхав на подовжені вихідні без ноутбука. Жодних аварій. Жодних 'швидких питань'. Runbooks тримали оборону.
Ще через місяць — повний тиждень відпустки. Один дрібний інцидент: runbook моніторингу не покривав специфічний крайній випадок — переповнений диск на нестандартному розділі. Черговий імпровізував правильно і сам додав цей випадок до runbook. Система покращила себе без мене. Це ознака того, що все працює.
Ще через місяць: повних два тижні. Нуль інцидентів, що потребували моєї участі. Команда надіслала мені фото дошки з написом: 'День 9: Капітан не дзвонив. Здається, система працює.'
Про що зазвичай мовчать
Виписати себе з процесів — це відчувається як зробити себе непотрібним. Так і є. В цьому суть.
Але це чіпляє щось некомфортне — ту частину твоєї ідентичності, що прив'язана до ролі 'людини, яка все знає'. Тієї, кому дзвонять. Тієї, хто рятує ситуацію.
Скажу чесно: було дивно, коли деплої відбувались без мене. Коли біллінгові проблеми вирішувались без повідомлення. Коли алерт моніторингу спрацював — і хтось інший закрив його за 8 хвилин. Частина мене хотіла бути потрібним.
Ось що я отримав натомість: свободу. Не лише відпусткову — щоденну. Я перестав бути вузьким місцем — єдиною точкою, де накопичувались усі рішення в очікуванні. Робота, яка раніше стояла в черзі за мною, тепер відбувалась у реальному часі. Команда рухалась швидше. Я фокусувався на рішеннях, які дійсно потребували мого судження, а не на задачах, які просто потребували моєї пам'яті.
Твій план дій
Станом на березень 2026-го я повторив цей процес у трьох різних організаціях. Патерн працює кожного разу. Якщо ти не можеш піти у відпустку на два тижні без того, щоб усе розвалилось — у тебе не система. У тебе звичка бути зайнятим.
Ось твій чеклист:
- Проведи аудит bus factor — випиши всі регулярні задачі, позначай, хто ще може їх виконати
- Напиши runbooks для всього з bus factor = 1 (заклади 30–60 хвилин на кожен)
- Проведи тіньовий тиждень — хтось інший виконує, ти дивишся і правиш доки
- Проведи сесії передачі знань — 30 хвилин на процес, структуровано
- Протестуй реальною відпусткою — спочатку подовжені вихідні, потім тиждень, потім два
Напиши runbook. Проведи тіньовий тиждень. Піди у відпустку.
Повернешся відпочившим, а команда буде сильнішою, ніж до твого від'їзду. Це не 'бути непотрібним'. Це хороша інженерія.
