Sre инженер кто это

Кто такой SRE-инженер?

Задача современного SRE-инженера — сделать так, чтобы система была надежной, стабильной и производительной. Да, это похоже на задачи классического системного администратора, однако в случае с SRE цель достигается немного иными способами.

SRE-инженер, как и сисадмин, должен понимать устройство инфраструктуры, быть в курсе, какое ПО работает, знать, какую нагрузку выдерживают серверы, понимать, как надо работать с утилитами операционной системы.

На практике выделяют 4 ключевых направления, которые отличают SRE-инженера от классического системного администратора.

1. SRE-инженер — это, в первую очередь, программист

Да, это программист, но с навыками администрирования. При этом в отличие от большинства разработчиков ПО он пишет код не в целях реализации бизнес-логики, а в целях повышения стабильности и производительности системы. То есть написание кода не является основной задачей SRE-инженера — это всего лишь способ достижения основной цели.

Таким образом, умение программировать помогает SRE-специалисту самостоятельно находить ошибку в программе и исправлять ее. Он без проблем залезет в код, найдет причину и сразу устранит проблему.

Кроме того, SRE-инженер может разрабатывать утилиты, помогающие следить за системой. К примеру, у вас на проекте уже есть утилиты трассировки либо сбора логов, однако они чем-то не устраивают SRE-инженера, но для него это не проблема, ведь он может либо написать свои утилиты, либо доработать существующие.

2. SRE-инженер применяет модель «Инфраструктура как код» (IaC)

Такой специалист старается не менять ничего в системе вручную, то есть он пишет для всего скрипты и конфигурационные файлы. Зачем? Да хотя бы для того, чтобы снизить вероятность человеческой ошибки. Кроме того, данный подход даёт возможность легко воспроизводить настройки на прочих серверах и узнавать, как именно система настроена.

3. SRE-инженер принимает участие в проектировании архитектуры

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

А еще он может уже на старте разработки определить критерии для программистов, которым надо следовать. К примеру, для приложения следует обеспечить возможность записи логов в конкретное место или же надо интегрироваться с общей мониторинговой системой. И если данные требования не выполнены, SRE-инженер не примет приложение на поддержку.

4. SRE-инженер активно использует метрики

Оценка стабильности системы происходит не по ощущениям, а по фактическим параметрам. Существуют 2 главные метрики: 1. SLO — цели уровня обслуживания. Речь идет о соглашении о метриках и допустимых значениях, причем пороговые значения превышаться не должны. К примеру, наибольший даунтайм системы — не более 20 часов/год, среднее время ответа сервиса — не более 1 секунды. 2. SLI — индикаторы уровня обслуживания. Это уже сами метрики, измеряющие в течение какого-либо времени. К примеру, даунтайм системы в год — 18 часов, среднее время ответа сервиса — 0,8 секунды.

Как раз таки на основании этих метрик и происходит оценка стабильности и производительности приложений. А если что-либо выходит за рамки установленных параметров, SRE-инженер имеет право наложить вето на разработку нового функционала и попросить разработчиков сконцентрироваться на устранении проблем.

Практический пример

Допускается, чтобы сервис завершал работу с ошибкой 5 раз в месяц. Еще не так давно в месяц было 2-3 ошибки. Однако за последние 2 недели случились уже 3 ошибки, следовательно, если такая тенденция сохранится, лимит на 5 месячных ошибок будет превышен. Учитывая ситуацию, SRE-специалист может сказать разработчикам: «Ошибок стало больше. Пока стабильность не вернется на прежний уровень, мы не можем пускать в production ни одной новой функции».

SRE-инженер: где востребован и как его найти

Инженеры SRE (Site Reliability Engineer) работают на границе DevOps и разработки и отвечают за надежность, масштабируемость и бесперебойную работу IT-систем. Они отлично разбираются в принципах организации работы распределённых систем, их безотказности, рисках, практических аспектах эксплуатации систем. Часто эти специалисты вырастают из системных администраторов и специалистов службы поддержки, которые основательно углубили свою экспертизу в программировании, автоматизации, облаках и DevOps. Рассказываем об особенностях их поиска и делимся примером успешного закрытия такой вакансии.

