Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

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

В новой статье серии «Карьера в 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:

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

Больше материалов по введению 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.
«Пишите мне, если вам нужен ментор или консультация» (Евгений Старченко, Lead SRE в SPS Commerce).
LinkedIn

Похожие статьи

8 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Из всего прочитанного увидел, что так никто и не понял смысл SRE и чем они отличаются от DevOps :(

изначально, это определенная роль в вполне конкретной компании (google)
поэтому, во всех остальных случаях — это больше анекдот про прапорщика и осла

«If DevOps is a sausage then SRE is a sizzle!»

В простонародье три буквы SRE могут относиться к:
Simple Restart Everything, или Sysadmin (Really Expensive), или Server Reboot Engineer или Sometimes Reliable Engineer...

И хотя Google вложил немало денег в продажу своего определения SRE, остальная часть отрасли приняла это на своих условиях, с результатами, которые варьируются от компании к компании. Отсюда может и быть различный опыт или «разный смысл». Что не всегда есть плохо.

Пока вы, как инженер, не столкнетесь с реальными задачами бизнеса нуждающегося в «Site Reliability Engineering», определить, что нужно конкретно от вас, DevOps, CloudOps, SecOps, SysOps, как от инженера — зачастую бывает довольно проблематично. И тут не важно сколько вы знаете про Гугл с их error budget...пока вы не потрудитесь в схожей компании с подобными проблемами и процессами.

Практики создания и поддержки надежной SaaS платформы «в масштабе» своего рода и есть Site Reliability.

Так как «классический» DevOps очень тяжело определить и померять, SRE как концепция более четко структурирована и определена для организации и команд.

На украинском рынке очень мало продуктовых компаний и еще меньше тех, кто дорос до уровня внедрения reliability в свой продукт. Для многих стремление к максимальной стабильности системы является бессмысленным и контрпродуктивным.

Очень тяжело научиться измерять и доносить важные для бизнеса показатели, если бизнес не понимает зачем это нужно — внедрение и обучение занимает много времени и ресурсов. В конце концов, как вы можете провести содержательную беседу с разработчиками о надежности сервисов компании, без должной оценки и измерения этой самой надежности?

Многие организации реагирует на инженерные проблемы эмоциями, вместо извлечения уроков из метрик или репортов. И кажется, что SRE устанавливает еще один набор ограничений. Но только так вы можете приступить к процессу повышения reliability.

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

И наверное только в такие моменты, действительно начинаешь понимать

смысл SRE и чем они отличаются от DevOps

... ;)

Можно сказать, что это две стороны одной медали. Но уровень погружения в продукт у SRE все-таки больше. Главное понимать, где начинается этот продукт, а где outsource или outstaff. В противном случае ваша работа будет больше OPS, чем SRE.

И хотя Google вложил немало денег в продажу своего определения SRE, остальная часть отрасли приняла это на своих условиях, с результатами, которые варьируются от компании к компании. Отсюда может и быть различный опыт или «разный смысл».

Если глобально посмотреть, то многие вещи будут казаться кем-то специально придуманными и проданными. Посмотрите на те же микросервисы или Agile. На самом деле есть процессы, которые зарождаются естественным путем и проходят определенный период вызревания. После этого многие компании просто делятся своим опытом. А другие компании пытаются заработать на хайпе.
А ведь каждый такой инструмент хорошо применим только в определенных условиях. Я встречаю много клиентов, которые не просто хотят, а требуют в своих проектах «современные технологии и практики». Просто говорят, нам все равно, подавай микросервисы и блокчейн. И даже развернутые оценки и обоснования, что в их ситуации это не нужно, не помогают.
Сначала сисадминов начали называть девопсами, а теперь они носят гордое имя SRE.
И если посмотреть на SRE в том виде, как оно используется в Google, то нет никаких сомнений и вариаций. Это работает понятно и приносит реальную пользу, которую, кстати, можно выразить не только в абстрактных SLI/SLO, но и в SLA в реальных деньгах.

+1. Таке враження, що вони так і не зрозуміли, що ’E’ in ’SRE’ stands for ’Engineering’. У нас взагалі жорстокий пріоритет на програмістський бекграунд, і кожен SRE в команді багато програмує, і не скрипти на баші, а нормальні розподілені системи, тому це еволюція як раз не з традиційних опсів, а з програмістів.

Junior SRE может начать с круглосуточного мониторинга посменно

 — весьма спорное утверждение, если у проекта есть круглосуточный мониторинг людьми посменно(имеется в виду кто-то действительно целый день смотрит в графики и логи) — то с SRE на проекте под вопросом. Ибо первым делом пишется нормальный alerting который звонит в пейджер только когда что-то сломалось и после этого SRE на смене либо спит либо занимается более интересными вещами. Ну а если Junior может сам в сервисе проблему локализовать и решить — то какой уж он тогда Junior?

Автор поправьте пожалуйста явные смысловые ошибки и орфографию:

книга Бенджамина Трейнора

 — эм...... там два десятка авторов, выбрать одного из них пусть даже начальника и назвать книгу только его......... ну вы поняли. А потом туже самую книгу называют

Site Reliability Engineeriing by Betsy Beyer, Niall Richard Murphy, Chris Jones and Jennifer Petoff.
Engineeriing

 — граматика

писать на одном из высокоуровневых языков разработки (Node.js

 — я конечно полностью нейтрален относительно языка, но пока не видел чтобы кто-то писал обход дерева на Node.js, хотя конечно можно — Turing complete, все дела.

но пока не видел чтобы кто-то писал обход дерева на Node.js

обхід дерева на js написаний у купі фронтенд фреймворків (та й бекенд думаю теж), тому що DOM це — сюрприз! — дерево. Чомусь мені здається що саме на js дерева обходять частіше ніж на будь-яких інших мовах.

Дякую за статтю. В цілому згідний

Подписаться на комментарии