# Принципи SRE у 2026: інженерія надійності, SLO та питання на співбесіді

> Принципи SRE у 2026 році: як обирати SLI, встановлювати SLO, рахувати бюджет помилок, писати в Prometheus алерти burn rate з кількома вікнами та відповідати на питання співбесід SRE, що звучать на кожному етапі.

- Published: 2026-11-07
- Updated: 2026-11-07
- Author: Anthony Fillion-Maillet
- Tags: devops, sre, slo, error-budget, prometheus, observability
- Reading time: 13 min

---

Принципи SRE перетворюють надійність із розмитої мети на конкретне число, з яким погоджуються і інженерна, і продуктова команди. Саме це число потім визначає, коли можна випускати нові функції, а коли слід зупинитися. Site reliability engineering у тому вигляді, як його сформулював Google і як його сьогодні застосовує більшість платформних команд, спирається на кілька ідей: вимірювати те, що відчуває користувач (SLI), встановлювати ціль нижче 100% (SLO), витрачати різницю як бюджет помилок (error budget) і обмежувати ручну роботу, яка підтримує системи в робочому стані. Питання на співбесідах SRE у 2026 році перевіряють саме ці ідеї, найчастіше через завдання визначити SLO для реального сервісу й написати алерт, який його захищає.

> **SLI, SLO і SLA одним реченням**
>
> SLI є вимірюванням: відношення успішних подій до всіх валідних подій, наприклад успішних запитів до всіх запитів. SLO означає внутрішню ціль для цього відношення в межах часового вікна, наприклад 99,9% за 30 днів. SLA означає договірне зобов'язання перед клієнтами зі штрафними санкціями, і воно завжди м'якше за SLO.

## Ключові принципи site reliability engineering

