Англійська для інженерів SRE: SLO, SLA, бюджет помилок і мова інциденту

Сайт Надійності Інженери мають одну з найбільш мовних ролей в програмному забезпеченні. SRE пише runbooks, веде живі виклики інцидентів, представляє ставки вигорання бюджету помилок керівництву, сприяє пост-мортним зустрічам і визначає SLO в договорній мові. Кожна з них вимагає точної, професійної англійської мови - нечітка мова в відповіді на інцидент може коштувати хвилин; нечіткі визначення SLO призводять до суперечок.

Цей посібник містить основні слова SRE і шаблони спілкування для кожного контексту.

---

Словник вимірювання надійності

Слі, Сло, Сла

Ці три терміни формують мову зобов’язань щодо надійності. Нерідні носії часто плутають їх, тому що вони звучать схоже. Розрізнення є критичним.

SLI — Індикатор рівня обслуговування SLI — це специфічний показник, який ви вимірюєте. Це число, яке кількісно виражає один аспект надійності послуги.

«Наша основна SLI для API розрахунку є успішність запитів — відсоток запитів, які повертають відповідь 2xx або не-500»

• Нет, не надо «Ми відстежуємо три SLI для платіжної служби: доступність (рівень успіху), затримка (P99 < 200 міс) і свіжість (оновлення стану платежу протягом 30 секунд).»

** SLO — Об’ єкт рівня обслуговування ** SLO — це цільове значення (або діапазон) для SLI за певний проміжок часу. Це внутрішня мета — ваш інженерний стандарт.

Наша SLO є 99,9% доступності вимірюється як рухоме 28-денне вікно

• Нет, не надо «Затримка SLO: час відповіді 99-го процентиля повинен залишатися нижче 500 мс»
• Нет, не надо «Ми маємо ступеневий SLO: 99,95% для платних клієнтів і 99,5% для безкоштовних користувачів — дві групи обслуговуються окремою інфраструктурою»

** SLA — Договір про рівень обслуговування** SLA є контрактним зобов’язанням до зовнішніх клієнтів, зазвичай з фінансовими штрафами за порушення. Ваше SLA, як правило, менш вимогливе, ніж ваше SLO — прогалина є вашим буфером безпеки.

«Наше SLA обіцяє 99,9% щомісячної доступності. Наша внутрішня мета SLO становить 99,95% — ми підтримуємо 0,05% буферу вище контрактного зобов’язання. ”

• Нет, не надо «Якщо ми порушимо SLA, клієнти будуть зараховані відповідно до таблиці простою в розділі 3 договору»
• Нет, не надо «SLA покриває тільки кінцеві точки API, зазначені в Додатку A — наші внутрішні інструменти виходять за рамки»

---

Помилка бюджету

Бюджет помилок — це кількість ненадійних помилок, які ваш SLO дозволяє у вказаний період часу. Це розрив між 100% і вашою метою SLO.

SLO	Error budget per 30 days
99%	7.2 hours
99.5%	3.6 hours
99.9%	43.2 minutes
99.95%	21.6 minutes
99.99%	4.3 minutes

** Говорячи про використання бюджету помилок: **

«Ми спалили 65% бюджету на помилки цього місяця за перші два тижні — переважно від аварійного переходу бази даних 8-го»

• Нет, не надо “При теперішньому темпі вигорання, ми вичерпаємо бюджет помилок до 22-го числа місяця.”
• Нет, не надо Після понеділкового інциденту, у нас залишилося лише 8 хвилин бюджету помилок на решту кварталу

** Мова прийняття рішень щодо бюджетів помилок: **

«Політика бюджету помилок: якщо ми вичерпаємо 50% бюджету помилок до середини періоду, ми заморожуємо некритичні розгортання і зосереджуємось на поліпшенні надійності»

• Нет, не надо «Ми маємо надлишок бюджету помилок в цьому кварталі — ми можемо дозволити собі запустити експеримент міграції наступного тижня»
• Нет, не надо “Команда продукту хоче запустити нову функцію, яка вимагає ризикованої зміни схеми бази даних. У нас немає достатньо бюджету на помилки, щоб поглинути ризик — ми відклали дату запуску»

---

Сообщение об инциденте

Інциденти є найважливішим контекстом комунікації для SRE. Мова повинна бути ясною, спокійною і структурованою — як під час інциденту, так і після смерті.

Уровень тяжести инцидента

Більшість команд використовують нумеровану шкалу тяжкості. Використовуйте їх постійно:

“Це SEV-1 — у нас повна недоступність платіжної служби і ми втрачаємо прибуток. Всі інженери команди реагування на інцидент були покликані»

• Нет, не надо “SEV-2 — погіршена продуктивність пошуку API, 30% рівень помилок. Деякі користувачі постраждали, але служба частково функціональна»
• Нет, не надо “SEV-3 — некритичне фонове завдання завершилося невдачею. Немає впливу на користувача, але нам потрібно дослідити перед щоденним експортом даних сьогодні ввечері»

Мова команди інциденту

Під час виклику інциденту в реальному часі чітке призначення ролі і структура зв’язку запобігають хаосу.

Открытие инцидента:

“Я відкриваю справу за відключення сервісу аутентифікації. Поточний стан: 100% спроб входу зазнають невдачі. Командир: я. Підказка для зв’ язку: [назва]. Мені потрібен інженер з команди аутентифікації і один з інфраструктури на цей виклик зараз»

** Призначення завдань: **

«Чи можете ви взяти мережевий бік — перевірити, чи це ізольовано до одного AZ або крос-регіонального?»

• Нет, не надо “[Ім’я], ти можеш бути ведучим зв’язку? Кожні 15 хвилин публікуйте оновлення на каналі #incidents
• Нет, не надо «Мені потрібен хтось, хто перевірить насиченість бази даних підключення — це було причиною останнього разу, коли ми бачили такі помилки»

** Запит на оновлення стану: **

“Що ви бачите на базі даних? Якийсь незвичайний вантаж?»

• Нет, не надо “Де ми на відновленні? Коли ми можемо очікувати, що попередня версія буде обслуговувати трафік?»
• Нет, не надо Чи можемо ми стверджувати, що всі ці країни є окремими державами, чи є вони частиною однієї держави?

** Інформування зацікавлених сторін (зовнішнє спілкування): **

“Поновлення 14:35 UTC: Ми розслідуємо підвищений рівень помилок у службі автентифікації. В даний час невідомо, коли буде розв’ язано цю проблему. Ми оновимо за 15 хвилин»

• Нет, не надо «Підтвердження 14:50 UTC: Ідентифікована коренева причина — зміна конфігурації, розгорнута о 14:10 UTC, призвела до виснаження бази з’єднань. Ми повертаємося назад. «10 хвилин»
• Нет, не надо “Оновлення 15:05 UTC: Відновлення завершено і рівень помилок повернувся до нормального. Служба автентифікації повністю працює. Ми зробимо всмоктування через 48 годин»

Завершение инцидента:

“Інцидент розв’язаний станом на 15:05 UTC. Тривалість: 55 хвилин. Я буду писати пост-морт і поділюся проектом для перегляду до кінця завтра»

---

Мова хронології подій

Часова шкала події є критичним артефактом - вона повинна бути точною про те, що сталося коли.

14:10 UTC — Зміна конфігурації розгорнута до виробництва (розгортання ID: 8294)»

• Нет, не надо 14:23 UTC — Перша попереджаюча сигналізація: рівень помилок аутентифікації перевищив 5% порог SLO
• Нет, не надо 14:28 UTC — Інцидент оголошений, командир інциденту призначений
• Нет, не надо 14:31 UTC — Початкова гіпотеза: витоку з’єднання під час розслідування
• Нет, не надо 14:48 UTC — Корінь причини підтверджено: новий розмір бази з’єднань (10) був недостатнім для пікового навантаження. Попереднє значення: 50
• Нет, не надо 14:52 UTC — початок відновлення
• Нет, не надо 15:05 UTC — Rollback complete, error rate returning to baseline (англійською)
• Нет, не надо 15:12 UTC — Сервіс повністю відновлений, інцидент вирішений

** Корисні прикметники та сполучники на часовій шкалі: **

• “Спочатку, інженер підозрював…”
• “Згодом стало ясно, що…”
• “В данном моменте, команда переключила внимание на…”
• “Паралельно, коммуникационный ведущий обновлял сторінку статуса.”
• “Причина не была установлена до 14:48…”
• “Незабаром після початку відновлення…”

---

Письма после смерти

Post-mortem (також називається ретроспективний, перегляд інциденту або перегляд навчання) є письмовим аналізом того, що пішло не так, чому, і що буде зроблено, щоб запобігти повторенню. Тон бездоганний — він аналізує системи і процеси, а не особистості.

Безупречная речь

