Карьера в IT: Site Reliability Engineer

[Kate]

В новой статье серии «Карьера в IT» разберемся, чем занимается Site Reliability Engineer — специалист, который отвечает за надежность, масштабируемость и бесперебойную работу IT-систем. SRE работает в пограничной области между DevOps и разработкой.

Об этой специализации нам рассказали Юрий Рочняк (N26), Алексей Глущенко (GlobalLogic), Станислав Полчаников (EPAM Ukraine), Евгений Старченко (SPS Commerce), Александр Драч (Upwork) и Дмитрий Бурьянов (Namecheap).

Особенности направления​

Концепцию Site Reliability Engineering придумали в 2003 году в Google. Ее создал вице-президент компании Бенджамин Трейнор, пытаясь решить проблемы Google с доступностью и стабильностью сервисов. Он собрал команду из сотрудников с разными специализациями: разработчиков, тестировщиков, Ops- и DevOps-инженеров — всех, кому было интересно улучшить работу системы.

Постепенно команда Трейнора решила проблемы с бесперебойной работой сервисов. А Бенджамин сформулировал новый подход к надежности IT-систем и подробно описал его в своей книге. По его словам, SRE — это «то, что происходит, когда программисту поручают то, что раньше называлось операциями».

Вслед за Google SRE-команды появились и в других компаниях, которые разрабатывают высоконагруженные системы: Apple, Facebook, Microsoft, Twitter, Oracle. Сейчас вакансии SRE открываются в IT-компаниях разного размера и направления.

«Работа SRE позволяет минимизировать время простоя сервисов компании и таким образом привнести больше уверенности в завтрашнем дне для пользователей и собственников бизнеса» (Евгений Старченко, Lead SRE в SPS Commerce).

На момент публикации на DOU открыто 11 вакансий на позицию SRE (7 по ключевому слову Site Reliability Engineer и 4 — по SRE). Из них 10 в Киеве и одна за рубежом. Но, по словам специалистов, с каждым годом популярность этого направления набирает обороты.

Зарплатные вилки SRE сравнимы с зарплатами DevOps-инженеров: около $2000 у специалистов с опытом работы до трех лет, от $3000 — у тех, кто работает в отрасли 4-5 лет и больше.

Задачи и обязанности​

Круг обязанностей SRE — на стыке между операционными задачами и разработкой автоматизированных систем. Туда может входить:

• настройка и обработка сигналов о проблемах в системе;
• мониторинг и логирование;
• управление сервисами так, чтобы их обновление не «укладывало» систему;
• прогнозирование роста сервисов и запросов для вычислительных мощностей;
• расчет оптимальной мощности для новой системы;
• проверка и контроль за тем, чтобы система была загружена оптимально и на ее работу не тратились лишние деньги.

«В нашем SRE-отделе есть несколько команд, которые отвечают за разные направления: CI/CD, Observability, Networking и так далее. Моя команда занимается инфраструктурой и масштабируемостью системы. Мы разрабатываем и поддерживаем внутренние инструменты (в нашем случае это Go и Python), пишем разные IaC, CI/CD пайплайны. И, конечно, он-колл» (Юрий Рочняк, Site Reliability Engineer в N26).

«Наша команда SRE состоит из небольших команд мониторинга, build-инженеров, автоматизации инфраструктуры, поддержки. Мы делаем все, чтобы результаты труда программистов попали к конечному пользователю как можно быстрее и качественнее. Это воплощение DevOps-подхода в рамках инфраструктуры. Мы отвечаем за то, чтобы разработчики могли легко и интуитивно пользоваться CI, не отвлекаясь на рутину» (Станислав Полчаников, Lead Systems Engineer в EPAM Ukraine).

«Основні обов’язки нашої команди SRE — перевірка надійності, відмовостійкості та стресостійкості систем, моніторинг, управління інцидентами, хаос-інжиніринг. А також — спільна робота з іншими командами над автоматизацією процесів задля зменшення ймовірності людської помилки» (Олександр Драч, SRE Team Lead в Upwork).

«Моя робота охоплює траблшутинг, аналіз деградацій сервісів, розробку та обслуговування інфраструктури, обслуговування CDN-провайдерів і комунікацію з ними, забезпечення роботи системи при DDoS, ротацію паролей для сервісних акаунтів. Крім цього, мені важливо бути на зв’язку 24/7 на випадок, якщо трапиться щось серйозне» (Дмитро Бур’янов, SRE в Namecheap).

Алексей Глущенко, Technical PM в GlobalLogic (до этого — SRE lead в Wirex), выделяет пять мифов об обязанностях SRE, с которыми он часто сталкивался:

• «SRE — это мониторинг + он-колл». На самом деле эти функции должна выполнять служба технической поддержки либо служба мониторинга. Никто не будет работать в круглосуточном мониторинге: это сжигает потенциал хорошего разработчика.
• «SRE должна решать любые проблемы без изменения софта». SRE — это комплекс мероприятий по увеличению надежности системы. А эта задача решается не только изменением окружения или настройкой супермониторинговой системы, а и работой с софтом.
• «SRE — это подразделение DevOps». Обе эти команды сконцентрированы на одном и том же. А значит, это равноценные команды — как FE и BE в разработке. Если DevOps-инженер занимается автоматизацией жизненного цикла приложения, то SRE отвечает за стабильную работу системы.
• «SRE решает все проблемы». Проблемы могут крыться не только в качестве кода, глубине мониторинга, типе выбранного облака, логирования и дороговизне окружения, а еще в качестве процессов и менеджмента.
• «SRE — волшебная пилюля против плохого софта». На самом деле, чтобы улучшить доступность сервиса и качество системы, нужно нанять не только SRE, DevOps, QA или талантливого программиста, а и пересмотреть подход компании в целом к качеству предоставляемых услуг. Если у сотрудников нет полномочий на решение проблемы, она никогда не будет решена.

Типичный рабочий день SRE во многом зависит от проекта и его фазы.

«Я работаю над проектом в фазе активной разработки. Сейчас „прикручиваю“ мониторинг в сервисы, до этого занимался полным построением CI-процесса. Примерно 80% времени уходит на разработку и тестирование, 20% — на митинги и помощь разработчикам. Когда сайт выйдет в продакшн, пропорция будет примерно 50/50, так как сложность внесения изменений сильно возрастет» (Станислав Полчаников, Lead Systems Engineer в EPAM Ukraine).

«Мой рабочий день может включать, например, автоматизацию на Python, Go с использованием Serverless, деплоймент на Terraform или CloudFormation, создание MVP c использованием нового облачного сервиса или платформенного решения вроде Kubernetes или ECS. Много времени занимает консультирование команд, ревью пул-реквестов, конфигурирование CI/CD или другой SaaS-системы. Меньше — траблшутинг и написание документации» (Евгений Старченко, Lead SRE в SPS Commerce).

«Мне поступают разные задачи: как разработка внутренних инструментов, то есть написание кода, так и поддержка существующих сервисов, написание конфигурации Terraform, Helm-чартов. Мы в компании стараемся идти по принципу „platform as a service“ — то есть предоставлять продуктовым командам инструменты для работы как сервису» (Юрий Рочняк, Site Reliability Engineer в N26).

Преимущества и недостатки​

Среди привлекательных сторон профессии SRE отмечают возможность работать с новыми технологиями, а также максимально широкий спектр задач:

«У SRE широкие полномочия и спектр обязанностей. В нашей профессии могут быть счастливы и те, кто пишет код, и те, кто ищет различные способы решения проблем, прежде чем прибегать к написанию кода. К тому же мы тестируем и внедряем новые технологии и подходы, оставаясь на острие технологического стека — эти знания способствуют удорожанию специалиста на рынке» (Евгений Старченко, Lead SRE в SPS Commerce).

«SRE, на мой взгляд, находятся недалеко от архитекторов в плане охвата, широты взгляда на проект. Кроме того, это направление быстро развивается. За пять лет технологии поменялись на глазах — скука в таких условиях точно не грозит. А еще я радуюсь, когда разработчики отмечают удобство настроек и легкий процесс работы» (Станислав Полчаников, Lead Systems Engineer в EPAM Ukraine).

«Что меня всегда привлекало в подобных „гибридных специальностях“ — это разнообразие задач. Это дает некую гибкость и свободу выбора. Можно позволить себе балансировать между сложными интересными задачами, которые требуют много личных ресурсов и простой понятной рутиной. Ну и чего греха таить, согласно многим опросам по разным странам, это одна из самых высокооплачиваемых позиций в IT» (Юрий Рочняк, Site Reliability Engineer в N26).

«Приваблює можливість співпрацювати з архітекторами й розробниками різних компонентів для розуміння, як ті взаємопов’язані. Тобто будувати картину архітектури як на загальному рівні, так і заглиблюватися в деталі. Окрім того, подобається давати їм зворотний зв’язок, який зрештою допомагає покращити наш продукт» (Олександр Драч, SRE Team Lead в Upwork).

К недостаткам специалисты относят «операционку», сверхвысокий уровень ответственности и необходимость часто переключаться между разными задачами, в том числе реагировать на «пожары»:

«Операционку никто не отменял. Над какими бы амбициозными задачами вы сейчас не работали, нужно быть готовым, что сейчас что-то произойдёт. Нужно быть начеку. Да и сами задачи прилетают с разных сторон — очень часто приходится переключать контекст» (Юрий Рочняк, Site Reliability Engineer в N26).

