Принимайте участие в зарплатном опросе! Уже собрано почти 8 000 анкет.
×Закрыть

Site Reliability Engineering: ответы на 10 главных вопросов о профессии

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

Так получилось, что Site Reliability Engineering я фактически начал заниматься намного раньше, чем познакомился с этим термином. Я учился на программиста, но проработал им недолго — ушел в системные администраторы. Был главным сисадмином Mail.ru, даже вместе с ним уходил из DataArt (когда-то DataArt написал Mail.ru, а через пару лет сервис отделился и переехал в Москву). Но потом вернулся и в компанию, и в разработку, причем занимался как раз вопросами производительности и надежности систем. Когда одному из наших клиентов понадобилась экспертиза в области SRE, оказалось, что мой опыт системного администратора, разработчика и системного аналитика как раз соответствует требованиям к SR-инженеру.

1. SRE — это из книжки, которую издавал Google?

В общем, да. Концепция Site Reliability Engineering появилась в Google еще в 2003 году. С тех пор собственные SRE-команды сформировали многие компании, прежде всего, конечно, те, успех бизнеса которых напрямую связан с бесперебойной работой компьютерных систем (Apple, Microsoft, Facebook, Twitter, Dropbox, Oracle и т. д.). Широкое распространение SRE началось 4–5 лет назад. За последние 2–3 года список тех, кто выделяет соответствующую роль в проектах, заметно расширился. В конце концов, кто сейчас не зависит от внутренних IT-систем, их надежности, производительности, интеграции с внешними сервисами?

Задачи Site Reliability-инженеров в разных компаниях могут различаться и зависят от типа самого бизнеса. В этом смысле SRE как относительно новый подход напоминает Agile, который, как вы наверняка заметили, у каждого свой. Тем не менее, перечень знаний и навыков, необходимых SR-специалисту, в любом случае будет совпадать примерно на 80%.

2. Обеспечение надежности — просто модное название техподдержки?

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

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

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

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

3. SRE — разработчик или DevOps?

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

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

4. Что такое reliability? Есть ли четкие критерии измерения надежности?

Первым делом SRE окружает любую систему метриками, которые могут различаться от проекта к проекту. Здесь важно не перестараться и не измерять то, что нас не интересует. Например, сами по себе объем дискового места на сервере или загрузка процессора, конечно, влияют на работу, но не отвечают ни на один из важных для нас вопросов. Поскольку SR-инженера интересуют не технические показатели, а Service Level Indicators (SLI) — показатели уровня обслуживания, то есть бизнес-метрики. Ситема лучше обслуживает клиентов, не тогда, когда процессор менее нагружен, а когда она способна стабильно выдерживать большее количество запросов без потери качества.

Только научившись измерять важные для бизнеса показатели, мы можем приступить к процессу повышения надежности. Понятно, что при этом растет и стоимость разработки, обслуживания и поддержки системы. Причем растут они экспоненциально, особенно если речь идет о системе, работающей в разных регионах, где возникает вопрос универсальной линии (а чаще всего SRE имеет дело именно с такими сложными историями). И здесь SRE оказывается ключевой фигурой при переговорах с бизнесом, поскольку может со ссылкой на количественные показатели объяснить, насколько система надежна, какими проблемами чреваты узкие места и во что обойдется устранение любого из этих бутылочных горлышек. Именно вместе с представителями бизнеса SR-инженеры устанавливают Service Level Objectives (SLO — еще одна важнейшая аббревиатура!) — цели уровня обслуживания, приемлемые показатели надежности.

5. Какого образования и опыта требует работа SRE?

Концепция все еще новая, и готовых специалистов на рынке практически нету. Поэтому мы на эти роли рассматриваем и разработчиков (хорошо, когда SRE не боится Python или Java), и DevOps-инженеров, готовых глубже погрузиться в код. Благо спектр задач очень широкий: от мониторинга и алертинга — задач вполне девопсковских, до сложного траблшутинга, доступного только опытным разработчикам.

Классические задачи: в логах сервера постоянно кончается память; или кончается тред-пул — какие-то треды не возвращаются; или один из трех серверов за лоад-балансером постоянно перегружен, хотя два других работают нормально. Это нетривиальные технические проблемы, решение которых требует глубокого понимания того, что находится под капотом: как масштабируются системы в облаках, как распределяется нагрузка и как сервер справляется с ней. Скорее всего, расследовать их должен разработчик уровня Senior. Есть задачи скорее конфигурационные, есть локальные и не такие сложные.

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

