Ця роль з часом стане такою ж поширеною, як QA Automation чи DevOps-інженер. Роль фахівця SRE завжди буде популярною, оскільки технології швидко розвиваються, а проєкти стають складнішими. Досвід SRE є важливим для компаній, які працюють над великими проєктами. SRE гарантує, що послуги та продукти компанії надійні, мають достатній для користувача час безвідмовної роботи та швидкі темпи вдосконалення. Більшість DevOps Engineers виконують тільки цю роль на проєкті. 18% фахівців мають також обов’язки DevSecOps, 7% працюють як DevOps і розробники, менеджмент а 12% поєднують одразу кілька ролей.
Ключові метрики SRE
Системи постійно змінюються, тому будь-якій організації потрібно вчитися керувати складними процесами для досягнення потрібної надійності. Користувачам потрібно, щоб системи працювали безперебійно, і щоб вони могли швидко відмовитися від сервісів, де виникає даунтайм або проблеми з продуктивністю. Недостатня надійність також має серйозні економічні наслідки, особливо в галузях, як-от електронна комерція, фінанси й охорона здоров’я. Коли відомо SLO, їх можна взяти за основу для бюджетів на помилки.
> Вимірювання доступності
Користувачі цього навіть не помітять, адже це не є ситуацією відмови. На його думку, важливо фіксувати усі (навіть незначні) інциденти. Навіть якщо ці edge-кейси побачили всього тисяча користувачів, все одно варто проаналізувати вплив. Якщо знаходять корисні інсайти, ними діляться з командою та закривають відповідні прогалини в моніторингу або end-to-end тестах. Як правило, на кожному постмортумі SRE-команда Preply генерує одну або дві першочергові задачі, щоби запобігти подібним проблемам у майбутньому, та декілька другорядних.
- Фахівці з DevOps/SRE/Operations, які нині живуть за кордоном, у середньому мають більше робочого досвіду, ніж їхні колеги в Україні.
- Як правило, на кожному постмортумі SRE-команда Preply генерує одну або дві першочергові задачі, щоби запобігти подібним проблемам у майбутньому, та декілька другорядних.
- Це професія, яка має великі перспективи майбутнього, оскільки нові системи стають все складнішими, а помилки можуть коштувати дорого.
- Частина DevOps-інженерів виконують на проєкті кілька ролей, окрім DevOps.
Тестування у SRE: чи є куди розвиватись
Скоріше за все, у вас просто недостатньо розвинуте бачення системи (так зване observability)», — пояснює Олексій. Команда SRE зазвичай співпрацює з командою розробників, щоб забезпечити максимальну надійність та швидкість розробки. Цей підхід здатен допомогти організаціям знизити ризик збоїв системи, покращити роботу та знизити витрати на управління IT-інфраструктурою. Тим паче, мова тут йде більше про людей та процеси, ніж про інструменти (Hello Agile;)).
Попередження інцидентів
Якщо протягом деплойменту відстежувати забагато метрик, система може видати хибнопозитивний результат», — ділиться Олексій. SRE-фахівців зазвичай приписують до системних адміністраторів або DevOps-інженерів, хоча це різні напрями. У нашій статті ми розглянемо 10 ключових аспектів SRE, які допоможуть тобі розібратися.
Від 99,9 до 99,99: кейс Preply
Він означає допустимий період, коли показники сервісу можуть бути нижчими за вказані в SLO. Жодна система не застрахована від збоїв на 100%, тому цей запас у вигляді бюджету на помилки і є необхідним. Якщо на нього пішло, наприклад, 30% бюджету, він вважається серйозним. Найнижчі зарплати у фахівців DevOps/SRE/Operations, які працюють у найменших компаніях. Ці роботодавці також частіше наймають менш досвідчених фахівців.
Продакшн-тести, з іншого боку, проводяться в режимі реального часу одразу на веб-сервісі. За їх допомогою можна оцінити правильність роботи розгорнутої системи створеної інженерами SRE. Тут мета інженерів-тестувальників (забезпечити стабільну якість продукції) добре поєднується з цілями SRE, а їх досвід допомагає швидко ставати своїми в командах SRE. Додайте до цього повільну відмову від QA-тестування, яке ми знаємо ще з часів водоспадної моделі розробки, і перехід на безупинне тестування в DevOps. Гадаю, всі ці фактори демонструють наскільки має сенс фахівцям з тестування спробувати себе в якості SRE. Щоби мінімізувати вплив інцидентів на систему, зокрема, використовують Canary-релізи — метод поетапного впровадження нового релізу (спочатку на обмежену групу користувачів, а за відсутності помилок — на всіх).
Від швидкості, з якою ви витрачаєте свій бюджет помилок, залежить, що планувати на наступний спринт і на чому має бути фокус команди. Ми вважаємо, що SLO – це внутрішня обіцянка рівня якості системи, яка має бути досягнута. Але ми вважаємо гарною практикою публікувати її для сусідніх команд. Це допомагає розуміти залежності і допомагає в плануванні роботи в майбутніх спринтах на основі даних. Філософія Google полягає в тому, щоб сприймати це, не як факап, а як нормальну процедуру, необхідну для повернення стабільності системи.
Продовжуємо детально аналізувати зарплати айтівців різних спеціалізацій. Цього разу зупинимося на зарплатах фахівців з DevOps/SRE/Operations, безпеки, сисадмінів та DBA. Після складання першої версії чек-лист буде далекий від досконалості і не вийде закріпити його в незмінному вигляді. У міру розвитку команд, інструментів і культури чек-лист потребуватиме оновлення.