SLI/SLO/SLA: SRE-практики и error budgets

Зачем знать: Middle 2 — это не только написать код, но и принимать решения о надёжности продукта. SLI/SLO/SLA — это язык, на котором продакт, бизнес и SRE договариваются о том, насколько сервис должен быть надёжным. Без понимания error budget разработчик либо переделывает то, что и так работает (трата времени), либо игнорирует деградацию (теряет пользователей). SRE-практики Google — это индустриальный стандарт, и любая зрелая компания (Uber, Stripe, Авито, Тинькофф) живёт по ним.

Содержание

1. Концепция: SLI vs SLO vs SLA, error budget
2. Production-практики: burn rate, RED/USE/Golden Signals
3. Gotchas: pitfalls measurement, alerting
4. Real cases: Google SRE, Stripe, Авито
5. Вопросы для собеседования
6. Practice
7. Источники

---

1. Концепция: SLI vs SLO vs SLA, error budget

1.1 Что такое SLI

SLI (Service Level Indicator) — измеримая характеристика сервиса. Это число, которое мы реально измеряем в production.

Примеры SLI:

• Availability: доля успешных запросов = count(status="2xx" OR status="3xx") / count(*).
• Latency: процент запросов быстрее X мс = count(duration < 200ms) / count(*).
• Throughput: запросов в секунду = rate(requests_total[5m]).
• Quality: для рекомендательной системы — точность top-10 рекомендаций.
• Freshness: для аналитики — задержка между событием и появлением в дашборде.

Хороший SLI — это пропорция (0 до 1), а не абсолютное число. Так его легко сравнивать с целью.

1.2 Что такое SLO

SLO (Service Level Objective) — целевое значение SLI на временном окне.

Примеры SLO:

• “99.9% запросов завершаются успешно за 30-дневное окно”.
• “99% запросов имеют latency < 200ms за 7-дневное окно”.
• “99.5% сообщений в Kafka обрабатываются в течение 5 минут”.

Структура SLO:

• SLI (что измеряем) — например, fraction of successful HTTP requests.
• Threshold (порог) — 99.9%.
• Time window — 30 дней (rolling или calendar).

Какой SLO выбрать:

• 99% (1.43 дня downtime/месяц) — для внутренних tooling.
• 99.5% (3.6 часа/месяц) — для нон-критичных user-facing.
• 99.9% (43 минуты/месяц) — для production API стандартно.
• 99.95% (21 минута/месяц) — для core path (checkout, login).
• 99.99% (4.3 минуты/месяц) — для критической инфраструктуры.
• 99.999% (26 секунд/месяц) — миф, требует огромных усилий.

Никогда не делай SLO 100%. Это убивает innovation (каждый рилиз — риск), невозможно достичь (sub-1% сбоев — закон Murphy), и не стоит затрат.

1.3 Что такое SLA

SLA (Service Level Agreement) — юридическое соглашение с пользователем, ОБЫЧНО с финансовыми последствиями.

Пример SLA AWS S3:

• Availability ≥ 99.9% per month.
• 99-99.9%: credit 10% bill.
• 95-99%: credit 25%.
• < 95%: credit 100%.

Правило: SLA всегда мягче SLO. Если внутренний SLO = 99.95%, то внешний SLA = 99.9%. Это buffer.

1.4 Error Budget

Error budget = 100% - SLO. Это “бюджет на ошибки” за период.

Пример:

• SLO = 99.9% за 30 дней.
• Error budget = 0.1% = 43 минуты downtime.
• За 30 дней допустимо 43 минуты быть “below SLO”.

Зачем нужен:

1. Risk management: можешь рилизить пока бюджет не исчерпан.
2. Negotiation tool: продакт хочет new feature → если бюджет горит, отвечаем “сначала стабилизация”.
3. Innovation budget: SLO 100% = ноль рилизов; разумный SLO = возможность экспериментов.

Error budget policy — формальное правило:

• Если burnt > 50% за 7 дней → freeze новых фич, фокус на reliability.
• Если burnt > 80% → escalation, postmortem.
• Если burnt > 100% → SEV1 incident, full team focus.

1.5 SLO как продуктовое решение

SLO — это продуктовое решение, не техническое. Вопросы:

