🔥 Как я чуть не уронил прод из-за cronjob

Обычное утро. Кофе, стендап, лёгкий PR в репу. И тут в монитор как шарахнет — прод API стал отвечать 5xx. Паника, алерты, PagerDuty в слезах.

📌 Что случилось?
Каждый день в 04:00 по UTC запускался innocently выглядящий cronjob в Kubernetes. Он гонял тяжелую агрегацию по БД и триггерил пересчёт данных в Redis. Всё было нормально… пока нагрузка на базу не выросла, а кластер не стал экономить CPU.

Результат:

* Cronjob выжрал CPU ноды.
* Redis улетел в swap.
* Лимиты на pod’ах не были прописаны.
* Horizontal Pod Autoscaler на проде не догнал ситуацию.
* Пользователи увидели 503.

💡 Выводы, которые я сделал и которые сэкономят вам время и нервы:

1️⃣ Cronjob != безобидный скрипт. Он может быть убийцей.
2️⃣ У cronjob должны быть:

* resource limits/requests
* successfulJobsHistoryLimit
* failedJobsHistoryLimit
* ttlSecondsAfterFinished
3️⃣ Разделяй traffic и batch workloads. Лучше – на уровне неймспейсов/taints.
4️⃣ Логируй отдельно вывод cronjob, а не в общие логи.
5️⃣ Придумай throttling для тяжелых задач. И используй nice / ionice если запускаешь скрипты.

🛡️ А лучше всего — не доверяй cronjob, пока не докажет, что он не пёс-камикадзе.

Подпишись 👉@devopslib