Site Reliability Engineering: відповіді на 10 головних запитань про професію

26 червня
Григорій Бурмістров, System Analyst, Site Reliability Engineer в DataArt
Site Reliability Engineering: відповіді на 10 головних запитань про професію
Site Reliability Engineering зараз бурхливо розвивається, але у Східній Європі ще не стала мейнстрімом. Багатьом ця абревіатура досі здається загадковою, позицію SR-інженера плутають то з системним адміністратором, то з девопсом. Я зібрав найчастіші запитання про SRE та постарався відповісти, на кого чекають у новій професії та що чекає тих, хто наважиться спробувати в ній свої сили.

Так сталося, що фактично я почав займатися Site Reliability Engineering набагато раніше, ніж познайомився з цим терміном. Я вчився на програміста, але пропрацював їм недовго — пішов у системні адміністратори. Був головним системним адміністратором Mail.ru, навіть разом із ним йшов з DataArt (колись DataArt написав Mail.ru, а через пару років сервіс відокремився й переїхав до Москви). Але потім повернувся і до компанії, і до розробки, причому займався якраз питаннями продуктивності та надійності систем. Коли одному з наших клієнтів знадобилась експертиза в галузі SRE, виявилося, що мій досвід системного адміністратора, розробника та системного аналітика якраз відповідає вимогам до SR-інженера.

1. SRE — це з книжки, яку видав Google?

Взагалі так. Концепція Site Reliability Engineering з'явилась у Google ще в 2003 році. З того часу власні SRE-команди сформували багато компаній, перш за все, звісно, ті, успіх бізнесу яких безпосередньо пов'язаний із безперебійною роботою комп'ютерних систем (Apple, Microsoft, Facebook, Twitter, Dropbox, Oracle тощо). Широке поширення SRE почалося 4–5 років тому. За останні 2–3 роки список тих, хто виділяє відповідну роль у проектах, помітно розширився. Зрештою, хто зараз не залежить від внутрішніх IT-систем, їхньої надійності, продуктивності, інтеграції з зовнішніми сервісами?

Завдання Site Reliability-інженерів у різних компаніях можуть відрізнятися та залежать від типу самого бізнесу. У цьому сенсі SRE як відносно новий підхід нагадує Agile, який, як ви напевно помітили, в кожного свій. Проте, перелік знань і навичок, необхідних SR-фахівцю, в будь-якому разі збігатиметься приблизно на 80%.

2. Забезпечення надійності — просто модна назва техпідтримки?

Ні. Інша справа, що концепція SRE передбачає, що розробники не просто пишуть код, але і стежать, як він працює у продакшені. У цьому сенсі межа між девелопментом і експлуатацією тут стирається. Одне з завдань SRE-команди — не дозволити релізу перетворитися на пінг-понг між розробниками та DevOps-інженерами, коли кожен стверджує, що проблема виникає на іншій стороні.

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

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

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

3. SRE — розробник або DevOps?

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

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

4. Що таке reliability? Чи існують чіткі критерії вимірювання надійності?

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

Тільки навчившись вимірювати важливі для бізнесу показники, ми можемо приступити до процесу підвищення надійності. Зрозуміло, що при цьому зростає і вартість розробки, обслуговування та підтримки системи. До того ж ростуть вони експоненціально, особливо якщо йдеться про систему, що працює в різних регіонах, де виникає питання універсальної лінії (а найчастіше SRE має справу саме з такими складними історіями). І тут SRE виявляється ключовою фігурою при переговорах з бізнесом, оскільки може з посиланням на кількісні показники пояснити, наскільки система є надійною, якими проблемами чреваті вузькі місця та у що обійдеться усунення будь-якого з цих пляшкових шийок. Саме разом із представниками бізнесу SR-інженери встановлюють Service Level Objectives (SLO, ще одна важлива абревіатура!) – цілі рівня обслуговування, прийнятні показники надійності.

5. Якої освіти й досвіду вимагає робота SRE?

Концепція досі є новою, і готових фахівців на ринку практично немає. Тому ми на ці ролі розглядаємо і розробників (добре, коли SRE не боїться Python або Java), і DevOps-інженерів, готових глибше зануритися у код. На щастя, спектр завдань є дуже широким: від моніторингу та алертінгу – завдань цілком девопсовських, до складного траблшутінгу, доступного тільки досвідченим розробникам.

Класичні задачі: в логах сервера завжди закінчується пам'ять; або закінчується тред-пул – якісь треди не повертаються; або один з трьох серверів за лоад-балансером постійно перевантажений, хоча два інших працюють нормально. Це нетривіальні технічні проблеми, вирішення яких вимагає глибокого розуміння того, що знаходиться під капотом: як масштабуються системи в хмарах, як розподіляється навантаження та як сервер справляється з ним. Найімовірніше, розслідувати їх повинен розробник рівня Senior. Є завдання скоріш конфігураційні, є локальні та не такі складні.

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

6. SRE — протилежність фіча-девелопменту?

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

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

7. Чи є робота SRE рутинною?

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

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

За приклад завдання, які доводиться вирішувати SRE, наведу один досить типовий випадок. У якийсь момент розробники не помітили помилки в новому коді: той мультиплікував повідомлення на адресу сусідньої системи, причому міг послати їх і три, і сім разів. У нас це ніяких проблем не викликало, але ті, хто займався сусідньою системою, прийшли з питанням про збільшене навантаження. Довелося взяти код, сам собою нетривіальний і складний для розуміння, та зайнятися пошуком помилки. Це було непросто, помилка виявилася пов'язаною з використанням тредів у Java.

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

8. SRE працює разом із розробниками або є частиною окремої команди?

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

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

9. Чому можна навчитися, працюючи на позиції SRE?

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

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

Для DevOps-інженерів SRE є чудовою можливістю краще зрозуміти, як системи написані. Така робота дозволяє зануритися у код на рівень, який через 2-3 роки за бажанням дозволить розвиватися далі вже в ролі програміста.

10. Концепція SRE — це надовго? Такий досвід буде затребуваним?

Це назавжди, а досвід у перспективі може виявитися незамінним. SRE здатний стати стабільним джерелом доходу для будь-якої компанії, націленої на великі та складні ентерпрайз-проекти. Системи продовжують ускладнюватись, оверхеди – збільшуватись, а утримати в голові подробиці розгортання 200 мікросервісів майже неможливо. Тому роль SRE в найближчі роки може стати такою ж звичайною, як 10 років тому став QA Automation, а 5 років тому – DevOps. Щоб управляти проектами з сотнями розробників, обов'язково знадобляться люди, здатні протистояти можливому хаосу. Інакше додатки почнуть схлопуватися під власною вагою.

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

КОРИСНІ РЕСУРСИ

Матеріалів про SRE в академічному розумінні існує мало. Перш за все я б рекомендував всім, кому цікава ця тема, дві книги, видані Google та доступні безкоштовно: Site Reliability Engineering і The Site Reliability Workbook. Третю книгу за темою Seeking SRE: Conversations About Running Production Systems at Scale можна прочитати безкоштовно за 10 днів або купити на сайті видавництва O'Reilly. Досить компактне вступ до концепції SRE пропонує аналітична компанія New Relic (доступний тут у pdf).

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