Чому Google-сервіси не «падають», або Що таке SRE

Привіт, мне звати Андрій, я працюю в ColibriQL, ця стаття про Site Reliability Engineering і буде цікава тим, хто хоче знати, як круті команди роблять вебсистеми надійними.

Інженери все більш уміло працюють з логами, частіше використовують моніторинг та інші інструменти спостереження за системою. Останні 3 роки мені доводилося досить багато підключати різну телеметрію до вебпроєктів. При цьому мені не вистачало загальної стратегії та правил для роботи з такими інструментами. Не завжди було зрозуміло, що робити з графіками та логами, щоб це приносило реальну користь.

У поточному проєкті мікросервіси пропускають через себе велику кількість трафіку. Регулярно бувають сплески активності, тому часто виникають проблеми зі стабільністю сервісів. Ми відкрили для себе Site Reliability Engineering (далі — SRE) і в цій статті я хотів би розповісти про ключові ідеї концепції з висоти 30 000 футів.

Що таке SRE

SRE — це сукупність практик надійної експлуатації сервісів. У SRE поняття надійності — вимірювана величина. Це набір метрик, що визначають, коли потрібно починати робити нові фічі, а коли — зосередиться на удосконаленні старих.

Вперше SRE з’явилося в Google у далекому 2003-му, але на відміну від DevOps, довгий час його роль була непублічною. Перша книга з цієї теми була опублікована лише у 2016 році.

Чому це важливо

Мікросервісна архітектура чи будь-яка інша багатокомпонентна система, як правило, має проблеми зі стабільністю. Кожен новий вузол підвищує шанс збою. Тільки в Північній Америці компанії втрачають понад $700 млрд на рік через непрацездатність сервісів (джерело).

Умовна деградація системи за різної доступності кожного компонента

Час простою (downtime) при різних рівнях доступності

При цьому досягти 100% доступності практично неможливо, а цифри в 99,999%, скоріш за все, обійдуться компанії набагато дорожче, ніж втрати від downtime в 0,001%:

Співвідношення рівня надійності до витрат на реалізацію

Чим більше «дев’яток» для кожного сервісу ви гарантуєте, тим складніше підтримувати обіцяний рівень надійності. Чим менше дев’яток, тим сильніша загальна деградація системи.

Як організувати SRE

Крок 1: Визначити, що таке «надійність»

Відповісти на питання:

  • Що є надійність для вашого проєкту?
  • Який рівень надійності є оптимальним?

На наступному кроці потрібно перетворити ці відповіді на метрики.

Крок 2: Визначити метрики

SLO (service level objective), SLI (service level indicator), SLA (service level agreement) відображають надійність всієї системи, або одного сервісу на верхньому рівні та визначають припустимий ліміт помилок — error budget.

SLI — це метрика, якою ми вимірюємо, наприклад, uptime, success rate для HTTP-запитів або середній час обробки запиту.

SLO — це ліміт наших метрик. За допомогою SLO ми задаємо рівень якості сервісу. Наприклад, якщо метрика — це співвідношення успішних запитів до невдалих, то SLO 99,99% означає, що наша мета — 99,99% успішних HTTP-запитів.

Error budget — це не про гроші, а про допустиму кількість помилок.

Error budget = 100% — SLO

SLA — це сума SLO та наслідків, якщо цілі не будуть виконані. Наприклад, якщо ваші цілі були порушені, то:

  • команда напише всім користувачам листа з вибаченнями та поясненням інциденту;
  • компанія поверне користувачам гроші.

Припустимо, у нас є мікросервіс «abc». Ми вибрали період, протягом якого будуть відбуватися зміни — 4 тижні, а вимірюватимемо лише одну метрику — uptime нашого сервісу.

Визначимо SLO — 99,9%. Виходячи з цього, ви можете собі дозволити бути офлайн 0.1% або 48 хвилин. Ці 48 хвилин — наш error budget.

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

У реальному житті має сенс створення багатьох SLO для кожного сервісу та, відповідно, стеження за багатьма SLI.

