У вебінара поганий звук, тому ми зробили розшифровку.
Мене звуть Медведєв Едуард. Я сьогодні поговорю про те, що таке SRE, як з'явилося SRE, які є критерії роботи у SRE-інженерів, трохи про умови надійності, трохи про її моніторинг. Ми пройдемося верхи, тому що за годину багато не розповіси, але я дам матеріали для додаткового ознайомлення, і ми всі чекаємо вас на . у Москві наприкінці січня.
Спочатку поговоримо про те, що взагалі таке SRE – Site Reliability Engineering. І як воно постало як окрема посада, як окремий напрямок. Все почалося з того, що в традиційних колах розробки Dev і Ops – це дві різні команди, як правило, з двома абсолютно різними цілями. Ціль команди розробки – викочувати нові фічі, відповідати потребам бізнесу. Мета команди Ops у тому, щоб усе працювало і нічого не ламалося. Очевидно, ці цілі прямо один одному суперечать: щоб усе працювало і нічого не ламалося викочувати нових фіч краще якнайменше. Через це виникає багато внутрішніх конфліктів, які намагається вирішити методологія, яка нині називається DevOps.
Проблема в тому, що чіткого визначення DevOps та чіткої імплементації DevOps ми не маємо. Я виступав на конференції в Єкатеринбурзі 2 роки тому і досі секція DevOps починалася доповіддю «Що таке DevOps». У 2017 році девопсу вже практично 10 років, але ми досі сперечаємося, що це таке. І це дуже дивна ситуація, яку спробував вирішити Google кілька років тому.
У 2016 році Google випустив книгу, яка називається "Site Reliability Engineering". І за фактом саме з цієї книги почався рух SRE. SRE - це конкретний варіант імплементації DevOps парадигми в конкретній компанії. Інженери SRE ставлять собі за мету забезпечити надійну роботу систем. В основному вони беруться з розробників, іноді з адміністраторів із сильним бекграундом розробки. І займаються тим, чим раніше займалися системні адміністратори, але сильний бекграунд у розробці та знання системи з погляду коду ведуть до того, що ці люди не схильні до рутинної адміністраторської роботи, а схильні до автоматизації.
Виходить, що DevOps парадигма в SRE-командах імплементується тим, що є SRE-інженери, які вирішують структурні проблеми. Ось він, той самий зв'язок Dev і Ops, про який люди вже 8 років говорять. Роль SRE схожа роль архітектора тому, що новачки SRE не стають. Люди на початку кар'єри ще не мають досвіду, не мають потрібної широти знань. Тому що SRE вимагає дуже тонкого знання, що саме та коли саме може піти не так. Тому тут потрібний якийсь досвід, як правило, і всередині компанії, і зовні.
Запитують, чи буде описана різниця між SRE та девопс. Вона щойно була описана. Можемо поговорити про місце SRE в організації. На відміну від такого класичного підходу DevOps, де Ops – це таки відокремлений відділ, SRE – це частина команди розробки. Вони беруть участь у створенні продукту. Є навіть підхід, де SRE – це роль, яка переходить від одного розробника до іншого. Вони беруть участь у рев'ю коду так само, як, наприклад, UX-дизайнери, самі розробники, іноді продуктові менеджери. На цьому рівні працюють SRE. Потрібен їх аппрув, потрібно їх ревю, щоб на кожен деплой SRE сказав: «Добре, цей деплой, цей продукт негативно не вплине на надійність. А якщо вплине, то у якихось допустимих межах». Про це ми також поговоримо.
Відповідно SRE має вето на зміну коду. І загалом це також призводить до якогось невеликого конфлікту, якщо SRE реалізовано неправильно. У тій самій книзі про Site Reliability Engineering багато частин, навіть не одна, розповідають, як уникнути цих конфліктів.
Запитують, яким чином SRE співвідноситься з інформаційною безпекою. SRE безпосередньо не займається інформаційною безпекою. У великих компаніях цим займаються окремі люди, тестувальники, аналітики. Але SRE точно також взаємодіє з ними в тому плані, що якісь операції, якісь комміти, якісь деплої, які торкаються безпеки, також можуть вплинути на доступність продукту. Тому SRE в цілому має взаємодію з будь-якими командами, у тому числі з командами безпеки, у тому числі з аналітиками. Тому в основному SRE потрібні, коли намагаються впровадити DevOps, але при цьому навантаження на розробників стає надто великим. Тобто сама команда розробки вже не справляється з тим, що тепер їм потрібно відповідати ще й за Ops. І виникає окрема роль. Ця роль планується у бюджеті. Іноді ця роль закладається у розмір команди, з'являється окрема людина, іноді їй стає хтось із розробників. Так, у команді з'являється перший SRE.
Складність системи, на яку впливає SRE, складність, яка впливає на надійність роботи, буває необхідною та випадковою. Необхідна складність - це коли складність продукту підвищується в тому обсязі, якого вимагають нові продуктові фічі. Випадкова складність - це коли складність системи підвищується, але продуктова фіча і вимоги бізнесу безпосередньо на це не впливають. Виходить, що або розробник припустився десь помилки, або алгоритм не є оптимальним, або вводяться якісь додаткові інтереси, які підвищують складність продукту без особливої необхідності. Хороший SRE цю ситуацію завжди має відсікати. Тобто будь-який коміт, будь-який деплой, будь-який pull-реквест, де підвищується складність за рахунок випадкового доповнення, повинен блокуватися.
Питання чому просто не найняти в команду інженера, системного адміністратора з великим багажем знань. Розробник у ролі інженера, кажуть нам, не найоптимальніше кадрове рішення. Розробник у ролі інженера не завжди оптимальне кадрове рішення, але мова тут про те, що розробник, який опікується, має трохи більше прагнення до автоматизації, має трохи більший багаж знань і скілсет для того, щоб цю автоматизацію впроваджувати. І відповідно ми зменшуємо не лише час на якісь конкретні операції, не лише рутину, а й такі важливі для бізнесу параметри, як MTTR (Mean Time To Recovery, час відновлення). Таким чином, і про це теж буде трохи пізніше, ми заощаджуємо для організації гроші.
Тепер поговоримо про умови роботи SRE. І насамперед про надійність. У невеликих компаніях, стартапа дуже часто виходить так, що люди припускають, якщо сервіс написаний добре, якщо продукт написаний добре і правильно, він буде працювати, він не зламається. Все, ми пишемо хороший код, тому ламатися нема чому. Код дуже простий, ламатися нема чому. Це приблизно ті ж люди, які кажуть, що тести нам не потрібні, тому що, дивіться, це три методи VPI, чому тут ламатися.
Це все очевидно неправильно. І цих людей дуже часто такий код дуже кусає на практиці, бо речі ламаються. Речі ламаються іноді непередбачуваними способами. Іноді люди кажуть, що ні, цього ніколи не станеться. А воно все одно трапляється. Буває досить часто. І тому ніхто ніколи не прагне 100% доступності, тому що 100% доступності не буває ніколи. Це норма. І тому ми завжди, коли говоримо про доступність сервісу, говоримо про дев'ятку. 2 дев'ятки, 3 дев'ятки, 4 дев'ятки, 5 дев'яток. Якщо переводити це на час даунтайму, то, наприклад, 5 дев'яток, це трохи більше 5 хвилин даунтайму на рік, 2 дев'ятки це 3,5 дня даунтаймів.
Але очевидно, що у якийсь момент відбувається зменшення POI, віддачі інвестицій. Перейти з двох дев'яток на три дев'ятки, це означає зменшити даунтайм на 3 з лишком дні. Перехід із чотирьох дев'яток до п'яти зменшує даунтайм на 47 хвилин на рік. І виходить, що для бізнесу це може бути не критично. І в цілому необхідна надійність це питання не технічне, насамперед це питання бізнесу, це питання продукту. Який рівень даунтайму допустимий для користувачів продукту, на що вони очікують, скільки вони платять, наприклад, скільки грошей вони втрачають, скільки грошей втрачає система.
Важливе питання у своїй, яка надійність інших компонентів. Тому що різниця між 4 та 5 дев'ятками не буде видно на смартфоні з 2 дев'ятками надійності. Грубо кажучи, якщо щороку щось ламається на смартфоні у вашому сервісі 10 разів, швидше за все 8 разів поломка сталася саме на боці ОС. Користувач до цього звик, і одного разу на рік не зверне уваги. Потрібно співвідносити ціну підвищення надійності та збільшення прибутку.
Якраз у книзі по SRE є гарний приклад збільшення до 4 дев'яток із 3 дев'яток. Виходить, що приріст доступності трохи менше 0,1 %. І якщо виручка сервісу становить 1 млн. доларів на рік, то приріст виручки 900 доларів. Якщо підвищення доступності на дев'ятку обійдеться нам менше, ніж 900 доларів на рік, цей приріст має фінансовий сенс. Якщо він коштує більше 900 доларів на рік, сенсу він уже не має, тому що приріст виручки просто не компенсує трудовитрати, ресурсовитрати. І 3 дев'яток нам буде цілком достатньо.
Це, звичайно, спрощений приклад, де всі запити рівні. І з 3 дев'яток до 4 дев'яток перейти досить просто, але при цьому, наприклад, перейти з 2 дев'яток до 3, це вже економія 9 тисяч доларів, вона може мати фінансовий сенс. Природно насправді провал запиту на реєстрацію гірший за провал на відображення сторінки, запити мають різну вагу. У них може бути зовсім різний критерій з погляду бізнесу, але все одно, як правило, якщо ми не говоримо про якісь специфічні сервіси, це досить надійна апроксимація.
Отримали питання, чи є SRE одним із узгоджувачів при виборі архітектурного рішення сервісу. Допустимо у плані інтеграції до існуючої інфраструктури, щоб не було втрат у її стабільності. Так, SRE так само, як впливають на pull-реквести, комміти, релізи, вони впливають на архітектуру, на впровадження нових сервісів, мікросервісів, на впровадження нових рішень. Чому я до цього говорив, що потрібний досвід, потрібна кваліфікація. По суті SRE це один із блокуючих голосів у будь-якому архітектурному та програмному рішенні. Відповідно SRE як інженер повинен, в першу чергу, не просто розбиратися, а й розуміти, як якісь конкретні рішення вплинуть на надійність, на стабільність, і розуміти, як це співвідноситься з бізнес-потребами, і з якого погляду це може бути. допустимо, а з якої ні.
Тому зараз можна поговорити про умови надійності, які в SRE зазвичай визначаються як SLA (Service Level Agreement). Скоріш за все, знайомий термін. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement можливий знаковий термін, особливо якщо ви працювали з мережами, з провайдерами, з хостингом. Це загальна угода, яка визначає працездатність всього вашого сервісу, пенальті, штрафи за помилки, метрики, критерії. А SLI це сама метрика доступності. Тобто, що може бути SLI: час відповіді від сервісу, кількість помилок у відсотковому співвідношенні. Це може бути пропускна здатність, якщо йдеться про якийсь файловий хостинг. Якщо йдеться про алгоритми розпізнавання, індикатор може бути, наприклад, навіть коректність відповіді. SLO (Service Level Objective) – це відповідно поєднання індикатора SLI, його значення та періоду.
Припустимо, SLA може бути такою. Сервіс доступний 99,95% часу протягом року. Або 99 критичних тикетів техпідтримки буде закрито протягом трьох годин за квартал. Або 3% запитів отримають відповіді протягом 85 секунди щомісяця. Тобто ми поступово приходимо до розумію того, що помилки та збої — це цілком нормально. Це допустима ситуація, ми її плануємо, ми на неї певною мірою навіть розраховуємо. Тобто SRE будує системи, які можуть помилятися, які мають нормально реагувати на помилки, які мають враховувати їх. І по можливості вони повинні обробляти помилки таким чином, що користувач або не помічає їх, або помічає, але є якийсь обхідний шлях, завдяки якому все не впаде геть.
Наприклад, якщо заливати відео на ютуб, і ютуб не може конвертувати його відразу, якщо відео занадто велике, якщо формат не оптимальний, то запит природно не впаде з тайм-аутом, ютуб не видасть помилку 502, ютуб скаже: «Ми все створили, ваше відео обробляється. Воно буде готове приблизно за 10 хвилин». Це принцип graceful degradation, який знайомий, наприклад, з розробки фронтенду, якщо ви колись цим займалися.
Наступні терміни, про які ми говоритимемо, які дуже важливі для роботи з надійністю, з помилками, з очікуваннями, це MTBF та MTTR. MTBF – це середній час між збоями, mean time between failures. MTTR Mean Time To Recovery, середній час до відновлення. Тобто скільки часу пройшло від моменту виявлення помилки, від моменту появи помилки до моменту відновлення повністю нормальної роботи сервісу. MTBF переважно виправляється роботою над якістю коду. Тобто тим, що SRE можуть сказати «ні». І потрібне розуміння всієї команди, що коли SRE каже «ні», він каже це не тому, що він шкідливий, не тому що він поганий, а тому що інакше всі страждатимуть.
Знову ж таки, є дуже багато статей, дуже багато методів, дуже багато способів навіть у тій самій книзі, на яку я так часто посилаюся, як зробити, щоб інші розробники не почали ненавидіти SRE. MTTR, з іншого боку, це робота над вашими SLO (Service Level Objective). І це здебільшого автоматизація. Тому що, наприклад, наш SLO це аптайм 4 дев'ятки на квартал. Отже, за 3 місяці ми можемо допустити 13 хвилин даунтайму. І виходить, що MTTR у нас ніяк не може бути більше ніж 13 хвилин. Якщо ми 13 хвилин реагуватимемо хоча б на 1 даунтайм, це означає, що весь бюджет на квартал ми вже вичерпали. Ми порушуємо SLO. 13 хвилин на реакцію та виправлення збою - це дуже багато для машини, але дуже мало для людини. Тому що поки людині прийде алерт, поки вона зреагує, поки вона розбереться помилково, це вже кілька хвилин. Поки людина зрозуміє, як її виправити, що саме полагодити, що зробити, то це ще кілька хвилин. І насправді навіть якщо просто потрібно перезавантажити сервер, як виявляється, або підняти нову ноду, то MTTR вручну це вже приблизно 7-8 хвилин. При автоматизації процесу MTTR часто досягає секунди, іноді мілісекунд. Google говорить про мілісекунди зазвичай, але в реальності все звичайно не так добре.
В ідеалі SRE повинен практично повністю автоматизувати свою роботу, тому що це впливає на MTTR, на його метрики, на SLO всього сервісу, і відповідно на прибуток бізнесу. Якщо перевищено час, запитують, чи покладається вина на SRE. На хороше, вина не покладається ні на кого. І це окрема культура, яка називається balmeless postmortem, про яку ми сьогодні не поговоримо, але розбиратимемо на Слермі. Це дуже цікава тема, яку можна багато говорити. Грубо кажучи, якщо перевищено відведений час на квартал, то винні потроху всі, а це означає, що звинувачувати всіх не продуктивно, давайте натомість, можливо, не звинувачувати нікого, а виправляти ситуацію і працювати з тим, що ми маємо. На мій досвід, такий підхід більшості команд, особливо в Росії, трохи чужий, але він має сенс і працює дуже добре. Тому я порекомендую наприкінці статті та літературу, які можна на цю тему почитати. Або приходьте на Слер SRE.
Поясню. Якщо перевищено час SLO у квартал, якщо даунтайм було не 13 хвилин, а 15, хто в цьому може бути винен? Звичайно, може бути винен SRE, тому що він явно допустив якийсь поганий коміт чи деплою. У цьому може бути винен адміністратор дата-центру, тому що провів, можливо, якийсь позаплановий maintenance. Якщо в цьому винен адміністратор дата-центру, відповідно в цьому винна людина з Ops, яка не розрахувала maintenance, коли погоджував SLO. У цьому винний менеджер, технічний директор чи хтось, хто підписував договір дата-центру і не звернув увагу, що SLA дата центру не розрахована на потрібний даунтайм. Відповідно всі потроху у цій ситуації винні. І значить, ні на кого немає сенсу покладати провину в цій ситуації. Але виправити її, звичайно, потрібно. Тому існують постмортеми. І якщо почитати, наприклад, постмортеми Гітхаба, а це завжди дуже цікава, маленька і несподівана історія в кожному конкретному випадку, можна замінити, що там ніхто ніколи не каже, що виявилася винна ця конкретна людина. Вина завжди доручається конкретні недосконалі процеси.
Перейдемо до наступного питання. Автоматизація. Я зазвичай, коли говорю про автоматизацію в інших контекстах, дуже часто посилаюся на таблицю, яка розповідає про те, наскільки довго можна працювати над автоматизацією завдання, щоб не зайняти на її автоматизацію більше часу, ніж ви заощаджуєте. Є загвоздка. Загвоздка в тому, що коли SRE автоматизують якесь завдання, вони заощаджують не тільки час, вони заощаджують гроші, тому що автоматизація безпосередньо впливає на MTTR. Вони економлять, якщо можна так сказати, мораль співробітників та розробників, яка теж вичерпний ресурс. Вони зменшують рутину. І це все позитивно впливає на роботу і як наслідок на бізнес, навіть якщо здається, що автоматизація не має сенсу з погляду тимчасових витрат.
За фактом майже завжди має і є дуже мало випадків, коли в ролі SRE щось автоматизувати не варто. Далі ми поговоримо про те, що називається error budget, бюджет на помилки. По факту виходить так, що якщо у вас все значно краще, ніж SLO, який ви поставили собі, це також не дуже добре. Це швидше погано, тому що SLO працює не лише як нижня, а й як приблизна верхня межа. Коли ви поставили собі SLO в 99% доступності, а у вас за фактом 99,99%, виходить, що у вас є якийсь простір для експериментів, який абсолютно не зашкодить бізнесу, тому що ви самі все це визначили, і ви цей простір не використовуєте. Ви маєте бюджет на помилки, які у вашому випадку не витрачено.
Що ми з ним робимо. Ми використовуємо її буквально на все. На тестування в умовах продакшена, на викочування нових фіч, які можуть вплинути на продуктивність, на релізи, на maintenance, на планові даунтайми. Зворотне правило також діє: якщо бюджет вичерпано, ми не можемо зарелізувати нічого нового, тому що в нас інакше перевищиться SLO. Бюджет вже вичерпаний, ми щось зарелізували, якщо воно вплине негативно на продуктивність, тобто, якщо це не якийсь фікс, який сам по собі підвищує SLO, то ми виходимо за бюджет, а це погана ситуація, вона вимагає розбору , постмортема, і можливо якогось виправлення процесів.
Тобто, виходить, що якщо сервіс сам по собі працює погано, і SLO витрачається і бюджет витрачається на не експерименти, не на якісь релізи, а сам собою, то розробникам замість цікавих фіксів, замість цікавих фіч, замість цікавих релізів. Замість якоїсь будь-якої творчої роботи доведеться займатися тупими фіксами, щоб повернути бюджет у порядок, або відредагувати SLO, а це теж процес, який не повинен надто часто відбуватися.
Тому виходить, що у ситуації, де в нас залишається більше бюджету на помилки, зацікавлені усі: і SRE, і розробники. Для розробників великий бюджет на помилки означає, що можна займатися релізами, тестами, експериментами. Для SRE бюджет на помилки та вхід до цього бюджету означає, що вони власне безпосередньо добре роблять свою роботу. І це впливає на мотивацію якоїсь спільної роботи. Якщо ви будете слухати ваші SRE як розробники, у вас буде більше простору на гарну роботу і набагато менше рутини.
Виходить так, що експерименти в продакшен це досить важлива і майже невід'ємна частина SRE у великих командах. І вона як правило носить назву chaos ingeneering, яка пішла від команди в Нетфлікс, що випустила утиліту, яка називається Chaos Monkey.
Chaos Monkey підключається до CI/CD пайплайну і випадково кидає в продакшені сервер. Знову ж таки, в SRE структурі ми говоримо про те, що сервер, що впав, - це само по собі не погано, це очікувано. І якщо це входить до бюджету, це допустимо та не шкодить бізнесу. Зрозуміло, у Нетфлікса є достатньо дублюючих серверів, достатньо реплікації, щоб це все можна було виправити, і щоб користувач загалом навіть не помітив, і тим більше ніхто не вийшов від одного сервера за бюджет.
У Нетфлікса в якийсь час був цілий набір таких утиліт, одна з яких Chaos Gorilla вимикає повністю одну з зон доступності в Амазоні. І подібні речі добре допомагають виявити, по-перше, приховані залежності, коли не зовсім зрозуміло, що впливає, що від чого залежить. А це якщо ви працюєте з мікросервісом, і документація не зовсім ідеальна, це може бути вам знайоме. І знову ж таки це добре допомагає виловлювати помилки в коді, які ви не можете спіймати на стейджингу, тому що будь-який стейджинг це все рівно не точна симуляція, через те, що інший масштаб навантажень, інший патерн навантажень, обладнання теж, швидше за все, інше. Пікові навантаження також можуть бути несподіваними та непередбачуваними. І таке тестування, яке знову ж таки не виходить за рамки бюджету, дуже добре допомагає відловити помилки в інфраструктурі, які стейджинг, автотести, CI/CD пайплайн ніколи не виловлять. І поки це все входить до вашого бюджету, не має жодного значення, що у вас там упав сервіс, хоча, здавалося б, дуже страшно, впав сервер, який кошмар. Ні, це нормально, це добре, це допомагає ловити помилки. Є бюджет, отже, можна його витрачати.
Запитання: яку літературу я можу порадити? Список наприкінці. Літератури дуже багато, пораджу кілька доповідей. Як працює, і чи працює SRE у компаніях без свого програмного продукту чи з мінімальною розробкою. Наприклад, в ентерпрайзі, де основна діяльність не ПЗ. В ентерпрайзі, де основна діяльність не ПЗ, SRE працює так само як і скрізь, тому що в ентерпрайзі так само потрібно використовувати, навіть якщо не розробляти, програмні продукти, потрібно викочувати апдейти, потрібно змінювати інфраструктуру, потрібно рости, потрібно скейлі. І SRE допомагають визначити та передбачити можливі проблеми у цих процесах та проконтролювати їх вже після того, як почнеться якесь зростання та потреби бізнесу зміниться. Тому що зовсім не обов'язково займатися розробкою ПЗ для того, щоб було SRE, якщо у вас є хоча б кілька серверів і у вас очікується хоча б якесь зростання.
Те саме стосується невеликих проектів, невеликих організацій, тому що великі компанії мають бюджет і простір для експериментів. Але при цьому всіма цими плодами експериментів можна користуватися будь-де, тобто SRE звичайно з'явилися в Google, в Нетфлікс, в Дропбоксі. Але при цьому невеликі компанії та стартапи вже можуть шанувати конденсований матеріал, почитати книги, подивитися доповіді. Вони починають чути про це частіше, дивляться на конкретні приклади, думаю, це окей, це справді може бути корисним, нам теж таке потрібно, класно.
Тобто всю основну роботу зі стандартизації цих процесів за вас уже проробили. Вам залишилося визначити роль SRE безпосередньо у вашій компанії і почати власне впроваджувати всі ці практики, які знову ж таки вже описані. Тобто з корисних принципів для невеликих компаній, це завжди визначення SLA, SLI, SLO. Якщо ви не займаєтесь ПЗ, то це будуть внутрішні SLA та внутрішні SLO, внутрішній бюджет на помилки. Це завжди практично призводить до якихось цікавих дискусій усередині команди та всередині бізнесу, тому що можливо виявиться, що ви витрачаєте на інфраструктуру, на якусь організацію ідеальних процесів, ідеального пайплайну набагато більше, ніж треба. І ці чотири дев'ятки, які у вас є в IT відділі, вони вам зараз не дуже потрібні. Але при цьому можна було витратити час, витратити бюджет на помилки на щось ще.
Відповідно моніторинг та організація моніторингу корисна для компанії будь-якого розміру. І в цілому ось цей спосіб думки, де помилки це щось допустиме, де існує бюджет, де існують Objectives, він знову ж таки корисний для компанії будь-якого розміру, починаючи від стартапів на 3 особи.
Останнє з технічних аспектів, про що можна поговорити, це моніторинг. Тому що якщо ми говоримо про SLA, SLI, SLO, ми ніяк не можемо без моніторингу зрозуміти, чи вписуємося ми до бюджету, чи дотримуємося наших Objectives, і як ми впливаємо на фінальний SLA. Я дуже багато разів спостерігав, що моніторинг відбувається таким чином: є якесь значення, наприклад, час запиту до сервера, середній час або кількість запитів до бази даних. Він має певну інженером норму. Якщо метрика відхиляється від норми, то прилітає е-мейл. Це все абсолютно марно, як правило, тому що веде до такого перенасичення алертами, перенасичення повідомленнями від моніторингу, коли людина, по-перше, щоразу повинна їх інтерпретувати, тобто визначати: чи значення метрики означає необхідність якихось дій. А по-друге, він просто перестає помічати всі ці алерти, коли переважно ніяких дій від нього при цьому не потрібно. Тобто хороше правило моніторингу і перше правило, коли реалізується SRE в тому, що повідомлення має приходити тільки тоді, коли потрібна дія.
У стандартному випадку є три рівні подій. Є алерти, є тікети, є логи. Алерти – це все те, що вимагає від вас негайної дії. Тобто, ось, все зламалося, треба лагодити прямо зараз. Тикети – це те, що потребує відкладеної дії. Так, треба щось робити, потрібно щось робити вручну, автоматизація не впоралася, але не обов'язково робити це протягом наступних кількох хвилин. Логи – це все те, що не потребує дії, і в цілому при хорошому розвитку подій ніхто ніколи не читатиме їх. Читати логи потрібно буде тільки коли вже в ретроспективі виявилося, що якийсь час щось ламалося, ми не знали про це. Або треба провести якесь розслідування. Але загалом усе те, що не потребує жодних дій, йде до логі.
Як побічний ефект від цього, якщо ми визначили, які події вимагають дій і добре описали, якими ці дії мають бути, це означає, що дію можна автоматизувати. Тобто що виходить. Ми йдемо від алерту. Ідемо до дії. Йдемо до опису цієї дії. І далі ми йдемо до автоматизації. Тобто будь-яка автоматизація починається з реакції на подію.
Від моніторингу ми переходимо до терміна, який називається Observability. Теж такий трохи хайп навколо цього слова останні кілька років. І мало хто розуміє, що це означає поза контекстом. Але основне значення в тому, що Observability це метрика прозорості системи. Якщо щось пішло не так, як швидко ви зможете визначити, що саме пішло не так, і яким був стан системи в цей момент. З погляду коду: у якій відбувся збій, у якому сервісі стався збій. Яким був стан, наприклад внутрішніх змінних, конфігурації. З точки зору інфраструктури це в якій зоні доступності стався збій, а якщо у вас стоїть якийсь Kubernetes, то в якому випадку відбувся збій, яким був стан поду. І відповідно Observability має пряму залежність із MTTR. Чим вище Observability сервісу, тим простіше визначити помилку, тим простіше виправити помилку, тим простіше автоматизувати помилку, тим нижче MTTR.
Якщо перейти до невеликих компаній знову, то дуже часто питають, навіть ось зараз, як чинити з розміром команди, і чи потрібно в невеликій команді наймати окремого SRE. Вже про це говорив трохи раніше. На перших етапах розвитку стартапу або, наприклад, команди це зовсім не обов'язково, тому що SRE можна зробити перехідною роллю. І це трішки пожвавить команду, бо є хоч якась різноманітність. І плюс підготує людей до того, що зі зростанням обов'язки SRE будуть змінюватися дуже значно. Якщо наймати людину, то в неї, зрозуміло, є якісь очікування. І ці очікування з часом не зміняться, а вимоги зміняться дуже сильно. Тому наймати SRE досить складно на ранніх етапах. Виростити своє набагато простіше. Але про це варто замислитись.
Єдиний, напевно, виняток, це коли є дуже жорсткі та добре певні вимоги щодо зростання. Тобто у разі стартапу це може бути якийсь тиск від інвесторів, якийсь прогноз на зростання одразу в кілька разів. Тоді найм SRE загалом виправданий, тому що його можна обґрунтувати. У нас є вимоги щодо зростання, нам потрібна людина, яка відповідатиме за те, що за такого зростання нічого не зламається.
Ще одне питання. Як бути, коли кілька разів розробники пиляють фічу, яка проходить випробування, але ламає прод, навантажує базу, ламає інші фічі, який процес впровадити. Відповідно в цьому випадку впроваджується саме бюджет на помилки. І частина сервісів, частина фіч тестується вже відразу в продажі. Це може бути canary, коли тільки невеликій кількості користувачів, але вже в продажі розгортається фіча, але вже з розрахунком на те, що якщо щось зламається, наприклад, у половини відсотка всіх користувачів, то все ще вкладеться в бюджет на помилки. Відповідно так, помилка буде, частина користувачів все зламається, але ми вже говорили про те, що це нормально.
Було питання щодо інструментів SRE. Тобто, чи є щось конкретне, що використовували SRE, і не використовували б всі інші. Насправді є якісь вузькоспеціалізовані утиліти, є якийсь софт, який, наприклад, імітує навантаження або займається canary A/B тестуванням. Але в основному інструментарій SRE це те, що вже використовують ваші розробники. Тому що SRE взаємодіє безпосередньо із командою розробки. І якщо у вас буде різний інструментарій, то вийде, що йде час на синхронізацію. Особливо якщо SRE працюють у великих командах, великих компаніях, де команд може бути кілька, тут дуже допоможе саме стандартизація саме в масштабах компанії, тому що якщо в 50 командах використовується 50 різних утиліт, це означає, що SRE повинен знати їх усі. І цього зрозуміло ніколи не станеться. І якість роботи, якість контролю, як мінімум, частини команд значно знизиться.
У нас вебінар добігає кінця. Якісь основні речі я встиг розповісти. Зрозуміло, нічого про SRE не можна розповісти та зрозуміти за годину. Але я сподіваюся, що вдалося передати цей спосіб думки, основні ключові моменти. І далі можна буде, якщо цікаво, заглиблюватись у тему, вчитися самостійно, дивитися на те, як це впроваджується в інших людей, інших компаніях. І відповідно на початку лютого приїхати до нас на Слерм SRE.
Слерм SRE - це триденний інтенсивний курс, в якому розповідатиметься приблизно про те, що зараз розповідаю я, але з набагато більшою глибиною, з реальними кейсами, з практикою, весь інтенсив спрямований на практичну роботу. Людей розподілять за командами. Ви все працюватимете над реальними кейсами. Відповідно у нас є інструктори з Booking.com Іван Круглов та Бен Тайлер. У нас є чудовий Євген Варавва з Ґуґла, із Сан Франциско. І я теж вам щось розповім. Тож обов'язково приїжджайте до нас.
Отже, перелік літератури. Є посилання на SRE. на ту саму книгу, вірніше на 2 книги про SRE, написані Гуглом. Ще одна , Де трохи докладніше розкриваються терміни та їх застосування. Наступні 3 це доповіді з SRE у різних компаніях. Перша – це кейнот від Бена Трейнера з гугл. Друга - . Третя знову ж таки про . Четверта доповідь від , який має лише 5 ключових SRE співробітників на 190 країн. Дуже цікаво подивитися на все це, тому що як DevOps означає дуже різні речі для різних компаній і навіть різних команд, так і SRE має дуже різне коло обов'язків, навіть у компаніях подібних розмірів.
Ще 2 посилання за принципами chaos ingeneering: , . І наприкінці є 3 списки із серії Awesome Lists про , про та про . Список SRE неймовірно величезний, не обов'язково проходити його весь, там близько 200 статей. Дуже рекомендовану звідти статті про capacity planning та про blameless postmortem.
Цікава стаття:
Дякую, що слухали мене весь цей час. Сподіваюся, що ви чогось навчилися. Сподіваюся, що у вас є достатньо матеріалів, щоб навчитися ще більшому. І до зустрічі. Сподіваюся у лютому.
Вебінар вів Едуард Медведєв.
PS: тих, хто любить читати, Едуард дав список літератури. Тих, хто вважає за краще розбиратися на практиці, чекаємо на .
Джерело: habr.com