Комментарии (1)
🐱
claude-haiku-4.5PrepBro AI23 мар. 2026 г.(ред.)
Ответ сгенерирован нейросетью и может содержать ошибки
Что такое SLA
SLA (Service Level Agreement — Соглашение об уровне обслуживания) — это контракт между поставщиком услуги и клиентом, который определяет гарантированные параметры качества обслуживания, сроки ответа, доступность и последствия за их нарушение. Для Java разработчика это важно понимать при разработке production систем.
Основные метрики SLA
1. Uptime/Availability (Доступность) — самая важная метрика
// SLA: 99.9% uptime в месяц
// Это означает, что из 30 дней сервис может быть недоступен:
// 30 дней * 24 часа * 60 мин = 43,200 минут
// 0.1% от 43,200 = 43.2 минуты в месяц
// МАКСИМАЛЬНОЕ время downtime: ~43 минуты в месяц
// Таблица: Соотношение процентов и downtime
// 99% = 7.2 часа downtime в месяц (не production)
// 99.5% = 3.6 часа downtime в месяц (плохо)
// 99.9% = 43 минуты downtime в месяц (обычно)
// 99.95% = 21 минута downtime в месяц (хорошо)
// 99.99% = 4.3 минуты downtime в месяц (очень хорошо)
// 99.999% = 26 секунд downtime в месяц (отличный уровень)
2. Response Time (Время ответа)
// SLA: 95-й percentile response time <= 200ms
// Это означает, что 95% запросов должны ответить за 200ms или быстрее
// 5% запросов могут быть медленнее (всё равно в рамках договора)
// Метрики:
// P50 (median): 50% запросов ответят за X ms
// P95: 95% запросов ответят за X ms
// P99: 99% запросов ответят за X ms (критичный случай)
// P99.9: 99.9% запросов ответят за X ms
// Max: максимальное время ответа
3. Error Rate (Уровень ошибок)
// SLA: Error rate <= 0.1%
// Это означает, что из 10,000 запросов максимум 10 может вернуть ошибку
// Примеры:
// - 500 Internal Server Error
// - 503 Service Unavailable
// - Timeout
// - Connection refused
4. Mean Time To Recovery (MTTR)
// SLA: MTTR <= 15 минут
// Если сервис упал, он должен восстановиться за 15 минут
5. Mean Time Between Failures (MTBF)
// SLA: MTBF >= 720 часов
// В среднем, сервис может быть down не чаще чем один раз в 30 дней
Практический пример SLA документа
SERVICE LEVEL AGREEMENT
Дата: 2024-03-23
Поставщик: ACME Corp
Клиент: Your Company
1. ДОСТУПНОСТЬ (UPTIME)
- Гарантированная доступность: 99.95%
- Измеряется в UTC
- Исключаются плановые обслуживания
- Максимум downtime в месяц: 21.6 минут
2. ВРЕМЯ ОТВЕТА (RESPONSE TIME)
- P50: <= 100 ms
- P95: <= 300 ms
- P99: <= 1000 ms
- Максимум: 5000 ms
- Применяется к 95% запросов
3. ЧАСТОТА ОШИБОК (ERROR RATE)
- API endpoints: <= 0.05% ошибок
- Web interface: <= 0.1% ошибок
- Исключаются ошибки клиента (4xx)
4. ПОДДЕРЖКА
- Critical: ответ в течение 15 минут, решение в течение 1 часа
- High: ответ в течение 1 часа, решение в течение 4 часов
- Medium: ответ в течение 4 часов, решение в течение 24 часов
- Low: ответ в течение 8 часов, решение в течение 48 часов
5. ПЛАНОВОЕ ОБСЛУЖИВАНИЕ (MAINTENANCE WINDOWS)
- Максимум 2 часа в неделю
- Обычно вторник-четверг, 2:00-4:00 UTC
- Уведомление за 7 дней
6. КОМПЕНСАЦИЯ ЗА НАРУШЕНИЕ
- 99.0-99.5% uptime: 5% от месячной подписки
- 95.0-99.0% uptime: 10% от месячной подписки
- < 95% uptime: 25% от месячной подписки
Как разработчик работает с SLA
1. Разработка с учётом SLA
// Spring Boot приложение с мониторингом SLA
@Service
public class OrderService {
private final MeterRegistry meterRegistry;
private final OrderRepository repository;
@Autowired
public OrderService(MeterRegistry meterRegistry, OrderRepository repository) {
this.meterRegistry = meterRegistry;
this.repository = repository;
}
public Order getOrder(Long id) {
// Отслеживаем время ответа для SLA
Timer.Sample sample = Timer.start(meterRegistry);
try {
// Основная логика
Order order = repository.findById(id).orElse(null);
// Фиксируем метрику
sample.stop(Timer.builder("orders.get.time")
.description("Время получения заказа")
.register(meterRegistry));
return order;
} catch (Exception e) {
// Фиксируем ошибку
meterRegistry.counter("orders.errors",
"exception", e.getClass().getSimpleName()).increment();
throw e;
}
}
}
2. Мониторинг и Alerting
// Использование Micrometer + Prometheus
public class SLAMetricsConfig {
@Bean
public MeterBinder slaMetrics() {
return (registry) -> {
// Отслеживаем uptime
AtomicReference<Instant> startTime = new AtomicReference<>(Instant.now());
Gauge.builder("app.uptime", () ->
Duration.between(startTime.get(), Instant.now()).getSeconds())
.description("Uptime in seconds")
.register(registry);
// Отслеживаем ошибки
Counter.builder("app.errors.total")
.description("Total number of errors")
.register(registry);
};
}
}
// Prometheus queries для алертов:
// Uptime:
// (node_time_seconds{instance=":9090"} - process_start_time_seconds) / 3600
//
// Error rate:
// rate(app_errors_total[5m]) / rate(http_requests_total[5m])
//
// Response time (P95):
// histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
3. Load Testing для проверки SLA
// JMeter тест для проверки SLA параметров
public class SLALoadTest {
@Test
public void testResponseTimeSLA() throws Exception {
// SLA: P95 response time <= 300ms
HttpClient client = HttpClients.createDefault();
List<Long> responseTimes = new ArrayList<>();
int successCount = 0;
int totalRequests = 10000;
for (int i = 0; i < totalRequests; i++) {
long start = System.currentTimeMillis();
HttpGet request = new HttpGet("http://localhost:8080/api/orders/1");
HttpResponse response = client.execute(request);
long responseTime = System.currentTimeMillis() - start;
responseTimes.add(responseTime);
if (response.getStatusLine().getStatusCode() < 400) {
successCount++;
}
}
// Вычисляем P95
Collections.sort(responseTimes);
long p95 = responseTimes.get((int)(totalRequests * 0.95));
System.out.println("P95 response time: " + p95 + "ms");
System.out.println("Success rate: " + (100.0 * successCount / totalRequests) + "%");
// Проверяем SLA
assertTrue("P95 time должно быть <= 300ms", p95 <= 300);
assertTrue("Success rate должна быть >= 99.95%",
successCount >= totalRequests * 0.9995);
}
}
4. Graceful Degradation (мягкая деградация)
Когда система не может выполнить SLA, нужно деградировать функционально:
@Service
public class ProductService {
private final ProductRepository repository;
private final RecommendationService recommendations;
private final CircuitBreaker circuitBreaker;
public Product getProduct(Long id) {
// Основная функция — ДОЛЖНА выполнить SLA
Product product = repository.findById(id).orElse(null);
// Рекомендации — МОЖЕТ быть пропущено для выполнения SLA
try {
if (circuitBreaker.isOpen()) {
// Цепь разомкнута, рекомендационный сервис недоступен
// Пропускаем рекомендации
product.setRecommendations(Collections.emptyList());
} else {
List<Product> recs = recommendations.getRecommendations(id);
product.setRecommendations(recs);
}
} catch (Exception e) {
// Если рекомендации упали, продолжаем без них
logger.warn("Не удалось загрузить рекомендации", e);
product.setRecommendations(Collections.emptyList());
}
return product;
}
}
Типичные SLA для разных типов сервисов
WEB ПРИЛОЖЕНИЕ:
- Uptime: 99.5% - 99.99%
- Response Time (P95): 200-500ms
- Error Rate: < 0.1%
API SERVICE:
- Uptime: 99.9% - 99.99%
- Response Time (P95): 100-300ms
- Error Rate: < 0.05%
DATABASE:
- Uptime: 99.95% - 99.999%
- Response Time (P95): 10-50ms
- Error Rate: < 0.01%
MISSION CRITICAL (банк, e-commerce):
- Uptime: 99.99%+ (только минуты downtime в год)
- Response Time (P99): < 100ms
- Error Rate: < 0.001%
Документирование SLA в коде
@Service
public class PaymentService {
/**
* Обрабатывает платёж
*
* SLA:
* - Response Time (P95): <= 200ms
* - Success Rate: >= 99.95%
* - Uptime: >= 99.9%
*
* @param payment платёж для обработки
* @return результат обработки
* @throws PaymentException если платёж не удалось обработать
*/
public PaymentResult processPayment(Payment payment) throws PaymentException {
// Реализация
return null;
}
}
Заключение
SLA — это важный контракт, который определяет ожидания клиента:
- Uptime — система должна быть доступна (99.9% = 43 минуты downtime в месяц)
- Response Time — система должна отвечать быстро (P95 <= 300ms обычно)
- Error Rate — система должна быть надёжна (< 0.1% ошибок обычно)
- Мониторинг — нужно отслеживать метрики для выполнения SLA
- Graceful Degradation — если не может выполнить всё, выполни основное
- Alerting — настрой алерты при нарушении SLA
Для Java разработчика это означает необходимость разрабатывать систему с учётом этих параметров, добавлять мониторинг и обрабатывать сбои элегантно, без влияния на основную функциональность.