6. SRE — противоположность фича-девелопменту?

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

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

7. Работа SRE — рутинная?

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

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

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

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

8. SRE работает вместе с разработчиками или как часть отдельной команды?

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

При другом подходе в проекте работает целая SRE-команда. Его мы особенно часто применяем в проектах, прошедших стадию активной разработки, где система достаточно стабильна. Такая система может очень активно эксплуатироваться заказчиком, поэтому улучшить процесс и взаимодействие, предусмотреть автоматическое восстановление может быть особенно важно. Команда дополняет ее метриками, разбирается с устройством, ищет проблемные места. В некоторых случаях SRE могут запросить доработку у команды девелоперов или самостоятельно сделать изменения в коде, если они ограничены по объему и вписываются в error budget.

9. Чему можно научиться, работая на позиции SRE?

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

Это работа позволяет разработчикам выходить за рамки тех 30% времени, которые фактически тратятся на то, чтобы система начала приносить пользу реальным людям. У них появляется возможность посмотреть и пощупать все современные способы работы в продакшене — мониторинга и алертинга. Причем предназначенные для этого инструменты, как правило, опенсорсные программы. То есть полученный опыт можно легко перенести в другие проекты и компании.

Для DevOps-инженеров SRE — прекрасная возможность лучше понять, как системы написаны. Такая работа позволяет погрузиться в код на уровень, который через 2-3 года при желании позволит развиваться дальше уже в качестве программиста.

10. Концепция SRE — это надолго? Такой опыт будет востребован?

Это навсегда, а опыт в перспективе может оказаться незаменимым. SRE способен стать стабильным источником дохода для любой компании, нацеленной на большие и сложные энтерпрайз-проекты. Системы продолжают усложняться, оверхеды увеличиваться, а удержать в голове подробности развертывания 200 микросервисов почти невозможно. Поэтому роль SRE в ближайшие годы может стать настолько же обычной, насколько 10 лет назад стал QA Automation, а пять лет назад — DevOps. Для того, чтобы управлять проектами с сотнями разработчиков, обязательно понадобятся люди, способные противостоять надвигающемуся хаосу. Иначе приложения начнут схлопываться под собственной тяжестью.

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

Полезные ресурсы

Материалов об SRE в академическом понимании мало. Прежде всего я бы рекомендовал всем, кому эта тема интересна, две книги, изданные Google: Site Reliability Engineering и The Site Reliability Workbook, обе они доступны для прочтения бесплатно. Третью книгу по теме Seeking SRE: Conversations About Running Production Systems at Scale можно прочитать бесплатно за 10 дней или купить на сайте издательства O’Reilly. Достаточно компактное введение в концепцию SRE предлагает аналитическая компания New Relic (доступно здесь в pdf).

Кроме того, существует масса презентаций, в которых разные компании рассказывают, как имплементируют эту концепцию у себя.

LinkedIn

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

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

SRE это гугловая реализация DevOps философии. А в тексте почему-то SRE регулярно противопоставляется DevOps хотя в контексте речь идет о Ops

SRE — это одна из реализаций идей DevOps, которую предпочел гугл. В частности, основное отличие SRE от традиционного DevOps, что SRE инженеры — это не Ops, а software инженеры, которые подходят к решению devops задач как к Software Engineering задачам.

В частности, основное отличие SRE от традиционного DevOps, что SRE инженеры — это не Ops, а software инженеры, которые подходят к решению devops задач как к Software Engineering задачам.

И в чемт отличие? DevOps (здорового человека) тоже как правило не Ops, а из Dev.
Другой вопрос что бывают случаи когда DevOps имплементирует бизнес-фичи, чтобы SRE имплементировали такое я не слышал. По вашему опыту SRE имплементируют бизнес-фичи или только инфраструктурные задачи?

Другой вопрос, что сейчас «DevOps-инженерами» называют админов, которые выучили как работать с каким-то облаком, или просто автоматизируют свою работу.

Классификация фич на бизнес и инфраструктурные — во-первых не взаимоисключающая, а во-вторых не всепокрывающая. Продукт может быть внешним, для конечного пользователя, или может быть внутренним — инфраструктурой. SRE, как и продуктовые (бизнес? SWE, в терминологии гугла) разработчики работают над общей целью: хороший, надёжный, предсказуемый продукт для пользователя. Технически и SWE и SRE пишут дизайн доки, код, следуют практикам софтверной инженерии. только у них разный фокус и, соответственно, разные сферы экспертизы. SWE могут лучше знать предметную область (мед. сферу, нефтяную, итд), а SRE часто намного глубже знакомы с идеями и приёмам построения распределённых систем, управления надёжностью, рисками, практических аспектов эксплуатации абстрактной системы «в продакшне», что также подразумевает знание сетей, протоколов, внутренностей ОС.

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

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