«Определенную уникальность роли SRE в проектной команде можно считать как плюсом, так и минусом. Уровень ответственности порой зашкаливает, и вряд ли получится ее делегировать: если что-то сломалось — встаешь и смотришь, что не так. По этой же причине не всегда возможно уйти в спонтанный отпуск» (Станислав Полчаников, Lead Systems Engineer в EPAM Ukraine).

«З недоліків зазначу лише те, що в неробочий час тобі можуть зателефонувати, наприклад, з питаннями щодо роботи з PagerDuty. Або подзвонить змінний інженер і скаже, що щось трапилось і потрібна твоя допомога» (Дмитро Бур’янов, SRE в Namecheap).

«Есть стереотип, что при любой проблеме виноват SRE. Это идет из древних времен, когда казнили посла с плохими новостями» (Алексей Глущенко, Technical PM в GlobalLogic, до этого — SRE lead в Wirex).

Как стать SRE и куда двигаться дальше​

В Западной Европе и США каноничным считается путь в SRE из разработки: программисты начинают интересоваться, что же под капотом у инструментов, с которыми они работают. В Украине же большинство SRE приходят в эту специализацию из DevOps или системного администрирования.

«Мне кажется, SRE — это естественная эволюция позиции „сисадмин широкого профиля“. Я сам начинал в службе поддержки, потом занимался системным администрированием. Затем познакомился с DevOps, облаками, автоматизацией. Позже подучил программирование — и вот я SRE» (Юрий Рочняк, Site Reliability Engineer в N26).

«Для меня это было эволюционное развитие. Я учился на DevOps-направлении EPAM University Programs, знал сети и программирование. Со временем стал понимать, что занимаюсь SRE» (Станислав Полчаников, Lead Systems Engineer в EPAM Ukraine).

«Я довго працював сисадміном у кількох компаніях. Також у мене були фриланс-проєкти, пов’язані з роботою в навантажених вебсервісах. Це дало бекграунд, щоб продовжити кар’єрний шлях у ролі SRE» (Дмитро Бур’янов, SRE в Namecheap).

Чтобы стать SRE, нужно уметь работать с Linux (зайти и глянуть логи, отсортировать, посмотреть загрузку процессора), знать одну из систем мониторинга (Nagios, Zabbix, Prometheus), одну из систем логирования (Splunk, ELK), а также писать на одном из высокоуровневых языков разработки (Node.js, Java, C#, C++, Python). В плане необходимых компетенций можно ориентироваться на DevOps Roadmap.

Главные источники знаний по SRE — книга Бенджамина Трейнора, создателя этого направления, а также другие классические книги от специалистов Google:

• The Site Reliability Workbook by Betsy Beyer, Niall Richard Murphy, Dave Rensin, Kent Kawahara and Stephen Thorne;
• Site Reliability Engineering by Betsy Beyer, Niall Richard Murphy, Chris Jones and Jennifer Petoff.

Другие полезные книги:

• The Phoenix Project by Gene Kim, Kevin Behr, George Spafford (на русском);
• The DevOps Handbook by Gene Kim, Patrick Debois, John Willis (на русском);
• Continuous Delivery by Jez Humble, David Farley;
• Accelerate by Nicole Forsgren, Jez Humble, Gene Kim.

Больше материалов по введению SRE собрано здесь: Google SRE, SRE University, Awesome SRE. А новости из мира DevOps и SRE можно почитать в телеграм-канале CatOps.

«Junior SRE может начать с круглосуточного мониторинга посменно — и постепенно перенимать знания старших специалистов, писать софт по автоматизации и мониторингу» (Алексей Глущенко, Technical PM в GlobalLogic, до этого — SRE lead в Wirex).

«Мир динамичен, новые инструменты возникают часто. Необходимо получать знания из смежных дисциплин, расти вширь, выглядывать за пределы своей „песочницы“. И готовиться к ситуациям, когда будешь седеть или терять волосы на нервной почве Я утрирую, конечно, но доля правды в этом есть» (Станислав Полчаников, Lead Systems Engineer в EPAM Ukraine).

«Звісно, SRE не обійтись без знання англійської, щоб досліджувати матеріали в оригіналі з усього світу, спілкуватися з колегами та читати жарти в LinkedIn Із загальних рис — уважність до деталей, вміння визнавати помилки та вчитись на них, комунікабельність і вміння зберігати спокій у стресових ситуаціях» (Олександр Драч, SRE Team Lead в Upwork).

Возможные варианты карьерного роста для SRE:

• развиваться как SRE Tech Lead;
• попробовать себя в смежных специализациях: DevOps, System Architecture;
• стать менеджером: Team Lead, Engineering Manager, Delivery Manager — и вплоть до CTO.

DOU

DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...

dou.ua