DevOps

🎯 Задача для продвинутых DevOps-инженеров: «Неуловимый таймаут»

🧠 Уровень: Senior DevOps / SRE / Infrastructure Architect
📦 Стек: Kubernetes, Docker, NGINX, Istio, PostgreSQL, Prometheus, Cloudflare

📍 Ситуация:

Продакшен-приложение периодически отдаёт 504 Gateway Timeout на определённые API-запросы. Проблема:
- возникает только при внешнем трафике (через Cloudflare)
- не воспроизводится в staging-окружении
- не зависит от нагрузки — может случиться в 3 часа ночи
- происходит на разных endpoint'ах, но всегда спустя 100 секунд

📈 Метрики:
- В K8s pod'ах таймаутов нет
- NGINX ingress не логирует ошибок
- Istio mesh — без аномалий
- PostgreSQL работает стабильно, без долгих транзакций
- В логах нет ни timeout, ни broken pipe, ни reset by peer

---

🧩 Ваша задача:

1. Найти, где именно происходит таймаут — в сети, прокси, mesh, firewall или app
2. Выяснить, почему именно 100 секунд
3. Подтвердить гипотезу, не разрушая прод
4. Предложить решение без увеличения всех таймаутов подряд
5. Составить диагностический plan на случай повторного возникновения

💡 Подсказка:

- NGINX по умолчанию имеет proxy_read_timeout 60, но это не оно
- Cloudflare автоматически завершает соединения по таймауту 100 секунд
- Если вы используете long-polling или upload, CDN может прерывать соединение до ответа

🛠 Решение (примерный путь):

1. Проверить `curl -v` через Cloudflare и напрямую — сравнить TTL
2. Выставить `proxy_request_buffering off` и `client_body_timeout`
3. Обновить Ingress с `nginx.ingress.kubernetes.io/proxy-read-timeout: "180"`
4. Проверить KeepAlive между Envoy и backend
5. В Cloudflare использовать `chunked encoding` или WebSockets, если запросы >100с

📌 **Вывод:**
Таймаут в 100 секунд — не случайность. Это один из самых частых лимитов на уровне облачных прокси и CDN. DevOps-инженер должен уметь находить такие «невидимые» границы между слоями системы и грамотно обходить их.

💬 Поделись решением с командой — и запиши его в postmortem, чтобы не попасться второй раз.

@devopsitsec

www.tg-me.com/us/DevOps/com.DevOPSitsec/1534

2.9K viewsJun 5 at 10:04

🎯 Задача для продвинутых DevOps-инженеров: «Неуловимый таймаут»

🧠 Уровень: Senior DevOps / SRE / Infrastructure Architect
📦 Стек: Kubernetes, Docker, NGINX, Istio, PostgreSQL, Prometheus, Cloudflare

📍 Ситуация:

Продакшен-приложение периодически отдаёт 504 Gateway Timeout на определённые API-запросы. Проблема:
- возникает только при внешнем трафике (через Cloudflare)
- не воспроизводится в staging-окружении
- не зависит от нагрузки — может случиться в 3 часа ночи
- происходит на разных endpoint'ах, но всегда спустя 100 секунд

📈 Метрики:
- В K8s pod'ах таймаутов нет
- NGINX ingress не логирует ошибок
- Istio mesh — без аномалий
- PostgreSQL работает стабильно, без долгих транзакций
- В логах нет ни timeout, ни broken pipe, ни reset by peer

---

🧩 Ваша задача:

1. Найти, где именно происходит таймаут — в сети, прокси, mesh, firewall или app
2. Выяснить, почему именно 100 секунд
3. Подтвердить гипотезу, не разрушая прод
4. Предложить решение без увеличения всех таймаутов подряд
5. Составить диагностический plan на случай повторного возникновения

💡 Подсказка:

- NGINX по умолчанию имеет proxy_read_timeout 60, но это не оно
- Cloudflare автоматически завершает соединения по таймауту 100 секунд
- Если вы используете long-polling или upload, CDN может прерывать соединение до ответа

🛠 Решение (примерный путь):

1. Проверить `curl -v` через Cloudflare и напрямую — сравнить TTL
2. Выставить `proxy_request_buffering off` и `client_body_timeout`
3. Обновить Ingress с `nginx.ingress.kubernetes.io/proxy-read-timeout: "180"`
4. Проверить KeepAlive между Envoy и backend
5. В Cloudflare использовать `chunked encoding` или WebSockets, если запросы >100с

📌 **Вывод:**
Таймаут в 100 секунд — не случайность. Это один из самых частых лимитов на уровне облачных прокси и CDN. DevOps-инженер должен уметь находить такие «невидимые» границы между слоями системы и грамотно обходить их.

💬 Поделись решением с командой — и запиши его в postmortem, чтобы не попасться второй раз.

@devopsitsec

BY DevOps