Деплой и инфра
Уровни балансировки: деплой без потерянных запросов
Прочитать, что connection draining предотвращает сбросы, — не то же, что увидеть, как нагрузочный тест держит ноль ошибок, пока ты выводишь бэкенд из-под него. Подними настоящий L7-балансировщик, докажи, что маршрутизация по пути работает там, где L4 не может, затем сделай rolling deploy, который не теряет ни одного запроса в полёте — и докажи это числами.
Преврати модель юнита в работающий стенд: маршрутизируй по пути на L7, выбери алгоритм, переживающий неравномерную нагрузку, настрой health checks, быстро выкидывающие мёртвый бэкенд, и добавь connection draining, чтобы rolling deploy завершился с нулём потерянных запросов под устойчивым трафиком.
Поставь перед двумя разными бэкендами L7-балансировщик (nginx, Envoy, HAProxy или облачный ALB), докажи маршрутизацию по пути, затем под устойчивой нагрузкой удали и замени бэкенд — и покажи, что деплой завершился с нулём 5xx и нулём сбросов соединений.
- Транскрипт curl, доказывающий, что /api/* и / попадают на разные бэкенды через один L7-балансировщик, плюс одна строка о том, почему L4-балансировщик это не воспроизведёт.
- Измерение health check: конфиг зондов плюс наблюдаемое время детекции-и-вывода и число неудавшихся запросов при убийстве бэкенда под трафиком.
- Таблица round-robin против least-connections под нагрузкой с перекосом латентности: p99 и распределение по бэкендам для каждого, с фразой о том, почему здесь выигрывает least-connections.
- Два нагрузочных прогона рядом — rolling deploy БЕЗ draining (ненулевые сбросы/5xx) и С draining (ноль сбросов/5xx) — под идентичной устойчивой нагрузкой, измеренные, а не оценённые.
- Короткий разбор: какой уровень выбрал и почему, какое окно draining взял и как вывел его из самого медленного запроса, и последовательность деплоя (дерегистрация, drain, ожидание, терминация, подтверждение).
- Добавь header-канарейку: маршрутизируй запросы с X-Canary: true на третий бэкенд, пока остальные остаются на стабильном пуле, и покажи разделение в access-логах.
- Введи sticky sessions (cookie или IP-hash), воспроизведи проблемы неравномерной нагрузки и грязного draining, которые они создают, затем вынеси состояние сессии (Redis или JWT), убери stickiness и покажи, что распределение и draining оба улучшились.
- Сравни TLS termination на краю против TLS passthrough на бэкенды: измерь стоимость CPU на бэкенд в каждом режиме и объясни, когда end-to-end шифрование стоит потерянной маршрутизации по пути.
- Напиши on-call runbook на одну страницу: как читать четыре сигнала (распределение по бэкендам, статус health check, состояние drain, доля 5xx), безопасную последовательность деплоя и первые три вещи для проверки, когда деплой начинает терять запросы.
Это стенд за каждым безопасным production-роллаутом: L7-балансировщик, маршрутизирующий по тому, что видит, алгоритм под твой профиль нагрузки, health checks, выкидывающие мёртвые бэкенды не медленнее своего интервала, и connection draining, дающий запросам в полёте завершиться перед выводом бэкенда. Два нагрузочных прогона — сбросы без draining, ноль ошибок с ним — это вся суть юнита, сделанная измеримой. Собери стенд один раз на игрушке, и zero-downtime деплой станет чек-листом, которому доверяешь, а не надеждой.