Что такое SLA?

Давай разжую эту тему про SLA, чтобы было понятно, как работает эта магия, а то некоторые думают, что это просто бумажка для отмазки.

SLA, или Service Level Agreement — это, по сути, официальная бумажка, где мы, как поставщики, и клиенты договариваемся, насколько хорошо должен работать сервис и что будет, если он накроется медным тазом. Не просто «обещаем стараться», а вот конкретные цифры, за которые потом можно получить по шапке.

Основные метрики, на которые мы, девопсы, смотрим как орлы:

• Доступность (Uptime): Это святое. Измеряется в тех самых «девятках». Все хотят пять девяток, но мало кто готов платить за железо, которое это обеспечит.
  • 99.9% — это вроде бы круто, но на деле значит, что сервис может лежать 43 минуты в месяц, и это ещё считается по соглашению! Представляешь, клиенту сказать: «Всё ок, у нас 99.9%!» — а он тебе: «Да иди ты нахуй, у меня пол-рабочего дня продаж нет!».
  • 99.99% — уже серьёзнее, тут всего 4 минуты простоя. Но чтобы это выдержать, архитектура должна быть — ёперный театр! — с кучей дублирующих компонентов. Один дата-центр чихнул — и всё, пиши пропало, SLA накрылось.
• RTO и RPO: Вот это две важные хуйни, которые все путают.
  • RTO — это сколько максимум сервис может быть недоступным после пиздеца. Скажем, час. Значит, за этот час ты должен всё поднять, даже если для этого надо взъебнуть пол-инфраструктуры.
  • RPO — это сколько данных мы готовы потерять. Допустим, 15 минут. Это диктует, как часто мы гоним бэкапы. Если RPO = 15 мин, а ты бэкапишь раз в сутки — ты, прости, полупидор, и при сбое будет не RPO, а пизда рулю и полный ахтунг.

Как мы, девопсы, с этим SLA живём и боремся, чтобы не получить по щам:

1. Мониторинг и алертинг — наше всё. Я настраиваю Prometheus, Grafana и прочую требуху так, чтобы они не просто данные собирали, а прямо в глаза тыкали: «Э, сабака сука, доступность упала до 99.85%, через 10 минут будет нарушение SLA!». Все алерты привязаны к этим порогам. Не «ой, что-то медленно», а «p99 latency превысил 200 мс, контрактный порог — 150, бля буду, срочно копай!».
2. Проектирование с прицелом на отказ. Чтобы выполнить эти ебушки-воробушки с доступностью, нельзя ставить всё на одну железяку. Зоны доступности, регионы, автоматический фейловер — без этого никуда. Иначе первый же сбой дата-центра — и ты уже распиздяй, который клиенту кредиты выписываешь.
3. Автоматизация реагирования. Когда ночью в три часа звонит пейджер, у тебя терпения ноль ебать, и думать нет сил. Поэтому я настраиваю ранбуки: алерт прилетел — система сама пытается сделать первые шаги (перезапустить под, переключить трафик), чтобы сократить время простоя (MTTR). Пока ты только глаза протёр, часть проблемы уже может решиться.
4. Пример из жизни — алерт в Prometheus: Вот смотри, как это выглядит в коде. Ничего не выдумываю, всё честно.

# Prometheus Rule для алерта при падении доступности ниже 99.9% за последний час
- alert: APIAvailabilityBelowSLA
  expr: (1 - (avg_over_time(probe_success{job="api-health"}[1h]))) * 100 > 0.1
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "Нарушение SLA по доступности API (менее 99.9%)"
    description: "Доступность за последний час составила {{ $value }}%"

Это правило орёт, когда доступность проседает ниже порога. И это не просто «ой, смотри» — это прямой сигнал, что через 5 минут начинается нарушение контракта, и могут пойти финансовые последствия.

А что если SLA всё-таки нарушили? Ну, тут всё просто и печально. В облаке — будь добр, выкати кредиты клиенту. Во внутренних соглашениях — готовься к разбору полётов, где тебе доходчиво объяснят, на каком тонком льду ты ходил. Поэтому эта хуйня — не просто формальность, а реальный ориентир, по которому строится вся наша работа: от архитектуры до ночных дежурств. И да, иногда из-за желания бизнеса сэкономить на железе, мы подозрение ебать чувствуем, что выполнить обещанные цифры будет охренеть как сложно.