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 началось
Задачи 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 — прекрасная возможность лучше понять, как системы написаны. Такая работа позволяет погрузиться в код на уровень, который через
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).
Кроме того, существует масса презентаций, в которых разные компании рассказывают, как имплементируют эту концепцию у себя.
