Як надійність систем впливає на досвід користувачів. Досягаємо доступності за допомогою SLO

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт! Мене звати Данііл, і сьогодні я хочу поділитися думками про надійність сервісів та зробити акцент на її сприйнятті кінцевими користувачами. Впевнений, багато з вас стикалися з дилемою, що взяти в роботу — нові фічі, які потрібні бізнесу, чи технічну досконалість, якої прагнуть інженери? Чи можуть SLO допомогти розв’язати ці проблеми?

Перш ніж ми зануримось у тему, дозвольте розповісти трохи про себе і чому ця тема мене так цікавить. Зараз я працюю Engineering Manager в Teya, фінтех-стартапі, місія якого — надавати малому бізнесу в Європі найкращу фінансову платформу. Я підтримую бекенд-команди, які займаються еквайрингом, де, як ви можете здогадатися, надійність є критично важливою.

До Teya я працював у Meta (раніше Facebook), де також підтримував бекенд-команди під час підготовки запуску нової платформи електронної комерції в екосистемі застосунків Meta. Забезпечення найвищих стандартів надійності перед запуском стало моїм ключовим пріоритетом і з цього часу моя пристрасть до надійності тільки зростала.

Почнемо з основних термінів.

Основна Термінологія

Надійність (Reliability) — здатність системи виконувати свої функції так, як очікується, коли це потрібно. Це не просто про час роботи системи, а про задоволення очікувань користувачів, яке потрібно ставити на перше місце, адже ми створюємо продукти саме для них. Якщо система швидко видає помилки, люди не будуть задоволені. Але як це виміряти?

Індикатор Рівня Обслуговування (Service Level Indicator, SLI) — кількісний показник надійності сервісу, який відображає, наскільки добре він виконує свої функції в певному аспекті. Наприклад, у швидкості відгуку (latency). Цей показник має тісно корелювати із задоволенням користувачів. Можна уявити це як відсоток «успішних» подій серед усіх «валідних» подій.

Ціль Рівня Обслуговування (Service Level Objective, SLO) — цільове значення для SLI, яке встановлює допустимий рівень продуктивності сервісу. Наприклад, SLO може вимагати, щоб доступність сервісу перевищувала 99.9% або щоб 99% запитів виконувались менше ніж за три секунди. У цьому випадку 99% — це SLO, а три секунди — поріг. Правильно визначене SLO чітко встановлює межу: якщо її дотримано, користувачі задоволені. Якщо межа постійно порушується — вони скаржаться або навіть перестають користуватись сервісом.

Угода Рівня Обслуговування (Service Level Agreement, SLA) — юридичний договір між постачальником послуг і його клієнтами, що визначає санкції за недотримання SLO. Однак SLА більше стосується юридичних зобов’язань, ніж повсякденної роботи в рамках Site Reliability Engineering (SRE).

Бюджет на Помилки (Error Budget) — це допустимий рівень ненадійності, який обчислюється як 100% мінус SLO. Прочитайте це ще раз. SLO припускають певну кількість допустимих збоїв. Наприклад, якщо ваше SLO щодо доступності становить 99%, це означає, що 1% запитів може не виконатися в межах вашого бюджету на помилки. Цей бюджет можна і треба! використовувати для експериментів або інновацій. Ідеально, якщо його буде використано повністю в певний часовий період.

Вікно Бюджету на Помилки (Error Budget Window) — період, протягом якого вимірюються SLO та бюджет на помилки. Він може бути фіксованим, наприклад, за тиждень або місяць. Або плаваючим, наприклад, останні 14 днів. Фіксоване вікно добре підходить для внутрішніх репортів, водночас плаваюче вікно краще відображає постійний досвід користувачів, адже їх довіра користувачів не відновлюється миттєво з початком нового місяця. Щоб правильно визначити це вікно, треба розуміти поведінку користувачів.

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

Швидкість Витрачання (Burn Rate) — це швидкість, з якою витрачається бюджет на помилки. Якщо швидкість дорівнює 1, це означає, що бюджет буде повністю витрачено до кінця періоду. Що є ідеальним результатом. Якщо швидкість менша за 1, у вас є додатковий простір для експериментів. Якщо ж вона перевищує 1, ви ризикуєте витратити бюджет завчасно, що може призвести до проблем із сервісом.

Чому SLO важливі

SLO є вирішальними для прийняття рішень на основі даних, які дозволяють збалансувати технічну досконалість із новою розробкою. Правильно визначені SLO відображають задоволеність користувачів; постійне їх порушення означає, що ви постійно розчаровуєте користувачів. Це робить SLO потужним інструментом для пріоритизації, гарантуючи, що критичні проблеми вирішуються перед менш важливими покращеннями. Очевидно, нікому не потрібна нова функція на тридцять п’ятому екрані додатка, якщо найбільш використовувана функція відпрацьовує вічність.

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

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

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

З чого почати

Добре, сподіваюся, до цього моменту ви вже вирішили, що SLO стане вашим наступним пріоритетом. Чудово! Але з чого почати? Що робити? Є багато варіантів визначення SLO. Іронія в тому, що дуже мало з них дійсно працюватимуть.

Основне, що потрібно для початку роботи з SLO, це три речі (ну, можливо, чотири): метрика, цільове значення, вікно та інколи поріг. Отже, як їх обрати?

Вибір метрики

Вибір правильних метрик для моніторингу — це перший крок у впровадженні SLO. Пріоритезуйте метрики, які:

Прямо відображають задоволеність користувачів

Метрики повинні мати чіткий і лінійний зв’язок із задоволенням клієнтів. Це основа успішності цього завдання. Які найважливіші функції надає сервіс для користувачів? У світі платежів це здатність швидко та надійно виконати транзакцію. У світі електронної комерції — можливість придбати товар. І так далі. Як бачите, передумовою цього кроку є розуміння бізнесу та його клієнтів. Що вони роблять і чого хочуть? Коли ви знайдете відповіді на ці питання, вибір правильної метрики стане простішим.

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

Корелюють зі збоями

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

Забезпечують чіткі сигнали

Уникайте метрик з великим шумом; дані повинні надавати дієві інсайти.

Є кілька загальних метрик, які можуть бути хорошою відправною точкою залежно від типу вашого сервісу.

Сервіси, орієнтовані на запити:

• Доступність. Частка коректних успішно оброблених запитів. Це вимірює час безперебійної роботи системи.
• Затримка. Частка запитів, оброблених за певний пороговий час, що вказує на швидкість системи.
• Якість. Частка запитів, оброблених без деградації, що забезпечує стабільну якість сервісу.

Сервіси обробки даних:

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

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

Важливо не обирати всі метрики одразу. Оберіть одну, максимум дві, і почніть з цьогоі поступово удосконалюйтесь. Як казав Вінс Ломбарді:

Людина, яка стоїть на вершині гори, не впала туди з небес.

Ще одне цікаве питання — як визначити «коректні» запити та «успіх» для доступності, наприклад. Як відправну точку можна використовувати кількість помилок 5xx із усіх запитів. Але з часом ви відкриєте багато цікавих питань про природу цих помилок і як їх рахувати. Єдине, будь ласка, не ускладнюйте все з самого початку.

Визначення цільового значення

Концепція надійності часто обертається навколо кількості «дев’яток» (наприклад, 99.9%, 99.99%). Однак прагнути до 100% надійності є недоцільним і зазвичай неправильним. Як сказав Бен Трейнор Слосс, засновник SRE у Google, 100% — це неправильна мета надійності практично для всього.

Натомість краще зосередитись на встановленні реалістичних та досяжних SLO, які узгоджуються з очікуваннями користувачів і цілями бізнесу. Як знайти це ідеальне значення? Не здивуєтеся, почувши ту саму пораду, що й у попередньому розділі — ітеруйте! Адже вибір неправильного числа кращий, ніж вибір жодного.

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

Якщо у вас є історичні дані, використовуйте їх для визначення початкової цілі. Якщо ні, почніть з двох або трьох «дев’яток», залежно від зрілості сервісу. І не забувайте ітерувати, збираючи більше даних та інсайтів.

Додавання ще однієї «дев’ятки» часто призводить до значного зростання витрат, причому ціна за додаткову надійність зростає майже експоненційно. Завжди корисно оцінювати, чи виправдані ці витрати з погляду цінності, яку це приносить бізнесу.

Підсумок

У сфері розробки програмного забезпечення пошук балансу між надійністю сервісу та швидкими інноваціями — складне завдання. Цілі рівня обслуговування (SLO) є важливими для управління цим конфліктом. Визначаючи та вимірюючи SLO, організації можуть гарантувати, що прагнення до швидкої розробки не компрометує надійність їхніх сервісів. SLO забезпечують структуровану основу для підтримки надійності, водночас пріоритизуючи задоволеність користувачів і залишаючи простір для інновацій.

Встановлення SLO — це ітеративний процес. Краще почати з недосконалої цілі та з часом її вдосконалити, ніж зовсім уникати встановлення цілей. Цей підхід дозволяє командам збирати дані, вчитися на досвіді та робити покращення поступово.

Практичний план

• Визначте критичні шляхи користувача. Зосередьтеся на найважливіших взаємодіях користувачів із вашим сервісом. Визначте ключові області, де надійність є критично важливою.
• Визначте SLI. Оберіть метрики, які найкраще відображають надійність цих критичних шляхів. Переконайтеся, що вони вимірювані та значущі. Як було сказано вище, для сервісів, орієнтованих на запити, доступність і затримка зазвичай є безпрограшним підходом, тож є сенс почати саме з них.
• Встановіть SLO. Встановіть реалістичні цілі для вибраних SLI, зважаючи на очікування користувачів і цілі бізнесу. Проаналізуйте історичні дані, якщо вони є. Якщо нема нічого, просто зробіть припущення. 99% або 99.9% мають працювати як відправна точка.
• Створіть публічний документ. Опишіть, що і як ви плануєте вимірювати. Покладіть це кудись в загальнодоступний спейс, щоб інші команди так само мали можливість бачити й надихатися вашими успіхами. За нагоди заохочуйте інших долучатись до цього процесу.
• Моніторте та вдосконалюйте. Постійно відстежуйте SLI й порівнюйте їх із SLO. Використовуйте ці дані для прийняття обґрунтованих рішень та стимулювання покращень. Це повинно стати ще одним вашим ритуалом, як дейлі або ретро (не в тому сенсі, що це перше, що скіпається, коли немає часу!). Дуже класним наступним кроком стане традиція робити випробування потужності (capacity tests) для файн-тюнингу SLO.
• Комунікуйте та узгоджуйте. Переконайтеся, що всі зацікавлені сторони розуміють SLO та їхню важливість. Узгодьте зусилля організації з досягнення цих цілей.

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