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

Впервые термин SRE официально употребила компания Google, когда сообщила о создании новой позиции под названием «Site Reliability Engineer» или «Инженер по надежности сайта». Выкристаллизовалась специальность SRE из одноименного подхода веб-разработки в недрах Google. Учитывая, что основной продукт компании — это веб-сайт, то и в экспертности мнения интернет-гиганта в этом вопросе сомневаться не стоит.

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

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



Согласно методологии, разработанной специалистами Google, Site Reliability Engineering — это набор принципов и практик, который включает аспекты разработки программного обеспечения. Эти принципы и практики применяются к проблемам как эксплуатации, так и инфраструктуры посредством привлечения к работе разработчиков, а сама решаемая проблема — имеет программную природу.

Почему мы вообще сравниванием DevOps и SRE?

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

Та же история происходит сейчас с SRE. Методология, которой менее семи лет — практически ребенок в мире подходов к разработке и поддержке, особенно, когда дело касается стабильности и отказоустойчивости веб-сайтов. Еще одно серьезное отличие SRE — он был порожден вполне конкретной компанией (Google) и ее командой разработки, тогда как те же DevOps возникли как массовое течение. При этом уже сейчас SRE довольно быстро из подхода к разработке в конкретной компании трансмутировало в обозначение инженерной позиции.

Теперь же, как и DevOps, SRE проходит тот же тернистый путь путаницы и непонимания, что это такое, кому нужно и зачем.

Кому нужен этот ваш SRE

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

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

При этом SRE должен работать с Linux, основными популярными системами мониторинга, логирования, быть неплохим (не ниже middle) кодером хотя бы на одном из основных высокоуровневых языков (например Java, C++/C#, Python и так далее).


Когда увидел описание вакансии SRE

В совсем больших компаниях от SRE ждут еще и кристального понимания и владения hard-скиллами DevOps. А это CI/CD, опыт работы с облачной инфраструктурой AWS/Azure, контейнеры и оркестрация, системы управления версиями и т.п.

Почувствовали то самое «все, везде и сразу», которое мелькало в вакансиях сисадминов, когда компании на самом деле нужен был DevOps? Из-за родственности и близости сфер, сейчас то же переживают и SRE. Компании поменьше, конечно, могут нанимать людей с частичным пересечением компетенций в этих областях, как это было и на заре становления методологии DevOps и зарождения отдельной профессии DevOps-инженера как такового. Однако уже сейчас нужно четко понимать, что опытный SRE — это мастодонт, обычно с опытом от 10 лет в сфере и парой сеньорских титулов.

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

И где этих SRE взять?

Как в случае и с DevOps и построением HighLoad-систем, SRE может и должно быть аутсорсным. Концепция стабильной отказоустойчивой системы вполне согласуются с основными принципами DevOps и использования облачных инструментов AWS и Azure для обеспечения бесперебойной работы инфраструктуры. Если рассматривать SRE как концепцию, то это — более углубленный программный подход к обеспечению безопасности системы не только на уровне процессов, но и с помощью специально созданных для конкретного проекта софтверных решений. Конечно, современные тарифы и инструменты Amazon и Microsoft позволяют выстроить надежную и безопасную систему, причем с миграцией в облака не только внешней, но и внутренней части проекта, но тут важно понимать, что серьезные миграции производятся специалистами-партнерами этих сервисов. При этом даже опытная команда переносит проект в облака или проводит аудит и оптимизацию крупных проектов от 3 месяцев до 2 лет (активная фаза обычно занимает от 6 до 12 месяцев).

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

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