Vocabulary for Site Reliability Engineers
Основні слова SRE пояснені простою англійською: SLO, error budget, toil, blameless postmortem, runbook і багато інших — з прикладами використання.
Сайт Reliability Engineering (SRE) має свій власний окремий словник - суміш традиційної термінології операцій, концепцій, що походять від Google, і мови програмного забезпечення. Для не-англомовних носіїв англійської мови, які переходять на ролі SRE або працюють разом з командами SRE, оволодіння цим словником є необхідним як для щоденного спілкування, так і для кар’єрного росту.
Цей посібник містить основні слова SRE з чіткими визначеннями, прикладами використання і нотатками щодо використання кожного з цих термінів на практиці.
Концепція рівня обслуговування
Індикатор рівня обслуговування (англ. Service Level Indicator, SLI)
SLI є специфічною метрикою, яка вимірює аспект надійності сервісу — наприклад, частка успішних HTTP-запитів, або частка запитів, які обслуговуються протягом 200 мс.
- “Наша основна SLI для служби оплати - це рівень успішності запитів на оплату.” *
- “Ми відстежуємо три SLI: доступність, затримку і частоту помилок.” *
Сло́ва (словен
** SLO ** — це цільове значення або діапазон для SLI — ціль надійності, до досягнення якої ведеться робота вашої команди.
“Наша SLO - 99,9% доступності, виміряна протягом 30-денного вікна.”
- “Ми пропустили наш SLO третій місяць поспіль, що викликало перегляд надійності.” *
Договору про рівень обслуговування (SLA)
** SLA ** це формальним договором з клієнтом, який визначає очікуваний рівень обслуговування і наслідки його відсутності. На відміну від SLO (внутрішня ціль), SLA має юридичні і фінансові наслідки.
“Наші корпоративні клієнти мають SLA, що гарантує 99, 95% часу роботи. Порушення цього запускає сервісний кредит».
** Ключове відмінність, яку слід запам’ятати: **
- SLI = те, що ви вимірюєте
- SLO = те, що ви націлюєте
- SLA = те, що ви обіцяєте клієнтам
Бюджетні помилки
Помилка бюджету
** Бюджет помилок ** — це кількість перерв або помилок, які ви можете мати, не порушуючи при цьому вашого SLO. Якщо ваш SLO має доступність 99, 9%, ваш бюджет помилок становить 0, 1% — близько 43 хвилин простою на місяць.
“Ми витратили 60% нашого бюджету на помилки цього місяця — нам слід сповільнити ризиковані розгортання.”
“Бюджет помилок дає нам можливість, на основі даних, вирішувати, наскільки ризикувати з новими випусками.”
Помилка Бюджет швидкості запису
** Частота запису ** описує, наскільки швидко ви використовуєте ваш бюджет помилок відносно очікуваної швидкості.
“Ми споживаємо наш бюджет на помилки втричі швидше, ніж очікувалося — якщо це продовжиться, ми вичерпаємо його за десять днів.”
Оперативні концепції
Toil
** Робота ** це ручна, повторювана, автоматизована операційна робота, яка не додає тривалої цінності. Зменшення праці є основним принципом SRE.
“Перезапуск служб вручну після кожного розгортання є чисто фізичною працею — нам потрібно автоматизувати це.”
“Команда SRE відстежує робочі години кожного кварталу і намагається зберегти їх нижче 50% інженерного часу.”
Runbook
** Runbook ** це документована процедура для обробки певного операційного сценарію — зазвичай, інциденту або рутинного завдання.
“Якщо затримка платіжної служби перевищує 2 секунди, виконайте інструкції з Runbook у Confluence, щоб діагностувати і розв’ язати проблему.”
“Ми автоматизуємо частини Runbook, щоб інженери, які працюють на виїзді, витрачали менше часу на повторювану діагностику.”
Playbook
** Playbook ** схожий на Runbook, але зазвичай включає більш широкий спектр сценаріїв або стратегію реагування на інцидент вищого рівня.
“Справочник по инцидентам безопасности определяет маршрут эскалации и протокол связи для нарушений данных.”
Інциденти і рецензії
Безсмертний Постмортем
** Безвинний постмортем ** це структурований огляд інциденту, який зосереджується на системних причинах, а не на окремих помилках. Цель - учиться и совершенствоваться, а не возлагать вину на кого-то.
“После отключения, мы провели безупречную аутопсию и выявили три процесса, которые способствовали инциденту.”
“Невинна культура є необхідною - люди не будуть повідомляти про майже промахи, якщо вони бояться покарання.”
Середній час відновлення (MTTR)
** MTTR ** — середній час, який знадобиться для відновлення роботи після аварії.
“Наша MTTR для інцидентів P1 наразі становить 47 хвилин — ми прагнемо досягти менше 30 хвилин до кінця кварталу.”
Середній час між відключеннями (MTBF)
** MTBF ** — середній час між аваріями. Вищий MTBF вказує на більшу надійність.
“Збільшення MTBF вимагає усунення повторюваних помилок, а не просто швидшого відновлення.”
Архітектура і будівництво
Інженерія хаосу
** Хаосна інженерія ** це практика навмисного введення помилок в систему для перевірки її стійкості.
- “Ми проводимо хаотичні експерименти в стадії, щоб перевірити, що наші автоматичні виключники поводяться правильно в умовах аварії.” *
Планування потужностей
** Планування обсягів ** передбачає майбутні потреби у ресурсах на основі прогнозів зростання і поточного використання.
“Залежно від темпів зростання нашого трафіку, нам доведеться подвоїти обсяг бази даних до 4-го кварталу — планування обсягу слід розпочати зараз.”
В дежурстве
Бути ** на гарячому ** означає бути доступним поза звичайними годинами для реагування на інциденти.
“Я на цій тижні на гарячій лінії — моє SLA для реагування на інциденти P1 становить 15 хвилин.”
Ключовий словниковий запас
| Term | Definition |
|---|---|
| SLI | The metric you measure (e.g., success rate) |
| SLO | The target for that metric (e.g., 99.9%) |
| SLA | The customer-facing commitment |
| Error budget | Allowable downtime within the SLO |
| Toil | Manual, repetitive, automatable work |
| Runbook | Step-by-step procedure for a specific scenario |
| Blameless postmortem | Incident review focused on systemic causes |
| MTTR | Average time to recover from an incident |
СРЕ лексика є точною за дизайном - ці терміни мають конкретні значення, які дозволяють точно повідомляти про надійність. Навчання правильному використанню цих засобів допоможе вам робити внесок у обговорення SRE, писати чіткіші звіти про інциденти і працювати ефективніше з командами, які зосереджені на надійності.
Національна мова: мова, що використовується для спілкування між ненаціональними групами
Основні концепції Site Reliability Engineering - Service Level Objectives (SLOs), бюджети помилок, зменшення праці - часто виражаються дуже конкретною, майже технічною англійською. Це зрозуміло; точність є життєво важливою, коли справа доходить до стабільності та продуктивності системи. Однак, для розробників, чия перша мова не є англійською, це може бути приголомшливо, що призводить до непорозумінь або неохоче вносити ефективний внесок. Цей розділ присвячений усуненню цього розриву, підкреслюючи спільні варіації фразування і пропонуючи практичні стратегії для інтерпретації і впевненого використання термінології SRE.
Однією з ключових областей є розуміння різниці між описовою і преписовою мовою. Спочатку ви можете почути такі фрази, як «Ми повинні зменшити працездатність» - це звучить директивно. Але більш корисним може бути таке формулювання: « Давайте дослідимо способи мінімізації повторюваних вручну завдань, які відволікають від активних поліпшень системи ». Аналогічно, заява про SLO не лише про числа; це про досвід користувача. Сказати «99,9% часу роботи» технічно точно, але пояснювати * чому *, що час роботи має значення - «Це перекладається на приблизно 43 хвилини простою на місяць, що безпосередньо впливає на наших користувачів і їх здатність виконувати критичні завдання» - дає важливий контекст. Іншою частою областю для плутанини є звинувачення. Концепція «безвинного постмортуму» не стосується приписування вини; це стосується вивчення інцидентів без судження. Фрази на кшталт «Що ми можемо зробити по-іншому наступного разу?» є набагато продуктивнішими, ніж обвинувальні висловлювання.
Крім того, зверніть увагу на тонкі відмінності в тому, як передається невідкладність. Фраза «невідкладно» часто має сильний емоційний відтінок. Замість того, щоб казати, що щось є «невідкладним», спробуйте сформулювати це як «вимагає негайної уваги» або «вплине на критичні операції». Це уникає непотрібної паніки і дозволяє більш раціонально оцінювати ситуацію. Також важливо розуміти, що прямі переклади технічних термінів можуть вводити в оману. Наприклад, «масштабування» не завжди означає швидке зростання; це просто означає пристосування до змінних вимог.
І, нарешті, не вагайтеся попросити про пояснення. Команди SRE загалом цінують активних учнів, які справді зацікавлені в розумінні основних принципів. Просте запитання, наприклад, «Чи можете ви розібратися, що означає «планування можливостей» в цьому контексті?» демонструє залученість і бажання навчатися - якості, які високо цінуються в середовищі SRE.
# Example: Monitoring CPU usage with Prometheus and Grafana
# This is a common scenario discussed when reviewing performance metrics.
grafana_query='{
"query": "sum(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)",
"title": "CPU Usage - Node Instance"
}'