В каких компаниях востребованы SRE-инженеры

Специалисты SRE необходимы в крупных компаниях со сложным, нагруженным софтом для обеспечения надёжной работы всех систем при регулярных апгрейдах, изменениях инфраструктуры и масштабировании. Как правило, эти кандидаты очень опытные: знают обо всех возможных багах инфраструктуры и понимают, как можно их не допустить или быстро устранить. SRE-подход возник в Google и стал популярен в промышленности, финтехе и среди продуктовых IT-компаний. Так, сейчас наша команда ведет поиски на несколько таких вакансий. Специалисты нужны в крупные российские банки: новейший стек технологий, высоконагруженные системы, отличные условия работы и высокопрофессиональные команды. Подробнее о требованиях и самих проектах можно узнать у наших консультантов, написав нам на почту.

Обязанности и компетенции SRE-инженеров

Обычно в обязанности SRE входит:

• проверка надежности, отказоустойчивости и стрессоустойчивости систем,
• мониторинг, управление инцидентами, хаос-инжиниринг,
• разработка и обслуживание инфраструктуры,
• разработка и поддержка внутренних инструментов,
• проверка и контроль оптимальной загрузки системы.

В чем трудность поиска

На российском IT рынке труда в названии вакансии часто можно увидеть DevOps и SRE одновременно. Эти специалисты очень близки друг к другу по hard skills, но компетенции SRE шире. Если DevOps-специалисту достаточно знать код на уровне написания скриптов, то от SRE ждут уверенных навыков программирования, минимум на уровне Junior-разработчика. Поэтому соискателей на такие вакансии стоит искать среди программистов, перешедших в DevOps, или же, наоборот, среди программистов, которым нравится заниматься настройкой CI/CD, и обладающих уверенным опытом работы с системами контейнеризации. Поиск точечный, поэтому от рекрутера требуется верное понимание профиля кандидата — его навыков и знаний.

Опыт GlobalCareer: крутой SRE в финтех-проект

Наш клиент — крупный российский банк — развивает несколько сервисов в разных департаментах. Системы становятся более масштабными и высоконагруженными, поэтому решено было усилить команду опытным SRE-специалистом, найти которого доверили GlobalCareer. От кандидата требовалось знание одного из языков программирования на уровне Middle и умение решать инфраструктурные задачи.

Екатерина Сиденко, рекрутер: «Было решено оценивать не только кандидатов, указывающих в своем профиле SRE, но и специалистов направления DevOps. При анализе резюме, мы уделяли особое внимание опыту программирования на Python, Java, Kotlin или Go, настройке CI\CD; навыкам и знаниям работы с Docker — контейнерами, системами мониторинга. Выбранная стратегия поиска помогла найти релевантных кандидатов, владеющих языком программирования на уровне написания кода и умеющих справляться с задачами по обеспечению надежности систем».

В итоге заказчику было отправлено 8 подходящих специалистов. Выбранный кандидат обладает опытом разработки на Python, а также глубокой экспертизой в DevOps. Ранее работал в IT-компании, занимающейся разработкой ПО, поэтому умеет работать над проектами разных заказчиков — с разным стеком и задачами. От открытия вакансии до принятия оффера специалистом прошло 1,5 месяца. В данный момент кандидат проходит испытательный срок.

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

Если в вашу команду нужны IT-специалисты, напишите нам, и мы найдем подходящих кандидатов.

Кто такой SRE и чем он занимается?

Леруа Мерлен переосмысливает DIY-ритейл так же как другие технологические лидеры меняют банкинг и ИТ-сервисы. Сейчас команда ищет новых людей — в компании открыт набор на стажировки. Среди направлений есть загадочное SRE, о котором слышали немногие.

Исправляем эту ситуацию! Узнали у менеджера бизнес-приложений в Леруа Мерлен про особенности этой профессии.

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

Олег, привет! Расскажи, что такое инжиниринг надежности?

SRE (Site Reliability Engineering) — набор методов, показателей и предписывающих способов обеспечения надежност и ПО. Инжиниринг надежности был создан в Google как ответ на практики DevOps по разработке и эксплуатации IT-сервисов и стал достоянием общественности несколько лет назад после публикации книги с одноименным названием.

