SLI, SLO, SLA

Три літери, які керують продакшеном

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

Індикатор рівня обслуговування (SLI): вимірювання поведінки сервісу. Приклади: затримка запитів, частота помилок, пропускна здатність, глибина черги. SLI — це те, що можна відобразити на графіку.

Ціль рівня обслуговування (SLO): цільове значення або діапазон для SLI. Приклад: «99,9 % HTTP-запитів успішні за ковзний 28-денний період». SLO — це обіцянка, яку ви даєте собі та користувачам щодо прийнятної якості сервісу.

Угода про рівень обслуговування (SLA): договірне зобов’язання, зазвичай із фінансовими штрафами за порушення. Приклад: «Ми повертаємо 10 %, якщо місячна доступність падає нижче 99,9 %». SLA — це обіцянка, яку захищають юристи.

Критична відмінність: ваша SLA завжди має бути м’якшою за SLO. Якщо ви внутрішньо цільуєте 99,9 %, а зовні укладаєте договір на 99,9 %, у вас нульовий запас. SRE зазвичай встановлюють SLO на один дев’яток жорсткіше за SLA: ціль 99,95 %, договір 99,9 %. Цей зазор поглинає неминучий «поганий тиждень».

Бюджети помилок: Зворотне SLO

Від цілей надійності до інженерних рішень

SLO задає ціль надійності. Бюджет помилок — це те, що залишилось: кількість відмов, яку можна витратити, перш ніж не досягти цілі.

Якщо ваше SLO обіцяє 99.9% успішних запитів за 28 днів, ваш бюджет помилок становить 0.1% запитів, або приблизно 40 хвилин повного простою на місяць. Цей бюджет можна витрачати як завгодно: на планові релізи, експериментальні функції, chaos engineering або толерантність до нестабільної залежності.

Бюджети помилок змінюють конфлікт dev vs ops. Без бюджету кожна аварія призводить до суперечок про те, хто випустив погану зміну та як запобігти наступній. З бюджетом:

- Бюджет є: відправляйте швидше, ризикуйте більше, проводьте експерименти. Бюджет це оплачує.

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

Це перетворює надійність з емоційної суперечки на вимірюваний ресурс. Інженери можуть свідомо витрачати бюджет, як будь-який інший виробничий ресурс.

Визначення Toil

Що вважається Toil

Не кожне операційне завдання кваліфікується як toil. SRE визначає toil точно: робота, яка є ручною, повторюваною, автоматизованою, тактичною, позбавленою тривалої цінності та масштабується лінійно зі зростанням сервісу.

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

Приклади, які кваліфікуються як toil:

- Ручний перезапуск сервісу після крашу через витік пам’яті

- Вставлення фрагментів логів у чат-канал під час розбору інциденту

- Заповнення форми тікета для надання нової бази даних

- Ручне формування щоквартального звіту про потужності

- Поодиноке схвалення рутинних запитів на розгортання

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

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

Обґрунтування аудиту toil

Ваша команда відстежує, як витрачається її час. Минулого кварталу розподіл був таким: 30 % — розгортання, 25 % — реагування на інциденти, 20 % — робота з потужностями, 15 % — розробка функцій, 10 % — разові запити від продуктових команд.

Гігієна чергування

Інженери, а не пейджери

On-call несе реальну ціну. Сон порушується, вихідні перериваються, а стрес від невідомих проблем накопичується. SRE розглядає on-call як обмежений ресурс, який має залишатися стійким, а не як героїчний тягар для тих, кому найбільше не байдуже.

Здорові чергування on-call дотримуються кількох принципів:

- Компенсований час: години чергування конвертуються в відгули, доплату або іншу еквівалентну вигоду. Безкоштовний on-call призводить до вигорання команди.

- Розумна глибина чергування: команда з шести осіб, де є первинний і вторинний черговий, означає, що кожен інженер виходить на зміну раз на три тижні. Черги з двох осіб руйнують кар’єри.

- Бюджет на виклики: SRE-книга Google рекомендує максимум два виклики за дванадцятигодинну зміну. Якщо цей ліміт перевищено, команда має інвестувати інженерний час у зменшення кількості алертів, а не просто терпіти їх.

- Лише actionable-алерти: кожна сторінка має вимагати втручання людини. Якщо алерт ігнорують, автоматизують або він спрацьовує регулярно під час нормальної роботи — він не повинен існувати. Алертна втома є дефектом надійності.

- Follow-the-sun передача черг: глобально розподілені команди передають зміни на межах часових зон, щоб ніхто не отримував виклики о 3-й ночі, якщо система справді не може чекати до ранку.

Blameless Postmortems

Як інциденти перетворюються на покращення

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

Без звинувачень означає, що документ приписує збої системам і процесам, а не окремим особам. Якщо інженер виконав неправильну команду, постмортем запитує: чому система дозволила цю команду? Чому жоден захист не виявив її? Яка зміна системи, документації чи інструментів запобігла б наступному інженеру зробити ту саму помилку?

Беззвинувачувальна культура існує з однієї причини: люди приховують помилки, коли бояться покарання. Приховані помилки стають наступним інцидентом. Вартість беззвинувачувальної культури є низькою порівняно з вартістю накопичення нерозкритих дефектів.

Постмортеми зазвичай охоплюють:

- Підсумок: одноабзацний опис інциденту та його впливу

- Хронологія: покрокова реконструкція з мітками часу

- Аналіз кореневих причин: технічні та процесні фактори, що дозволили виникнення збою

- Виявлення: як команда дізналася про інцидент і скільки часу це зайняло

- Усунення: дії, вжиті для відновлення сервісу

- Висновки: що спрацювало, а що — ні

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

Пункти дій зберігаються в трекері. Вони пріоритезуються як будь-яка інша інженерна робота. Постмортеми без пунктів дій зводяться до розповіді. Робота нічого не змінює.

Чотири золоті сигнали

Що має вимірювати кожен сервіс

Книга Google SRE пропонує чотири сигнали, які має експонувати кожна сервісна служба, що взаємодіє з користувачами: затримка, трафік, помилки та насиченість. Разом вони описують стан служби з точки зору користувача. Моніторинг з меншою кількістю сигналів залишає «сліпі зони»; моніторинг із сотнями метрик перевантажує команду «втомою від алертів».

Затримка: скільки часу займають запити. Відстежуйте розподіли, а не середні значення. p50 (медіана) описує типовий досвід. p99 описує найгірший 1 % користувачів. Середнє значення приховує довгі «хвости»: служба з медіаною 50 мс і p99 5 000 мс виглядає нормально за середнім показником, але псує досвід одному користувачеві зі ста.

Трафік: навантаження на службу. Для веб-сервісу це запити за секунду. Для потокового сервісу — одночасні з’єднання. Для пакетного завдання — оброблені елементи за хвилину. Трафік корелює з рішеннями щодо ємності та виявляє аномалії навантаження.

Помилки: частота невдалих запитів. До них належать явні помилки (HTTP 500), неявні помилки (HTTP 200 з пошкодженими даними) та порушення політики (відповідь занадто повільна для SLO). Важливо розрізняти ці типи: відповідь 200 з некоректним payload часто шкодить користувачам більше, ніж чесна 500.

Насиченість: наскільки завантажена система. Використання CPU, глибина черги, тиск пам’яті, заповненість пулу з’єднань. Насиченість передбачає майбутню затримку: система на 95% CPU має дуже мало запасу, перш ніж затримка для користувачів різко зросте.

Більшість сповіщень SRE базуються на цих чотирьох сигналах. Сповіщення за симптомами (сповіщення, коли користувачі помітять проблему) ефективніші за сповіщення за причинами (сповіщення, коли CPU перевищує 80%). Чотири золоті сигнали описують симптоми.

Кар’єрні шляхи SRE

Де навички SRE оплачуються

Кар’єра SRE розгалужується залежно від того, яка частина дисципліни інженеру подобається найбільше:

SRE інфраструктури: будує платформи, на яких працюють інші команди. Kubernetes, service mesh, внутрішня хмара. Глибока системна інженерія, теорія розподілених систем і проєктування платформ. Дуже добре оплачується у великих компаніях, бо робота масштабується: один SRE інфраструктури підтримує сотні продуктових інженерів.

Embedded SRE: працює разом із продуктовою командою інженерів, щоб підвищити надійність конкретного сервісу. Наполовину інженер, наполовину коуч. Сильні комунікаційні навички та навички code review важливі так само, як і технічна глибина. Часто найкращий шлях для інженерів, які люблять викладати.

Інструменти надійності: будує стек observability: моніторинг, алерти, дашборди, інструменти для постмортемів, платформи управління інцидентами. Велика робота з фронтендом і data engineering. Результатами користуються всі інші команди.

Production engineering: термін Facebook/Meta для SRE, що фокусується на capacity, розгортанні та управлінні трафіком. Глибока робота з мережами та системами.

Технічні сертифікації, які варто мати: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional та сертифікації CNCF (Kubernetes Administrator, Kubernetes Application Developer) свідчать про знання cloud-native технологій. Сертифікації Linux Foundation демонструють глибину знань у системах. Жодна з цих сертифікацій не замінить портфоліо, але вони допомагають пройти первинний відбір рекрутерів.

Підсумок

Що ви тепер знаєте

Інженерія надійності сайтів виникла як відповідь Google на проблему масштабування і перетворилася на дисципліну, яку тепер застосовують у всій галузі. Ви ознайомилися з:

- Переходом від ручних операцій до інженерної надійності

- SLI, SLO, SLA та концепцією error budget (оберненої до SLO)

- Визначенням toil, правилом 50 % і зменшенням toil через інженерні рішення

- Сталими чергуваннями on-call та практикою беззвинувачувальних постмортемів

- Чотирма золотими сигналами як відправною точкою для моніторингу сервісів

- Кар’єрними треками SRE та сертифікаціями, які відкривають двері

Дві ідеї найважливіші. Надійність — це число, узгоджене заздалегідь. І toil — це дефект, а не опис посади. Тримайте ці дві ідеї, і все інше в SRE випливає природно.

Рекомендоване читання: книга Google SRE (безкоштовно онлайн: sre.google/books/), SRE Workbook для практичних вправ і матеріали Charity Majors про observability. Урок «geometry-of» глибше розглядає візуальну структуру, що лежить в основі практики SRE: розподіли затримок, конуси error budget, графіки залежностей і макети дашбордів.