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

0
187
views

Site Reliability Engineer — специалист, отвечающий за надежность, масштабируемость и бесперебойную работу IT-систем. SRE работает в пограничной области между DevOps и разработкой. Об этой специализации сайту DOU.UA рассказали Юрий Рочняк (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 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 SRESRE UniversityAwesome 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.

ОСТАВЬТЕ ОТВЕТ

Please enter your comment!
Please enter your name here