Кто такой инженер по надежности, и какие задачи он выполняет?

SRE (Site Reliability Engineer) — это человек, который, как и DevOps, одной ногой в Dev другой — в Ops. Но в фокусе у него не инфраструктура и доставка кода, а сам сервис. Можно сказать, что DevOps в основном про инфраструктуру, и его клиенты — айтишники, SRE — про бизнес-приложение, а его клиенты — пользователи. Работы у SRE хватает: надо понять, как устроен сервис, какая у него архитектура и зависимости, какие бизнес-процессы поддерживаются, а также определить требования по доступности и качеству. Поняв, какие показатели и события надо отслеживать, SRE организовывает и автоматизирует сбор и хранение соответствующих метрик. Он использует доступные корпоративные инструменты, а иногда и собственную разработку.

Получается, SRE должен знать программирование?

Да, SRE, в том числе немного программист. Более того, идеальный SRE тратит на ручную работу и всю операционку максимум 50% рабочего времени, а остальное посвящает автоматизации, исследовательской работе и реализации возможностей по улучшению качества сервиса и удешевлению поддержания этого качества. SRE очень важно подружить между собой команды разработки и поддержки и упростить администрирование сервиса. А если нужно, то и в траблшутинге он примет участие, куда же без этого. Работа не из простых, но интересная — она открывает бесконечный простор для развития, особенно технического.

Что нужно, чтобы стать инженером по надежности?

Нужно хорошо разбираться в архитектуре информационных систем, в протоколах взаимодействия сервисов, уметь считать пропускную способность и отказоустойчивость, разбираться в большом количестве инструментов, понимать, как работает мониторинг и алертинг, уметь читать ошибки и знать хотя бы один язык программирования — сейчас это в основном Python или Go. Еще очень важно никогда не останавливаться на достигнутом и продолжать искать возможности для улучшения. Это не перфекционизм — в эксплуатации развивающегося сервиса результат почти никогда не является конечным.

Можно ли стать SRE с нуля?

Споры по поводу ответа на этот вопрос не прекращаются до сих пор. Одни утверждают, что не бывает SRE-практикантов или Junior SRE (как и DevOps, кстати), ведь уже на входе требуется много знаний и навыков, а прокачаться полностью так и вовсе невозможно. Другие считают, что SRE — такая же профессия, в которой есть старт, и путь самурая поддается градации на уровни. Лично я убежден, что нет ограничений в такой молодой отрасли. Если компания готова растить кадры в «боевых» условиях, то стать SRE можно, начав с самых базовых навыков. Просто нужно выполнять несложные прикладные задачи (которые уже несут реальную ценность) и интенсивно осваивать востребованные инструменты и навыки. Конечно, в этом случае необходим наставник, который поможет пройти путь до специалиста или даже до профессионала.

Если ты уже знаешь и понимаешь Linux на уровне уверенного пользователя, можешь написать нехитрый скрипт, знаешь на базовом уровне Python и то, что находится «под капотом» у приложения, то ты уже можешь попробовать свои силы!

Sre инженер кто это

Site Reliability Engineering — это инженерная специальность, цель которой обеспечивать надежность и безотказность разрабатываемых сервисов.

В таком виде профессии SRE не больше пяти лет, но сами практики и подходы стали появляться в компаниях раньше, — когда возник запрос на сервисы с уровнем надежности, которого сложно достичь.

Это, например, соцсети, почта, поисковые системы, телефония, а постепенно подключились банки и такси. Люди привыкли, что такие сервисы доступны 24/7, это незаметно стало частью нашей жизни.

Если пять лет назад межбанковские переводы могли идти 2—3 дня, и никто не ожидал от них более высокой скорости, то сейчас деньги зачисляются мгновенно через приложение. Чтобы обеспечивать и поддерживать такой уровень бесперебойной работы, и нужны SRE-инженеры.

Когда в компании возникает потребность в SRE

Есть мнение, что отдельные SRE-специалисты и тем более целые команды востребованы только в крупных компаниях.

