Розробники часто стикаються з проблемою перевантаження систем моніторингу через некритичні помилки в CI/CD. У проекті автоматизації контенту, що охоплює Dev.to, Substack та Bluesky, виникли труднощі з налаштуванням Sentry та зайвим навантаженням на Vercel. Помилка Invalid margin value: 360 постійно засмічувала дашборд, а скасовані завдання GitHub Actions створювали хибні сповіщення, що ускладнювало відстеження реальних проблем.
Перші спроби вирішення, такі як вимкнення Sentry або спроби використання неіснуючих функцій умовного виконання, не дали результату. Редагування вихідного коду безпосередньо також виявилося неефективним, оскільки скрипт автоматизації перезаписував файл при кожному запуску. Це вимагало системного підходу до валідації конфігурації, щоб забезпечити стабільність середовища та достовірність даних про помилки в системі спостереження.
Ключовим технічним рішенням стало впровадження спеціального провайдера в NestJS для валідації параметра SENTRY_MARGIN. Тепер значення перевіряється під час запуску програми: якщо воно виходить за межі допустимого діапазону від 0 до 300, система автоматично скидає його до 180. Це повністю усунуло помилку Invalid margin value: 360, яка раніше спричиняла постійні сповіщення в Sentry.
Для боротьби з шумом у CI/CD було змінено логіку виконання завдань у GitHub Actions. Використання умови if для перевірки статусу workflow дозволило пропускати завдання, які були скасовані користувачем. Завдяки цьому Sentry більше не отримує звіти про помилки від перерваних процесів, що значно покращило чистоту логів та дозволило розробникам зосередитися на справжніх збоях у коді.
Оптимізація торкнулася і щотижневого робочого процесу для розсилки новин. Раніше він запускався при кожному push-запиті, що викликало надмірне навантаження на Docker. Перехід на розклад за cron та додавання фільтрації шляхів до файлів дозволили запускати процес лише тоді, коли це дійсно необхідно. Це усунуло проблеми з тайм-аутами Vercel та оптимізувало використання ресурсів.
Нарешті, було впроваджено уніфікований підхід до публікації контенту через єдиний JSON-файл. Скрипт автоматизації генерує payload, який потім споживається окремими діями для кожної платформи. Такий підхід гарантує синхронізацію між каналами та спрощує підтримку коду. Загалом ці зміни дозволили скоротити технічний шум у CI/CD приблизно на 70%, забезпечивши стабільну роботу системи.
🔗 Першоджерело: Читати оригінал