Приклади реальних SLA

Google Cloud SLA — uptime як мінімум 99,5% для одного інстансу та 99,99% — для групи інстансів у різних зонах. При порушенні SLO клієнт має право вимагати гроші назад.

Microsoft Azure SLA — практично те саме, тільки гарантований uptime залежить від накопичувача:

  • 99,9% для Premium SSD;
  • 99,5% для Standard SSD;
  • 99% для Standard HDD.

Клієнт має право отримати «кредити», якщо умову було порушено.

AWS SLA — 99,99% для одного інстансу.

Ці SLA — лише «вершина айсбергу», яка додається до угоди з користувачем. Крім цього, інженери створюють велику кількість внутрішніх SLO/SLI для кожного компонента системи.

Які метрики потрібно вимірювати, окрім uptime? Доволі часто актуальні Golden Signals: latency, errors, traffic, saturation:

  • latency — час, необхідний для обробки одного запиту, найчастіше вимірюється в мілісекундах;
  • errors — невдалі HTTP-запити чи будь-які внутрішні помилки;
  • traffic — кількість запитів, які обробляє сервіс. Важливо вчасно повідомляти команду, якщо сервіс обробляє більше запитів, ніж очікується;
  • saturation — досить абстрактний термін, що означає ємність/ capacity сервісу. Для кожного сервісу визначається окремо.

Також завжди мають сенс метрики реагування на аварійні ситуації MTTD та MTTR:

  • MTTD (Mean Time To Detect) — скільки часу потрібно команді для виявлення помилок;
  • MTTR (Mean Time To Restore) — скільки часу потрібно команді для відновлення роботи.

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

Крок 3: Імплементація метрик

В вебі популярні три напрямки телеметрії:

  1. моніторинг;
  2. логінг;
  3. трейсинг.

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

Організація телеметрії — задоволення не з дешевих, адже вона потребує багато часу для налаштування та значного обсягу серверних ресурсів для зберігання даних:

Моніторинг

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

Існує 2 типи моніторингу:

  • black-box моніторинг — коли ви не знаєте, що відбувається всередині компонента. Ви можете спостерігати поведінку системи лише зовні. Наприклад, моніторинг використання системних ресурсів контейнером;
  • white-box моніторинг — коли ви маєте доступ до внутрішніх показників компонента. Наприклад, моніторинг успішних/невдалих HTTP-запитів або більш кастомних показників бізнес-логіки.

Логування

Цей напрямок надає безліч додаткової інформації щодо експлуатації системи. Логування легко реалізувати, але дорого зберігати логи протягом тривалого часу. У деяких проєктах, з якими я мав справу, команда хотіла зберігати логи за останній рік, але виходило зберігати дані лише за 5-10 тижнів.

Система логування — це про баланс між інформативністю та витратами ресурсів на зберігання.

Трейсинг (tracing/distributed tracing)

Трейсинг передбачає спостереження за системою з точки зору подій у сервісах.

Це схоже на логування, тільки тут події пов’язані між собою у ланцюжки. Наприклад, у нас є два мікросервіси, які взаємодіють між собою:

З точки зору трейсингу, у мікросервісі 1 у нас три події обробки запиту та три події обробки відповіді. Те ж саме у мікросервісі 2. Якщо щось виходить з ладу, у нас 12 можливих точок поломки.

Трейсинг пов’язує події в один ланцюжок, виконує профайлінг, перевіряє, чи події були виконані в очікуваній послідовності.

Головний мінус трейсингу — це трудозатрати на його впровадження, тому що частину подій інженер повинен вказувати в коді самостійно. Хоча при цьому можна автоматизувати деякі з цих вказівок.

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

Для налаштування телеметрії з високим рівнем спостереження необхідно комбінувати метрики, логінг та трейсинг. Ми знаємо, що неминуче відбуватимуться збої і все передбачити неможливо, тому кожен компонент системи має бути під максимальним спостереженням. Тим, хто відповідає за компоненти, необхідно навчитися розуміти інформацію, яку надає телеметрія. Саме завдяки здатності читати телеметрію ми поступово зменшуємо час на виявлення (MTTD) та час на виправлення збоїв (MTTR).

