• Оглавление
• Зачем это бизнесу
• Откуда берутся простои и каскадные отказы
• Базовые механики защиты
  • Таймауты
  • Повторы с экспонентой и джиттером
  • Circuit Breaker (прерыватель цепи)
  • Bulkhead (изоляция по «переборкам»)
  • Деградация и «тёплый» кэш
• Пошаговый план внедрения
• Пример кода на Go: таймауты + ретраи + Circuit Breaker + Bulkhead + fallback
• Наблюдаемость и алерты
• Тестирование отказов и учение под нагрузкой
• Частые ошибки
• Чек‑лист внедрения
• Итоги

Зачем это бизнесу

Любая интеграция — очереди, платёжные шлюзы, KYC, адреса доставки — иногда тормозит или ложится. Без защитных механизмов падает уже ваш продукт: растут задержки, размножаются ретраи, переполняются пулы соединений, истощаются ресурсы. Это выливается в:

• прямые потери выручки (недооформленные заказы, отмены, брошенные корзины);
• рост инфраструктурных расходов (накрученные автоскейлом инстансы ради «погасить пожар»);
• просадки SLA и репутационные риски.

Правильные таймауты, повторы с джиттером, Circuit Breaker и изоляция (Bulkhead) позволяют локализовать проблему, не давая ей тянуть весь продукт ко дну, и поддерживать работоспособность критичных сценариев. Это дешевле, чем «лить железо», и надёжнее, чем надеяться на удачу.

Откуда берутся простои и каскадные отказы

Корневая причина — несогласованность ожиданий. Ваш сервис ждёт ответ 10 секунд, внешний партнёр в пике отвечает 30–60 секунд. За это время у вас накапливаются висящие запросы, забиваются пулы, растёт очередь, а затем «всё упало». Добавьте жёсткие ретраи без паузы — и вы сами устраиваете DDoS партнёру и себе.

Каскадный отказ усиливают:

• бесконечные ожидания по умолчанию (нет таймаута — нет контроля);
• общие ресурсы для разных интеграций (один пул на всех);
• повторы без джиттера и бэк‑оффа;
• попытки «продавить» зависший сервис вместо деградации и быстрого отказа;
• отсутствие наблюдаемости: не видно, что именно упало и где «узкое место».

Базовые механики защиты

Таймауты

Таймаут — предельное время ожидания. Он должен быть короче вашего SLO на конечный пользовательский запрос. Если пользовательский SLO — 1 секунда «до первой полезной реакции», подчинённые вызовы не должны съедать весь бюджет.

Практика:

• ставьте таймаут на каждый сетевой вызов — клиентский, серверный, в пулы, в драйвер БД;
• разделяйте: таймаут на установление соединения, на получение первого байта, на весь ответ;
• выбирайте по измерениям: p95 задержки + небольшой запас, а не «на глаз».

Повторы с экспонентой и джиттером

Ретраи — полезны при временных сбоях (сети, пик нагрузки). Но повторять нужно с экспоненциальной задержкой и случайным разбросом (джиттер), чтобы не «бить в такт» и не усугублять пик. Максимум 2–3 попытки для онлайновых запросов.

Circuit Breaker (прерыватель цепи)

CB следит за ошибками и задержками вызовов к зависимости. Когда их доля превышает порог, «прерывает цепь»: дальнейшие звонки сходу отвергаются (fast‑fail) на время «охлаждения». Это даёт зависимой системе отдохнуть и экономит ваши ресурсы. Потом — «полуоткрытое» состояние: пробные вызовы проверяют, вернулась ли здоровая работа.

Ключевые настройки: окно наблюдения, порог ошибок, минимальное число запросов, длительность «охлаждения».

Bulkhead (изоляция по «переборкам»)

Идея из кораблестроения: разбить ресурсы на отсеки. У каждой интеграции — свой пул соединений, свой семафор или очередь. Если один партнёр «течёт», вода не затопит весь корабль.

Реализация: отдельные HTTP‑пулы, отдельные очереди задач, отдельные семафоры на поток для интеграций, лимиты параллелизма на конкретные операции.

Деградация и «тёплый» кэш

Если зависимость недоступна, лучше отдать старые данные/уменьшенный функционал, чем «500». Примеры: показать закэшированные тарифы доставки, задержать бонусы до фоновой синхронизации, использовать статический список ПВЗ. Важно пометить пользователю, что данные могут обновиться позже.

Пошаговый план внедрения

1. Опишите внешние зависимости: платёж, антифрод, геокодер, KYC, SMS, карты. Для каждой — критичность и SLO.
2. Измерьте фактические p50/p95/p99 задержки и долю ошибок в нормальное время и в пике.
3. Выставьте таймауты на клиент: connect, TLS, request/response. Убедитесь, что они меньше пользовательского SLO.
4. Включите ретраи с экспонентой и джиттером. Ограничьте максимум попыток.
5. Добавьте Circuit Breaker с порогами на уровне зависимости. Определите «окно охлаждения» и минимальную выборку.
6. Разделите пулы и лимиты параллелизма для разных интеграций (Bulkhead).
7. Пропишите деградацию: что показываем пользователю, что откладываем во «внутреннюю очередь».
8. Наблюдаемость: метрики таймаутов, ретраев, состояния CB, длины очередей, процент деградаций.
9. Тесты отказов: инъекция задержек, ошибки 5xx/429, полная недоступность; нагрузочные прогоны.
10. Регулярные пересмотры порогов по новым измерениям.