• Чего ожидает пользователь?
• Сколько денег теряем за минуту downtime?
• Конкуренты живут на каком SLO?
• Стоимость 99.99% vs 99.9% — оправдана?

В 2026 году крупные компании имеют SLO-driven culture: каждый сервис владельцем декларирует SLO, ошибки бюджета влияют на roadmap.

1.6 Multi-window multi-burn-rate alerts

Простой алерт “error rate > 0.1%” — плохой. Либо ложный (короткий spike), либо slow (заметим поздно).

Google SRE ввели multi-window multi-burn-rate:

Burn rate = насколько быстро тратим бюджет:

• Burn rate = 1: ровно по SLO, бюджет исчерпается за period.
• Burn rate = 14.4: тратим в 14.4 раза быстрее, бюджет исчерпан за 2 дня.

Стандартная конфигурация (для 30-дневного окна):

Severity	Burn rate	Short window	Long window	Time to exhaustion
Page (P1)	14.4	5min	1h	2 дня
Page (P2)	6	30min	6h	5 дней
Ticket (P3)	3	2h	24h	10 дней
Ticket (P4)	1	3 days	—	30 дней

Зачем оба окна:

• Short window — быстро триггерит на острый incident.
• Long window — фильтрует ложные срабатывания (1-минутный flap не считается).

Алерт триггерится только когда обе оконные skewed rate выше threshold.

Пример Prometheus rule:

- alert: SLOBurnRate14_4
  expr: |
    (
      slo:error_rate:5m{service="api"} > 14.4 * 0.001
      and
      slo:error_rate:1h{service="api"} > 14.4 * 0.001
    )
  for: 1m
  labels:
    severity: page
  annotations:
    summary: "API burning error budget at 14.4x (SLO 99.9%)"

1.7 SLI типы детально

Availability — самая базовая.

sli_availability =
  rate(http_requests_total{status!~"5.."}[5m]) /
  rate(http_requests_total[5m])

Latency — обычно как proportion below threshold, не как percentile:

sli_latency =
  histogram_count_over_time(http_request_duration_seconds_bucket{le="0.2"}[5m]) /
  histogram_count_over_time(http_request_duration_seconds_count[5m])

То есть SLO: “99% запросов должны быть быстрее 200ms”. А не “P99 < 200ms” (это менее robust).

Throughput — обычно для batch/streaming:

sli_throughput = rate(messages_processed_total[5m])
SLO: rate >= 10000 per second.

Quality — для ML/рекомендаций:

• Доля рекомендаций с CTR > X.
• Доля поисковых результатов с relevant hit в top-3.

Freshness — для аналитики/event-driven:

sli_freshness =
  count(event_lag_seconds < 300) / count(events)
SLO: 99% events with lag < 5 min.

1.8 RED, USE, Four Golden Signals

Это разные модели для дашбордов и SLI.

RED (Tom Wilkie, Weaveworks) — для request-driven services:

• Rate — RPS.
• Errors — error rate.
• Duration — latency distribution.

Подходит для HTTP API, gRPC, message processors.

USE (Brendan Gregg) — для resources:

• Utilization — % использования (CPU, disk).
• Saturation — длина очереди ожидания.
• Errors — счётчик ошибок (disk errors, network errors).

Подходит для серверов, дисков, сети.

Four Golden Signals (Google SRE Book) — для services:

• Latency.
• Traffic (rate).
• Errors.
• Saturation (загрузка resource pool — DB connections, threadpool).

Это надмножество RED + S. Стандарт для production-сервисов.

1.9 Implementation: Prometheus + sloth

Vanilla Prometheus rules — много boilerplate. Каждый SLO требует записи 8-10 rules (recording rules, burn rate alerts).