Софт для телеметрії

Ось кілька рішень із особистого досвіду:

  • Datadog — all-in-one — хмарне рішення, забезпечує роботу за трьома напрямками телеметрії, легко впроваджується. Основним мінусом є те, що сервіс платний і якщо у вас багато трафіку, телеметрія коштуватиме дорого.
  • Prometheus+Grafana+Loki+Tempo — open source, ці технології покривають три напрямки телеметрії. Створені практично однією командою, тому добре інтегруються одна з одною. Grafana дозволяє створювати моніторингові програми з графіками, картами і таблицями. Також є сотні готових дашбордів для популярних задач. Навіть SpaceX використовує Grafana. Prometheus — популярне сховище для метрик, Loki — для логів, Tempo — для трейсингу. На старті потребує більше часу на імплементацію, ніж Datadog. І підтримку. Ну, і зберігаєте ви всі дані на своїх серверах.
  • Opentracing+Jaeger — open source, популярне рішення для трейсингу. Jaeger — це програма для перегляду трейсингів, розроблена інженерами Uber в 2015 році.

Крім того, популярним є ELK — Elasticsearch, Logstash, and Kibana. Не доводилося особисто з ними працювати, тут є стаття для порівняння з Loki.

Крок 4: Визначити та задокументувати план дій на випадок, якщо щось піде не за планом

Цю частину можна розділити на 3 групи:

  • Alert development policy — документ про те, як правильно сповіщати команду, якщо щось пішло не так. Хороший алерт, інформативний і приходить лише тим, хто має його отримати. Необхідно розробити правила, за якими ефективно створюються тригери та вміст алертів. Як правило, інженери просто домовляються про це без правил, — але це знижує ефективність реакції команди на алерти. Ось цікавий документ від Rob Ewaschuk, колишнього SRE у Google.
  • Escalation policy — документ про те, що робити після отримання алерту. В ідеальному світі, якщо відбувається інцидент, on-call інженер отримує алерт і сам фіксить проблему. У реальному світі інколи самостійно вирішити проблему неможливо. Потрібні більш досвідчені або спеціалізовані інженери. У таких випадках потрібні escalation policies — інструкції, як діяти у разі певного збою та як комунікувати з командою під час його обробки. Тут можна переглянути приклад Escalation policy.
  • Error budget policy — алгоритм дій, якщо error budget вичерпано. У цьому випадку виправлення проблеми отримує найвищий пріоритет і команда зупиняє розробку нових фіч до моменту, поки не виправить проблемний сервіс.

Крок 5: On-call schedule

Оn-call schedule — графік роботи «чергових». Якщо станеться збій, завжди буде доступний інженер, що відреагує на нього. Якщо команда добре попрацювала над escalation policy, навіть наймолодший розробник «на чергуванні» зможе швидко і правильно відреагувати.

Оn-call schedule — це індивідуальне питання. При формуванні графіка варто розуміти, як часто вашу систему «штормить». Для однієї зміни чергування проходять досить спокійно, кожен алерт — це велика подія. Для іншої кілька алертів за ніч можуть бути нормою.

Розробники не завжди раді бути доступними 24/7, тому пріоритет при організації on-call schedule — знайти баланс між роботою та особистим життям інженера.

Популярні помилки on-call schedule:

  1. Відсутність компенсації за чергування. Якщо компанія не цінує час співробітників, співробітники не будуть піклуватися про бізнес. Компенсація — це доплата до зарплати чи відпустка.
  2. Погано отримувати вночі алерти, що не вимагають негайної реакції. У неробочий час мають приходити лише критичні алерти, які неможливо обробити автоматично.
  3. Ставити на on-call лише невелику групу людей, не задіювати всю команду. Якщо більша частина роботи інженера — сидіти на on-call і фіксити баги, то це пряма дорога до вигорання. Краще поступово розподіляти чергування. Так у командах буде більше залученості та відчуття відповідальності за код.
  4. Робити суворий розклад. Таке трапляється, якщо on-call schedule приходить зверху і компанія використовує «універсальний» підхід для всіх. Регулярно перевіряйте, наскільки добре працює розклад, змінюйте його за необхідності.