С одной стороны, это действительно так: небольшому проекту не требуется такой же уровень надежности, как, например, банку.

Минимальный уровень надежности легко получить, почти ничего не делая. В простом интернет-магазине не нужен SRE-инженер: задач для него нет, со всем справятся программисты, которые разрабатывают сайт.

Отталкиваться нужно от потребностей и возможностей бизнеса, поскольку SRE — это дорогостоящая история.

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

Другие же проекты изначально нельзя создавать без специалистов по надежности: скажем, атомную станцию или банковское приложение.

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

Любой разработчик может заниматься SRE, если работает в ИТ достаточно долго, чтобы разбираться в архитектуре приложения. Идеально, если он это приложение и проектировал. А отдельная специализация нужна в больших командах от 20—30 человек.

Чем занимается SRE-инженер

SRE-специалист обеспечивает нормальное использование сервиса и его бесперебойную работу. Все его обязанности исходят из этой главной цели — обеспечения устойчивости.

• Определение и контроль SLA, SLO, SLI (соглашение об уровне услуг) и бюджета на ошибки.

Это начало работы SRE: ответ на вопрос, что для конкретной компании означает «нормальная работа». Сбои все равно будут, но нужно понять, что такое «не слишком много сбоев».

Например, если пользователь в соцсетях не может редактировать свои настройки или просматривать сторис — соцсеть все еще работает или уже нет?

Об этом нужно договориться с бизнесом, а затем — с командой бэкенда и всех внутренних сервисов.

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

Если соцсеть не показывает сторис только 0,1% пользователей — она работает или нет? Здесь нужно договориться о каких-то разумных цифрах, потому что поддерживать систему всегда работающей на 100% трудозатратно и неоправданно дорого.

• Бюджет ошибок — это SLA наоборот.

SRE-инженеры договариваются о том, сколько процентов времени нужно обязательно предоставлять доступ. Все оставшееся время — это наш бюджет ошибок. Его принято расходовать, поэтому и называют бюджетом.

Он расходуется сам, когда случается непредвиденный сбой. Его можно расходовать на сложный деплой, когда мы хотим пользователю показать даунтайм и израсходовать выделенный бюджет ошибок.

• Настройка мониторинга и алертов, постмортемы.

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

Если говорить о реактивном реагировании на инциденты, то это могут быть диагностические инструменты, встроенные в сами приложения, метрики и логи, тулы, которые сокращают время диагностики.

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

• Проактивное реагирование — это то, чем занимается SRE-инженер все оставшееся время.

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

• Дежурство, реагирование на инциденты.

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

У него есть договоренности на дежурство. Они выглядят так: «От момента начала инцидента до начала работы SRE должно пройти пять минут».

Это довольно жесткий тайминг: например, если инцидент произошел в нерабочее время и ты был вне дома, то за пять минут приступить нереально. Поэтому мы устанавливаем понятные правила дежурств, определяем, кто как реагирует, а наши дежурные могут друг друга подменять.

Какими навыками обладает SRE-инженер

Hard skills

Я опишу портрет условного сеньора. Любой SRE-инженер — это очень широкий T-shaped-специалист (то есть эксперт в одной сфере, который разбирается на среднем или минимальном уровне во многих других сферах).

Навыков у SRE-инженера очень много:

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

Список может показаться устрашающим, но, как я и сказал, быть гуру в каждой сфере не надо. Нужно понимать, как это устроено, поскольку SRE-инженер обеспечивает работу масштабного сервиса, в котором все это есть. При этом ломаться может что угодно — и по-разному воздействовать на связанные системы.

Soft skills

• Первое и главное — это стрессоустойчивость.

Работа в SRE очень стрессовая. Много стресса вызывает дежурство, особенно в начале, если ты сам не разрабатывал эту систему.

Постоянно думаешь: вот-вот что-то сломается и нужно будет быстро чинить, а компания в это время теряет деньги из-за падения системы. Это прямой источник стресса, поэтому SRE-инженеру очень важно быть к нему устойчивым и действовать в критических ситуациях хладнокровно.

• Второе — это навыки коммуникации.

Конечно, они нужны всем, но для SRE крайне важны. Как правило, за разные части системы, которые SRE делают надежными, отвечают разные команды — и со всеми надо выстроить отношения.