Пример кода на Go: таймауты + ретраи + Circuit Breaker + Bulkhead + fallback

Ниже — рабочий пример. Он показывает:

• клиент с таймаутами;
• повторы с экспонентой и джиттером;
• Circuit Breaker на github.com/sony/gobreaker;
• Bulkhead через семафор (ограничение параллелизма);
• fallback из «тёплого» кэша, если цепь разомкнута или попытки исчерпаны.

package main

import (
	"context"
	"errors"
	"fmt"
	"io"
	"log"
	"math/rand"
	"net/http"
	"sync"
	"time"

	"github.com/sony/gobreaker"
)

// Настраиваем общий HTTP‑клиент с таймаутами на уровне транспорта
var httpClient = &http.Client{
	Transport: &http.Transport{
		MaxIdleConns:        100,
		MaxIdleConnsPerHost: 10,
		IdleConnTimeout:     30 * time.Second,
		TLSHandshakeTimeout: 5 * time.Second,
		ExpectContinueTimeout: 1 * time.Second,
	},
	Timeout: 0, // общий Timeout отключаем; используем context с дедлайном на запрос
}

// Bulkhead: ограничим параллелизм вызовов к внешней системе до N
var bulkhead = make(chan struct{}, 20) // не более 20 одновременных вызовов

// Простой тёплый кэш последнего успешного ответа
type cache struct {
	mu    sync.RWMutex
	value string
	ts    time.Time
}

func (c *cache) Get(ttl time.Duration) (string, bool) {
	c.mu.RLock()
	defer c.mu.RUnlock()
	if c.value == "" {
		return "", false
	}
	if time.Since(c.ts) > ttl {
		return "", false
	}
	return c.value, true
}

func (c *cache) Set(v string) {
	c.mu.Lock()
	c.value = v
	c.ts = time.Now()
	c.mu.Unlock()
}

var warmCache cache

// Настройки ретраев
const (
	maxAttempts     = 3
	baseBackoff     = 100 * time.Millisecond
	maxBackoff      = 2 * time.Second
	cacheTTL        = 30 * time.Second
	callTimeout     = 800 * time.Millisecond // дедлайн на один внешний вызов
	cooldown        = 5 * time.Second        // время «охлаждения» для CB
	minRequestsCB   = 20                     // минимальное число запросов для принятия решения
	errorRatioThresh = 0.5                    // порог доли ошибок
)

// Circuit Breaker с параметрами
var cb *gobreaker.CircuitBreaker

func init() {
	rand.Seed(time.Now().UnixNano())
	st := gobreaker.Settings{
		Name:        "external-api",
		MaxRequests: 5, // в полуоткрытом состоянии допустим 5 пробных вызовов
		Interval:    30 * time.Second, // окно сбора статистики
		Timeout:     cooldown,         // сколько держать разомкнутым
		ReadyToTrip: func(counts gobreaker.Counts) bool {
			requests := float64(counts.Requests)
			if requests < float64(minRequestsCB) {
				return false
			}
			errors := float64(counts.TotalFailures)
			errorRatio := errors / requests
			return errorRatio >= errorRatioThresh
		},
	}
	cb = gobreaker.NewCircuitBreaker(st)
}

func jitter(d time.Duration) time.Duration {
	// равномерный джиттер +/- 50%
	jd := time.Duration(rand.Int63n(int64(d))) - d/2
	res := d + jd
	if res < 0 {
		return 0
	}
	if res > maxBackoff {
		return maxBackoff
	}
	return res
}

func retryableStatus(code int) bool {
	// Повторяем при 5xx и 429
	if code >= 500 || code == 429 {
		return true
	}
	return false
}

func doExternalCall(ctx context.Context, url string) (string, error) {
	req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
	if err != nil {
		return "", err
	}
	resp, err := httpClient.Do(req)
	if err != nil {
		return "", err
	}
	defer resp.Body.Close()
	if retryableStatus(resp.StatusCode) {
		return "", fmt.Errorf("remote status %d", resp.StatusCode)
	}
	b, err := io.ReadAll(resp.Body)
	if err != nil {
		return "", err
	}
	return string(b), nil
}