Впроваджувати on-call schedule та escalation policies можна в PagerDuty або в іншому аналозі. Ці послуги варті своїх грошей, якщо у вас велика команда. На етапі розробки або для команд з кількох програмістів можна обійтися Slack.

Кажуть, деякі віддають on-call schedule на аутсорс — не знаю, наскільки це ефективно. Якщо у вас був такий досвід — поділіться у коментарях.

Крок 6: Автоматизація

Якщо ваш SLI — це 99,99% uptime і збій відбувається один раз на місяць, то ваші інженери мають 4 хвилини, щоб виявити збій і відновити систему. Щоб швидко реагувати на подібні інциденти, необхідно автоматизувати первинну реакцію на збій. Наприклад, можна перезавантажити контейнер. Це, безумовно, примітивне, але швидке рішення що можливо дозволить виграти час на пошук проблеми.

Концептуально автоматизація — це скоріше територія DevOps. Однак, SRE тут визначає пріоритети.

Звідки беруться SRE фахівці і що вони повинні знати

Як правило, це DevOps, який вміє писати код або програміст, який знає Ops. У вакансіях прописані вимоги до вас як до сильного кодера та DevOps одночасно. Наприклад:

  • CI/CD.
  • Програмування: fluent Python and/or Golang.
  • DevOps: автоматизація, контейнеризація і телеметрія.
  • Здатність приймати рішення на основі даних.
  • Досвід у створенні scalable, high-load, fault-tolerant систем.
  • SRE практики.

У великих компаніях SRE — це окремі команди фахівців, а у маленьких командах цю роль на себе бере тімлід або хтось інший.

Висновок

SRE — це дисципліна надійної експлуатації сервісів, ще один підхід (разом з DevOps) для перетворення свіжонаписаного коду в працюючу на сервері систему.

Якщо DevOps — концепція автоматизації рутинних завдань та активної взаємодії програмістів з «Ops», то SRE звертає увагу інженерів на недостатню надійність системи, пропонуючи практики для контролю надійності.

При всій різниці підходів, мені здається, SRE вирішує ту саму проблему, що і DevOps, але з іншого боку. SRE не замінює DevOps, а розширює його.

У цій статті поверхово описано вершину айсберга, ключові концепції. Якщо хочете знати більше — ось кілька книг про SRE:

При написанні статті у тому числі використовувалися матеріали із цих книг. А також трохи з книги Mastering Distributed Tracing.

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному10
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А чому автор постійно тицяє нас носом у мікросервіси? А що якщо у мене моноліт, то йому SRE не потрібен?

Справедливо, моноліту також може бути потрібний SRE.

У нас налаштовані Alerts в Google Cloud на рівень 4хх або 5хх помилок, рестарт контейнерів, CPU та Memory utilization для БД. Алерти надходять в slack, а черговий інженер має реагувати. Але зараз так само хочемо налаштувати різні рівні escalation policy, щоб можна було бачити, що on duty працює над проблемою, або ескалувати на команду далі. Будемо скоріше за все використовувати Taskcall для цього, в них є інтеграція з GC та Slack.

Схоже, ви непогано все організували без витрат на розгортання та підтримку софту для телеметрії.

Вцілому, якщо проекту:
— для агрегації логів достатньо 3rd party рішення
— для трейсингу достатньо 3rd party рішення або трейсинг не потрібен
— від моніторингу не потрібно нічого кастомного
У такому разі, розгортання open-source інструментів телементрії буде невиправданим,
3rd party рішення заощаджують багато ресурсів компанii на технічну частину для SRE.

Якщо DevOps — концепція автоматизації рутинних завдань та активної взаємодії програмістів з «Ops»

Вообще-то это культура работы с кодом, которая основана на подходе push-and-forget, кода разработчик делает ветку с фичей, под нее идет автодеплой, тесты, а на выходе — повышение скорости и (или) качества кодревью. Ну или уведомление разработчику что тест не прошел и надо пофиксить.

100% cогласен с вашим определением DevOps.

Класний і корисний матеріал. Ми десь рік тому додали трейсинг на проект і це ну дуже спростило життя.

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

Щодо on-call і junior‘ів: часто, щоб розібратися в проблемі, потрібно багато доступів і експертизи в різних частинах продукту. Нам поки вдається додавати людину в графік чергування мінімум через 6-8 місяців, коли інженер вже знайомий зі структурою і розуміє, що і звідки може вилізти

Дякую за відгук 👍

Згоден щодо junior‘ів і on-call

Крок 5: On-call schedule

Написано максимально вырвиглазно. Куча терминов намешано вообще без понимания что куда относится.

Якщо команда добре попрацювала над escalation policy, навіть наймолодший розробник «на чергуванні» зможе швидко і правильно відреагувати.

Такое случится, если хорошо поработать над написание runbook и организацией on-call support. Escalation policy определяет исключительно порядок нотификаций об инциденте. Т.е. приходит алёрт, открывается инцидент, и в зависимости от параметров (например urgency) нотификация об инциденте идёт первому инженеру из escalation policy. Если инженер не делает acknowledge инцидента (забухал, машина сбила, выключил звук на телефоне), то после некоторого таймаута инцидент эскалируется на следующего инженера из escalation policy. Ну и так далее.

Популярні помилки on-call schedule

Все эти ошибки, это ошибки (некоторые из которых спорно отнесены к ошибкам) организации on-call support, а не графика дежурств.

деякі віддають on-call schedule на аутсорс

Ну и тоже самое

Спасибі за коментар. Це мій перший досвід написання статті, і перший досвід написання українською. Працюватиму над зрозумілістю мого тексту.

Тут можна переглянути приклад Escalation policy.

Посилання видає 404 сторінку

Для збору метрик в вебі популярні три напрямки телеметрії:
моніторинг;
логінг;
трейсинг.

все с ног на голову или мышь родила слона

Logs, metrics, and traces are often known as the three pillars of observability

metrics are a measurement at a point in time for the system

Ця «стаття» копіює conclusion секції з розділів першої половини книжки Site Reliability Engineering (https://sre.google/books/). Рекомендую книгу всім зацікавленим.

Не всі ту книгу читали, тому добре, що є такі статті)

Ну так ця стаття абсолютно не розкриває матеріалу з книги. В книгі, наприклад, інженери гугл розповідають, як вони вибирали необхідні SLI і скільки ітерацій пройшли перш ніж зупинились на 4 основних показниках. Як рахували необхідні SLO. А сам цимес книги саме в довсіді, який SRE команда гугла почерпнула за роки створення reliable-систем.

Як би ми тоді взнали про ColibriQL? ;))

Мета статті поверхово пояснити за 5 хвилин як влаштовано SRE. Орієнтовано для читача, що не знайомий з цією концепцією.

Ну, ви могли б хоча б написати disclaimer, що скопіювали текст цього посту з книги.

Hе написав такий disclaimer тому що не згоден з формулюванням «скопіювали». При написанні статті використовувалися матеріали з кількох книг, ресерч та особистий досвід. Дописав наприкінці статті, що використовував книги. 
Як писав в попередньйому комментарi, ця публикацiя створена, щоб познайомити читача з SRE, не більше. Коли я вперше знайомився із цією темою, мені не вистачало такої статті. Думаю, це може бути корисним.

Google-сервіси не «падають»

вже в самому заголовку невірне твердження:
https://outage.report/google
дивитися блок «Outage History»

Підписатись на коментарі