Нужно коммуницировать в том числе и во время сбоев: позвать коллег из зависимых сервисов, а бизнес-владельцам объяснить происходящее на понятном им языке.

Кто может стать SRE-инженером

Есть программисты, которым все в ИТ любопытно и интересно, они постоянно что-то пробуют вне работы, делают проекты для себя. Если занимаются фронтендом, то пробуют бэкенд, и наоборот. Именно такие специалисты в будущем становятся SRE, если их привлекает надежность и безопасность в программировании.

SRE-инженер — это специалист с широким кругозором, который уже многое в ИТ попробовал: писал код и автоматизировал, знает операционные системы и сети, разбирается в железе и базах данных.

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

Но в целом специализация здесь неважна: SRE становятся и фронтендеры, и мобильные разработчики. Хорошие SRE-инженеры — это специалисты в любой сфере, которые по крупицам собирали знания о надежности и обладают широким опытом в ИТ.

Чем SRE-инженер отличается от DevOps

SRE и DevOps отличаются системой ценностей, поэтому в одних и тех же ситуациях они принимают разные решения.

Основные ценности в DevOps — это автоматизация и быстрый time to market, то есть скорость поставки. Их задача — как можно больше релизить и больше автоматизировать, сокращая рутинные действия.

Грубо говоря, их KPI — это то, как быстро мы можем релизиться. А KPI SRE — это то, как хорошо мы укладываемся в оговоренные условия обслуживания.

Если у нас много человеческого фактора и нужна высокая степень надежности, то автоматизация помогает этого достичь. В этом случае мы похожи на DevOps.

Но иногда автоматизация мешает. Бывают сложные нетривиальные решения, где автоматика ошибается и вредит главной цели.

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

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

SRE интересует, тестируют ли они код вообще. А насколько хорошо это настроено — как раз зона ответственности DevOps. SRE затрагивает все, что касается продакшена, — это приоритет.

Как стать SRE-инженером и какие у него перспективы

Тому, кто хочет стать SRE, нужно недолго поработать в бэкенде — получить уровень мидла. Затем перейти в DevOps и тоже стать мидл-специалистом. После этого он уже готовый SRE-инженер. Если сразу не берут в SRE, то можно прийти в компанию на позицию мидл-бэкенд-разработчика или DevOps, поработать какое-то время и перейти в SRE. Главное — помнить, что надо широко развиваться. Делать это можно либо в своей компании, либо искать варианты на открытом рынке. Вакансий именно SRE-инженера не слишком много, поэтому начать можно с бэкенда или DevOps.

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

Владимир Скляренко, руководитель ИТ-подбора в «Тинькофф»

Кандидаты на позицию SRE-инженера выдвигают такие зарплатные ожидания (cуммы после вычета налогов):

мидл — 180—300 тыс. рублей;
сеньор — 250—400 тыс. рублей.

1. высокие зарплаты и большие перспективы;
2. приобретение уникальных навыков, которые всегда востребованы на рынке;
3. отсутствие бюрократии и долгих согласований: придумываешь и приоритезируешь задачи сам.

1. стрессовая работа;
2. большая ответственность за весь проект.

• Где учиться

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

1. Site Reliability Engineering: Measuring and Managing Reliability от Coursera;
2. «SRE практики и инструменты» от Otus;
3. Интенсив «SRE: внедряем DevOps от Google» от Слёрм.

Важное качество, без которого не стать хорошим SRE, — умение решать проблемы. В какой-то степени это даже предпринимательский скилл.

SRE-инженер обнаруживает проблему, придумывает ее решение, сам ее решает вместе с командой — и сервис становится лучше.

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

А если когда-нибудь SRE надоест, можно уйти в любое направление: в бэкенд, фронтенд, руководство. У SRE-инженера есть навыки во всем, а развиться чуть больше под конкретную область легко. Главное — это опыт решения проблем, который всегда пригодится и высоко ценится бизнесом.

Фото на обложке: khwanchai / Adobe Stock

Подписывайтесь на наш Telegram-канал, чтобы быть в курсе последних новостей и событий!