SRE (Site Reliability Engineering) — це підхід до управління ІТ-інфраструктурою, який популяризував Google. 2003 року компанія виявила, що традиційні методи не відповідають потребам їхньої вебінфраструктури, і винайшла свій. Основні принципи SRE передбачають автоматизацію процесів, вимірювання та аналіз рівня надійності, стратегії моніторингу, план реагування на інциденти тощо.
Практики SRE швидко стали популярними: їх почали інтегрувати різні команди, змінюючи та налаштовуючи під себе. Netflix, Dropbox, Facebook, Uber, LinkedIn та багато інших — SRE-практики допомагають цим сервісам забезпечити безперебійну роботу за високих навантажень та швидко відновлюватися у разі збоїв. Google та інші бізнеси детально описують ці принципи. Проте без прийняття культури й мислення, що лежать в основі SRE, у бізнесів просто з'являтимуться нові співробітники та процеси без вагомих результатів.
У цьому матеріалі ділимося ключовими підходами SRE. Для ілюстрації застосування цих практик ділимося кейсом компанії Preply, про який розповів Олексій Остапець, Senior Site Reliability Engineer в Preply на конференції DevOps fwdays'24, що відбулася у лютому в просторі Genesis Space. Він прокоментував, як розвивати інженерну культуру команди та сприймати інциденти не як технічні збої, а справжні бізнес-події, які потребують розумного вирішення.
> Вимірювання доступності
> Від 99,9 до 99,99: кейс Preply
> Ключові метрики SRE
> Як зменшити MTTR. Алгоритм відповіді на інциденти
> Побудова культури
> Попередження інцидентів
Вимірювання доступності
Чи може сервіс бути доступним на 100%? Методика SRE передбачає, що уникнути збоїв — неможливо. Стабільність систем зазвичай оцінюють у кількості «девʼяток»: 99%, 99,9%, 99,99% тощо. Так, 99% передбачає 128 хвилин години недоступності (даунтайму) на тиждень, а 99,999% — всього 6 секунд.
Також доступність може вимірюватися не у часі, а, наприклад, за кількістю запитів. У будь-якому випадку структура формули однакова: успішні одиниці / загальна кількість. Незалежно від способу вимірювання, результат буде у відсотках, які округляють до девʼяток. Показник доступності може також враховувати додаткові критерії. Наприклад, компанія визначила правило, за яким система має відповідати користувачу швидше ніж за 600 мс. Якщо затримка перевищує це значення, можна вважати, що система не працює.
Рівень доступності, який встановлює компанія, залежить від її цілей та пріоритетів. Здавалося б, варто прагнути якомога більшої кількості девʼяток. Проте виявляється, що висока надійність має свою ціну: максимальна стабільність обмежує швидкість розробки нових фічей і доставки користувачам, а також різко підвищує їхню вартість. Водночас користувачі можуть навіть не помітити різниці, адже у взаємодії присутні менш надійні компоненти, такі як стільникова мережа або пристрій, з яким вони працюють. «Користувач смартфона, надійного на 99%, не може відрізнити надійність обслуговування на 99,9% і 99,999%», — йдеться в інструкції Google.
Хоча абсолютна доступність неможлива, галузь зазвичай визначає досить високі значення. У найпопулярніших глобальних продуктів цей показник варіюється в межах 99.99%.
Компанії, які пропонують складніші технологічні сервіси, такі як хмарні сховища, визначають доступність на рівні пʼяти девʼяток (99,999%) і вище, наприклад, певні сервіси Google Cloud Platform, Amazon Web Services, Azure Cosmos DB. Серед них є Amazon S3 з режимом «11 дев'яток» доступності.
Від 99,9 до 99,99: кейс Preply
Preply — це платформа для репетиторів та студентів усього світу, на якій проводиться мільйони уроків щомісяця. Команда вносить чимало змін до продукту: на 120 інженерів припадає близько 100 релізів на день, тому періодичні баги та збої є природними. «За останній календарний рік у нашій системі трапилося 138 інцидентів, які наші клієнти відчули на собі, — ділиться Олексій Остапець, Senior Site Reliability Engineer в Preply. — Чи можна цю ситуацію покращити? Як варіант — перестати релізити код, однак ми живемо в інших реаліях. Користувачі очікують постійних оновлень та нових фіч, отже ми мусимо експериментувати. Отже, навчилися швидко відновлюватися і робити висновки».
$63 000 — стільки склали фінансові втрати компанії за останній рік лише через інциденти. Іншими словами, стільки обходиться та швидкість розробки, яку вона підтримує. Пʼять років тому команда не оцінювала фінансовий вплив, проте розуміє, що раніше ця цифра була в десятки разів більша. 2019 року, під час Covid-19, у світі вибухає тренд на онлайн-навчання, і Preply починає швидко зростати. На той час у системі було 20 моніторів, платформна команда складалася з двох людей, які кожну другу ніч отримували OnCall-дзвінки через інциденти. Доступність сервісу складала 99,9%, що еквівалентно 45 хвилинам недоступності на місяць.
Тоді компанія почала розвивати SRE-практики: аналізувати кожен інцидент, ділитися висновками (так званими постмортумами), рахувати фінансові втрати та вплив на користувачів, оновлювати процеси та безперервно покращувати їх, а також інвестувати у розвиток інженерної культури команди. Нині у системі працюють вже тисячі моніторів, у команді є налагоджені процеси. Більшість інцидентів закриваються продуктовими командами у значно коротший термін. Попри кількість щоденних релізів та кратне зростання команди, доступність сервісу складає 99,99%, що еквівалентно 4,5 хвилинам недоступності на місяць.
«Найголовніше, що ми зрозуміли за кілька років розвитку SRE-практик, — інциденти все одно трапляються. Варто сприймати кожен з них, як подію, коли ми можемо зробити висновки, навчитися та оновити процеси. Якщо у вас давно не було інцидентів, — це підозріло. Напевно ви регулярно робите зміни до продукту, на вас здійснюють DDOS-атаки та полюють баунті-хакери. Скоріше за все, у вас просто недостатньо розвинуте бачення системи (так зване observability)», — пояснює Олексій.
Ключові метрики SRE
Завдання SRE — не просто максимізувати час безвідмовної роботи, а збалансувати ризик недоступності з цілями швидкого впровадження інновацій. Якщо ви дбатимете лише про стабільність, тоді випуск нових фічей та інновацій припиняться. Тож як визначити, коли найкращий час для нових релізів, а коли варто зосередитись на технічному боргу та покращенні стабільності системи?
Команда Google, розробляючи методику, хотіла визначити точний показник вимірювання доступності. Так зʼявилося поняття SLO (Service Level Objective), на якій ґрунтується уся робота над стабільністю системи. Це конкретна мета, яку організація встановлює для якості своїх послуг. Наприклад, 99.9% аптайму за місяць або відгук сервера не довше ніж 5 мс.
Ця метрика не має бути захмарною, так само як не варто гнатися за «девʼятками». «Надмірна доступність стала очікуванням, що може призвести до проблем. Не робіть свою систему надто надійною, якщо досвід користувача не вимагає цього, — пояснює команда Google. — Визначте найнижчий рівень надійності, прийнятний для користувачів кожної служби, а потім вкажіть це як свій SLO».
«Внутрішні SLO дають командам розуміння відповідальності за свій домен, за користувачів, для яких вони релізять фічі, — це ключовий фактор попередження інцидентів. Це змушує команди робити певні висновки та відповідально підходити до змін», — ділиться Олексій.
SLI (Service Level Indicator) — це метрика, яку використовують для вимірювання рівня якості послуг. Це фактичні дані, які вказують, наскільки добре або погано функціонує система.
SLA (Service Level Agreement) — це угода з клієнтом, в якій ви гарантуєте стабільне дотримання певної метрики. В ній також встановлюються штрафи за невиконання цього показника. Часто SLA може бути нижчим за SLO — наприклад, компанія визначила як мету швидкість відповіді у 5 мс, але перед користувачами гарантує швидкість не менше 10 мс, щоби мінімізувати фінансові втрати.
Ці метрики лягають в основу поняття Error budget. Бюджет помилок — це час, протягом якого ви готові дозволити своїм системам не працювати на користь релізів нових фічей та інновацій.
Наприклад, Preply встановила SLO на рівні 99,99% доступності системи, що означає, що недоступність не має складати більше ніж 4,32 хвилини на місяць. Доки ліміт не перевищено, команда може релізити нові фічі, ризикувати та фокусуватися на швидкості розробки. «Якщо ми виходимо за Error Budget, команда домовляється з менеджментом, що працюватиме над покращенням стабільності системи протягом наступного спринту», — пояснює Олексій.
З цими метриками має працювати кожна команда та стейкхолдери, інакше вони не зможуть прийняти важливі рішення, чи потрібно зробити продукт більш стабільним, чи дозволити більшу швидкість розробки. У такий спосіб команда розробки продукту стає самоконтрольованою. Вони знають бюджет і можуть керувати ризиками.
Щоби зрозуміти та спланувати бюджет помилок, практики SRE передбачають дві додаткові концепції:
MTBF — загальний час безвідмовної роботи / кількість відмов. Це середній час між збоями.
MTTR — загальний час простою / кількість відмов. Це середній час відновлення після збою.
Ці показники можна обчислити історично (наприклад, за останні 3 місяці або рік). Наприклад, у компаній встановлений SLO 99,9%, який дозволяє 43,2 хв недоступності на місяць. Її історичний MTBF складає 10 днів, а історичний MTTR — 30 хв. Тоді команда може розрахувати очікувану недоступність у 90 хвилин на місяць ((30 днів / 10 днів) * 30 хвилин).
Це виходить за межі цільового показника, значить команда має зменшити MTBF або MTTR — тобто подбати, щоби збої траплялися рідше (випускати менше релізів) або швидше відновлюватися. Для цього потрібен алгоритм відповіді на інцидент, який ми розглянемо далі.
Як зменшити MTTR. Алгоритм відповіді на інциденти
Команда Google пропонує алгоритм дій для реагування на інциденти, який передбачає такі кроки:
Виявлення інциденту — проблеми або порушення в роботі системи.
Оцінка впливу інциденту на користувачів та бізнес-процеси.
Аналіз та діагностика проблеми.
Відновлення сервісу.
Пошук кореневої причини інциденту та її виправлення.
Рефлексія (аналіз ефективності заходів, їхнього впливу на систему, випуск постмортума).
Висновки та вдосконалення — впровадження поліпшень для покращення майбутнього реагування на подібні інциденти.
Важливо здійснити перші чотири кроки якнайшвидше, адже саме цей проміжок часу визначає MTTR. Цей механізм має бути відпрацьованим командою до автоматизму. Після того, як буде відновлено систему, команда може спокійно працювати над виправленням помилок, адже витрати error budget вже зупинено.
«Альтернативою ролбеку може бути перемикання функціонала — так звані feature-switchers. У нашій команді розвинена культура експериментів, тому всі зміни реалізовані під так званими прапорами, які можна масштабувати на певну кількість користувачів і відключити частину функціонала сайту або застосунку», — каже Олексій.
На його думку, важливо фіксувати усі (навіть незначні) інциденти. Навіть якщо ці edge-кейси побачили всього тисяча користувачів, все одно варто проаналізувати вплив. Якщо знаходять корисні інсайти, ними діляться з командою та закривають відповідні прогалини в моніторингу або end-to-end тестах. Як правило, на кожному постмортумі SRE-команда Preply генерує одну або дві першочергові задачі, щоби запобігти подібним проблемам у майбутньому, та декілька другорядних.
Побудова культури
На думку Олексія, працюючи над практиками реагування на інциденти, бізнес має сфокусуватися на трьох аспектах: розвитку навичок, налагодженні інструментів та найголовніше — побудові відповідної інженерної культури.
Комунікація є важливою частиною в ефективному менеджменті інцидентів. «Як правило, коли трапляється інцидент, розробники не хочуть ділитися цим публічно та брати на себе відповідальність. Натомість вони займають позицію очікування. Ми мусимо зламати цю «стіну» і показати, як добре робити висновки та оновлювати процеси, аби проблеми не повторювалися» — стверджує він.
Ще більший страх у розробників викликає механізм відкату. Філософія Google полягає в тому, щоб сприймати це, не як факап, а як нормальну процедуру, необхідну для повернення стабільності системи. «Ми зрозуміли, що немає успішного розгортання, якщо у вас не підготовлений відповідний відкат», — йдеться в інструкції Google.
Так, щоби закріпити вищенаведений алгоритм та розвивати відповідну культуру, в Preply практикують низку тренінгів, зокрема симуляції інцидентів. У ньому бере участь невелика група інженерів, які мають реагувати на реальний інцидент у продакшені. «Ми створюємо окремий ротейшн на учасників тренінгу і генеруємо помилки від імені певної кількості користувачів у системі (ендпойнти або бекграунд-задачі). Далі тригериться інцидент, і ми переходимо до відпрацювання алгоритму: організовуємо дзвінок, розподіляємо ролі, проводимо дослідження і звичайно здійснюємо ролбек», — ділиться Олексій.
За його словами, головний ефект таких тренінгів — прокачка базових навичок, потрібних під час реальних інцидентів та подолання страху здійснити відкат. «Цю практику ми проводимо вже понад два роки, і зараз більшість інцидентів швидко закриваються командами з мінімальним впливом на користувачів, — розповідає він. — Якщо раніше інженери боялися брати відповідальність та довго дискутували: в чому проблема, як її виправити, підготуймо фікс, то тепер вони мислять в інший спосіб. Зʼявилася проблема, — усі знають, що її треба усунути якомога швидше, і знають, як це зробити».
Попередження інцидентів
Чи можна попередити інциденти у системі? Погана новина — ні. Хороша новина полягає в тому, що їх і не треба попереджувати. Цікаву практику описує команда Google Cloud: вони власноруч впроваджують періодичні даунтайми в деяких службах, щоб уникнути надмірної доступності. «Ми виявили, що ця практика допомагає виявити служби, які використовують ці сервери неналежним чином. Маючи цю інформацію, можна перемістити робочі навантаження в більш слушне місце та підтримувати належний рівень доступності серверів», — стверджують вони.
Для пошуку слабких місць та вразливостей команда Netflix використовує практику Chaos Engineering — метод систематичного впровадження стресу в системі. З допомогою спеціальних інструментів вони імітують сценарії раптових збоїв, стрибки трафіку, мережеві збої, відмову серверів та перевіряють, як система реагує на такі події. Це дозволяє виявити проблеми в архітектурі, конфігурації або коді та вирішити їх.
Щоби мінімізувати вплив інцидентів на систему, зокрема, використовують Canary-релізи — метод поетапного впровадження нового релізу (спочатку на обмежену групу користувачів, а за відсутності помилок — на всіх). Цей термін взятий з практики американських шахтарів, які брали до вугільних шахт канарок у клітинах, щоб виявляти небезпечний рівень чадного газу. Наразі розробники використовують для цього автоматизовані інструменти. «Якщо система бачить, що збільшується Error Rate або падають важливі метрики, вона автоматично повертає сервіс до минулого релізу. В Preply використовуємо для цього інструмент Argo Rollouts. Водночас з Canary-релізами варто бути обережним. Якщо протягом деплойменту відстежувати забагато метрик, система може видати хибнопозитивний результат», — ділиться Олексій.
Крім того, командам варто налаштувати якісний моніторинг з прогнозуванням, який допомагає визначити заздалегідь проблеми з інфраструктурою, як закінчення пропускної здатності або наближення до максимальних навантажень та виявляти аномалії.
Отже, SRE-практики допомагають знайти баланс між швидкістю розробки та стабільністю і пропонують метрики для вимірювання та відстеження впливу. Згідно з SRE Report 2024 від Catchpoint, 47% компаній вважають інциденти джерелом корисних бізнес-інсайтів. Кожен збій може стати джерелом інформації для покращення користувацького досвіду. Варто розвивати інженерну культуру, будувати якісні процеси та навчитися швидко відновлюватися.
