Я перейшов з DevOps у SRE: ось чим я зараз займаюсь

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Привіт, мене звати Олександр, і я SRE в українській продуктовій компанії Brainstack_. До цього я працював на позиції DevOps Engineer п’ять років, а позиції SRE у компанії взагалі не існувало. З часом я почав проявляти все більше інтересу до позиції SRE, самостійно опанував необхідні навички й перейшов на цю роль всередині компанії.

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

Чим займається SRE та навіщо він бізнесу

SRE (Site Reliability Engineer) займається питаннями стабільності, відмовостійкості та розширення системи, а також аналізом інцидентів.

З власного досвіду скажу, що розширення системи варто планувати вже і за 65% використаних ресурсів. Особливо це актуально для компаній, що використовують фізичні сервери, адже замовлення, встановлення та налаштування вимагає багато часу. Якщо ж компанія використовує клауд — це набагато простіше. Там працює автоскейлінг і розширення відбувається у пару кліків за хвилину.

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

Чим відрізняється фокус роботи SRE від інших ролей

SRE vs DevOps

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

Натомість DevOps зосереджений на продукті та комунікації з командою. Його завдання проконтролювати, аби команда розробки мала інструменти для ефективної праці, а головний фокус — на налаштуванні інструментів розробки та доставки ПЗ: систем безперервної інтеграції, автоматизованого тестування, розгортання тощо.

Однак SRE тісно співпрацює з DevOps для створення надійної інфраструктури. Наприклад, допомагає в налаштуванні систем моніторингу та алертингу.

SRE vs Системний адміністратор

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

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

SRE vs DevSecOps

DevSecOps відповідає за вбудовування заходів безпеки (сек’юріті) на всіх етапах життєвого циклу ПЗ: кодування, збірки, тестування, доставки. А SRE фокусується саме на надійності та доступності систем в продакшені.

Звісно, не всі компанії наймають трьох різних людей на ці ролі, і досить часто цю посаду обіймає універсальний фахівець. У малих компаніях це, може, і працює, але за великого спектру роботи, це призводить до розфокусу співробітника та зниження його продуктивності. Девопс, який займається усім, зокрема збіркою CI/CD, не буде такий ефективний. Як мінімум через брак часу.

Головні функції SRE інженера

Аналіз інцидентів та постійне вдосконалення системи

• Моніторинг та розслідування причин інцидентів в роботі системи.
• Збір метрик (KPI) для аналізу — час простою, фінансові втрати.
• Розробка рекомендацій для поліпшення архітектури, інфраструктури, коду, процесів.
• Впровадження змін для мінімізації майбутніх інцидентів.

Забезпечення масштабованості та розширюваності

• Моніторинг використання ресурсів і прогнозування зростання навантаження.
• Рекомендації з розгортання нових серверів, баз даних.
• Оптимізація архітектури для кращої розподіленості навантаження.

Розробка СЛО/SLI та постійне їх вдосконалення

• Визначення Service Level Objectives (SLO) — умов надійності системи.
• Аналіз Service Level Indicators (SLI) — частота інцидентів та час необхідний на їх вирішення.
• Регулярний перегляд цільових показників якості та їх підвищення.
• Автоматизація збору метрик та генерування звітності по досягненню SLO.

Які інструменти використовує SRE

Інструменти SRE та DevOps фахівців дуже схожі. Тому і вважається, що «заходити» в цю професію найкраще через DevOps. У своїй роботі я використовую:

• PagerDuty — система оповіщення про інциденти. Це один з найважливіших інструментів для SRE. Він допомагає реагувати на інциденти у будь-який час та зменшувати ризики.
• Jenkins, GitLab CI — для автоматизації тестування, збірки та деплою коду.
• Zabbix, Prometheus, Grafana — збір метрик для моніторингу та побудови графіків KPI.
• ELK stack — для збору та аналізу логів.
• Python — автоматизація та створення сервісів. Наприклад, для збору й аналізу сервісних метрик.
• Pingdom — система аналізу доступності сайтів та робота заданих сценаріїв на них.
• Sentry — система збору і аналізу помилок.
• Locust — інструмент проведення навантажувальних тестів.

Навички, необхідні SRE

Розробка: вміти аналізувати код та знаходити причину, чому він не працює. Наприклад, ви запустили новий реліз, і користувачі помічають помилку. SRE в такому випадку може визначити, проблема у коді чи інфраструктурі, та швидко зреагувати. Тому буде перевагою для SRE володіти мінімум двома мовами програмування: Python та тією, з якою працює компанія (в моєму випадку це PHP).

Моніторинг: вміти працювати з системами збору метрик і вчасно проводити аналіз задля забезпечення безперебійної роботи. Постійно вдосконалювати систему моніторингу та реагування на інциденти.

Аналітичне мислення: швидко розбиратися у великій кількості метрик і логів, знаходити причинно-наслідкові зв’язки між подіями.

Управління проектами: якісно планувати і організовувати заходи для підвищення надійності системи.

Комунікація: взаємодія з різними командами (девелопери, сисадміни, СТО, фінансовий відділ). SRE розраховує фінансові запити та допомагає покращити взаємодію у командах.

Як я перейшов із DevOps у SRE

Моя головна мотивація у роботі — це нові виклики. Я вже понад 10 років в ІТ, з яких 5+ провів на посаді DevOps. Прагнення розвитку та зацікавленність у нових викликах привели мене до того, що я почав опановувати SRE.

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

Також корисно буде прочитати книги для професійного зростання: Building Secure & Reliable Systems, Site Reliability Engineering та The Site Reliability Workbook.

Перспективи SRE

Згідно з дослідженням зарплат DOU за зиму 2024 року, середня заробітна плата SRE складала $4 500 (у DevOps — $3 500). Але, на мою думку, потенційно вища зарплата — не те, що має мотивувати девопса змінити позицію. Набагато важливіше ваше прагнення вирішувати нові виклики, зацікавленість у роботі та покращення навичок.

Професія SRE зараз усе більше користується попитом. Вона входить до рейтингу Linkedin Jobs on the Rise, а за даними Gartner, до 2027 року 75% компаній використовуватимуть практики SRE у своїх організаціях для оптимізації операцій. Для порівняння — у 2022 цей показник був лише 10%.

Тож якщо ви шукаєте нових можливостей для розвитку і відчуваєте у собі жагу до опанування SRE, зараз саме час закладати фундамент для майбутнього. Тим паче, що в перспективі SRE може вирости до Head of Engineering чи CTO.