[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-nablyudaemost-chto-takoe-slo-sli-i-sla":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":16,"progress":17,"seo":18},769,"chto-takoe-slo-sli-i-sla",20,"nablyudaemost","Наблюдаемость","📊","Что такое SLO, SLI и SLA?","SLA, SLO, SLI — три уровня определения и измерения надёжности сервиса, введённые Google в рамках практик Site Reliability Engineering (SRE).\n\n- **SLA (Service Level Agreement)** — юридическое соглашение с клиентом, определяющее минимальный уровень качества и компенсации при нарушении.\n- **SLO (Service Level Objective)** — внутренняя цель команды по надёжности, строже SLA, без юридических последствий.\n- **SLI (Service Level Indicator)** — конкретная метрика, показывающая текущий уровень качества.\n\n```\nSLI (что измеряем) → SLO (какую цель ставим) → SLA (что обещаем клиенту)\n\nSLI: availability = 99.97%\nSLO: availability >= 99.95%   -- SLO выполняется\nSLA: availability >= 99.9%    -- SLA выполняется\n```\n\n### Error Budget (бюджет ошибок)\n\nError budget = 100% - SLO. Это «допустимый» объём ошибок или простоя.\n\n| SLO | Error Budget\u002Fмесяц | Допустимый downtime\u002Fмесяц |\n|-----|-------------------|--------------------------|\n| 99% | 1% | 7 часов 18 минут |\n| 99.9% | 0.1% | 43 минуты 50 секунд |\n| 99.95% | 0.05% | 21 минута 55 секунд |\n| 99.99% | 0.01% | 4 минуты 23 секунды |\n| 99.999% | 0.001% | 26 секунд |\n\n**Как использовать error budget:**\n- Пока error budget > 0: можно деплоить новые фичи, проводить эксперименты\n- Error budget исчерпан: замораживаем фичи, фокусируемся на надёжности\n- Error budget сгорает слишком быстро: алерт (burn rate alert)\n\n### Типичные SLI\n\n| SLI | Формула | Для чего |\n|-----|---------|----------|\n| Availability | `success_requests \u002F total_requests` | Доступность сервиса |\n| Latency | `requests_within_threshold \u002F total_requests` | Скорость ответа |\n| Throughput | `successful_operations \u002F time_period` | Пропускная способность |\n| Error Rate | `error_requests \u002F total_requests` | Частота ошибок |\n| Freshness | `data_age \u003C threshold` | Актуальность данных |\n| Correctness | `correct_responses \u002F total_responses` | Корректность ответов |\n\n\u003Cdetails>\u003Csummary>Реализация SLI\u002FSLO с Prometheus (recording + alert rules)\u003C\u002Fsummary>\n\n```yaml\n# recording_rules.yml — предвычисление SLI\ngroups:\n  - name: sli_rules\n    rules:\n      # SLI: Availability (доля успешных запросов)\n      - record: sli:availability:ratio_rate5m\n        expr: |\n          sum(rate(http_server_requests_seconds_count{status!~\"5..\", job=\"order-service\"}[5m]))\n          \u002F\n          sum(rate(http_server_requests_seconds_count{job=\"order-service\"}[5m]))\n\n      # SLI: Latency (доля запросов быстрее 500ms)\n      - record: sli:latency:ratio_rate5m\n        expr: |\n          sum(rate(http_server_requests_seconds_bucket{le=\"0.5\", job=\"order-service\"}[5m]))\n          \u002F\n          sum(rate(http_server_requests_seconds_count{job=\"order-service\"}[5m]))\n\n      # Error budget consumed (за последние 30 дней)\n      - record: slo:error_budget:consumed_ratio_30d\n        expr: |\n          1 - (\n            (1 - sli:availability:ratio_rate5m)\n            \u002F\n            (1 - 0.999)\n          )\n```\n\n```yaml\n# alert_rules.yml — алерты на burn rate\ngroups:\n  - name: slo_alerts\n    rules:\n      # Быстрое сгорание error budget (бюджет закончится за ~2 дня)\n      - alert: ErrorBudgetFastBurn\n        expr: |\n          (\n            1 - (\n              sum(rate(http_server_requests_seconds_count{status!~\"5..\", job=\"order-service\"}[1h]))\n              \u002F\n              sum(rate(http_server_requests_seconds_count{job=\"order-service\"}[1h]))\n            )\n          )\n          \u002F\n          (1 - 0.999) > 14.4\n        for: 2m\n        labels:\n          severity: critical\n        annotations:\n          summary: \"Error budget burning fast — exhaustion in ~2 hours\"\n\n      # Медленное сгорание (бюджет закончится за ~5 дней)\n      - alert: ErrorBudgetSlowBurn\n        expr: |\n          (\n            1 - (\n              sum(rate(http_server_requests_seconds_count{status!~\"5..\", job=\"order-service\"}[6h]))\n              \u002F\n              sum(rate(http_server_requests_seconds_count{job=\"order-service\"}[6h]))\n            )\n          )\n          \u002F\n          (1 - 0.999) > 6\n        for: 30m\n        labels:\n          severity: warning\n        annotations:\n          summary: \"Error budget burning slowly — exhaustion in ~5 days\"\n```\n\n\u003C\u002Fdetails>\n\n### Grafana Dashboard для SLO\n\n```promql\n# Текущая availability (SLI)\nsli:availability:ratio_rate5m{job=\"order-service\"}\n\n# Error budget оставшийся (%)\n(1 - (1 - sli:availability:ratio_rate5m) \u002F (1 - 0.999)) * 100\n```\n\n### Пример SLO-документа для сервиса\n\n```\nСервис: Order Service\nВладелец: Team Orders\n\nSLO 1: Availability\n  SLI: доля HTTP-запросов с кодом != 5xx\n  Target: 99.9% за 30-дневное окно\n  Error budget: 0.1% (~43 мин downtime)\n\nSLO 2: Latency\n  SLI: доля HTTP-запросов с latency \u003C 500ms\n  Target: 99% за 30-дневное окно\n  Error budget: 1% запросов могут быть медленнее\n\nДействия при исчерпании error budget:\n  1. Заморозка нестабильных деплоев\n  2. Приоритет задачам надёжности\n  3. Post-mortem для крупных инцидентов\n```\n\n### Важное\n- **SLO должен быть не 100%**: 100% SLO невозможен и блокирует любые изменения. «Достаточно надёжный» — правильный подход.\n- **SLO определяет SLA**: SLO всегда строже SLA. Если SLO нарушен, команда реагирует **до** нарушения SLA.\n- **Error budget — инструмент баланса**: между скоростью разработки (новые фичи) и надёжностью.\n- **SLI должен отражать пользовательский опыт**: не «CPU \u003C 80%», а «99% запросов отвечают за \u003C 500ms».\n\n### Частые ошибки\n- **SLO = SLA**: если SLO равен SLA, нет запаса — любая деградация сразу нарушает соглашение.\n- **Слишком высокий SLO**: 99.999% означает 26 секунд downtime в месяц — стоимость поддержания огромна.\n- **SLI не привязан к пользовательскому опыту**: мониторить внутренние метрики вместо user-facing.\n- **Нет error budget policy**: error budget определён, но нет процесса, что делать при его исчерпании.\n- **Один SLO на весь сервис**: разные endpoint'ы имеют разную важность. `\u002Fapi\u002Fpayments` и `\u002Fapi\u002Fhealth` — разные SLO.\n\n### Как используется в 2026\n- **SLO-based alerting** — стандартная практика в Google, рекомендуется в SRE Book. Prometheus + burn rate alerts.\n- **Grafana SLO feature** — встроенная поддержка SLO в Grafana Enterprise и Cloud.\n- **OpenSLO** — open-source стандарт для описания SLO в формате YAML.\n- **Sloth** — инструмент для генерации Prometheus recording\u002Falerting rules из OpenSLO-описания.\n- **Platform Engineering** — SLO как контракт между Platform team и Product teams.\n\n> **На собеседовании:** чётко разграничьте SLA (юридическое), SLO (внутренняя цель), SLI (метрика). Обязательно объясните Error Budget и его роль как баланса между фичами и надёжностью. Сильный ответ включает конкретный пример: \"SLI availability = 99.97%, SLO >= 99.95%, SLA >= 99.9%\". Частая ошибка — не упомянуть, что SLO не должен быть 100%.","","senior",[15],"observability",[],null,{"title":19,"description":20,"ogTitle":19,"ogDescription":21,"keywords":22,"schemaAnswer":20,"featuredSnippetReady":23},"Что такое SLO, SLI и SLA? — Gymterview","SLA, SLO, SLI — три уровня определения и измерения надёжности сервиса, введённые Google в рамках практик Site Reliability Engineering (SRE).","SLA, SLO, SLI — три уровня определения и измерения надёжности сервиса, введённые Google в рамках практик Site Reliabilit",[15,13],true]