Какие были проблемы с доступностью системы на проекте

Проблемы с доступностью системы

Контекст проекта

На протяжении своей карьеры встречал различные проблемы с доступностью (availability) систем. Поделюсь наиболее значимыми примерами из практики.

Основные проблемы

1. Single Point of Failure

Одна из критических проблем — отсутствие redundancy в архитектуре. В одном из проектов у нас был:

• Единственный инстанс базы данных (без репликации)
• Один load balancer
• Отсутствие failover механизма

Результат: при перезагрузке БД система была полностью недоступна на 15+ минут.

Решение:

// Реализовали circuit breaker pattern
public class DatabaseCircuitBreaker {
    private volatile boolean isOpen = false;
    private long lastFailureTime;
    private int failureCount = 0;
    private static final int FAILURE_THRESHOLD = 3;
    private static final long TIMEOUT_MS = 60000;

    public <T> T execute(Supplier<T> operation) throws Exception {
        if (isOpen && System.currentTimeMillis() - lastFailureTime < TIMEOUT_MS) {
            throw new CircuitBreakerOpenException();
        }
        
        try {
            T result = operation.get();
            failureCount = 0;
            isOpen = false;
            return result;
        } catch (Exception e) {
            failureCount++;
            lastFailureTime = System.currentTimeMillis();
            if (failureCount >= FAILURE_THRESHOLD) {
                isOpen = true;
            }
            throw e;
        }
    }
}

2. Медленные SQL запросы

Отсутствие indexing и оптимизации привело к деградации производительности:

• Запросы выполнялись 10+ секунд
• Connection pool исчерпывался
• Система становилась недоступной для новых пользователей

Решение:

• Добавили индексы на часто используемые колонки
• Реализовали connection pooling (HikariCP)
• Добавили query caching

@Configuration
public class DataSourceConfig {
    @Bean
    public HikariDataSource dataSource() {
        HikariConfig config = new HikariConfig();
        config.setMaximumPoolSize(20);
        config.setMinimumIdle(5);
        config.setConnectionTimeout(30000);
        config.setIdleTimeout(600000);
        config.setMaxLifetime(1800000);
        return new HikariDataSource(config);
    }
}

3. Memory Leaks и OutOfMemoryError

Логирование и кеширование без должного управления памятью привели к:

• Утечкам памяти в long-lived объектах
• OutOfMemoryError при пиковых нагрузках
• Необходимости в частых перезагрузках

Решение:

public class CacheManager {
    private final Map<String, CacheEntry> cache = 
        new ConcurrentHashMap<>();
    private static final long MAX_CACHE_SIZE = 100 * 1024 * 1024; // 100 MB
    private static final long ENTRY_TTL_MS = 300000; // 5 minutes

    public void put(String key, Object value) {
        if (cache.size() * estimateSize(value) > MAX_CACHE_SIZE) {
            evictOldest();
        }
        cache.put(key, new CacheEntry(value, System.currentTimeMillis()));
    }

    private void evictOldest() {
        cache.entrySet().stream()
            .min(Comparator.comparingLong(e -> e.getValue().timestamp))
            .ifPresent(e -> cache.remove(e.getKey()));
    }
}

4. Отсутствие мониторинга и алертинга

Мы не знали о проблемах, пока их не сообщали пользователи. Решили:

• Добавили health checks endpoints
• Интегрировали Prometheus для метрик
• Настроили Alerting через PagerDuty

@RestController
@RequestMapping("/actuator")
public class HealthCheckController {
    @GetMapping("/health")
    public ResponseEntity<HealthStatus> health() {
        boolean dbOk = checkDatabase();
        boolean cacheOk = checkCache();
        boolean diskOk = checkDiskSpace();
        
        if (dbOk && cacheOk && diskOk) {
            return ResponseEntity.ok(new HealthStatus("UP"));
        }
        return ResponseEntity.status(503)
            .body(new HealthStatus("DOWN"));
    }
}

5. Проблемы с масштабированием

Система не была готова к horizontal scaling:

• Сессии хранились в памяти (sticky sessions)
• Глобальные переменные и static поля
• Отсутствие распределённого кеша (Redis)

Выводы

Лучшие практики для обеспечения доступности:

1. Redundancy — дублирование критических компонентов
2. Monitoring — видимость проблем в real-time
3. Graceful degradation — система продолжает работать в режиме пониженной функциональности
4. Proper testing — нагрузочное и chaos engineering тестирование
5. Dokumentation — процедуры восстановления и failover

Эти проблемы стали ценными уроками в вопросе построения надёжных и доступных систем.