** Обвинювати (уникнути): **

❌ «Інженер розгорнув неправильну конфігурацію.»

• Нет, не надо ❌ «Розробник забув перевірити параметри пулу з’єднань.»

** Бездоганний (використання): **

✅ “Зміна значення конфігурації без відповідної зміни в контрольному списку розгортання.”

• Нет, не надо ✅ “Параметри пулу з’ єднань на даний момент не включені в набір перевірки перед розгортанням.”
• Нет, не надо ✅ “Не було автоматизованої перевірки, яка б виявила неправильну конфігурацію до виробництва.”

Зміна полягає в тому, що від “хто” зробив щось до “які умови зробили це можливим”. Одне неправильно введене значення, що спричинило 55-хвилинний відключення, вказує на системний проміжок у перевірці — а не на особисту помилку.

Постмодернізм і мова

** Резюме (2-3 речення вгорі): **

«18 березня 2026 року служба автентифікації пережила 55-хвилинний відключення, викликаний зміною конфігурації, яка зменшила розмір бази даних. Інцидент вплинув на 100% користувачів, які намагалися увійти. Цей пост-мортний огляд факторів, що сприяють, хронології та елементів дій»

Секція удару:

«Інцидент вплинув на всіх користувачів, які намагалися автентифікуватися між 14:10 і 15:05 UTC — приблизно 55 хвилин»

• Нет, не надо «Засновано на обсязі спроб входу в той час дня, приблизно 12 000 спроб входу зазнали невдачі»
• Нет, не надо “Данные не были утрачены. Данные клиентов не были скомпрометированы. Служба повернулася до нормальної роботи без відновлення даних»

** Причина: **

« Основною причиною була зміна налаштувань, яка встановила розмір бази даних на 10, вниз від попереднього значення 50. Під час пікового навантаження (~400 запитів/сек), зменшений пул призвів до того, що всі доступні з’єднання були вичерпані, що призвело до відхилення нових з’єднань з помилкою тайм-аута

Внесок факторів (системний):

«Параметри пулу з’єднань можна налаштувати через сховище інфраструктури як коду, яке не має кроку перевірки, який перевіряє розміри пулу з’єднань проти очікуваного навантаження.»

• Нет, не надо «Стежинне середовище не відтворює обсяг виробничого трафіку, тому неправильна конфігурація не з’явилася до розгортання»
• Нет, не надо «Поріг попередження моніторингу для насиченості пулу з’єднань був встановлений на 95%, який не був досягнутий, поки служба вже не зазнала невдачі»

** Елементи дій: **

Записувати елементи дій як конкретні завдання, які можна призначати, з власниками і датами виконання:

« Додати насиченість пулу з’ єднань до списку передрозгортання: мінімальний розмір пулу має бути обґрунтовано у PR, якщо його змінено. » Власник: [назва]. Дата виходу: 25 березня 2007 року

• Нет, не надо “Оновлення генератора навантаження середовища для імітації пікового виробничого трафіку. Власник: [назва]. 5 квітня»
• Нет, не надо “Знизити поріг попередження про насиченість пулу з’ єднань з 95% до 70%. Власник: [назва]. Дата виходу: 20 березня 2014 року

---

Что делает хорошее пост-мёртвое

Аналіз п’ яти причин є поширеним способом для визначення корінних причин:

1. ** Чому ** користувачам не вдалося увійти? → Служба автентифікації повернула помилки.
2. ** Чому ** служба автентифікації повертає помилки? → З’ єднання з базою даних вичерпані.
3. ** Чому ** були вичерпані з’ єднання з базою даних? → Розмір бази даних було встановлено на 10 замість 50.
4. ** Чому ** розмір пулу було встановлено неправильно? → Зміна налаштувань була внесена без перевірки відповідності вимогам завантаження.
5. ** Чому ** не було перевірки? → У конвеєрі розгортання не існує автоматичної перевірки розміру пулу з’ єднань.

Результат: елемент дії не є « Перевірити параметри пулу з’ єднань перед розгортанням » (ручний процес), а є « Додати автоматичне перевірення розмірів пулу з’ єднань у CI/ CD ». Системні рішення, а не рішення людей.

---

Мова Runbook

Runbook — це покрокова інструкція щодо виконання звичайного завдання або відповіді на попередження. Ясність і точність є критичним - runbooks часто читаються під тиском під час інциденту.

** Принципи стилю Runbook: **