Sloth (https://sloth.dev) — генератор SLO rules из YAML:

version: "prometheus/v1"
service: "api"
labels:
  team: "backend"
slos:
  - name: "requests-availability"
    objective: 99.9
    description: "99.9% of requests succeed"
    sli:
      events:
        error_query: sum(rate(http_requests_total{job="api",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="api"}[{{.window}}]))
    alerting:
      page_alert:
        labels: { severity: page }
      ticket_alert:
        labels: { severity: ticket }

Sloth генерирует ~30 Prometheus rules автоматически: recording rules для 5m/30m/1h/2h/6h/24h/3d окон, burn rate alerts для 14.4x/6x/3x/1x.

OpenSLO (https://openslo.com) — спецификация SLO как код, vendor-neutral. Поддерживается sloth, Nobl9, Splunk и другими.

1.10 Postmortem culture

Когда SLO нарушен — postmortem обязателен.

Принципы Google SRE:

1. Blameless — критика процессов и систем, не людей.
2. Detailed timeline — что когда происходило (UTC).
3. Root cause analysis — 5 whys.
4. Action items — конкретные, с owner и deadline.
5. Distribution — пострадавшие команды читают.

Шаблон:

• Impact summary (пользователи, длительность, $$$).
• Timeline (detection → mitigation → resolution).
• Root cause.
• What went well.
• What went wrong.
• Where we got lucky.
• Action items (с owner и due date).

Don’t blame the engineer who pushed the button — он действовал в рамках процесса. Виноват процесс/инструмент, который позволил ошибку.

1.11 Incident management

Когда incident случается:

Уровни (severity):

• SEV1: полный outage, потеря данных, security breach. All-hands, war room.
• SEV2: значительная деградация core path. On-call + еscalation.
• SEV3: minor degradation, workaround есть. On-call.
• SEV4: cosmetic, без impact. Ticket.

Roles:

• Incident Commander (IC) — координатор, принимает решения.
• Communications Lead — общается с stakeholders, customers.
• Operations Lead — технические действия.
• SME (Subject Matter Experts) — эксперты по компонентам.

Tools: PagerDuty / OpsGenie / FireHydrant / incident.io.

Flow:

1. Detection (alert).
2. Acknowledgement (on-call берёт).
3. Triage (severity).
4. Mitigation (stop bleeding — rollback, failover).
5. Resolution (fix root cause).
6. Postmortem.

---

2. Production-практики: burn rate, RED/USE/Golden Signals

2.1 Дизайн SLO для нового сервиса

Шаги:

1. Identify critical user journeys: что пользователь хочет сделать?
   • Sign up, login, checkout, search.
2. Choose SLI per journey:
   • Login: 99% < 2s, 99.9% success.
   • Search: 99% < 500ms, quality top-10 relevance.
3. Set initial SLO based on baseline:
   • Измерь текущий performance за 30 дней.
   • SLO = немного ниже baseline (иначе всегда burnt).
4. Define error budget policy:
   • 50% burnt = code freeze.
   • 100% burnt = SEV2.
5. Implement alerts (multi-window burn rate).
6. Iterate quarterly — meet retrospective, adjust SLO.

2.2 Calendar vs rolling window

Calendar window — конкретный месяц (Jan 1 - Jan 31).

• Плюс: понятен бизнесу, совпадает с биллингом.
• Минус: в начале месяца “чистый лист”, в конце паника.

Rolling window — последние 30 дней.

• Плюс: непрерывный — burn rate всегда актуален.
• Минус: момент исчерпания зависит от прошлого.

Production стандарт: rolling 30 дней для алертов, calendar для отчётов.

2.3 Error budget burn rate in code

В Go-сервисе можно exporter, который считает burn rate в текущем окне:

func (b *BurnRateExporter) Collect(ch chan<- prometheus.Metric) {
    errors := b.errors.WithLabelValues("api").Get()
    total := b.total.WithLabelValues("api").Get()

    sliErrorRate := errors / total
    sloErrorBudget := 1.0 - 0.999 // for 99.9% SLO
    burnRate := sliErrorRate / sloErrorBudget

    ch <- prometheus.MustNewConstMetric(
        b.burnRateDesc,
        prometheus.GaugeValue,
        burnRate,
        "api",
    )
}

2.4 SLI для streaming/async

Для async систем (Kafka consumer):

Lag SLO:

• “99% messages with consumer lag < 30 seconds”.
• “99.9% messages processed within 5 minutes”.

Прометей метрики:

kafka_consumergroup_lag{group="orders"} # current lag

SLI — на основе rate of lag > threshold:

sli_lag =
  (count_over_time(lag_seconds > 30 [5m]) > 0) ? 0 : 1

2.5 SLI для batch jobs

Completeness SLO: 99.9% jobs finish in expected time.

SLI:

• Doneness ratio: completed_today / expected_today.
• Latency: job duration < N minutes.

2.6 SLO testing in pre-prod

Чтобы убедиться, что SLO достижим:

• Chaos engineering: inject latency, kill pods.
• Load testing: проверить, что под нагрузкой SLI остаётся.
• Failover tests: переключение datacenter.

2.7 Reporting и review

Ежемесячный SLO review с командой:

• Какие SLO нарушены?
• Burn rate динамика.
• Top causes downtime.
• Action items.

Customer-facing SLA report — обычно автоматический в портале (status.example.com).

2.8 Connection between SLO and on-call

• SLO нарушение → page on-call.
• Page count за неделю — метрика самой quality on-call.
• Слишком частые pages — alerting noise или real reliability problem.
• Цель: < 2 pages per week per engineer.

2.9 SLO для multi-region

Если сервис multi-region:

• Per-region SLO (per AZ if needed).
• Global SLO (aggregate).
• Регион может быть down, global SLO держится благодаря failover.

2.10 SLO budget exchange

В крупных компаниях (Netflix, Google) есть error budget exchange:

• Сервис A не использовал бюджет → может “отдать” сервису B.
• Не формально, но в политиках.

---

3. Gotchas

3.1 ⚠️ Latency percentiles vs latency budget

Не пиши SLO “P99 < 200ms”. Лучше “99% requests < 200ms”.

Почему:

• P99 — статистическая аппроксимация (зависит от histogram buckets).
• При неравномерной нагрузке P99 малых окон шумный.
• “99% < threshold” — линейный счётчик, легко агрегировать.

3.2 ⚠️ Aggregation over windows

При aggregation per-region SLI → global SLI:

• Не усредняй %, используй сумму good/total.
• sum(good_region_1) + sum(good_region_2) / sum(total_region_1) + sum(total_region_2).

3.3 ⚠️ SLO == 100% невозможно

Если бизнес настаивает 100%:

• Объяснить: hardware fails, networks fail, you fail.
• 99.9% — это уже круто.
• 99.99% требует expensive engineering.

3.4 ⚠️ SLI учитывает только то, что видишь

Если client не смог connect (TCP timeout), сервер этого не видит — счётчик 5xx ноль. SLI: 100%. Реальность: пользователь страдает.

Решение:

• Synthetic monitoring (Pingdom, Datadog Synthetics) — внешние health checks.
• Client-side metrics (RUM — Real User Monitoring).
• LB логи (NGINX, Envoy) — видят TCP errors.

3.5 ⚠️ Alerting on noisy SLI

Если burnt rate шумный (мало запросов в окне):

• Минимальный QPS threshold для алерта.
• Не алертить, если total_requests < 100 в окне.

3.6 ⚠️ Burn rate alerts слишком чувствительны

14.4x alert может срабатывать каждый второй deploy. Решения:

• Deploy window: на 10 минут после deploy alerts суппрессятся.
• Запускать canary первым.

3.7 ⚠️ Per-customer SLO vs aggregate

Если 1 customer генерирует 50% трафика:

• Aggregate SLO 99.9% при ему 95% = он недоволен.
• Альтернатива: per-customer SLO, особенно для enterprise.

3.8 ⚠️ SLO без budget policy = decoration

Если есть SLO, но никто не следит за бюджетом — это просто метрика на дашборде. Должна быть policy: “при 80% burnt — feature freeze”.

3.9 ⚠️ Конфликт SLO между сервисами

API SLO 99.9% при downstream DB SLO 99.5% — невозможно. SLO зависят:

SLO_api ≤ SLO_db × SLO_cache × SLO_auth_service

Если каждый downstream 99.9%, и их 3 — твой SLO не выше 99.7%.

3.10 ⚠️ Pre-aggregation в Prometheus

Recording rules должны быть до error budget computation, иначе мегабайты данных при query.

# Recording rule
sli:requests:rate5m = rate(http_requests_total[5m])
sli:errors:rate5m = rate(http_requests_total{status=~"5.."}[5m])

И уже из них считать budget.

3.11 ⚠️ Counter resets

Если pod рестартует, http_requests_total обнуляется. Prometheus rate() это понимает (auto-handles resets), increase() тоже. Не используй raw counter в SLI расчётах.

3.12 ⚠️ Daylight saving time

Calendar window и DST: за день может быть 23 или 25 часов. Влияет на error budget computation. Используй UTC.

---

4. Real cases

4.1 Google SRE practices

Google SRE Book (открытая) описывает их подход:

• Каждый сервис имеет SLO.
• Error budget — формальный mechanism.
• Если бюджет horst — dev team помогает с reliability instead of new features.
• 50/50 split on-call: SRE и dev shared.

4.2 Stripe reliability

Stripe публично гордится 99.999% uptime для payments. Их практики:

• Synthetic monitoring каждые 5 секунд.
• Failover между datacenter < 30 секунд.
• Postmortem публичный для major incidents.

4.3 Cloudflare incidents

Cloudflare имеет 2-3 крупных incident в год. Их postmortem — образец:

• Public, detailed, blameless.
• Concrete action items.
• Follow-up через месяц.

4.4 Авито SRE

Авито (РФ) внедрили SLO-driven подход:

• Каждый сервис декларирует SLO в репе (yaml).
• Sloth для Prometheus rules.
• Quarterly SLO review.

4.5 Тинькофф / T-Bank

T-Bank — финтех, требования к надёжности высокие:

• Core path 99.99%.
• Non-core 99.9%.
• SLO влияет на bonus инженеров (косвенно через team OKR).

4.6 Netflix Chaos Engineering

Netflix не просто меряет SLI — они проактивно его ломают:

• Chaos Monkey kills pods.
• Chaos Kong kills regions.
• Gremlin для controlled chaos.

Если после Chaos Kong SLO остался — система действительно resilient.

4.7 Heroku 2022 outage (lesson)

Heroku в 2022 имел 24h downtime. Их SLA: 99.99%. После incident:

• Refund 100% bill за месяц (по SLA).
• Public postmortem.
• Investment в multi-region.

4.8 GitHub 2020 outage

GitHub упал на 7 часов. SLO нарушен на квартал. Постмортем показал database failover bug — фикс затронул архитектуру.

---

5. Вопросы для собеседования

Q1: В чём разница между SLI, SLO и SLA? A: SLI — что измеряем (число). SLO — целевое значение SLI (target). SLA — юридическое соглашение с пользователем, обычно с финансовыми последствиями за нарушение.

Q2: Что такое error budget? A: 100% - SLO. Бюджет на ошибки за период. Например, при SLO 99.9% за месяц — 43 минуты downtime разрешено. Используется как механизм управления rolling out изменений.

Q3: Зачем нужен error budget? A: Risk management (можно ли рилизить?), переговоры с продактом (бюджет горит → focus на стабильности), innovation balance (без бюджета на ошибки невозможно экспериментировать).

Q4: Что такое burn rate? A: Скорость траты error budget. Burn rate = 1 — ровно по SLO. Burn rate = 14.4 — тратим в 14.4 раза быстрее, бюджет исчерпан за 2 дня.

Q5: Что такое multi-window multi-burn-rate alerts? A: Алерты с двумя окнами (short + long). Short — быстрая детекция (5min/30min), long — фильтрация шума (1h/6h). Тригерятся только если обе окна показывают высокий burn rate. Стандарт Google SRE.

Q6: Какой SLO выбрать для нового сервиса? A: Начни с измерения baseline за 30 дней. SLO чуть ниже baseline. Стандарт для production API — 99.9%. Critical path — 99.95%. Internal tooling — 99% хватит.

Q7: Почему SLO 100% — плохая идея? A: Невозможно достичь (hardware fails), убивает innovation (каждый рилиз — риск), не стоит затрат (sub-1% улучшения требует огромных инвестиций), даёт ложную уверенность.

Q8: Чем RED отличается от USE? A: RED (Rate, Errors, Duration) — для request-driven services (HTTP API). USE (Utilization, Saturation, Errors) — для resources (CPU, диски). USE — снизу вверх (ресурс → impact), RED — сверху вниз (запрос → производительность).

Q9: Что такое Four Golden Signals? A: Google SRE стандарт для сервисов: Latency, Traffic, Errors, Saturation. Расширение RED + saturation (загрузка пула — DB connections, threadpool).

Q10: Что такое sloth? A: Open-source генератор Prometheus rules из YAML SLO спецификации. Снимает boilerplate (1 SLO = 30 rules автоматически). Совместим с OpenSLO.

Q11: Что такое OpenSLO? A: Спецификация SLO как код. Vendor-neutral формат YAML. Поддерживается sloth, Nobl9, Splunk. Аналогично OpenAPI для API спецификации.

Q12: Как считать latency SLI правильно? A: Не как P99, а как ”% запросов быстрее threshold”. Например, count(duration < 0.2) / count(*). Линейный счётчик, robust, легко агрегировать.

Q13: Что такое error budget policy? A: Формальное правило, что делать при разных уровнях burnt бюджета. Например: 50% burnt — code freeze, 80% — escalation, 100% — SEV2 incident. Без policy SLO — просто метрика.

Q14: Что такое blameless postmortem? A: Анализ инцидента, фокусирующийся на процессах и системах, а не на людях. Принципы: detailed timeline, root cause analysis, concrete action items, public distribution. Цель — учиться, не наказывать.

Q15: Какие роли в incident response? A: Incident Commander (координатор), Communications Lead (общение с stakeholders), Operations Lead (технические действия), SME (эксперты по компонентам). PagerDuty/OpsGenie помогают.

Q16: Calendar window vs rolling window? A: Calendar — конкретный месяц, понятен бизнесу. Rolling — последние 30 дней, всегда актуален для алертов. Production стандарт: rolling для алертов, calendar для отчётов.

Q17: Как SLO влияют на дизайн системы? A: SLO 99.9% при 3 downstream сервисах требует каждый minimum 99.97%. Архитектурные решения: cache, circuit breaker, fallback, graceful degradation, multi-region. SLO определяет, что можно/нельзя.

Q18: Что такое synthetic monitoring и зачем для SLO? A: Внешние health checks (Pingdom, Datadog Synthetics) делают регулярные запросы и измеряют latency/availability. Важно для SLO, потому что server-side метрики не видят TCP timeouts и DNS failures.

Q19: Как выбрать burn rate alerts thresholds? A: Google SRE рекомендует: 14.4x (5min/1h) для page severity 1, 6x (30min/6h) для page severity 2, 3x (2h/24h) для ticket, 1x (3d) для long-term. Пропорциональны бюджету.

Q20: Что делать, если SLO постоянно нарушается? A: 1) Понять, реалистичен ли SLO (может слишком жесткий). 2) Анализ root causes — общий паттерн? 3) Roadmap reliability work. 4) Возможно, заявить более низкий SLO (better honest 99% than aspirational 99.9% with lies).

