SRE без дурнів: розбираємо концепцію на прикладах Azure

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

Основна проблема, яку я багато вбачаю в абревіатурі SRE, багато хто не розуміє, які проблеми вирішують ці практики та для чого вони були створені. Щоб розібратися, потрібно поринути у концепцію Site Reliability Engineering і зрозуміти, як і чому вона виникла.

Витоки та мета SRE

SRE або Site Reliability Engineering був розроблений Google на початку 2000-х. Основною метою цього підходу було розв’язання проблем, пов’язаних із надійністю та стійкістю складних розподілених систем. У традиційних ІТ-інфраструктурах часто виникає конфлікт між розробниками, які прагнуть швидко вносити зміни та випускати нові функції, та операційними командами, які відповідають за стабільність та надійність системи.

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

Цей матеріал буде корисним для інженерів, які хотіли б зайнятися Azure та SRE. Також у нас є канал про Azure в телеграмі: доєднуйтесь до спільноти.

Чим не є SRE

SRE (Site Reliability Engineering) є не просто операційною роллю або заміною DevOps. Це не розв’язання всіх проблем ІТ-інфраструктури й актуально не лише для великих компаній. SRE охоплює більше, ніж технічні аспекти, зокрема організаційні та культурні зміни. В Azure SRE не обмежується моніторингом з Azure Monitor, CI/CD з Azure DevOps або управлінням інцидентами з Azure Service Health, але містить комплексні інженерні підходи для підвищення надійності та продуктивності систем.

Одна з ключових концепцій у SRE — керування надійністю через угоди (домовленості допустимого часу простою) про рівні обслуговування (SLA) та мету рівня обслуговування (SLO). Розуміння цих понять є критично важливим для успішного застосування SRE-практик. SRE — це підхід, який допомагає забезпечити надійну та стабільну роботу програмного забезпечення, поєднуючи принципи розробки та операційної роботи. З акцентом на автоматизацію та управління інцидентами.

SLA та SLO: що це таке

• SLA (Service Level Agreement) — це формальна угода між постачальником послуг та клієнтом, яка визначає очікуваний рівень обслуговування. SLA містить метрики, за якими оцінюється продуктивність, і штрафні санкції за недотримання цих показників. Наприклад, SLA може гарантувати, що вебсайт буде доступний щонайменше 99.9% часу на місяць.
• SLO (Service Level Objective) — це внутрішні цілі, які встановлюються задля досягнення рівня обслуговування, визначеного SLA. SLO — це більш конкретні та вимірні цілі, які команди використовують для відстеження та покращення продуктивності системи. Наприклад, якщо SLA вимагає 99.9% доступності, SLO може встановлювати мету 99.95% доступності, щоб забезпечити деякий запас.
• SLI (Service Level Indicator) — це показник, який використовується для вимірювання конкретних аспектів якості та продуктивності сервісу. Наприклад: час відповіді, доступність або частота помилок. Це один із ключових компонентів в управлінні надійністю та ефективністю ІТ-систем.

Чому 100% — це не правильно

У реальному світі досягнення 100% доступності чи продуктивності практично неможливе та економічно недоцільне. Прагнення до 100% призводить до надмірних витрат на інфраструктуру та підтримку, що рідко виправдане з погляду бізнесу. Натомість SRE встановлює реалістичні SLO, які забезпечують високий рівень надійності, але водночас враховують допустимі ризики та витрати.

Очікування

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

Приклади використання SLO та SLA в Azure

Azure Service Level Agreements (SLA)

Azure надає різні SLA, наприклад, гарантуючи доступність віртуальних машин до 99.9% та баз даних до 99.99% часу.

Azure Monitor

Azure Monitor дозволяє налаштовувати та відстежувати SLO, наприклад, моніторинг часу відгуку та рівень помилок програм.

Azure Application Insights

Частина Azure Monitor призначена для моніторингу вебзастосунків. Допомагає відстежувати метрики — час відгуку та відсоток успішних запитів.

Azure Service Health

Інструмент для отримання повідомлень про статус сервісів Azure, зокрема про планові роботи та інциденти. Допомагає керувати очікуваннями користувачів.

Azure Ping Test

Інструмент для перевірки доступності та затримки мережних з’єднань. Допомагає покращувати продуктивність та відповідати SLO та SLA.

Error Budget

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

Що таке Error Budget

Error Budget — це допустима кількість помилок або простоїв, яка може бути прийнята протягом певного періоду, не порушуючи SLO (Service Level Objectives).

Приклад
Для SLO 99.9% доступності Error Budget становить 0.1% (це відповідно 43.2 хвилин простою на місяць). Якщо програма призводить до інцидентів та викликає 30 хвилин простою, у вас залишається 13.2 хвилин Error Budget, що дозволяє продовжувати впровадження нових функцій. За умови вичерпання Error Budget варто фокусуватися на покращенні надійності.

Навіщо потрібний Error Budget

1. Баланс між інноваціями та стабільністю. Дозволяє командам знаходити оптимальний баланс між випуском нових функцій та підтримкою стабільності системи.
2. Прозорість та вимірність. Надає вимірний спосіб оцінки продуктивності системи.
3. Мотивація команд. Мотивує розробників та адміністраторів працювати разом для підтримки балансу між якістю та швидкістю розробки.

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

Використання Error Budget в Azure

1. Визначення SLO та Error Budget. Встановіть SLO, наприклад, 99.9% доступності, та визначте Error Budget як 0.1%.
2. Моніторинг за допомогою Azure Monitor. Відстежуйте метрики продуктивності та доступності, налаштовуйте дашборди та сповіщення.
3. Діагностика з Azure Application Insights. Аналізуйте помилки та їхні причини.
4. Управління інцидентами з Azure Service Health. Отримуйте сповіщення про стан сервісів та швидко реагуйте на інциденти.
5. Коригувальні дії. При досягненні граничного значення Error Budget призупиніть деплой розробок нових функцій в промислове середовище та зосередьтеся на покращенні надійності.

Висновок

Error Budget допомагає знаходити баланс між інноваціями та стабільністю. Використовуючи Azure Monitor, Azure Application Insights та Azure Service Health, ви можете ефективно керувати та відстежувати свій Error Budget, забезпечуючи надійну роботу програм. Не обов’язково витрачати весь Error Budget, але якщо його не використовують, це може свідчити про надмірну консервативність у впровадженні нових змін та інновацій.

Toil

У сфері управління ІТ-операціями важливо відокремити рутинну роботу, що не приносить довготривалої цінності від завдань, які сприяють розвитку та покращенню системи.

Що таке Toil

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

Для чого зменшувати Toil

1. Підвищення ефективності. Зниження Toil дозволяє командам зосередитись на важливих завданнях.
2. Підвищення задоволеності команди. Менше рутини — більше мотивації.
3. Підвищення надійності системи. Автоматизація знижує ймовірність помилок.

Використання інструментів Azure для зменшення Toil

1. Azure Automation
   • Як допомагає: автоматизує завдання оновлення та розгортання інфраструктури.
2. Azure DevOps
   • Як допомагає: автоматизує CI/CD, тестування та реліз.
3. Azure Logic Apps
   • Як допомагає: автоматизує інтеграційні завдання та управління бізнес-процесами.
4. Azure Functions
   • Як допомагає: виконує події, автоматизуючи завдання без необхідності постійної підтримки інфраструктури.
5. Azure Monitor
   • Як допомагає: автоматизує моніторинг, діагностику та оповіщення.

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

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

Висновок

Toil — це рутинна робота, яку можна автоматизувати. Інструменти Azure, такі як Azure Automation, Azure DevOps, Azure Logic Apps, Azure Functions та Azure Monitor допомагають зменшити Toil, звільняючи час для більш важливих завдань.

В управлінні ІТ-операціями важливо розрізняти індивідуальний Toil та організаційний Toil. Індивідуальний Toil стосується рутинних завдань, які виконує конкретний працівник, відволікаючи його від більш важливих та творчих задач. Організаційний Toil охоплює загальні рутинні процеси в організації, які знижують спільну ефективність команди або відділу. Зменшення як індивідуального, так і організаційного Toil дозволяє підвищити продуктивність і ефективність всієї організації.

Що робити з цим усім?

Моніторинг (Monitoring) та спостережливість (Observability)

Що таке моніторинг та спостережливість

• Моніторинг. Процес збору, аналізу та відображення даних про стан та продуктивність системи.
• Спостережливість. Здатність системи надавати детальну інформацію про свою внутрішню роботу через метрики, логи та трасування для полегшення діагностики та усунення проблем.

Навіщо потрібні моніторинг та спостережливість

1. Підвищення надійності. Дозволяють своєчасно виявляти та усувати проблеми.
2. Поліпшення продуктивності. Допомагають оптимізувати роботу системи.
3. Прискорення діагностики. Забезпечують доступ до деталізованої інформації для швидкого вирішення інцидентів.

Використання інструментів Azure для моніторингу та спостережливості:

1. Azure Monitor
   • Як допомагає: збір та аналіз метрик, логів та трасувань. Налаштування дашбордів та оповіщень.
   • Приклад: моніторинг CPU, пам’яті та мережевого трафіку віртуальних машин.
2. Azure Application Insights
   • Як допомагає: моніторинг продуктивності та доступності застосунків. Збір телеметрії та діагностика помилок.
   • Приклад: Відстеження часу відгуку та частоти вебпрограм.
3. Azure Log Analytics
   • Як допомагає: збір та аналіз логів із різних джерел. Створення запитів та звітів для виявлення аномалій.
   • Приклад: аналіз логів із вебсерверів для виявлення частих помилок та збоїв.
4. Azure Service Health
   • Як допомагає. Надає інформацію про стан сервісів Azure, попереджає про інциденти та планові роботи.
   • Приклад: отримання повідомлень про збої у роботі хмарних сервісів.
5. Azure Network Watcher
   • Як допомагає: моніторинг та діагностика мережевих проблем. Збір даних про трафік та перевірка підключень.
   • Приклад: діагностика затримок та перевірка доступності мережевих ресурсів.

Висновок

Моніторинг та спостережливість — це ключові елементи для підтримки високої надійності та продуктивності систем. Інструменти Azure, такі як Azure Monitor, Azure Application Insights, Azure Log Analytics, Azure Service Health та Azure Network Watcher, допомагають забезпечити ефективний моніторинг, що дозволяє швидко виявляти та усувати проблеми.

RED сигнали та MTTR

Для ефективного моніторингу та управління системами важливо звертати увагу на RED сигнали (Rates, Errors, Duration), які забезпечують основні інсайти про роботу системи. Наприклад, підвищення рівня помилок (Errors) в API може сигналізувати про проблеми з новими функціями. Це допомагає швидко реагувати на проблеми.

Зменшення MTTR (Mean Time to Recovery) є важливим KPI, що дозволяє оцінювати ефективність процесів відновлення і покращувати їх. Наприклад, автоматизація процесів відновлення зменшує час на вирішення інцидентів, що може зменшити MTTR на 30%.

У сфері ІТ-операцій часто використовуються терміни Monitoring, APM та Telemetry, але вони мають різні значення та цілі. Monitoring (моніторинг) — це процес спостереження за системами та застосунками в режимі реального часу для виявлення проблем і збоїв. APM (управління продуктивністю застосунків) фокусується на вимірюванні та покращенні їх продуктивності. Telemetry (телеметрія) — це збір, передача та аналіз даних про роботу системи для отримання глибших інсайтів. Розуміння різниці між цими поняттями допомагає ефективніше керувати ІТ-інфраструктурою.

Observability (спостережуваність) — це ключовий аспект ефективного управління ІТ-системами. Спостережуваність дозволяє зрозуміти внутрішній стан системи за допомогою зовнішніх сигналів: метрик, логів і трасування. Це допомагає швидко діагностувати та розв’язувати проблеми. Важливо уникати надлишку алертів, які можуть перевантажити команду. Краще мати один, але критичний алерт, який дійсно вказує на серйозну проблему. Такий підхід підвищує ефективність реагування і знижує ризик пропуску важливих інцидентів.

Fragile та Antifragile

Що таке Fragile та Antifragile?

• Fragile. Системи, які легко ламаються під тиском чи змінами. Вони не витримують стресу і стають менш ефективними або повністю виходять із ладу.
• Antifragile. Системи, що покращуються під впливом стресу, змін чи нестабільності. Вони адаптуються та стають більш стійкими.

Навіщо потрібні системи Antifragile?

1. Стійкість до збоїв. Antifragile системи витримують стреси й навіть покращуються, що підвищує загальну надійність.
2. Гнучкість та адаптивність. Такі системи краще справляються зі змінами та непередбачуваними ситуаціями.
3. Довгострокова ефективність. Antifragile системи стають продуктивнішими та надійнішими з часом.

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

• MTTD (Mean Time to Detect) — середній час виявлення проблеми. Ця метрика показує, наскільки швидко команда може виявити проблему або інцидент.
• MTTR (Mean Time to Recovery) — середній час на відновлення. Ця метрика вимірює, скільки часу потрібно для відновлення системи після інциденту.
• MTRS (Mean Time to Restore Service) — середній час відновлення сервісу. Показує, скільки часу потрібно для повернення сервісу до нормальної роботи після збою.
• SLO (Service Level Objective) — цільовий рівень сервісу. Це конкретні метрики, що визначають цілі для якості сервісу, наприклад, час відповіді або доступність.
• RPO (Recovery Point Objective) — точка відновлення даних. Визначає максимальну допустиму втрату даних у разі інциденту, показуючи, наскільки часто потрібно робити резервне копіювання даних.

Приклади інструментів Azure для створення Antifragile систем

1. Azure Auto-Scaling
   • Як допомагає: автоматичне масштабування ресурсів у відповідь на навантаження.
   • Як допомагає: автоматичне додавання віртуальних машин зі збільшенням трафіку.
2. Azure Traffic Manager
   • Як допомагає: управління трафіком та маршрутизація запитів.
   • Приклад: перенаправлення трафіку на доступні ресурси під час збоїв.
3. Azure Site Recovery
   • Як допомагає: забезпечення безперервності бізнесу та відновлення після збоїв.
   • Приклад: автоматичне відновлення критичних програм у разі збою.
4. Azure Chaos Studio
   • Як допомагає: тестування стійкості системи шляхом введення штучних збоїв.
   • Приклад: симуляція відмови сервісів для перевірки реакції системи.
5. Azure Backup
   • Як допомагає: захист даних та відновлення після втрат.
   • Приклад: регулярне резервне копіювання даних та їх швидке відновлення.

Висновок

Antifragile системи — це ключ до підвищення стійкості та надійності. Інструменти Azure, такі як Auto-Scaling, Traffic Manager, Site Recovery, Chaos Studio та Backup допомагають створювати системи, які не тільки витримують стрес та зміни, але й стають кращими з часом.

Підсумки

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

Наостанок варто згадати про вплив штучного інтелекту (AI) на SRE. У нові часи виникають нові виклики для SRE у сервісах на базі AI, які ми розглянемо у наступних статтях. AI відкриває нові можливості, але також вимагає адаптації наявних підходів до забезпечення надійності та стабільності систем.