SRE (Site Reliability Engineering) – підхід до забезпечення доступності веб-проектів. Вважається фреймворком для DevOps і говорить як досягти успіху в застосуванні DevOps-практик. У цій статті переклад книги від Google. Цей переклад я готував самостійно та покладався на власний досвід розуміння процесів моніторингу. У телеграм-каналі и я публікував також переклад 6 розділу цієї книги про цілі рівня обслуговування.
Переклад катом. Приємного читання!
Неможливо керувати сервісом, якщо немає розуміння, які показники насправді мають значення і як їх вимірювати і оцінювати. З цією метою ми визначаємо та надаємо певний рівень обслуговування нашим користувачам, незалежно від того, чи вони використовують один з наших внутрішніх API або публічний продукт.
Ми використовуємо свої інтуїцію, досвід та усвідомимо бажання користувачів мати уявлення про індикатори рівня обслуговування (SLI), цілі рівня обслуговування (SLO) та угоду про рівень обслуговування (SLA). Ці вимірювання описують основні метрики, які ми хочемо контролювати і на які реагуватимемо, якщо не зможемо надати очікувану якість сервісу. Зрештою, вибір відповідних показників допомагає керувати правильними діями, якщо щось піде не так, а також дає впевненість команді SRE у здоров'ї сервісу.
У цьому розділі описується підхід, який ми використовуємо для боротьби з проблемами метричного моделювання, метричного відбору та метричного аналізу. Більшість пояснень буде без прикладів, тому ми будемо використовувати сервіс Шекспір, описаний у прикладі його реалізації (пошук за творами Шекспіра), щоб проілюструвати основні моменти.
Термінологія рівня обслуговування
Багато читачів, ймовірно, знайомі з концепцією SLA, але терміни SLI і SLO заслуговують на ретельне визначення, оскільки в загальному випадку термін SLA перевантажений і має ряд значень залежно від контексту. Для ясності ми хочемо відокремити ці значення.
Індикатори
SLI є індикатором рівня обслуговування — ретельно визначеним кількісним заходом одного з аспектів рівня обслуговування.
Більшість сервісів як ключового SLI вважають затримку запиту — скільки часу потрібно повернення відповіді запит. Інші поширені SLI включають частоту помилок, що часто виражається як частку всіх отриманих запитів, і пропускну здатність системи, що зазвичай вимірюється в запитах на секунду. Вимірювання часто агрегуються: сирі дані спочатку збираються, а потім перетворюються на швидкість зміни, середнє значення або процентиль.
В ідеалі, SLI безпосередньо вимірює рівень обслуговування, що представляє інтерес, але іноді для виміру доступна тільки пов'язана метрика, тому що початкову важко отримати або інтерпретувати. Наприклад, затримки на стороні клієнта часто є більш відповідною метрикою, але буває, що вимір затримки можливий лише на сервері.
Іншим видом SLI, важливим для SRE, є доступність або час, протягом якого сервісом можна користуватися. Часто визначається як частка успішних запитів, що іноді називають виробленням. (Тривалість терміну служби — ймовірність того, що дані зберігатимуться протягом тривалого часу, ще важлива і для систем зберігання даних.) Хоча доступність на 100% неможлива, доступність близька до 100% часто досяжна, значення доступності виражаються у вигляді кількості «дев'яток» відсотка доступності. Наприклад, доступність 99% та 99,999% може бути позначена як «2 дев'ятки» та «5 дев'яток». Поточна заявлена мета доступності Google Compute Engine - "три з половиною дев'ятки" або 99,95%.
Цілі
SLO — ціль рівня обслуговування: цільове значення або діапазон значень рівня обслуговування, який вимірюється SLI. Нормальним значенням для SLO є "SLI ≤ цільового значення" або "нижня межа ≤ SLI ≤ верхня межа". Наприклад, ми можемо вирішити, що ми повернемо результати пошуку за творами Шекспіра швидко, прийнявши у вигляді SLO значення середньої затримки запиту пошуку менше 100 мілісекунд.
Вибір відповідного SLO – складний процес. По-перше, ви не завжди можете вибрати конкретне значення. Для зовнішніх вхідних HTTP-запитів до вашого сервісу метрика кількості запитів за секунду (QPS) переважно визначається бажанням ваших користувачів відвідати ваш сервіс, і ви не можете встановити SLO для цього.
З іншого боку, ви можете сказати, що хочете щоб середня затримка для кожного запиту становила менше 100 мілісекунд. Постановка такої мети може змусити вас писати свій фронтенд із малою затримкою або купувати обладнання, що забезпечує таку затримку. (100 мілісекунд, очевидно, є довільною величиною, але краще мати ще нижчі показники затримки. Є підстави вважати, що висока швидкість краще, ніж повільна, і що затримка обробки запитів користувача вище певних значень фактично змушує людей триматися подалі від вашого сервісу.)
Знову ж таки, це більш неоднозначно, ніж може здатися на перший погляд: зовсім викидати QPS з розрахунку не варто. Справа в тому, що зв'язка QPS і затримка сильно пов'язані один з одним: більш високий QPS часто призводить до великих затримок, і зазвичай послуги відчувають різке зниження продуктивності при досягненні певного порога навантаження.
Вибір і публікація SLO задає очікування користувача про те, як працюватиме сервіс. Ця стратегія може зменшити безпідставні скарги на власника сервісу, наприклад, на його повільну роботу. Без явного SLO користувачі часто створюють власні очікування щодо бажаної продуктивності, які можуть бути ніяк не пов'язані з думкою людей, що проектують і управляють сервісом. Такий розклад може призвести до завищених очікувань від сервісу, коли користувачі помилково вважають, що сервіс буде доступнішим, ніж він є насправді і викликати недовіру, коли користувачі вважають, що система менш надійна, ніж вона є насправді.
угоди
Угода про рівень обслуговування — це явний або неявний контракт з вашими користувачами, який включає наслідки настання (або відсутності) SLO, які в них містяться. Наслідки найлегше розпізнаються, коли є фінансовими — знижка чи штраф, — але можуть приймати інші форми. Легкий спосіб розповісти про різницю між SLO та SLA полягає в тому, щоб запитати «що станеться, якщо SLO не буде виконано?». Якщо немає очевидних наслідків, ви майже напевно дивитеся на SLO.
SRE зазвичай не бере участі у створенні SLA, оскільки SLA тісно пов'язані з рішеннями для бізнесу та продуктів. SRE, проте, бере участь у наданні допомоги при запобіганні наслідкам невдалих SLO. Вони також можуть допомогти визначити SLI: очевидно, має бути об'єктивний спосіб виміру SLO в угоді або виникнуть розбіжності.
Google Search — приклад важливого сервісу, який не має SLA для громадськості: ми хочемо, щоб усі користувалися пошуком якомога ефективніше, але ми не підписали контракт з усім світом. Тим не менш, все ще є наслідки, якщо пошук недоступний — недоступність призводить до падіння нашої репутації, а також зниження доходів від реклами. Багато інших сервісів Google, таких як Google for Work, мають явні угоди про рівень обслуговування з користувачами. Незалежно від того, чи має конкретна послуга SLA, важливо визначити SLI та SLO та використовувати їх для керування службою.
Так багато теорії тепер до досвіду.
Індикатори практично
Враховуючи, що ми зробили висновок, що важливо вибрати відповідні показники для вимірювання рівня обслуговування, як ви тепер дізнаєтесь, які показники мають значення для сервісу чи системи?
Про що ви і ваші користувачі дбаєте
Не потрібно використовувати кожен показник як SLI, який ви можете відстежувати у системі моніторингу; розуміння того, що користувачі хочуть від системи, допоможе вибрати кілька показників. Вибір занадто великої кількості індикаторів ускладнює належний рівень уваги до важливих показників, у той час як вибір невеликої кількості може залишити значні шматки вашої системи поза увагою. Зазвичай ми використовуємо кілька ключових індикаторів для оцінки та розуміння стану системи.
Сервіси зазвичай можна розбити на кілька частин з точки зору SLI, які є для них актуальними:
- Користувальницькі фронтенд-системи, такі як інтерфейси пошуку Шекспір сервісу з нашого прикладу. Вони повинні бути доступні, не мати затримок і мати достатню пропускну здатність. Відповідно, можна запитати: чи можемо ми відповісти на запит? Скільки часу знадобилося, щоб відповісти на запит? Скільки запитів може бути опрацьовано?
- Системи схову. Для них важлива низька затримка відповіді, доступність та довговічність. Відповідні питання: скільки часу потрібно для читання чи запису даних? Чи можемо ми отримати доступ до даних на запит? Чи доступні дані, коли нам вони потрібні? розділ 26 Цілісність даних: те, що ви читаєте, це те, що ви записали, для детального розбору цих питань.
- Системи з великими даними, такі як конвеєри обробки даних, залежать від пропускної здатності та затримки обробки запиту. Відповідні питання: скільки даних опрацьовується? Скільки часу потрібно, щоб дані просувалися від прийому запиту до відповіді? (Деякі частини системи можуть мати затримки на окремих етапах.)
Збір індикаторів
Багато індикаторів рівня сервісу найбільш природно збирати за сервера, використовуючи систему моніторингу, таку як Borgmon (див. ) або Prometheus, або просто періодично аналізуючи логи, виявляючи HTTP відповіді зі статусом 500. Тим не менш, деякі системи повинні бути забезпечені збиранням метрик на стороні клієнта, оскільки відсутність моніторингу на стороні клієнта може призвести до пропуску низки проблем, які торкаються користувачів, але впливають на показники за сервера. Наприклад, зосередженість на затримці відповіді бекенда нашого тестового додатку з пошуком за творами Шекспіра може призвести до затримки обробки запитів на стороні користувача через проблеми з JavaScript: у цьому випадку вимірювання того, скільки часу займе обробка сторінки в браузері, є найкращим показником.
Агрегація
Для простоти та зручності використання ми часто агрегуємо сирі виміри. Це потрібно робити обережно.
Деякі показники здаються простими, наприклад, кількість запитів на секунду, але це, очевидно, прямий вимір неявно агрегує дані за часом. Чи є вимір отриманим конкретно один раз на секунду, чи цей вимір усереднений за кількістю запитів протягом хвилини? Останній варіант може приховати набагато більшу миттєву кількість запитів, які зберігаються лише на кілька секунд. Розглянемо систему, яка обслуговує 200 запитів на секунду з парними номерами та 0 у решту часу. Константа у вигляді середнього значення в 100 запитів на секунду і вдвічі велике миттєве навантаження - зовсім не те саме. Так само усереднення затримок запитів може здатися привабливим, але приховує важливу деталь: цілком можливо, більшість запитів будуть швидкими, але серед них виявиться багато запитів, які будуть повільними.
Більшість показників краще розглядати як розподіл, а не середні. Наприклад, для SLI затримки деякі запити будуть оброблятися швидко, в той час, як деякі завжди займатимуть більше часу, іноді набагато більше. Просте середнє може приховувати тривалі затримки. На малюнку наведено приклад: хоча типовий запит обслуговується приблизно 50 мс, 5% запитів у 20 разів повільніше! Моніторинг та оповіщення, засновані лише на середній затримці, не показують змін у поведінці протягом дня, коли насправді існують помітні зміни у тривалості обробки деяких запитів (найвищий рядок).
50, 85, 95 і 99 відсотили затримки системи. Вісь Y наведена в логарифмічному форматі.
Використання відсотків для індикаторів дозволяє побачити форму розподілу та його характеристики: високий рівень відсотка, такий як 99 або 99,9, показує найгірше значення, а на 50 відсотках (також відомому як медіана) можна побачити найчастіший стан метрики. Чим більше дисперсія часу відгуку, тим більше тривалі запити впливають на досвід користувача. Ефект посилюється за високого навантаження за наявності черг. Дослідження користувальницького досвіду показали, що люди зазвичай віддають перевагу більш повільній системі з високою дисперсією часу відгуку, тому деякі команди SRE зосереджуються тільки на високих відсоткових значеннях, виходячи з того, що якщо поведінка метрики на 99,9 відсотка є хорошою — більшість користувачів не будуть відчувати проблем.
Примітка щодо статистичних помилок
Зазвичай ми вважаємо за краще працювати з процентилями, а не із середнім (середнім арифметичним) набором значень. Це дозволяє розглядати дисперсніші значення, які часто мають суттєво відрізняються (і більш цікаві) характеристики, ніж середнє. Через штучний характер обчислювальних систем значення метрик часто спотворюються, наприклад, жоден запит не може отримати відповідь менш ніж за 0 мс, а тайм-аут в 1000 мс означає, що успішних відповідей зі значеннями, що перевищують тайм-аут, не може бути. В результаті ми не можемо прийняти, що середнє та медіани можуть бути однакові або близькі один до одного!
Без попередньої перевірки і якщо деякі стандартні припущення та апроксимації не виконуються, ми намагаємося не робити висновків, що наші дані нормально розподілені. Якщо розподіл не відповідає очікуваному, процес автоматизації, який усуває проблему (наприклад, коли бачить викиди за граничні значення, він перезапускає сервер з високими затримками обробки запиту), може робити це занадто часто або недостатньо часто (обидва варіанти не дуже хороші).
Стандартизувати індикатори
Ми рекомендуємо стандартизувати загальні характеристики SLI, щоб не доводилося про них міркувати щоразу. Будь-яка функція, яка відповідає стандартним шаблонам, може бути виключена зі специфікації окремого SLI, наприклад:
- Інтервали агрегування: "усереднений за 1 хвилину"
- Області агрегування: «Усі завдання у кластері»
- Як часто проводяться виміри: «Кожні 10 секунд»
- Які запити включені: «HTTP GET із завдань моніторингу чорної скриньки»
- Як дані отримані: «Завдяки нашому моніторингу, виміряному на сервері»,
- Затримка доступу до даних: "Час до останнього байта"
Щоб заощадити зусилля, створіть набір багаторазових шаблонів SLI для кожної загальної метрики; вони також спрощують всім розуміння те, що означає певний SLI.
Цілі на практиці
Почніть із роздумів (або дізнайтеся!), про що піклуються ваші користувачі, а не про те, що ви можете виміряти. Часто те, що турбує ваших користувачів, важко чи неможливо виміряти, так що в результаті ви наблизитесь до їхніх потреб. Однак, якщо ви просто почнете з того, що легко виміряти, ви отримаєте менш корисні SLO. В результаті ми іноді виявляли, що початкове визначення бажаних цілей і подальша робота з конкретними індикаторами працює краще ніж вибір індикаторів, а потім досягнення цілей.
Визначте цілі
Для максимальної ясності, має бути визначено як вимірюються SLO та умови, за яких вони дійсні. Наприклад, ми можемо сказати наступне (другий рядок такий самий, як перший, але використовує SLI-значення за замовчуванням):
- 99% (усереднені протягом 1 хвилини) викликів Get RPC буде завершено менш ніж за 100 мс (вимірюється на всіх серверах backend).
- 99% викликів Get RPC буде завершено менш ніж за 100 мс.
Якщо форма кривих продуктивності є важливою, ви можете вказати кілька цілей SLO:
- 90% викликів Get RPC здійснилися менш ніж за 1 мс.
- 99% викликів Get RPC здійснилися менш ніж за 10 мс.
- 99.9% викликів Get RPC здійснилися менш ніж за 100 мс.
Якщо ваші користувачі генерують гетерогенні навантаження: масова обробка (для якої важлива пропускна здатність) та інтерактивна обробка (для якої важлива величина затримки), може бути доцільно визначити окремі цілі для кожного класу навантаження:
- 95% запитів клієнтів важлива пропускна спроможність. Встановіть підрахунок RPC-дзвінків <1 с.
- 99% клієнтам важлива величина затримки. Встановіть підрахунок RPC-дзвінків з трафіком <1 кБ і <10 мс.
Нереалістично і небажано наполягати на тому, що SLO будуть виконуватися у 100% випадків: це може знизити темпи введення нового функціоналу та деплойменту, зажадати дорогих рішень. Натомість краще дозволити бюджет помилок — частку дозволеного простою системи та відстежувати це значення щодня чи щотижня. Можливо, вище керівництво хотітиме щомісячну чи щоквартальну оцінку. (Бюджет помилок – це просто SLO для порівняння з іншим SLO).
Частку порушення SLO можна порівняти з бюджетом помилок (див. Розділ 3 та розділ ), при цьому значення різниці використовується як вход у процес, який вирішує, коли розгортати нові релізи.
Вибір планових значень
Вибір планових значень (SLO) не є суто технічною діяльністю через інтереси продукту та бізнесу, які мають бути відображені у вибраних SLI, SLO (і, можливо, SLA). Аналогічно, може знадобитися обмін інформацією щодо питань, пов'язаних з укомплектуванням штату персоналу, часом виходу на ринок, наявністю обладнання та фінансуванням. SRE має бути частиною цієї розмови та допомагати розібратися з ризиками та життєздатністю різних варіантів. Ми прикинули кілька питань, які можуть допомогти забезпечити більш продуктивне обговорення:
Не вибирайте мету, засновану на поточній продуктивності
Хоча розуміння переваг та меж системи має важливе значення, адаптація показників без міркувань може блокувати вас у підтримці системи: знадобляться героїчні зусилля для досягнення цілей, які не можуть бути досягнуті без істотної реорганізації.
Будьте простіше
Складні розрахунки SLI можуть приховати зміни у продуктивності системи та ускладнять пошук причини проблеми.
Уникайте абсолюту
Хоча виникає спокуса мати систему, яка може приймати навантаження, що необмежено зростає, без збільшення значення затримки — ця вимога нереальна. Система, яка підходить до таких ідеалів, ймовірно, змусити витратити багато часу на проектування та створення, обійдеться дорого в експлуатації виявиться занадто гарною для очікувань користувачів, яким вистачило б і меншого.
Використовуйте якнайменшу кількість SLO
Виберіть достатню кількість SLO для забезпечення гарного покриття атрибутів системи. Захистіть SLO, які ви обрали: якщо ви ніколи не зможете виграти суперечку про пріоритети, вказавши конкретну SLO, можливо, не варто розглядати цю SLO. Однак, не всі атрибути системи піддаються SLO: важко підрахувати рівень захвату користувача за допомогою SLO.
Не женіться за досконалістю
Ви завжди можете уточнити визначення та цілі SLO з часом, коли дізнаєтесь більше про поведінку системи під навантаженням. Краще починати з плаваючої мети, яку ви згодом уточните, ніж вибирати надто сувору мету, яка має бути ослаблена, коли ви виявите, що це недосяжно.
SLO можуть і повинні стати основним драйвером у визначенні пріоритетів роботи для SRE та розробників продуктів, оскільки вони відображають турботу про користувачів. Хороший SLO - це корисний інструмент примусу команди розробників. Але погано продумана SLO може призвести до марнотратності, якщо команда докладає героїчних зусиль для досягнення надмірно агресивної SLO або поганого продукту, якщо SLO занадто низьке. SLO це потужний важіль, використовуйте його з розумом.
Контролюйте вимірювання
SLI та SLO є ключовими елементами, що використовуються для керування системами:
- Моніторьте та вимірюйте SLI системи.
- Порівняйте SLI зі SLO і вирішіть, чи потрібні дії.
- Якщо потрібна дія, з'ясуйте, що має статися, щоб досягти мети.
- Виконайте цю дію.
Наприклад, якщо крок 2 показує, що час очікування запиту збільшується, і порушить SLO через кілька годин, якщо нічого не буде зроблено, крок 3 може включати тестування гіпотези про те, що навантаження на сервери прив'язана до процесорів і додавання нових серверів розподілить навантаження . Без SLO ви не знали б, чи потрібно (або коли) вживати заходів.
Встановили SLO - слідом встановляться очікування користувача
Публікація SLO встановлює очікування користувачів від поведінки системи. Користувачі (і потенційні користувачі) часто хочуть знати, що можна очікувати від сервісу, щоб зрозуміти, чи він підходить для використання. Наприклад, люди, які бажають користуватися веб-сайтом для обміну фотографіями, можуть захотіти уникнути використання сервісу, який обіцяє довговічність і низьку вартість в обмін на дещо меншу доступність, хоча одна й та сама послуга може бути ідеальною для системи управління архівними записами.
Щоб встановити реалістичні очікування для ваших користувачів, використовуйте одну або обидві такі тактики:
- Зберігайте запас міцності. Використовуйте жорсткішу внутрішню SLO, ніж оголошена користувачам. Це дасть вам можливість реагувати на проблеми, перш ніж вони стануть видимими ззовні. Буфер SLO також дозволяє мати запас міцності при встановленні релізів, які впливають на продуктивність системи та забезпечити простоту обслуговування системи без необхідності розчаровувати користувачів даунтаймом.
- Не виконуйте очікування користувачів. Користувачі ґрунтуються на тому, що ви пропонуєте, а не на ваших словах. Якщо фактична продуктивність вашого сервісу набагато краща за заявлену SLO, користувачі будуть покладатися на поточну продуктивність. Ви можете уникнути надмірної залежності, навмисно вимикаючи систему або обмежуючи продуктивність при невеликих навантаженнях.
Розуміння того, наскільки добре система відповідає очікуванням, допомагає вирішити, чи слід інвестувати прискорення системи та робити її більш доступною та стійкою. Як альтернатива, якщо сервіс надто добре працює, деякий час роботи персоналу має бути витрачено на інші пріоритети, такі як погашення технічного боргу, додавання нових функцій або введення в експлуатацію нових продуктів.
Угоди на практиці
Створення SLA вимагає, щоб бізнес-і юридичні команди визначали наслідки та штрафи за його порушення. Роль SRE полягає в тому, щоб допомогти їм зрозуміти ймовірні труднощі з виконанням SLO, що містяться у SLA. Більшість рекомендацій щодо створення SLO також застосовна для SLA. Доцільно бути консервативним у тому, що ви обіцяєте користувачам, оскільки чим більше, тим складніше змінити або видалити SLA, які здаються нерозумними або важкими для виконання.
Дякую, що прочитали переклад до кінця. Підписуйтесь на мій телеграм-канал про моніторинг и .
Джерело: habr.com