3:17 ночі. Телефон вібрує. Uptime-монітор — сервіс, який пінгує твій сайт кожні кілька хвилин і алертить, коли той перестає відповідати — каже: твій додаток мертвий. Ні команди. Ні чергування. Ні SRE (site reliability engineer, людина, чия вся робота — тримати сервіси живими). Тільки ти, ноутбук і адреналін.
Це не гіпотетично. 1 березня AWS зазнав каскадного збою, який почався в регіоні ОАЕ і перекинувся на US-EAST-1, поклавши 38 сервісів і залишивши соло-фаундерів наодинці з дашбордами помилок без нікого, кому можна зателефонувати. Потім 27 березня Cloudflare Pages зламав управління кастомними доменами на кілька годин — фаундери, які задеплоїли маркетингові сайти через Pages, спостерігали, як їхні домени зникають з інтернету посеред робочого дня.
Я через це проходив. Більше разів, ніж капібарі варто визнавати. Перші кілька інцидентів я панікував і робив гірше. Зараз у мене є плейбук. Він прибирає паніку з рівняння і замінює її кроками. Ось він повністю. 📋
Крок 0: Нічого не чіпай
Контрінтуїтивно. Додаток лежить. Кожна секунда коштує грошей, репутації, або і того, й іншого. Інстинкт кричить: лагодь зараз.
Але найнебезпечніше, що можна зробити під час інциденту — діяти, не розуміючи, що зламалось.
Я бачив, як соло-фаундери заходять по SSH — з'єднуються з сервером через захищений термінал — на прод о 3 ночі, запускають команду по пам'яті і кладуть базу разом з додатком. Одна проблема стає двома. Оригінальний фікс зайняв би 20 хвилин. Відновлення бази зайняло 6 годин.
Правило нуль: перш ніж торкатися будь-чого, витрать 2 хвилини на розуміння ситуації. Не 20 хвилин. Дві. Прочитай помилку. Перевір логи. Сформуй гіпотезу. Тоді дій.
Крок 1: Тріаж — 2 хвилини
Задай три питання:
Сервіс повністю лежить чи частково деградований? Зроби запит на health endpoint — спеціальний URL, який повідомляє, чи працюють ключові системи додатку, як вбудована перевірка пульсу. Якщо додаток вантажиться, але API-виклики (запити від фронтенду до бекенду) падають — це часткове. Якщо не вантажиться нічого — це повне. Від цього залежить терміновість.
Чи зачеплені зараз користувачі? Перевір аналітику. Якщо 3 ночі у твоєму часовому поясі і користувачі в тому ж поясі — може, п'ять людей помітили. Якщо користувачі глобальні — сотні вже дивляться на сторінку помилки.
Коли це почалось? Перевір дашборд моніторингу. Якщо зламалось 5 хвилин тому — ймовірно, пов'язано з останньою зміною. Якщо сервіс кульгав 3 години і алерт прийшов тільки зараз — у моніторингу є прогалина, яку треба закрити завтра.
Запиши відповіді. Блокнот, повідомлення собі, текстовий файл. Це стає твоїм інцидент-логом — єдиним документом, що відстежує все про цей аутейдж. Вранці подякуєш собі.
Крок 2: Комунікація — 1 хвилина
Навіть якщо ніхто не спить, опублікуй статус. Сторінка статусу, соцмережі, Discord — де б користувачі не перевіряли. Одне речення:
'Ми знаємо про проблему з [сервісом]. Розбираємось. Оновимо протягом 30 хвилин.'
Тиша лякає більше, ніж відома аварія. Користувачі, які бачать 'розбираємось' — чекають терпляче. Користувачі, які не бачать нічого — уявляють найгірше і починають писати про це. Одна хвилина комунікації купує 30 хвилин тихого дослідження. ⚙️
Крок 3: Перевір очевидне — 5 хвилин
80% інцидентів у невеликих компаніях зводяться до однієї з п'яти причин:
1. Диск заповнений. Запусти df -h (показує місце на диску у зрозумілому форматі). Якщо будь-яка файлова система показує 100% — це воно. Швидкий фікс: знайди і видали роздуті лог-файли. du -sh /var/log/* покаже винуватців.
2. Пам'ять закінчилась. Запусти free -h (показує використання RAM). Якщо вільної пам'яті майже нуль — щось її пожирає. ps aux --sort=-%mem | head -10 покаже найбільших споживачів — цифровий еквівалент пошуку того, хто залишив усе світло ввімкненим. Вбий роздутий процес, перезапусти сервіс.
3. Процес впав. Запусти systemctl status your-app — systemctl це менеджер сервісів Linux, інструмент, який запускає, зупиняє і моніторить додатки. Якщо написано "inactive (dead)" або "failed" — перезапусти: systemctl restart your-app. Потім перевір, чому впало: journalctl -u your-app --since "1 hour ago" (journalctl читає системний щоденник подій).
4. SSL-сертифікат протух. SSL (Secure Sockets Layer) — це замочок у браузері, що означає зашифроване з'єднання. Сертифікати мають термін дії. Сертифікати Let's Encrypt живуть 90 днів. Якщо забув про автоподовження — ось тобі проблема на 3 ночі. Фікс: certbot renew && systemctl reload nginx. Налаштуй автоподовження Certbot цими вихідними, щоб це більше не повторилось.
5. DNS-проблема. DNS (Domain Name System) — це телефонна книга інтернету, яка перетворює "yoursite.com" на адресу сервера, яку комп'ютери можуть знайти. Запусти dig yoursite.com для перевірки. Якщо не резолвиться — можливо, у DNS-провайдера проблеми. Або домен протух. Так, домени протухають. Я бачив таке навіть у стартапів з інвестиціями.
Якщо жодна з п'яти причин не підходить — ти в тих 20%, де треба реально дебажити. Переходь до кроку 4.
Крок 4: Аудит нещодавніх змін — 5 хвилин
Щось змінилося. Сервіси не ламаються спонтанно — як водопровід, вони відмовляють, бо щось зрушило. Запитай:
- Я щось деплоїв нещодавно? Деплой — це пуш нового коду на живий сервер. Перевір
git log --since="24 hours ago", щоб побачити нещодавні зміни. - Я міняв конфігурацію? Перевір часові мітки модифікації конфіг-файлів.
- Оновилась залежність? Залежність — це чужий код, від якого залежить твій додаток: бібліотека, фреймворк. Перевір lock-файл пакетів на нещодавні зміни.
- У хостинг-провайдера щось сталось? Перевір їхню сторінку статусу.
Найчастіша відповідь: ти щось задеплоїв. Фікс: відкатись — повернись до попередньої робочої версії. Не дебаж. Відкатись. Підніми сервіс, дебажити будеш завтра.
# Якщо тегуєш релізи (мітки версій типу v1.2.3):
git checkout v1.2.3
bash deploy.sh
# Якщо ще не тегуєш (почни з сьогодні):
git revert HEAD
bash deploy.sh
Відкат відчувається як здача позицій. Це не так. Це найпрофесійніша реакція: пріоритет аптайму над его. Полагодиш код завтра з кавою і денним світлом. 🍵
Крок 5: Правило 30 хвилин
Якщо за 30 хвилин не знайшов кореневу причину — справжню причину поломки, а не просто симптом — ескалюй. 'Але я соло-фаундер. Ескалювати кому?'
- Підтримка хостинг-провайдера. Якщо платиш за managed-хостинг — використовуй його. Це буквально те, за що ти платиш.
- Підрядник на ретейнері. Навіть $200/міс за 'можу написати тобі о 3 ночі двічі на рік' — того варте.
- Спільнота. Релевантний Discord-сервер, Slack-група або форум. Запости помилку, логи, що вже перевірив. Хороші спільноти відповідають швидко.
- AI-асистент. Вставте помилку в Claude або ChatGPT: 'Ось лог помилок мого сервера. Сервіс впав о 3:17. Ось що я вже перевірив: [список]. Що ще варто подивитись?' Він не зайде по SSH на сервер, але може підказати діагностичні кроки, які ти пропустив.
Правило 30 хвилин існує, бо після півгодини соло-дебагу о 3 ночі здатність міркувати деградує. Починаєш пробувати випадкові речі. Випадкові зміни на живому продакшн-сервері о 3 ночі — ось так дані зникають назавжди.
Крок 6: Ранок після інциденту
Ти пережив кризу. Лягай спати. Серйозно. Постмортем — структурний аналіз того, що пішло не так і як цього уникнути — буде завтра. З кавою. З чистою головою. 🛁
Чеклист на завтра:
- Що зламалось? Одне речення.
- Яка коренева причина? Не 'сервер впав', а 'Неправильно налаштована ротація логів заповнила диск на 100%'.
- Який був вплив? Тривалість, кількість зачеплених користувачів, втрати в доході, якщо можна виміряти.
- Що завадило швидшому виявленню? Закрий цю прогалину в моніторингу.
- Що завадило швидшому відновленню? Додай цей крок до плейбуку.
- Що запобіжить повторенню? Впровадь цього тижня. Не 'колись'. Цього тижня.
Запиши це у файл. incidents/2026-03-27.md. Ти будуєш інституційну пам'ять — пошукову історію того, що ламалось раніше і що це лагодило. Коли наступний інцидент вдарить, минулий ти вже залишив нотатки.
Підготовка до інциденту
Найкращий інцидент-респонс стається до інциденту. Ось що варто налаштувати цими вихідними:
- Uptime-моніторинг. UptimeRobot має безкоштовний тариф: 50 моніторів, інтервал 5 хвилин. Пінгує сайт і шле SMS, коли він падає. Налаштуй раз — забудь. ✅
- Ротація логів. Налаштуй
logrotate— утиліту Linux, яка автоматично стискає і видаляє старі лог-файли — для кожного логу, який генерує додаток. Диски не заповнюються, коли логами керують. - Автоподовження SSL. Certbot з cron job (запланована задача, яка запускається автоматично за таймером). Більше ніколи не подовжуй сертифікат вручну.
- Автоматичні бекапи. Дамп бази на S3 (хмарне сховище Amazon) або будь-який об'єктний сторідж, кожні 6 годин. Протестуй відновлення хоча б раз. Бекап, який ти жодного разу не відновлював — це надія, а не бекап.
- Скрипт відкату. Одна команда, щоб повернутись до попередньої версії. Нуль думання о 3 ночі.
Загальний час: приблизно 3 години у спокійну суботу. Ці 3 години захистять бізнес наступного разу, коли щось зламається у темряві.
Найспокійніші фаундери, яких я знаю, спокійні не тому, що в них нічого не ламається. Ламається у всіх. Вони спокійні, бо мають плейбук. Вони вже через це проходили. Вони знають, що робити далі. І знають — глибоко, з досвіду — що паніка жодного разу, ні разу, не полагодила сервер. 🫶
incident-response, devops, automation, solo-founder, infrastructure