• Одна дія на крок
• Використовувати наказовий настрій (« Виконати наступну команду », а не « Наступну команду слід виконати »)
• Включити очікуваний вивід
• Включити дії, які слід виконати, якщо крок зазнає невдачі

** Приклад витягу з runbook: **

** Крок 3: Перевірка поточного налаштування пулу з’ єднань **

• Нет, не надо Виконайте наступну команду, щоб отримати дані про поточний розмір пулу зі сховища параметрів:
• Нет, не надо
• Баш aws ssm get- parameter — name « / prod/ db/ connection_ pool_ size » & # 160; …
• Нет, не надо Очікуваний вивід: значення має бути 50 (або вище). Якщо значення нижче 20, перейдіть до кроку 4 (аварійне перевищення). Якщо параметра не існує, перейти до команди з інфраструктури.
• Нет, не надо ** Крок 4: Застосувати перевищення аварійних налаштувань **
• Нет, не надо Якщо розмір пулу з’ єднань виявиться недостатнім, скористайтеся наступною командою для перевизначення параметрів. Ця зміна набула чинності негайно, без розгортання:
• Нет, не надо
• Баш aws ssm put- parameter — name ”/ prod/ db/ connection_ pool_ size” — value “50” — overwrite & # 160; …
• Нет, не надо Після застосування перевірте відновлення служби за допомогою моніторингу метрики насиченості пулу з’ єднань у Grafana (панель приладів: « Пул з’ єднань DB — виробництво »). Перед оголошенням відновлення служби, слід дати їй 2 хвилини на нормалізацію.

---

Словник звітів надійності

SRE регулярно представляють дані про надійність інженерному керівництву і бізнес-зацікавленим сторонам. Ось деякі фрази для різних ситуацій:

Доклад про хороші місячні:

«Ми підтримували 99,97% доступності цього місяця — набагато вище нашого 99,9% SLO. Бюджетне споживання помилки було 15%. ”

• Нет, не надо Кількість інцидентів зменшилася на 40% за квартал, а середній час розв’язання (MTTR) поліпшився з 47 хвилин до 22 хвилин

Скажу про важкий період:

«Цього місяця доступність впала до 99,85 % — нижче нашої мети 99,9 % SLO. Основним чинником були три інциденти в платіжній службі, всього 65 хвилин простою»

• Нет, не надо “Ми використали весь бюджет на помилку Q1 за перші шість тижнів. Команда працює в режимі надійності: немає нових функцій, поки ми не відновимо бюджет»

Представлення тенденцій:

«Тренд 28-денної доступності покращується з того часу, як ми впровадили шаблон автоматичного вимкнення в лютому»

• Нет, не надо «Затримка P99 постійно перебувала в межах SLO, але P99.9 перевищує поріг приблизно на 2% днів — є проблема хвостової затримки, яку ми ще не діагностували»

Встановлення очікувань:

“Міграція бази даних, запланована на наступний місяць, може призвести до 15-хвилинного переривання роботи. У нас є достатній бюджет помилок, щоб поглинути це, якщо ми знаходимося в вікні обслуговування»

• Нет, не надо «Якщо міграція пройде за планом, наша помилка бюджету на кінець місяця буде приблизно 60% залишилося.»

---

Швидкий довідник з словника SRE

Term	Meaning
SLI	Service Level Indicator — what you measure
SLO	Service Level Objective — your internal target
SLA	Service Level Agreement — your contractual commitment
error budget	Allowed unreliability = 100% − SLO
burn rate	Speed at which error budget is being consumed
toil	Manual, repetitive, automatable operational work
MTTR	Mean Time to Recovery/Resolution
MTTF	Mean Time to Failure
MTTD	Mean Time to Detect
runbook	Step-by-step guide for a repeatable operation or alert response
blameless post-mortem	Root-cause analysis focused on systems, not individuals
incident commander	Person coordinating the response during a live incident
SEV-1/2/3	Severity levels for incidents (SEV-1 = critical)
on-call rotation	Schedule determining which engineer responds to overnight alerts
chaos engineering	Intentionally injecting failures to test resilience
canary deployment	Gradual traffic rollout to reduce blast radius
blast radius	Scope of impact if a change or failure occurs

Точність, потрібна в мові SRE, відображає точність, потрібну в системах, в яких працюють SRE. Кожне слово в визначенні SLO з часом буде оскаржене; кожен крок у runbook з часом буде виконано о 3 годині ранку. Пишіть з огляду на цього читача.