Site Reliability Engineering: звідки взявся цей підхід і чим займаються SRE-фахівці

7 травня
Марцин Дерило, Site Reliability Engineer у DataArt
Site Reliability Engineering: звідки взявся цей підхід і чим займаються SRE-фахівці
У створенні та впровадженні програмного забезпечення здебільшого задіяні дві ключові сторони: команда розробників відповідає за написання і тестування коду, команда підтримки — за стабільну роботу системи після запуску і подальших оновлень. На відміну від розробників команда підтримки зазвичай не любить зміни. Це протиріччя ризикує перерости у відкритий конфлікт, який не може не позначитись на загальній ефективності.

РІШЕННЯ: SITE RELIABILITY ENGINEERING (SRE)

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

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

ЩО ТАКЕ НАДІЙНІСТЬ?

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

Однак SRE-фахівцям необхідні чіткі метрики, які допоможуть відстежити, наскільки добре працює їхня команда. Тому в SRE введено поняття індикаторів рівня обслуговування (Services Level Indicators, SLI) для оцінки показників, критично важливих для конкретного бізнесу. Задача команди SRE — надати способи їхнього вимірювання, визначити поточний стан системи, допомогти встановити цільові значення для цих метрик та змінювати систему в заданому напрямку.

Цілі рівня обслуговування (Service Level Objectives, SLO), акцентуючи увагу на аспектах роботи системи, найбільш важливих для бізнесу і користувачів, допомагають встановлювати очікування на програмному рівні. SLO дозволяють робити припущення про необхідний рівень надійності того чи іншого сервісу. До того ж ці показники є рухливими: їх можна коригувати в ході роботи, у процесі спостережень за поведінкою сервісу.

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

Досягнення 100 % SLO також має на увазі, що в майбутньому змінюватися нічого в системі не буде, а це означає відмову від інновацій.

Сенс SRE-підходу полягає в тому, щоб забезпечити сервісу достатню надійність, залишивши простір для можливих змін і заклавши похибку на випадок виявлення проблем і помилок у майбутньому. Це називається бюджетом на виправлення помилок (100 % мінус ваш показник SLO). У міру виходу нових версій ПЗ ви можете стежити за рештою бюджету на помилки, швидкістю його витрачання та на основі цього ухвалювати рішення. Якщо він тане надто швидко, можливо, вам варто пригальмувати або приділити більше уваги тестуванню перед релізом. Бюджет на помилки мають бачити всі: розробники, фахівці підтримки, SRE, представники бізнесу. Контроль за ним має природним чином врівноважувати інновації та стабільність, мінімізуючи конфлікти між командами розробників, які вносять зміни, та SRE, відповідальних за стабільність систем.

ОСНОВИ РОБОТИ SRE

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

Крім того, SRE мають реагувати на інциденти, розв’язувати ряд нетермінових питань щодо продакшену тощо. Якщо такої роботи дуже багато, команда може занудьгувати, що негативно позначиться на мотивації. Тому обсяг рутини потрібно обмежувати — у Google ліміт на неї встановлено на рівні 50 %.

У SRE-фахівця бувають дні, коли рутинної роботи більше, та дні, коли можна зосередитися виключно на інжинірингу. Але що робити, якщо перших забагато? Перш за все, про це має дізнатись менеджер, відповідальний за SRE. Можливо, вам варто наполягти на розширенні команди, щоб розподілити навантаження, або передати частину задач команді розробників. У принципі, обмеження обсягу рутинної роботи входить до зони відповідальності SRE. Якщо вчасно не потурбуватися про цю проблему, вона безпосередньо завадить основній задачі — інжинірингу: пошуку можливостей для поліпшення, впровадження інновацій, підвищення продуктивності та стабільності систем.

Власне інженерна діяльність SRE-фахівців буває двох видів:

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

На відміну від підтримки SRE-команда покликана забезпечити максимально швидкі зміни, дотримуючись узгоджених SLO та бюджету на виправлення помилок.

До речі, не звертаючись до ресурсів бюджету на помилки, ви досить сильно ризикуєте. В одній із книг, написаних SRE-командою Google, є класна історія про розподілений сервіс блокування. Він був дійсно стабільним і надійним — настільки, що багато інших сервісів стали покладатися на нього. Але одного разу сталось неймовірне: працювати він припинив, а разом з ним і інші, що вибудували з ним надлишкові залежності. Команда, що стоїть за цією системою, опублікувала свої SLO, щоб всі могли скорегувати очікування з урахуванням заявлених показників надійності. Щоб переконати інші команди, що їхній сервіс зовсім не є зразком абсолютної надійності, вони навіть почали спеціально запускати штучні перебої в продакшені. Таким чином їхній бюджет на виправлення помилок було витрачено. Мораль: ми повинні витрачати бюджети на помилки, економити їх безглуздо, а часом навіть шкідливо.

Наступний важливий елемент SRE — моніторинг. Існує декілька способів контролю стану системи: наприклад, оповіщення, тікети у JIRA чи інших системах, логування.

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

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

Також необхідно зміцнювати впевненість у собі у відповідальних за надзвичайні ситуації, готуючи їх за допомогою рольових ігор. Наприклад, Google використовує вправи з Wheel of Misfortune (“Колесо невдач”), які вчать не хвилюватися, коли дзвонить телефон або вмикається сигнал тривоги.

Підхід SRE зачіпає й управління змінами. Не варто розраховувати, що негативних наслідків нововведень можна цілком уникнути, але за допомогою SRE-підходу їх можна пом'якшити. Для цього розроблено спеціальні методи, наприклад, прогресивне розгортання, яке дозволяє швидко виявити проблему та відкотитися назад до останнього стабільного стану. Такі процеси потрібно автоматизувати — працювати з ними вручну досить нудно, що сприяє неуважності інженерів та призводить до зростання кількості проблем.

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

Як я дізнався на конференції в Дубліні цього року: під час інтерв'ю в Google кандидатам на позиції SRE пропонують виконати вправи з планування навантаження. До завдання на розробку системи (наприклад, служби обміну фотографіями) додають дані про те, скільки користувачів зареєструється, скільки фотографій буде завантажуватися щодня тощо. У відповідь потрібно назвати точні цифри: скільки машин вам потрібно, скільки дискового простору тощо.

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

ПАРА ПОРАД І РЕКОМЕНДАЦІЙ

Виходить, для підвищення надійності існує не так багато можливостей:

  • Гроші — вкладаючи в систему додаткові кошти, ви отримаєте більше надлишкових ресурсів або більші сервера.
  • Зниження якості: неповне завантаження сайтів, автоматичне переривання операцій з викликом резервних відповідей. Цей шлях часом обмежує функціонал, проте дозволяє системі продовжувати роботу і в разі помилок, при яких інакше вона б відключилася.
  • Збільшення часу очікування — повторні спроби, експоненціальне відкладання запиту і джиттери: у цьому випадку заради надійності ви жертвуєте часом.

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

  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    18 листопада
  • Україна, Remote.UA; Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    1 липня
  • Україна, Дніпро; Україна, Київ; Україна, Львів; Україна, Одеса; Україна, Харків; Україна, Херсон
    25 червня
  • Україна, Одеса
    25 червня