Як перевірити логи після деплою і не пропустити проблему

Як перевірити логи після деплою і не пропустити проблему

Перші хвилини після деплою часто виглядають дивно. У логах більше подій, сервіс перезапускається, кеш прогрівається, окремі job-и повторюються, а monitoring ще не встиг показати повну картину. Для початківця це найскладніший момент: незрозуміло, чи перед тобою нормальний післярелізний шум, чи перший сигнал проблеми.

Уяви просту ситуацію. Ти викотив невелику зміну, smoke test пройшов, головна сторінка відкривається. Через кілька хвилин у логах з’являються timeout-и, а в чаті хтось пише, що відповідь стала повільнішою. Один timeout ще не означає аварію. Але якщо вони почалися саме після релізу, ростуть серіями й збігаються зі скаргами, це вже не шум.

Почни не з помилки, а з часу

Перший орієнтир - точний час деплою. Без нього логи легко обманюють: стара помилка може виглядати новою, а випадковий warning - наслідком релізу.

Запиши час релізу з часовим поясом і дивись три короткі відрізки: що було за 10-15 хвилин до деплою, що сталося в перші хвилини після нього, і що повторюється через 10-20 хвилин. Це допомагає відділити одноразові повідомлення старту від стабільної проблеми. Один запис про перезапуск сервісу після деплою очікуваний. Повторний перезапуск кожні дві хвилини - вже сигнал.

Що зазвичай є нормальним шумом

Не кожен warning після релізу означає, що треба відкотитися. Після деплою можуть бути нормальними повідомлення про старт процесу або контейнера, прогрів кешу, короткий стрибок запитів, один retry фонового завдання або відомий warning, який був і до релізу.

Ключове питання не “чи є в логах неприємний рядок”, а “чи змінилася поведінка після релізу”. Якщо warning існував раніше з тією самою частотою, він може бути технічним боргом, але не обов’язково інцидентом цього деплою.

Що перевірити першим

Після швидкої прив’язки до часу йди від найризиковіших сигналів до менш важливих.

1. Нові помилки. Шукай error-и, яких не було до деплою, особливо в коді, який змінювався.
2. Обсяг подій. Один error може бути випадковим, але серія однакових error-ів після релізу важливіша.
3. Timeout-и і latency. Повільна відповідь часто шкодить користувачу раніше, ніж сервіс повністю падає.
4. 5xx і failed jobs. Вони показують, що проблема вже впливає на запити або фонову роботу.
5. Повторні retry. Retry корисний як захист, але масові retry можуть швидко створити додаткове навантаження.

Не дивись лише на найстрашніший рядок. Дивись на картину: коли почалося, чи повторюється, чи пов’язано з конкретним endpoint-ом, job-ом або користувацькою дією.

Як використати AI без сліпої довіри

AI добре допомагає структурувати перевірку, коли ти даєш йому контекст: час деплою, що змінилося, очікувану поведінку й фрагмент логів. У цій статті є готовий запит у метаданих. Його варто використовувати як чеклист для аналізу, а не як автоматичне рішення.

Важливо не просити “подивись, чи все ок”. Таке питання занадто широке. Краще попросити розділити сигнали на очікувані, ризикові й ті, що треба перевірити наступними. Тоді відповідь допоможе не пропустити обсяг помилок, latency, нові warning-и й rollback triggers.

Після відповіді AI все одно перевір числа руками в monitoring або лог-системі. Якщо модель каже, що timeout-и виглядають ризиково, подивись графік latency і реальну кількість запитів. Якщо вона помітила нову помилку, перевір, чи справді вона з’явилася після релізу.

Типові помилки під час перевірки

Найчастіша помилка - реагувати на перший яскравий error і не дивитися на частоту. Друга - ігнорувати повільність, бо “сайт же відкривається”. Третя - порівнювати логи без прив’язки до часу деплою.

Є ще одна пастка: чекати ідеальної впевненості. Після релізу її часто немає. Тому краще заздалегідь домовитися про rollback triggers. Наприклад: стабільний ріст 5xx, timeout-и на ключовому endpoint-і, failed jobs, які блокують оплату або реєстрацію, чи скарги користувачів разом із ростом latency.

Що робити далі

Якщо все виглядає стабільно, залиш коротку нотатку: коли перевірив, які сигнали дивився, що було нормальним, що залишив під наглядом. Це допоможе наступній людині не починати з нуля.

Якщо сигнали погіршуються, не ховайся в логах надто довго. Підтверди проблему другим джерелом, повідом команду, зафіксуй rollback triggers і готуй відкат або швидке виправлення. Завдання після деплою не в тому, щоб прочитати всі логи. Завдання - швидко зрозуміти, чи користувачам стало гірше.