[Книга Google про SRE](https://sre.google/sre-book/service-level-objectives/) розглядає надійність як функцію продукту, що має свою ціну. Кожна додаткова «дев'ятка» коштує більше інженерного часу й уповільнює релізи, тоді як користувачі рідко помічають різницю між 99,99% і 99,999%, бо їхня власна мережа, пристрій та інтернет-провайдер менш надійні. Мета полягає в правильному рівні надійності, а не в максимальному.

Із цієї відправної точки випливає кілька принципів:

- **Надійність вимірюється з боку користувача.** Завантаження CPU і перезапуски подів є причинами. Невдалі оформлення замовлень і повільне завантаження сторінок є тим, що відчуває користувач, і саме це фіксує SLI.
- **100% є хибною ціллю.** SLO на рівні 100% забороняє будь-які зміни, адже кожен деплой несе ризик. Проміжок нижче 100% і є бюджетом помилок, який призначений для витрачання на релізи, експерименти та міграції.
- **Toil має верхню межу.** Настанова Google з [розділу про усунення toil](https://sre.google/sre-book/eliminating-toil/) утримує операційну роботу нижче 50% часу SRE-інженера. Toil означає ручну, повторювану, автоматизовувану роботу, яка зростає лінійно разом із сервісом. Решта часу йде на інженерну роботу, що цей toil усуває.
- **Постмортеми проводяться без пошуку винних.** Розбір інциденту з'ясовує, що в системі дозволило збою статися, а не хто ввів команду. Інженер, якого звинувачують, приховує інформацію, а розбір без звинувачень її розкриває.
- **Моніторинг сповіщає за симптомами.** Виклик чергового (page) надходить тоді, коли користувачі страждають або ось-ось почнуть страждати, а не тоді, коли окремий вузол виглядає незвично.

На співбесіді досвідченого SRE від людини, яка лише прочитала книгу, зазвичай відрізняє саме другий пункт. Відповідь junior-рівня трактує бюджет помилок як допуск на збої. Відповідь senior-рівня трактує його як інструмент керування релізами: механізм, що дозволяє продукту й команді надійності сперечатися на основі даних, а не думок.

## Вибір SLI, що відображають досвід користувача

Хороший SLI являє собою відношення в діапазоні від 0 до 1, обчислене з подій, які впізнав би користувач. [SRE Workbook](https://sre.google/workbook/implementing-slos/) пропонує короткий перелік залежно від типу сервісу:

| Тип сервісу | Типові SLI | Де вимірювати |
|---|---|---|
| API, що обробляє запити | Доступність, затримка | Логи load balancer або ingress, серверні метрики |
| Конвеєр даних | Свіжість, коректність, покриття | Часові мітки результатів конвеєра, завдання валідації |
| Система зберігання | Довговічність, затримка читання та запису | Шар зберігання, синтетичні проби |
| Фронтенд | Час завантаження сторінки, частка помилок у браузері | Real user monitoring |

Вимірювання на load balancer виявляє збої, яких застосунок узагалі не бачить, наприклад под, що впав і нічого не повертає. Вимірювання в браузері виявляє проблеми CDN і DNS, але додає шум від слабких мобільних з'єднань. Більшість команд починає з load balancer або ingress, бо дані там уже є.

У Prometheus два класичні SLI для HTTP-сервісу: частка доступності та частка затримки. SLI затримки вважає успішними запити, швидші за заданий поріг, тож він є відношенням, як і інші, а не перцентилем.

```promql
# checkout-sli.promql
# Availability SLI: share of requests that did not fail with a 5xx
sum(rate(http_requests_total{job="checkout-api", code!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="checkout-api"}[5m]))

# Latency SLI: share of requests served in under 300 ms
# Uses the histogram bucket with le="0.3", so 0.3 must be a configured bucket boundary
sum(rate(http_request_duration_seconds_bucket{job="checkout-api", le="0.3"}[5m]))
/
sum(rate(http_request_duration_seconds_count{job="checkout-api"}[5m]))
```

На співбесідах регулярно спливають дві деталі. По-перше, відповіді 4xx зазвичай вважаються валідними, але успішними, бо 404 чи помилка валідації є помилкою клієнта; якщо рахувати їх як збої, клієнт із некоректною поведінкою може спалити весь бюджет. По-друге, поріг затримки має збігатися з межею бакета гістограми, інакше запит нічого не поверне або непомітно використає не той бакет. Prometheus 3.16, випущений 5 листопада 2026 року, підтримує нативні гістограми, які знімають обмеження фіксованих бакетів, але їх потрібно ввімкнути на боці скрейпінгу.

## Встановлення цілей SLO та розрахунок бюджету помилок

SLO поєднує SLI, ціль і часове вікно. Вікно зазвичай ковзне, 28 або 30 днів, тож бюджет відновлюється поступово, а не обнуляється першого числа місяця. Ціль обирають на основі історичних показників і очікувань користувачів, а не того, що гарно виглядає на слайді.

Таблиця нижче показує, що дозволяє кожна ціль у 30-денному вікні. Це проста арифметика: бюджет дорівнює `(1 - SLO) × 30 днів`.

| Ціль SLO | Бюджет помилок | Допустимий повний простій за 30 днів |
|---|---|---|
| 99% | 1% | 7 год 12 хв |
| 99,5% | 0,5% | 3 год 36 хв |
| 99,9% | 0,1% | 43 хв 12 с |
| 99,95% | 0,05% | 21 хв 36 с |
| 99,99% | 0,01% | 4 хв 19 с |

Для SLO на основі запитів бюджет виражається в запитах, а не у хвилинах: за цілі 99,9% і 12 мільйонів запитів у вікні допускається 12 000 невдалих запитів. Бюджети на основі запитів справедливіші для сервісів із нерівномірним трафіком, бо збій о третій ночі витрачає менше бюджету, ніж такий самий збій у піковий час.

Поширене завдання на співбесіді полягає в тому, щоб обчислити залишок бюджету та швидкість його витрачання. Скрипт нижче є саме тією відповіддю, якої очікують, коли питання вимагає коду.

```python
# error_budget.py
from dataclasses import dataclass

@dataclass
class SloWindow:
    objective: float      # 0.999 for a 99.9% SLO
    window_days: int      # rolling window, usually 28 or 30
    total_requests: int   # valid events seen in the window so far
    failed_requests: int  # bad events seen in the window so far

    @property
    def budget_fraction(self) -> float:
        return 1 - self.objective  # 0.001 for 99.9%

    def budget_remaining(self) -> float:
        """1.0 means untouched, 0 means spent, negative means SLO breached."""
        allowed_failures = self.budget_fraction * self.total_requests
        return 1 - self.failed_requests / allowed_failures

    def burn_rate(self, recent_errors: int, recent_total: int) -> float:
        """1.0 means the budget lasts exactly the window; 10 means ten times too fast."""
        return (recent_errors / recent_total) / self.budget_fraction

    def hours_to_exhaustion(self, burn: float) -> float:
        # Remaining share of budget, consumed at `burn` times the sustainable pace
        return self.budget_remaining() * self.window_days * 24 / burn

slo = SloWindow(objective=0.999, window_days=30, total_requests=12_000_000, failed_requests=7_800)
burn = slo.burn_rate(recent_errors=240, recent_total=16_000)
print(f"budget left: {slo.budget_remaining():.0%}")             # 35%
print(f"burn rate: {burn:.1f}")                                 # 15.0
print(f"exhausted in: {slo.hours_to_exhaustion(burn):.1f} h")   # 16.8 h
```

Burn rate, що дорівнює 15, означає, що сервіс збоїть на 1,5% запитів, тоді як SLO допускає 0,1%. З такою швидкістю решта 35% бюджету зникне менш ніж за 17 годин, і це виправдовує те, щоб розбудити чергового.

## Алерти burn rate з кількома вікнами

Сповіщення безпосередньо за SLI («частка помилок понад 0,1%») породжує виклики на кожен короткий сплеск і пропускає повільні витоки. [Розділ SRE Workbook про алерти на основі SLO](https://sre.google/workbook/alerting-on-slos/) натомість рекомендує алерти з кількома вікнами та кількома порогами burn rate. Кожен алерт відповідає на одне питання: чи витрачається бюджет настільки швидко, що вичерпається раніше, ніж хтось на нього подивиться?

Еталонні пороги для 30-денного вікна:

| Критичність | Довге вікно | Коротке вікно | Burn rate | Витрачений бюджет на момент спрацювання |
|---|---|---|---|---|
| Page | 1 год | 5 хв | 14,4 | 2% |
| Page | 6 год | 30 хв | 6 | 5% |
| Ticket | 3 дні | 6 год | 1 | 10% |

Довге вікно забезпечує значущість: одна погана хвилина не будить чергового. Коротке вікно, що становить одну дванадцяту довгого, дозволяє алерту швидко скинутися після завершення інциденту, тож виклик не триває ще годину після виправлення. Обидві умови мають виконуватися одночасно.

Перший блок записує частку помилок для кожного вікна як recording rule, щоб вирази алертів залишалися дешевими. Другий блок визначає два алерти рівня page для SLO 99,9%, де частка бюджету становить 0,001.

```yaml
# checkout-slo-recording.rules.yml
groups:
  - name: checkout-slo-recording
    interval: 30s
    rules:
      - record: slo:sli_error:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{job="checkout-api", code=~"5.."}[5m]))
          / sum(rate(http_requests_total{job="checkout-api"}[5m]))
      - record: slo:sli_error:ratio_rate1h
        expr: |
          sum(rate(http_requests_total{job="checkout-api", code=~"5.."}[1h]))
          / sum(rate(http_requests_total{job="checkout-api"}[1h]))
      # Same pattern for 30m and 6h, omitted for brevity
```

```yaml
# checkout-slo-alerts.rules.yml
groups:
  - name: checkout-slo-alerts
    rules:
      - alert: CheckoutErrorBudgetFastBurn
        # 2% of the monthly budget spent in one hour
        expr: |
          slo:sli_error:ratio_rate1h > (14.4 * 0.001)
          and slo:sli_error:ratio_rate5m > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "checkout-api burns its error budget 14x too fast"
      - alert: CheckoutErrorBudgetSlowBurn
        # 5% of the monthly budget spent in six hours
        expr: |
          slo:sli_error:ratio_rate6h > (6 * 0.001)
          and slo:sli_error:ratio_rate30m > (6 * 0.001)
        labels:
          severity: page
```

Писати ці правила вручну для кожного сервісу швидко стає рутиною. [Sloth](https://github.com/slok/sloth), генератор SLO з відкритим кодом, приймає коротку специфікацію й створює наведені вище recording rules та алерти з кількома порогами burn rate. Заповнювач `{{.window}}` замінюється на кожне вікно, яке потрібне Sloth.

```yaml
# checkout-slo.sloth.yml
version: "prometheus/v1"
service: "checkout-api"
labels:
  owner: "payments-team"
slos:
  - name: "requests-availability"
    objective: 99.9
    description: "Checkout requests that do not fail with a 5xx"
    sli:
      events:
        error_query: sum(rate(http_requests_total{job="checkout-api",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="checkout-api"}[{{.window}}]))
    alerting:
      name: CheckoutHighErrorRate
      page_alert:
        labels:
          severity: page
      ticket_alert:
        labels:
          severity: ticket
```

Команди, яким потрібен формат, незалежний від постачальника, звертаються до [специфікації OpenSLO](https://github.com/OpenSLO/OpenSLO), що описує SLO у YAML без прив'язки до конкретного бекенду моніторингу.

## Політика бюджету помилок і рішення щодо релізів

Бюджет помилок без політики перетворюється на дашборд, на який ніхто не реагує. [Приклад політики бюджету помилок](https://sre.google/workbook/error-budget-policy/) у SRE Workbook чітко визначає, що відбувається, коли бюджет вичерпано, і хто заздалегідь це погодив.

Типова політика містить:

- **Тригер.** Сервіс перевищив бюджет помилок у ковзному вікні.
- **Наслідок.** Релізи нових функцій зупиняються, за винятком виправлень безпеки та змін, що підвищують надійність, доки сервіс не повернеться в межі SLO.
- **Шлях винятків.** Окремий інцидент, спричинений залежністю поза контролем команди, може бути виключено з розрахунку, а рішення документується.
- **Ескалація.** Суперечки передаються визначеній ролі, наприклад CTO, а не тому, хто сперечається найгучніше.

Політику підписують продукт та інженерія ще до першого порушення, і в цьому весь сенс: заморожування релізів стає заздалегідь погодженим правилом, а не сваркою посеред інциденту. Інтерв'юери часто запитують, що відбувається, коли бюджет стабільно залишається недоторканим. Очікувана відповідь: SLO може бути надто м'яким або команда релізить надто обережно, і бюджет слід витрачати на швидші релізи чи ризикованіші міграції.

> **Пастка SLA на співбесіді**
>
> Якщо встановити внутрішній SLO на рівні клієнтського SLA, запасу не залишається: перше ж порушення SLO вже означає договірний штраф. SLO має бути суворішим за SLA, щоб алерти спрацювали, а заморожування релізів почалося, поки договір ще виконується.

## Зменшення toil, чергування та постмортеми без звинувачень

Час SRE ділиться між операціями та інженерією. Операції охоплюють чергування (on-call), тікети й ручні втручання. Інженерія охоплює автоматизацію, планування потужностей і функції надійності. Коли toil перевищує орієнтир у 50%, команда SRE повертає частину роботи команді розробки або інвестує в автоматизацію, інакше вона перетворюється на операційну команду з новою назвою.

Стан чергувань вимірюють, а не припускають. Корисні сигнали: кількість викликів за зміну, частка викликів, що потребували дій, і час підтвердження. Виклик, який не потребує жодних дій, є помилкою в алертингу, і його виправляють або видаляють. Алерти за симптомами на основі burn rate SLO, як у правилах вище, суттєво скорочують кількість викликів порівняно з алертами на CPU, пам'ять чи перезапуски окремих подів.

Коли трапляється інцидент, [розділ про культуру постмортемів](https://sre.google/sre-book/postmortem-culture/) книги SRE описує подальший розбір. Постмортем фіксує вплив у термінах SLO (скільки бюджету витрачено), хронологію, чинники, що сприяли збою, і заходи з відповідальними та термінами. Він не називає конкретну людину причиною. На співбесідах часто звучать два уточнювальні питання: як гарантувати, що заходи справді виконано (відстежувати їх у тому самому беклозі, що й функції, і переглядати на регулярній зустрічі), і коли постмортем обов'язковий (будь-який інцидент, що витратив значну частку бюджету, будь-який виклик, що когось розбудив, будь-яка втрата даних).

Чотири золоті сигнали з книги SRE, а саме затримка, трафік, помилки й насичення, доповнюють картину моніторингу. Затримка та помилки зазвичай стають SLI. Трафік і насичення живлять планування потужностей і дашборди, а не виклики чергових.

## Питання на співбесіді SRE з очікуваними відповідями

Нижче наведено питання, що регулярно повторюються на співбесідах SRE та senior DevOps, разом із суттю сильної відповіді. [Модуль питань про принципи SRE](/technologies/devops/interview-questions/sre-principles) відпрацьовує ті самі теми, а [модуль про алертинг і реагування на інциденти](/technologies/devops/interview-questions/alerting-incident-response) охоплює бік чергувань.

**П: Чим відрізняються SLI, SLO та SLA?**

SLI є виміряним відношенням, SLO є внутрішньою ціллю для нього в межах вікна, а SLA є зовнішнім договором зі штрафами. SLO суворіший за SLA, щоб команда реагувала до того, як компанія втратить гроші.

**П: Чому не встановити SLO на рівні 100%?**

Тому що кожна зміна несе ризик, тож ціль 100% забороняє релізи. До того ж користувачі не здатні відчути надійність, вищу за надійність власної мережі. Проміжок нижче 100% і є бюджетом помилок, який фінансує релізи.

**П: Визначте SLO для API оформлення замовлень.**

Сильна відповідь обирає два SLI (доступність без урахування 4xx і затримку нижче порогу, виміряну на load balancer), ковзне вікно 30 днів, цілі на основі даних за останній квартал і пояснює, як із них випливають алерти та політика бюджету помилок. Назвати лише «99,99% uptime», не уточнивши, що саме вимірюється, є класичною слабкою відповіддю.

**П: Чому алерти на перцентиль затримки p99 є поганими алертами SLO?**

Перцентиль p99 у короткому вікні шумний і не агрегується між інстансами. Перетворення затримки на частку запитів нижче порогу робить її адитивною, порівнянною з SLI доступності та сумісною з алертами burn rate.

**П: Поясніть burn rate і чому алерти використовують два вікна.**

Burn rate дорівнює спостережуваній частці помилок, поділеній на частку бюджету; значення 1 означає, що бюджету вистачить рівно на вікно. Довге вікно відфільтровує короткі сплески, коротке дозволяє алерту швидко зникнути після відновлення.

**П: Що таке toil і як його тримати під контролем?**

Ручна, повторювана, автоматизовувана робота без тривалої цінності, яка масштабується разом із сервісом. Її вимірюють, обмежують (Google використовує поріг 50%) і скорочують через автоматизацію або передачу роботи команді-власниці сервісу.

**П: Що робить постмортем безоцінковим (blameless)?**

Він зосереджується на системних умовах, які дозволили збою статися, виходить із того, що люди діяли розумно з огляду на наявну інформацію, і завершується відстежуваними заходами. Перевірка проста: чи поділився б залучений інженер кожною деталлю без страху?

Питання про моніторинг часто йдуть одразу за питаннями про SLO на тій самій співбесіді. [Посібник із питань на співбесіді щодо Prometheus](/blog/devops/prometheus-vs-grafana-vs-datadog-monitoring-devops-interview) охоплює PromQL, типи метрик і кардинальність, а [сторінка технології DevOps](/technologies/devops) містить перелік усіх модулів для ширшої підготовки.

## SLO та бюджети помилок на практиці: головне

- Кожен SLI варто визначати як відношення успішних подій до валідних, виміряне якомога ближче до користувача, а для більшості API не враховувати 4xx як збої
- Ціль SLO слід обирати на основі історичних даних і ковзного вікна 28 або 30 днів, тримаючи її суворішою за будь-який клієнтський SLA
- Ціль потрібно переводити в бюджет у хвилинах або запитах і знати цифри напам'ять: 99,9% за 30 днів дають 43 хвилини
- Алерти мають базуватися на burn rate з парними вікнами (14,4 для 1 год і 5 хв, 6 для 6 год і 30 хв), а не на сирій частці помилок чи CPU
- Коли SLO мають більше ніж кілька сервісів, правила краще генерувати через Sloth або подібний інструмент, щоб пороги залишалися узгодженими
- Політику бюджету помилок слід написати й підписати до першого порушення, включно з правилом заморожування та шляхом ескалації
- Toil, кількість викликів і заходи з постмортемів варто відстежувати так само ретельно, як і нові функції

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/uk/blog/devops/sre-principles-2026-slos-error-budgets-interview-questions