// Обёртка с ретраями, таймаутом, bulkhead и fallback из кэша
func callWithResilience(parent context.Context, url string) (string, error) {
	// Bulkhead — берём слот
	select {
	case bulkhead <- struct{}{}:
		defer func() { <-bulkhead }()
	case <-parent.Done():
		return "", parent.Err()
	}

	operation := func() (any, error) {
		var lastErr error
		for attempt := 1; attempt <= maxAttempts; attempt++ {
			// Таймаут на попытку
			ctx, cancel := context.WithTimeout(parent, callTimeout)
			res, err := doExternalCall(ctx, url)
			cancel()
			if err == nil {
				// Успех — обновляем тёплый кэш
				warmCache.Set(res)
				return res, nil
			}
			lastErr = err
			// Если контекст закрыт — дальше смысла нет
			if errors.Is(err, context.DeadlineExceeded) || errors.Is(err, context.Canceled) {
				// Немедленный выход — таймаут попытки
				break
			}
			// Бэк‑офф с джиттером перед повтором, кроме последней попытки
			if attempt < maxAttempts {
				backoff := jitter(baseBackoff << (attempt - 1))
				timer := time.NewTimer(backoff)
				select {
				case <-timer.C:
				case <-parent.Done():
					if !timer.Stop() {
						<-timer.C
					}
					return nil, parent.Err()
				}
			}
		}
		return nil, lastErr
	}

	// Circuit Breaker
	res, err := cb.Execute(operation)
	if err != nil {
		// Если цепь разомкнута или попытки не удались — пробуем тёплый кэш
		if v, ok := warmCache.Get(cacheTTL); ok {
			return v, nil
		}
		return "", err
	}
	return res.(string), nil
}

func main() {
	url := "https://httpbin.org/delay/1" // внешняя зависимость; можно заменить на ваш URL
	ctx := context.Background()

	// Демонстрация периодических вызовов
	ticker := time.NewTicker(2 * time.Second)
	defer ticker.Stop()
	for i := 0; i < 10; i++ {
		<-ticker.C
		start := time.Now()
		res, err := callWithResilience(ctx, url)
		lat := time.Since(start)
		if err != nil {
			log.Printf("call failed: %v (latency=%s, cb_state=%s)", err, lat, cb.State().String())
			continue
		}
		log.Printf("ok: %d bytes (latency=%s, cb_state=%s)", len(res), lat, cb.State().String())
	}

	log.Println("done")
}

Что важно в примере:

• нет «общего таймаута на клиент» — дедлайн делаем на каждую попытку через контекст;
• ретраи ограничены и с джиттером;
• Bulkhead не даст этой интеграции съесть весь пул потоков;
• CB быстро переводит зависимость в fast‑fail, а пользователю можно отдавать «тёплый» кэш;
• метрики и состояние CB можно экспортировать в привычные инструменты (добавьте счётчики вокруг вызовов).

Наблюдаемость и алерты

Какие метрики нужны:

• доля таймаутов и ошибок по каждой зависимости;
• распределение задержек (p50/p95/p99) до зависимости;
• состояние Circuit Breaker (open/half‑open/closed), число переходов;
• длина очередей/пулов, число отклонённых запросов Bulkhead;
• доля ответов из fallback/кэша.

Алерты — не по одной ошибке, а по устойчивым отклонениям: «>20% таймаутов 5 минут», «CB открыт > 2 минут», «p95 > X при QPS > Y». Так вы не будете «стрелять по воробьям».

Тестирование отказов и учение под нагрузкой

• Инъекция задержек и ошибок: Toxiproxy, тестовые эндпоинты, фичи облачных балансировщиков;
• Нагрузочные сценарии с эмуляцией пика и «подсадкой» зависимости;
• Комбинированные сценарии: медленный партнёр + всплеск трафика + деградация кэша;
• Отладка пользовательского опыта: тексты сообщений, повторная синхронизация, уведомления.

Важно: договоритесь с партнёрами о лимитах RPS и окнах повторов, чтобы не усугублять пиковые ситуации.

Частые ошибки

• Таймауты «по умолчанию» и «бесконечные чтения»;
• Ретраи из фронта, бэка и очередей одновременно — получается лавина;
• Общие пулы/соединения для всех интеграций;
• Слишком длинные таймауты в онлайне — пользователи ждут, SLA тонет;
• CB без «полуоткрытого» состояния или с порогами «с потолка»;
• Отсутствие деградации: или «всё работает», или «всё упало».

Чек‑лист внедрения

• Для каждой зависимости есть SLO и измерения p95/p99 задержек;
• На каждом сетевом вызове стоят таймауты (connect, TLS, response);
• Ретраи с экспонентой и джиттером, максимум попыток ограничен;
• Circuit Breaker с понятными порогами и охлаждением;
• Изоляция ресурсов (Bulkhead): отдельные пулы/семафоры;
• Прописана деградация и fallback‑данные;
• Метрики и алерты по отказам и состояниям CB;
• Прогоны с инъекцией ошибок и задержек перед релизом;
• Регулярный пересмотр порогов по данным наблюдаемости.

Итоги

Интеграции не обязаны быть идеальными, чтобы вы держали SLA. Достаточно дисциплины на своей стороне: таймауты, управляемые ретраи, Circuit Breaker, изоляция и предсказуемая деградация. Эти механики дешевле масштабирования «на авось», они сокращают простои, удерживают выручку и снимают стресс с команды поддержки. Начните с самых критичных зависимостей, включите метрики — и вы увидите эффект уже в ближайший релиз.