чтобы SRE имплементировали такое я не слышал. По вашему опыту SRE имплементируют бизнес-фичи или только инфраструктурные задачи?

просто гугл дорос до чисто инфраструктурных размеров настолько что инфраструктурные задачи а) бизнес-задачи (странно что где-то это не так иначе не было бы б и админов и воот айти-отделов) б) с другой стороны уже требуют непосредственно «программных подходов».

с третьей стороны это всё ещё видимо довольно актуальное стремление называть всех «программистами» (software engineer) как у мелкософта я слышал как-то совсем не стало тестеров а все стали SDET правда признаюсь не слышал чем там у них дело кончилось но SDET это по крайней мере программист которого заставили тестировать просто потому что он изнутри знает устройство и что всякие автомат и юнит-тесты... а вот SRE это вообще не программист это именно и очень конкретно админ а то что он умеет на баше и даже на питон ну кто сегодня не умеет на питон? )) а повторюсь размеры инфраструктуры конкретно у гугла стали таковы что им это стало выгодно (видимо) но ещё раз это ни разу не программист даже если программиста таки поставить делать SRE.

вот скажем есть у меня маленький свечной заводик сайты чинить мелкие совершенно никакой особой «инфраструктуры» там нет чаще чистый вордпресс но с другой стороны их много и многие операции просто скриптованы автоматизированы а то и сишечка там ну просто чтобы не разбираться с чем там ещё )) вот выходит что я тоже SRE ))

ЗЫ: если что меня ирландский гугл звал на SRE кажется в цюрих я стал разбираться что это вообще такое слушать выступления их главного и вообще конечно может «диагноз по фотографии» (к) (тм) субъективный но они очень конкретно именно админы сперва админы и только потом (может быть) всё остальное.

Действительно, отдельные SRE нужны не во всех организациях, а начиная с некоторого размера инфраструктуры.
«SRE — админ, а ни разу не программист» — это распространённое заблуждение. Если это действительно так в какой-то организации, то эти SRE работают неправильно.
В гугле тоже есть SET (Software Engineer in Testing). Это не тестировщики, которые пишут тесты (боже упаси тестируют руками), а программисты, которые пишут, например фреймворки для тестирования. Тесты пишут сами продуктовые программисты.

DevOps (здорового человека) тоже как правило не Ops, а из Dev.

В наших реаліях 80% буде навпаки. Ходив по конфах been there done that.

Вот дают! Новая профессия! Teem Lead, DevOps, PM, HR, QA, support — все нужны чтобы подружить... теперь еще и SRE?
яплакаль, как печально со временем живется... А кто будет дружить всех вместеперечисленных?

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

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

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

cloud.google.com/...​tandards-or-close-friends

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

Дико поддерживаю! В мире галер ДевОпсами начали называть билд инженеров

Я настолько стар, что помню те времена, когда под DevOps подразумевалась коллаборация между Dev и Ops командами ради создания стабильного и быстроразвивающегося продукта. Потом находчивые ребята с галер придумали продавать билд\релиз инженеров задорого и называть их «девопсами» (что противоречит всему духу философии), по итогу приведя к девальвации звания.

И вот сейчас есть мерзкое ощущение, что они собрались то же самое проделать с SRE

У нас SRE это чаще следующий этап развития после Senior DevOps и(или) Senior Developer. Делать инфляцию специализации не в наших интересах.

пинг-понг между разработчиками и DevOps-инженерами

Это приговор затертому термину DevOps :)

Вначале были:
Алгоритмисты, которые превращали ТЗ в блок-схемы
Кодеры, которые превращали блок-схемы в код
Сисадмины, которые обеспечивали работу кода

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

Все было логично и продумано. Но потом внезапно взяли кардиохирурга и скрестили с девопсом.

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

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

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

SRE — область, пограничная между разработкой и DevOps

Ох...
А нас самом деле без нормальных процессов (см. ITIL) называйте позиции как хотите — ярлыками дело не сделаешь.

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

Тобто, спершу devops героїчно долає пінг-понг між девами та адмінами, а потім приходить sre та робить вже свою справу))))

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

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