С каким бэкграудом идти в SRE-инженеры: кейсы по внедрению и лайфхаки от специалистов
Задумывались ли вы о переходе из кодинга фич в сторону инфраструктурной разработки? Любопытство к SRE практикам растет, поскольку устойчивость и надежность приложений стали главными факторами успеха на рынке. В этом материале мы собрали для вас успешные карьерные кейсы действующих SRE-инженеров.
Статья написана по мотивам вебинара «Карьера SRE-инженера: с чего начать и как им стать», где спикеры Слёрма рассказали о своем пути, первом знакомстве с SRE-практиками и о том, как их грамотное использование повлияло на надежность систем. Передаем им слово.
Сергей Бухаров, Head of SRE Process в Dodo Engineering
Я начинал карьеру в качестве .NET и Node.js разработчика. Сейчас развиваю инфраструктурную платформу в Dodo Engineering в качестве SRE. Путь был околослучайный. Я пришел в Dodo на позицию .NET-разработчика совсем зеленым джуном. Тогда в компании еще не было SRE и DevOps.
Требования к стартапу по надежности со стороны бизнеса постепенно стали повышаться. Одно дело, когда ваша сеть состоит из 10 заведений в одном городе, и система может лежать несколько часов без последствий, и совсем другое, когда количество заведений приближается к 1000 в 15+ странах. Частые и долгие падения уже никого не устроят. В определенный момент мы решили достичь баланса между надежностью и скоростью разработки, но, чтобы инфраструктурная команда не расширялась вслед за ростом количества сервисов и нагрузки.
Когда я пришел, команда инфраструктуры состояла из трех человек и ее нужно было усилить. Я на уже умел так или иначе программировать и обладал базовыми инженерными компетенциями, поэтому тоже попал в усиление.
Долгое время я писал огромный деплой-скрипт, который доставлял наш монолит на сервера. Вся моя экспертиза шла в сторону мониторинга естественным путем. В какой-то момент у нас появился человек, который знал, что такое SRE, но никогда не внедрял его на практике. С этого момента мы пошли в этом направлении. Я тоже стал трансформироваться в SRE-инженера, а не в инфраструктурного инженера с навыками программирования.
Из экспертизы у нас был книга Google по SRE. По сути методичка, в которой описано, как должно быть в идеале, но не написано, как к этому прийти. Мы пошли методом проб и ошибок.
Dodo Engineering сейчас
Dodo Engineering представляет собой систему, которая управляет всеми процессами в заведениях, от приема заказа любым из способов до доставки клиенту. Также это трекинг заказов внутри пиццерии, отчетность, графики, смены и тд.
Что касается внутрянки — это монолит, который находится в состоянии распиливания. Вокруг него порядка 40+ микросервисов. Как правило, все это написано на .NET. В качестве хранилища используется MySQL (сейчас активно переезжаем на восьмой MySQL).
Разработкой платформы занимаются около 250 человек. Из них семь человек отвечают за SRE процессы и находятся в инфраструктурной команде, которая пишет свои сервисы на GO и предоставляет их разработчикам.
Что делает команда инфраструктуры
Сейчас у нас есть достаточно широкий набор перевязанных между собой сервисов. Мы предоставляем разработчикам облачный Kubernetes и инструменты для доставки туда приложений. Рядом с k8s мы делаем систему мониторинга и тулинг для инцидент-менеджмента (другими словами пейджер, отвечающий за составление расписаний и доставку алертов), а также инструмент для автоматизации самого процесса управления инцидентами и дальнейшей генерации постмортема.
Есть еще более мелкие тулы, что-то вроде инструмента для накатки миграции на MySQL, чтобы разработчики это могли делать самостоятельно. Основное — это компьют, мониторинг вокруг компьюта, мелкий тулинг и инцидент менеджмент.
Дежурства
С недавнего момента мы дежурим только по инфраструктуре, которую предоставляем. Если сломалась MySQL база или разработчики не понимают, что с ней происходит, мы приходим на помощь. В остальное время разработчики сами дежурят по собственным сервисам, так как падения у нас в основном связаны с тем, что пошло что-то не так именно с приложением, а не с нижележащей инфраструктурой.
Мы стремимся к тому, чтобы командно-инфраструктурная платформа была центром распространения практик SRE. Речь идет об управлении инцидентами, дежурствах, SLO, SLA, мониторинге и тд. Мы все это реализуем у себя, распространяем на всю компанию и привлекаем к этому разработчиков.
Команда SRE сейчас
Мы поняли, что это не самый хороший паттерн, когда один человек целиком и полностью отвечает за видение и за внедрение всего, что связано с SRE. Это не эффективно и служит прямым путем к его выгоранию. Мы центр компетенций. В нашей команде есть люди из разных областей и мы совместно планируем активности и делаем инструменты для разработчиков.
Павел Лакосников, Team Lead команды SLA в Авито
Бэкграунд: разработка (PHP, LUA, Golang + немного Python). Сейчас работаю в разработке, моя команда со стороны смотрит, как делать надежные решения, сервисы и приложения.
Изначально я кодил продуктовые фичи. Переход в категорию платформы и инфраструктуры стал плавным. У меня было чувство ответственности за выпущенный продукт, поэтому я там помог, здесь помониторил, потом коллеге что-то подсказал. Постепенно фокус компании переместился на надежность. Она крута тем, что ты можешь сказать: «знаешь мам, благодаря моей работе, 3000 человек сегодня стали на чуточку счастливее, на 3000 человек меньше увидели ошибку». Это классно.
Изначально в Авито, как и у всех, не было никаких процессов. Был монолит, выкатки, потом появились микросервисы, а за ними несколько крупных падений. После них пришло понимание, что надо следить и отвечать за сервисы и их надежность внутри самой команды. Позже появились люди, которые начали следить за мониторингом 24/7, чтобы лишний раз не дергать разработчиков или наоборот пинать их, когда все плохо.
Позже мы поняли, что инциденты требуют разбора. Далее встал вопрос, а помогают ли нам эти разборы. И вот на базе этого появилось желание замерять какую-то нормированную метрику. С этого момента в Авито стали применяться классические метрики SRE.
SRE в Авито сейчас
Мы предоставляем продуктовым разработчикам рельсы, по которым они могут быстро катиться, делать фичи и другие крутые штуки.
Наша SLA команда смотрит за тем, насколько Авито надежный и в каких местах эту надежность можно улучшить. Мы не выступаем с позиции классического SRE-инженера, которому принесли микроволновку и сказали: «Она теперь в твоей вотчине, ты отвечаешь за то, чтобы она работала». Культура нашей компании предполагает, что разработчик продолжает отвечать за то, что он сделал. Сделал плохо, будь любезен кати это до прода, а если начнет сыпаться, чини.
Задачи команды SLA
Наша команда нужна, пока количество общих потерь от инцидентов превышает бюджет стоимости команды. Мы организовываем процесс, чтобы разработчики следили за своими продуктами, и даем best practice, чтобы быстро катиться и откатываться: делаем инструменты observability, учим делать Canary Deployment и тд.
В команде также есть ребята, которые непосредственно занимаются тулингом нашей платформы, чтобы снимать и описывать нефункциональные требования. У нас каждый сервис должен иметь описание нефункциональных требований. Существует платформа, которая в процентном соотношении проверяет, насколько сервис отвечает своим же задекларированным требованиям по надежности.
Моя задача помочь разработчикам эту цифру посмотреть и понять, как ее можно затюнить. Допустим у нас есть требования, как должны работать сервисы, лежащие на критичном пути пользователя. Какой уровень и качество они должны оказывать, сколько девяток. Мы помогаем ребятам понять, как эту историю оседлать. У нас есть набор best practice, экспертиза в архитектуре и определенная экспертиза в инфраструктуре. Благодаря этому мы помогаем им становиться надежнее. Также мы пытаемся форсить общие политики и стратегии: как мы подходим к замерам этих девяток, как мы их приоритезируем и замеряем.
Кроме того, наша команда консультирует по инцидент менеджменту. Это открывает нам инсайты о том, где чаще всего команды спотыкаются. Например, со стороны разработки чаще всего ошибаются в написании конфигов.
Мы не останавливаемся в своем развитии и постоянно улучшаем процессы в компании. У нас появляются и SRE вакансии, и отделы, которые будут заниматься инцидент менеджментом. Важно, чтобы этот процесс был живым и развивался. Нельзя сказать, что мы все сделали.
Максим Козлов, RnD-архитектор, техлид
Мой путь был таким: разработчик, архитектор, RnD-архитектор, техлид. Сейчас я разрабатываю различные распределенные системы, мигрирую монолиты в микросервисы, внедряю (успешно) и капаю всем на мозг про практики chaos engineering.
Я пришел в RnD-отдел в 2018 году. В один момент мой руководить кому-то рассказал, о том, что мы делали у себя в команде. В то время у нас были свои проекты и нам хотелось посмотреть, насколько они надежные, как система выдержит падения и тд. Так получилось, что в компании тогда были серьезные перестановки и пришло много людей с продвинутыми взглядами. Появилась виртуальная команда, в которой я уже был в качестве chaos-инженера.
Что касается экспертизы, то мы ни с кем не советовались, просто находили информацию в интернете. До этого проекта я писал так называемы джепсон-тесты. Джепсон — отличный инструмент для стресс-тестирования. Мне нужно было сделать какую-то архитектуру с базой данных, проверить мастер и тд. Нужно было делать эксперименты по сбою, какими они могут быть: сетка падает, нода умирает, деградирует что-то под нагрузкой. Тогда я это и увидел. Еще к этому времени прочитал про Chaos Monkey, попробовал его и мне очень понравилось. Я ходил в департаменте и говорил: «Давайте что-нибудь сломаем!».
Первый крупный эксперимент и угрозы
С моим руководителем мы провели самый первый эксперимент над одной очень большой системой, которая очень долго разрабатывалась, была очень дорогой и критически важной. Наша задача была попробовать ее расшатать.
Все подробности раскрывать нельзя, но это система, где порядка двухсот машин занимались IBM, были кластеры с грядами, кластеры Kafka и кластеры баз данных. Бизнес-процесс был очень большим, плюс были какие-то внешние системы, к которым система должна была ходить авторизовывать, запрашивать права, обогащать данные и прочее. Новое руководство не понимало, что это за система, поэтому перед нами поставили задачу проверить насколько она соответствует своим же требованиям по надежности.
Нам важно было больше смотреть на это с точки зрения бизнеса: что происходит с входными транзакциями в эту систему, как они обрабатываются, зависают или не зависают, продолжаются, если что-то идет не так или останавливаются. В результате мы выявили порядка 35 дефектов.
И это было очень интересное время, потому что звонили моему руководителю и говорили, что я подставляю какой-то продукт. А я просто не мог подставить, когда начинаешь грузить одну из порядка 32 нод и все замирает. Кто-то потом сказал, что такого быть не может. Потом все узнали, что может. Какие-то вещи в итоге отдавались в разработку, правились и дальше тестировались.
Так мы работали около полугода. Нам с руководителем давали какую-то нагрузку, мы проводили эксперименты, записывали результаты и делали отчеты. Потом нам на помощь прислали девопса, чтобы он смотрел в мониторы. Далее случилась такая картина:
Подается нагрузка, какие-то тысячи TPC, мы их видим, разгоняем, сколько-то раз оно держится, потом мы проводим эксперимент и падает половина, все бизнес-метрики валятся, лейтенси по 10 — 20 секунд на транзакции. А человек просто смотрит в мониторы и даже не догадывается. Именно это послужило флажком — если что-то падает, а вы не замечаете, значит что-то идет не так.
Это был первый сложный, но успешный эксперимент. Тот факт, что мы все отловили на процессе тестирования, а не в живом продакшене, стал весомым аргументом для начала масштабирования chaos engineering в других командах.
Сhaos engineering сейчас
Я выступаю за то, что chaos-инженер — это не должность, а роль в команде. Ее может исполнять кто угодно. Сейчас я как chaos-инженер прихожу в команды, которые хотят повысить свой уровень надежности, и помогаю подсветить слабые места. Также я показываю инструменты, с помощью которых можно делать различные эксперименты над системой.
Я проповедую за то, чтобы разработчик или команда, которая делает продукт, могли сами проводить такие тесты. Команда сама, например, назначала на роль chaos-инженера бэкенд-разработчика на неделю. Ему даются любые возможности, что хочет пусть делает с продуктом или сервисом. А если он из другой команды, то еще лучше. Ломать не свое всегда приятнее. Одно условие — все результаты должны быть отражены в постмортеме.
В результате получится главная ценность подхода — команда или разработчик лучше узнают свой продукт, начнут задавать вопросы, лучше поймут порядок действий при инцидентах и заметят, каких метрик сейчас не хватает для повышения надежности сервиса.
Когда я прихожу куда-то, мне хочется делать все в проме, но это сложный процесс. У меня есть целый список пунктов, которые должны принять менеджер, разработчик и автор продукта, чтобы дойти хотя бы до первых экспериментов. Правда в последнее время становиться проще.
Итог
SRE — это живой процесс, который практически не останавливается. Говорить о том, что в компании внедрена культура SRE можно только после того, как она научилась считать свои потери.
Какой нужен бэкграунд для старта карьеры SRE-инженера? Кейсы встречаются разные. SRE-инженером может стать разработчик, который повысил компетенции в инфраструктуре и инфраструктурный инженер, научившийся разработке. Если в вашей компании еще нет практики SRE, вы можете, будучи даже джуном-разработчиком, стать ее инициатором и постепенно показывать, какую пользу это может принести.
Если говорить о самой роли, то SRE-инженера отличает системный подход к решению проблем за счет устранения рудкоза, а не просто установки костыля. Важно не просто починить поломку, а сделать так, чтобы она больше не случалась.
Можно сначала внедрить SRE, а потом сформировать под эти задачи команду. Или сделать наоборот. По какому бы пути ни пошла ваша компания, вам будут полезны наши практические курсы по SRE:
