Одна з перших проблем, з якими можна зіткнутися під час адаптації SRE & DevOps практик, - це культура розробки. Без прийняття культури і мислення, що лежать в основі SRE, у вас просто з'являтимуться нові процеси, співробітники, ви навіть прочитаєте низку відомих книжок, але так, як у хлопців із гугла, зробити все одно не вийде - хоча б тому, що умови інші.
Фокус уваги на надійності систем вимагає переоцінки ставлення вашої організації в цілому як соціотехнічної системи до кількох найважливіших речей.
Як клієнти використовують ваші системи і що важливо для них?
Яке ставлення команд до інцидентів? Яких уроків навчилися? У командах довірчі відносини?
Чи ухвалюються рішення, які ґрунтуються на даних?
Ключові метрики
Згідно з класичним підходом, під час впровадження SRE насамперед треба визначити SLI, SLO і SLA.
SLI
SLI - це кількісні показники, які часто агрегуються за вікном виміру і виражаються у вигляді частки, середнього значення або процентиля.
Зазвичай SLI - це відношення двох чисел: кількість хороших подій, поділена на загальну кількість подій.
Наприклад, ви можете подивитися кількість успішних HTTP-запитів / загальна кількість HTTP-запитів. Значення SLI буде варіюватися від 0% (нічого не працює) до 100% (нічого не зламано).
Щоб допомогти командам визначити SLI, ми вирішили для початку взяти підхід, який використовується в Google, - ті самі "four golden signals" (latency, traffic, errors і saturation).
Latency - це показник, який говорить про затримки, він говорить про час, який потрібен для виконання запиту. Наприклад, низькі показники вказують на те, що система здатна швидко обробляти запити, а високі показники означають, що запити виконуються повільно.
Traffic вимірює швидкість запитів за певний період часу.
За допомогою Errors вимірюють кількість невдалих запитів.
Saturation вимірює кількість запитів, які система обробляє в цей момент.
Моніторинг цих показників є гігієнічним мінімумом і допомагає переконатися, що продуктивність системи залишається на бажаному рівні, і визначити області, в яких можна зробити поліпшення.
На жаль, у перші ітерації виходить визначити лише частину з цих показників, і варто зафіксувати хоча б їх. Рекомендація їсти слона по шматках, а не всього за раз тут доречна.
Як правило, критичний шлях користувача описує набір взаємодій користувача з сервісом або ланцюжком сервісів для досягнення певного кінцевого результату. Наприклад, це може бути додавання товару в кошик і оплата замовлення.
Звідки брати ці SLI? Хорошим кроком буде зіставити критичний шлях користувача і ваші наявні метрики: якщо якихось не вистачає, завжди можна додати, зазвичай хлопці з бізнесової частини здатні вам із цим допомогти.
Тепер давайте поговоримо про технічну частину. Це потрібно, щоб ми розуміли один одного і мали спільну термінологію. Ми збираємо метрики додатків, метрики зазвичай зберігаються в TSDB, а щоб отримати загальне розуміння метрик у цих ваших системах зберігання та моніторингу, давайте пояснимо, з чого воно складається. Зазвичай це value, sample, metric і time series.
Value - це значення, яке на будь-якому континенті значення, фактично це результат вимірювання. Наприклад, 100500 HTTP-запитів, які сервіс отримав з моменту старту.
Sample - це value + timestamp. Наприклад, 100500 HTTP-запитів, які сервіс отримав з моменту старту, виміряних 2022-12-31 16:30 UTC.
Metric - це унікальний ідентифікатор вимірюваного ресурсу. Він складається з імені сімейства метрик із прикріпленими до нього лейблами. Наприклад, http_requests_total{pod="billing-1"} і http_requests_total{pod="delivery-2"} - це дві різні метрики з сімейства метрик http_requests_total.
Time series (частіше "series") - це Metric + будь-яка кількість пов'язаних Sample з цим id. Наприклад, http_requests_total{pod="billing-1"} із семплами 700@16:30:00 UTC, 800@16:30:15 UTC, 900@16:30:15 UTC і т. д.
Active time series (частіше "active series") - це Metric, яка записала хоча б один семпл за останні 20 хвилин.
SLO
SLO - це чітко визначені, конкретні цілі або обіцянки для доступності системи.
SLO допомагає побачити розділову межу між щастям і нещастям користувачів, показує стан системи, чи працює система надійно, як це сприймають користувачі.
Ми вважаємо, що SLO - це внутрішня обіцянка рівня якості системи, яка має бути досягнута. Раз це обіцянка, то вона може бути приватною і публічною. Але ми вважаємо гарною практикою публікувати її для сусідніх команд. Це допомагає розуміти залежності і допомагає в плануванні роботи в майбутніх спринтах на основі даних.
Але для абстрактного щастя користувачів недостатньо просто збирати дані, далі потрібно визначитися з Error budget і Burn rate.
Бюджет помилок - це кількість помилок (обумовлених SLI), які ви можете мати за певний період часу, це залежить від обраних значень SLO, якщо вам ліньки рахувати в голові, є калькулятор (https://uptime.is/).
Burn rate - це швидкість витрачання бюджету помилок. Ми використовуємо це як один із підходів до оповіщення для роботи з управління нашими SLO як обіцянками і рівнем сервісу, який ми пообіцяли. Від швидкості, з якою ви витрачаєте свій бюджет помилок, залежить, що планувати на наступний спринт і на чому має бути фокус команди.
Взагалі, справедливо кажуть, що історії з книжок з SRE працюють тільки в Google. На папері все має гарний вигляд, але на практиці виявляється, що це працює тільки в них. І тим не менше це чудова ідея, яку вони просувають: вам не потрібно виставляти сотні показників на дашборд, для початку вистачить і одного значення SLO за доступністю.
Якщо недостатньо 4 золотих сигналів, то можна використовувати й інші індикатори.
Наприклад, для застосунків, крім згаданих чотирьох золотих сигналів, можна використовувати такі показники, як час відгуку, точність виводу, використання ресурсів і масштабованість.
Для баз даних та інколи для великих даних загальні показники включають ефективність запитів і затримки, якість і цілісність даних, час резервного копіювання та відновлення, доступність того, наскільки швидко ти можеш прочитати дані, які були записані.
Для черг можна використовувати такі метрики, як частота, кількість і розмір повідомлень, затримки, частота помилок, показники успішної доставки. Упевнений, що це тема для окремої статті, книги або воркшопу.
Як ще підвищити надійність додатків, незалежно від їхньої мови чи платформи?
Для додатків деякі з поширених методів включають ізоляцію компонентів, реалізацію стратегій самовідновлення, а також виконання періодичних перевірок.
Класична історія: користувач скаржиться на доступність сервісу, звісно ж, з'ясовується, що у всіх у команді "все працює! ось же зайшов, все відкривається!". Однак користувача не хвилює, що в конкретної команди одного з мікросервісів усе працює. У нього не працює, він не отримує сервіс. Доступність сервісу у користувачів - це головний пріоритет з точки зору SRE. Це дуже важливий момент, і він вимагає перебудови способу мислення.
Щоб спостерігати систему "очима користувача", звичайних систем моніторингу недостатньо. Завжди можна підняти умовний моніторинг і побачити, що поди рестартують або оперативна пам'ять зайнята на 90%, але це зазвичай не має жодного значення, якщо користувач не може замовити товар, наприклад ялинку на H, або бачить заглушку, яка просить його вимкнути впн. Якщо поди рестартяться - це нормально, якщо пам'ять зайнята за 90% - це теж нормально. Користувачі цього навіть не помітять, адже це не є ситуацією відмови. А ось якщо у користувача недоступний кошик - це проблема.
Запити на зміни
Поговорімо про зміни і про те, як ними керувати. Ми любимо і цінуємо процес RFC (request for change) - запитів на зміни.
*Терміном "RFC" ми називаємо одночасно і процес, і артефакт у вигляді документа.
Коли команда одного сервісу хоче внести зміну в продакшен, вона має отримати схвалення від команд залежних сервісів. Наприклад, хтось каже: "Наша команда хоче викотити зміну, яка торкнеться зміни API контракту з іншим сервісом". Його залежності відповідають: "Ні, в цей час у нас трафік, давай перенесемо". Вони домовляються про відповідний час і тільки тоді вносять зміни. RFC - невіддільна частина SRE.
У різних командах у процесі беруть участь різні люди. Це може бути як розробник, так і делівері-менеджер, який зацікавлений, щоб його сервіс відповідав обіцянкам. Вважаємо, що управління рівнем сервісу починається з прозорості та планування змін, це означає, що ти докладно описав у документі, які зміни буде зроблено, яких сусідів торкнеться, скільки часу планується, скільки часу знадобиться на відкат.
Чек-листи
Одного дня настає день, коли ти думаєш, що непогано було б мати чек-лист із перевірками готовності до продакшену.
Production readiness - це знову ж таки і процес, і документ, що дають змогу почати проєктування надійності сервісів у продакшені. Результатом роботи є документ зі списком виявлених проблем, що в довгостроковій перспективі має зменшити трудовитрати та ризики, з якими може зіткнутися продукт.
Добре складений чек-лист є важливим компонентом readiness'ів.
Треба не намагатися зробити ідеальний чек-лист, а за допомогою здорового глузду і минулого досвіду визначити важливі теми для обговорення. Мета полягає в тому, щоб заповнити прогалини, які можуть становити значний ризик, а не в тому, щоб розробити чек-лист, який може покрити все.
Один з основних чинників, який слід враховувати під час розроблення контрольного списку PR, полягає в тому, щоб не забігати занадто далеко вперед від поточного статусу систем.
Застосовувані найкращі практики і стан продуктів повинні враховуватися при створенні чек-листа, який дає конкретну, корисну інформацію, що розвиває зворотний зв'язок. Занадто велике захоплення найкращими практиками та рекомендаціями (наприклад, обговорення використовуваних шаблонів проєктування коду) може стати слизькою доріжкою, повільно перетворюючи readiness'и на огляд архітектури з кількома практичними пропозиціями.
Після складання першої версії чек-лист буде далекий від досконалості і не вийде закріпити його в незмінному вигляді. У міру розвитку команд, інструментів і культури чек-лист потребуватиме оновлення.
Такі підходи повсюдно використовуються в Google, Spotify, Ringcentral, Grafana, Weaveworks і в інших технологічних компаніях.
Чек-листи - це база для майбутньої автоматизації.
Доброю практикою є публікація свого чек-листа. Це може бути як сторінка в системі зберігання знань всередині компанії, так і репозиторій на github.
Інциденти
Управління інцидентами - напевно, головний стовп, з якого виросла культура SRE. Що важливо: усунути вплив і після обговорити, як не допустити повторення поведінки системи в майбутньому для цієї або інших систем, поділитися своїм досвідом і спостереженнями з колегами.
Наприклад, вплив (impact) може бути внутрішнім, або інфраструктурним, а може і чинити негативний ефект на досвід користувачів.
Якщо стався інцидент, інженер має відповісти на 3 запитання.
Що сталося?
Який вплив?
Які наступні кроки?
Після цього слід ухвалити кілька рішень.
Відкривати інцидент чи це не інцидент зовсім?
Які кроки зробити, щоб пом'якшити вплив, це тимчасові чи довготривалі кроки?
Можливо, виділити більше ресурсів (залучити інші команди/експертів)?
Постмортеми - це добре
Як відомо, хороший постмортем - це заповнений постмортем.
Postmortem (або root cause analysis report) - це знову і процес, і документ для дослідження інциденту та визначення причин його виникнення. Він допомагає виявити слабкі місця в системі та розробити заходи щодо їх усунення, щоб уникнути повторення подібних ситуацій у майбутньому.
Postmortem є частиною процесу управління надійністю системи і зазвичай містить такі кроки.
Збір інформації про інцидент: час і дата виникнення, деталі проблеми, яких сервісів і компонентів торкнулися.
Визначення причини інциденту: пошук кореневої причини проблеми і виявлення будь-яких факторів, які могли її спровокувати.
Розробка плану дій: складання списку заходів, які необхідно вжити, щоб усунути проблему і запобігти її повторенню.
Напевно, найцікавіша частина після розслідування події полягає в подальшому плані дій. І тут відкритий спектр підходів. Наприклад, як це виправити для сервісу. Як підійти до плану з точки зору системного дизайну. Як масштабувати ваші зміни на схожі типові сервіси. Де ще в компонентах є ймовірність повторення точно такої самої помилки. Як почати нову ініціативу, якщо вона виходить за межі завдання на спринт.
Нехай це буде дружнім нагадуванням: якщо ви не маєте процесу та детальних документів, то саме час спробувати їх у своїх командах. Це весело!
Ретроспективи
Ретроспектива - це один зі способів для учасників вашої команди дізнатися, що вони роблять правильно, де можуть покращити, як уникнути повторення одних і тих самих помилок і, найголовніше, як критично думати про те, як вони працюють разом. Добре продумані ретроспективи дають змогу командам ітеративно покращувати свій продукт і процес співпраці.
Базове правило для ретро і постмортемів - це беззвинувачувальна риторика. Це дає змогу зростити довіру ваших котанів.
Колесо невдачі
Наступна найкраща практика, яка допоможе вашим інженерам бути вищими, сильнішими і сеньйорнішими, це проведення уявних експериментів. "Що?! - скажете ви. - Роботи на півроку вперед, а він тут уявні експерименти пропонує!" Але це зовсім не жарт.
Wheel of Misfortune (https://github.com/dastergon/wheel-of-misfortune) - це хороший привід зібратися разом і помалювати графіки.
Мета уявного експерименту - зміцнити впевненість чергових інженерів за допомогою симуляції сценаріїв збоїв. Це той випадок, коли ви практикуєтеся у налагодженні проблем в умовах без стресу, покращуєте розуміння процесу управління інцидентами і робите успіхи в ефективному спілкуванні з іншими інженерами вашої команди. Це чудовий спосіб навчити нових співробітників, стажерів. Колесо невдачі сподобається навіть досвідченим фахівцям.
Тренування інженерів - це насамперед весело...і корисно.