---

6. Practice

1. Define SLO для своего сервиса: возьми существующий API, измерь baseline latency и error rate за 30 дней, определи 3 SLO (availability, latency, throughput).

2. Sloth setup: установи sloth, опиши SLO в YAML, сгенерируй Prometheus rules, разверни в test cluster.

3. Burn rate alerts: добавь Grafana алерты (или Alertmanager) для 14.4x/6x/3x burn rates. Запусти chaos test, проверь что paging triggers.

4. Postmortem template: создай шаблон postmortem для своей команды. Проведи на учебном примере (например, “выкатили баг, увели DB”).

5. Error budget dashboard: Grafana dashboard с remaining budget, burn rate trend, top contributors к ошибкам.

6. SLO retrospective: через 30 дней работы с SLO собери ретру: что нарушалось, действия, корректировки.

7. Cascading SLO: посчитай, какой SLO у API возможен с 4 downstream (каждый 99.9%).

8. Chaos test + SLO: запусти chaos engineering experiment, измерь impact на SLI, удалось ли остаться в SLO budget.

---

7. Источники

1. Google SRE Book (free): https://sre.google/sre-book/ — фундаментальная книга.
2. Google SRE Workbook: https://sre.google/workbook/ — practical guide.
3. “Implementing SLOs” (Google): https://sre.google/workbook/implementing-slos/ — chapter on SLO.
4. Sloth documentation: https://sloth.dev/ — Prometheus SLO generator.
5. OpenSLO: https://openslo.com/ — vendor-neutral spec.
6. “Site Reliability Engineering” book — O’Reilly.
7. “The Site Reliability Workbook” — O’Reilly.
8. “Implementing Service Level Objectives” — Alex Hidalgo, O’Reilly.
9. PagerDuty Incident Response docs: https://response.pagerduty.com/ — incident management.
10. Nobl9 SLO documentation: https://www.nobl9.com/learn-slo — commercial vendor с хорошим контентом.