«Можно бить разработчиков за баги, а можно внедрить SRE» — о чём говорили на митапе Слёрма

Зачем нужно SRE, когда есть DevOps, что такое SLO и бюджет на ошибки, каким компаниям точно не надо внедрять новую методологию, существуют ли джуниор-инженеры по SRE и сколько платят опытным. Об этом и не только говорили на митапе Слёрма «Профессия SRE: практика и мифы».

На YouTube можно посмотреть видеозапись встречи, а здесь мы приводим текстовую версию разговора с некоторыми сокращениями.

Заметка на полях: Site Reliability Engineering (SRE) произносится на русском как «эс-эр-и».

Марсель Ибраев (МИ): Что такое SRE: это технология, методология или профессия? Что такое SRE простыми словами?

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

Артём Артемьев (АА): Ты давно читал про DevOps? Забей в поиске, прочтёшь почти то же самое. На самом деле SRE — это то, как в Google в своё время увидели DevOps. Получилось немного по-другому, но нечто очень похожее на DevOps.

Павел Селиванов (ПС): Тут я соглашусь. Google пишет, что SRE — это практическая имплементация методологии DevOps. И мне правда кажется, что это так.

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

МИ: В Google, получается, взяли на себя смелость опубликовать своё видение.

АА: Кстати, интересно, что у Facebook тоже есть своё видение DevOps, просто Facebook об этом не написал книжку. Не рассказал, как у них это получилось. Но у них DevOps нет. У них operations отдается всем инженерам, все инженеры так или иначе занимаются operations. Но есть люди, которые занимаются инфраструктурой, и они называются продакшн-инженерами.

ПС: У меня даже есть идея, почему Google написал такую книжку, а Facebook нет. Потому что Facebook делает сервисы для себя по большей части, а Google — для других. И когда Google надоело, что пользователи их хают, когда сервисы работают нормально, они попытались объясниться.

МИ: Получается, Google переварил DevOps, в итоге у них родился Site Reliability Engineering. Но почему тогда концепция стала такой популярной? Просто бренд сыграл, или эта штука действительно хорошо показывает себя на практике?

АА: Многие конторы ищут Святой Грааль: «вот у нас всё плохо, но сейчас мы наймём DevOps и всё полетит». С DevOps не получилось, давай теперь переименуем его в SRE.

МИ: Звучит логично.

АА: Насколько популярно, не знаю. Думаю, если собрать статистику, в скольких компаниях есть SRE… У вас в Mail.ru есть SRE?

ПС: Да.

АА: Больше, чем DevOps?

ПС: Скорее всего, да. Больше ли, чем админов — я не уверен. Mail.ru придумала, как работать хорошо, задолго до появления Docker, SRE, DevOps и всего прочего. А так как компания большая, смысла менять своё на новое и хайповое нет. Это огромные усилия. Поэтому мы по многим, особенно глобальным вещам живём на наших внутренних регламентах и инструментах. А ими занимаются сисадмины.

МИ: Непопулярно.

ПС: Зато работает.

АА: Я ещё вижу в реалиях русскоговорящего рынка, что у нас есть проблема — никто не понимает (по крайней мере, мало кто понимает), что есть проблема с DevOps. Что мы должны получить от внедрения DevOps? Как правило, все говорят про Continuous delivery, сбор метрик.

МИ: Ну да, построили пайплайны, и у нас как будто построен DevOps.

АА: Но по факту выходит, что метрики все зеленые, а пользователи жалуются. Инженеры говорят: «всё хорошо, всё работает».

МИ: Получается, SRE — это реинкарнация, нечто, что получило физическую оболочку в рамках Google. Был некий DevOps, который все понимали по-своему, и Google не исключение, они тоже поняли это по-своему, набили кучу шишек и пришли к подходу, который назвали Site Reliability Engineering.

АА: Когда Google начал выдумывать SRE, ещё DevOps не был объявлен (хотя о нём впервые заговорили в 2000 году где-то во Франции, но это было ещё не широко). Ребята из Google не знали о DevOps, просто придумали то же колесо сами.

ПC: Мне тоже кажется, что DevOps был придуман в рамках каких-то встреч и конференций (как и Agile манифест в своё время), когда люди собрались и начали думать, как сделать так, чтобы всем стало хорошо. Собрались, придумали, и кто-то дальше эту идею развивал. А Google к этому подходил иначе, с точки зрения своих внутренних проблем. Они решали конкретную задачу, да, возможно, ту же самую задачу, что и комьюнити, и очень похожими средствами, но задача была полностью практическая. Нужно было решать конкретные вещи в конкретные сроки и конкретными действиями.

МИ: Означает ли это, что концепция SRE и весь его инструментарий подойдут далеко не всем? Если заработало у Google, не факт, что заработает у других?

АА: Аналогично и для DevOps. Но смотря про что говорить. Если про то, что надо мерить SLO со стороны пользователя, наверное, это почти всем подойдет. Если про подход «катись как можно чаще», а ты запускаешь космические корабли, то катиться как можно чаще — дорого и непонятно, надо тестировать больше.

МИ: Да, ко всему нужно подходить с головой и с пониманием, что ты делаешь, а не просто гнаться за хайпом.

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

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

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

МИ: То есть глобально SRE-инженер занимается автоматизацией?

АА: Старается заниматься. Ну и DevOps тоже. Большая задача SRE — уметь падать и быстро чиниться. Та самая концепция Error budget.

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

Концепция Error budget, когда сказано, что твой сервис 5% в месяц может быть сломанным, позволяет убедиться, что команда этого сервиса не замедлилась и бежит быстро. «Move fast and break things» — не бояться немного сломать, но в то же время экспериментировать и доносить нужные ценности. Это второй аспект. Возможно, он важен только компаниям размера Google. Когда у тебя небольшая компания, вы и так все мотивированы и бежите вперёд. Error budget вас сильно не спасёт.

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

Марсель, ты говоришь, что SRE-engineer — это человек, который должен заниматься автоматизацией. Мне кажется, это может вводить в заблуждение, потому что под словом «автоматизация» мы часто понимаем набор скриптов, который сделает grep в логи, положит в такой-то файлик, а дальше этот файлик по TCP отправит туда-то — вот это автоматизация. Однострочник на Bash, скриптик на Python и так далее. Просто с этой точки зрения любой разработчик тоже занимается автоматизацией, но почему-то его работу мы автоматизацией не называем.

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

Странно было бы заопенсорсить свой набор из миллиона bash-скриптов, zabbix-шаблонов и прочего. Вывалить это всё на гитхаб и сказать: «вот, ребят, мы за десять лет существования компании накопили вот такую кучу — нате». Понятно, что это ни у кого бы не взлетело. А вот инструменты, которые делают разработчики для поддержки инфраструктуры, они действительно новые и полезные.

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

МИ: То есть SRE-инженер, как правило, из разработки. Появляется проблема, и он смотрит не на то, как это закостылить, а на то, как автоматизировать, и может написать программу или приложение, которое всё это будет обрабатывать. Ещё я слышал, что с SRE связаны системы мониторинга доступности, чтобы у нас приложение было доступно и соответствовало неким метрикам. Это тоже задача SRE-инженера? Его задача эти метрики настраивать, отслеживать — как он с ними работает?

АА: Метрики отслеживать — не задача инженера SRE. Моя задача как инженера SRE — сделать инструменты для команд, чтобы они понимали, сколько у них осталось SLO, почему он уменьшается и как выглядит работа их приложения, конкретного сервиса этой команды для конечного пользователя: какой был latency, сколько было ошибок и как это всё выглядело.

Они ко мне обращаются за помощью, когда видят, что тает их SLO и они не понимают почему. На авторизации логины стали длиннее на пару секунд, и они считают это нормальным, но это выпало из SLO, начинает выпадать из допустимого latency. Ко мне прям прибегали ребята из сервиса авторизации и спрашивали: почему у нас SLO тает, «вчера было 3 секунды, а сегодня 3,5 секунды — ничего страшного же». Но если вы договорились, что должно быть 3 секунды, то, ребят, извините.

МИ: А можешь расшифровать, что значат SLO, SLA, SLI?

АА: Думаю, все слышали про SLA (Service Level Agreement) — это договор с любой компанией об уровне предоставления услуг, где компания обязуется, что 99% времени некий сервис будет работать.

МИ: Например, сервер на хостинге? То, что мы берём в аренду.

АА: Например, строка поиска в Google. Забиваешь, что нужно найти, а он тебе ищет. SLA там 99%. То есть Google сам говорит: зуб даю, что 99% будет.

При этом инженеры боятся, что они могут ошибиться и не попасть в эти 99%, и будет совсем больно. Поэтому внутри, у себя в команде, они договариваются: вот мы хотим, чтобы было 99.9%, тогда у нас есть в запасе 0,9%, и мы точно попадём. И вот этот их внутренний договор называется SLO.

МИ: Значит, SLA — для внешних, а SLO — внутри.

АА: И считается SLO по запросам от пользователя, как правило. Чем ближе к пользователю подошел, тем лучше. Идеально, если в java-скрипте тусуются отдельные элементы в браузере, и этот скрипт репортит куда-то о том, что не удалось аджаксом скачать какой-то кусочек элемента. Потому что часто, если у нас упал самый главный nginx, то это у нас в nginx логов нет, значит запросов нет, latency хорошие, всё хорошо. А тут java-скрипт начнет говорить, что есть ошибка. Либо, если это мобильный клиент, он прямо с мобилки сыплет свои ошибки, это просто идеально: мы всё знаем и считаем.

И есть ещё SLI (Service Level Indicator) — это те параметры, о которых мы говорим. Например, задержка для клиента, как быстро он скачал страницу — это один SLI. Либо количество ошибок, сколько клиентов у нас получили пятисотый статус ответа вместо двухсотого — это второй SLI. Вот два очень распространенных SLI: latency и количество ошибок.

МИ: Ну и про Error budget расскажи. Я так понимаю, это некий бюджет, который закладывается на ошибки, на простой. Если команда разработки и в целом проект его превышает, то что-то происходит. Правильно ли я понимаю?

АА: Когда мы зафиксировали SLO и сказали, что обязуемся, чтобы 99.9% запросов валидно ответили пользователю, то у нас остались 0.01% запросов к сервису, которые могут пофейлиться. Если у нас там миллион запросов, то 0.01 от миллиона считаем. Это и есть наш Error budget или бюджет на ошибки.

Когда у нас есть в запасе эта цифра, мы в некоторых ситуациях можем не думать, что написали код, который не очень протестирован. Если у нас полно Error budget, мы можем не тратить ещё неделю на тестирование кода, а прямо сейчас выкатить его, потому что нам очень надо посмотреть, как он работает (понятно, что при этом мы должны уметь быстро откатываться и выкатывать код не на всех пользователей, а на 5%). Если код начал валиться, мы его откатили, перестали вести на него трафик и немного потратили своего Error budget. Но это позволило нам очень быстро проверить гипотезы и доставить ценности.

С другой стороны, если мы полностью потратили свой Error budget, нам нужно очень хорошо тестировать код и смотреть, на что мы его потратили: если у нас часто отваливалась база данных, то самое время отложить бэклог и заняться автоматическим переключением баз данных на slave.

ПС: Мне кажется, Error budget ещё очень полезен для оценки, какие решения сейчас нужно внедрять, в каких решениях назрела необходимость. Предположим, у нас есть сервис, который в теории доступен 100% времени. Он работает без ошибок, мы его не разрабатываем или нечасто деплоим, новые ошибки туда не приезжают. А когда мы его деплоим, у нас нет никакого rolling updates и вот этих всех модных штук, мы просто выключаем и включаем заново. И смотрим, что, например, генерируем таким образом энное количество ошибок.

При этом мы понимаем, что если деплоим раз в какое-то количество времени, то, даже несмотря на то, что никакой системы rolling updates нет, такие деплои за рамки Error budget не выходят. И это такой прекрасный показатель — сказать, когда команде нужно задумываться о технических вещах. Вот сейчас назрел момент, мы начали выходить за Error budget, давайте его пофиксим хотя быть тем, что начнём выкатываться без простоя. Или мы действительно можем выкатываться с простоем.

МИ: Если всё сложить, то получается, что SRE-инженер — это некий человек, который мыслит одновременно и в плоскости инфраструктуры, доступности приложений и в плоскости разработки. Некий «клей», который связывает эти два дела и думает больше о конечном клиенте и доступности, чем о написании кода или настройке Terraform и подобных вещах. Он вне рутины и визионирует эти процессы.

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

То есть, в DevOps команда разработки уже отвечает не только за то, чтобы код написать, кинуть админам и сказать, «нате, деплойте», админы там подеплоят, поймут, что ничего не деплоится, вернут разработчикам; разработчик скажет: «у меня работает, у вас не работает, идите разбирайтесь» — классический конфликт. В рамках философии DevOps разработчик отвечает за свой код: и написание, и его работу в продакшене.

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

МИ: Окей, с задачами SRE разобрались. Теперь другой вопрос: шумиха вокруг SRE — это хайп, или все-таки у подхода есть реальное будущее? Второй Kubernetes или временное явление?

АА: Сложно сказать, DevOps — это хайп или уже не хайп? Наверное, уже не хайп. Но если SRE — это случай DevOps, то кто-то будет его использовать, а кто-то нет.

МИ: Мне кажется, хайп спадет, но останутся те, кто нашёл в этом пользу. На первый план выйдет что-то другое.

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

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

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

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

ПС: Вот ты Марсель говоришь, «человек, который умеет всё». Но я не согласен. Артём, как ты думаешь, бывают ли джуниор SRE-инженеры?

АА: Думаю, даже бывают SRE-интерны.

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

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

МИ: Внедрение SRE, как и DevOps, — это революция или эволюция? Стоит ли пушить решение о том, что нам нужен SRE или DevOps в компании?

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

Мне понравился доклад на одной из конференций. Там был тезис, что DevOps нельзя внедрить насильственно. Единственный вариант — разогнать всю команду и набрать другую из людей, которые с DevOps знакомы. А чтобы никого не разгонять, надо взять несколько админов и послать на DevOps-конференцию. Пусть они послушают, поплюются, расскажут всем, что это фигня. Взять потом других админов или разработчиков, отправить туда. И постепенно за годик-два компания начнёт гореть идеями DevOps — и со стороны разработки, и со стороны администрирования. Тогда команды сами придут к бизнесу и скажут: «Чуваки, мы тут такую штуку знаем, давайте мы её внедрим». Из такого состояния SRE можно, пожалуй, считать революционным. Но когда нет никакого движения, никакой основы, то ничего не получится.

АА: Я вполне согласен с Павлом. Ещё часто SRE, как и DevOps, могут заносить сами владельцы бизнеса, которые хотят стабильности. Но насильно в инженера не занесёшь, надо продать, а продать тяжело, если кто-то упирается.

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

АА: Тут всегда простой вопрос — как чувствуют себя пользователи? Например, если пользователи жалуются, а графики все зеленые.

ПС: В целом да.

МИ: Как вообще вот этим мифическим SRE-инженером стать? Что нужно сделать? Какими скиллами обладать, чтобы претендовать на такую позицию?

ПС: Я недавно размышлял над этим вопросом. Думаю, особенно у нас, в России, есть проблема. Вот если бы конкретный живой человек спросил у меня, я бы ему рассказал об определённых вещах, на которые нужно посмотреть. Он бы пришёл в первую попавшуюся компанию, где нужен SRE, а ему бы начали задавать вопросы о рейдах, например, или еще каких-то странных вещах. И тут вопрос: когда вы в современной компании последний раз видели живой рейд и зачем? Наверное, это полезно знать, но честно — мне это сейчас не нужно в моей работе, и я на эти вопросы не отвечу. В большинстве случаев это не задача SRE. Есть, конечно, системщики, которые этим занимаются. Но у большинства компаний не железные сервера, а есть какое-то облако, купленное или свое, и приложение нужно эксплуатировать в рамках этого облака.

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

Современные DevOps-инструменты типа infrastructure as code, инструменты оркестрации, как Kubernetes, инструменты мониторинга — Prometheus, Grafana, возможно, и Zabbix всё еще бывает полезен. Docker. Это основной технологический список. Но очень важно то, в какую компанию вы придёте. Если ей нужны настоящие SRE, то с этим списком, скорее всего, получится пройти. Если нужны переименованные админы, то у вас начнут спрашивать про рейды и так далее.

АА: Я бы добавил, что Network тоже важен для SRE, потому что твои сервисы включаются по сети. И она, возможно, не ARP.

МИ: Да, есть такое. Я про это даже как-то рассказывал, что ездил в EPAM в гости, и мне жаловались, что сейчас растёт поколение девопсов, которые делают банальные ошибки, связанные с сетью.

МИ: Требуется ли делать упор на умение программировать как таковое или всё-таки надо знать какой-то конкретный язык?

ПС: Программирование как таковое — это когда вам объяснили на Паскале в институте общие принципы программирования, циклы, операторы, ветвления? Нет, этого будет недостаточно. Но я знаю, что нормальный программист довольно легко переходит с одного языка на другой. Особых требований к языкам нет. Есть более популярные и менее популярные.

МИ: Стоит ли учиться программированию по книгам?

АА: Мне кажется, более ценно учиться в сервисах, которые тебе предоставляют задачку и окошко, куда нужно писать код, а потом можно в соседнем окошке посмотреть решение и обсуждение, как люди до тебя пришли к этому коду.

ПС: Я думаю, про языки проще найти готовые курсы, туториалы и документацию, если язык не первый. Книжки — это скорее основы, которые в институте проходят. Но они довольно медленно устаревают. Тот же «Чистый код» читать — это хорошо.

МИ: Что конкретно должен уметь «кодить» SRE? В какую сторону смотреть?

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

МИ: Сколько зарабатывает SRE в России? У меня под рукой нет данных, но думаю, зависит от компании и требуемых скиллов.

ПС: Я тоже без понятия, но в целом про зарплату могу сказать так: когда я только начинал заниматься сопровождением, админы чаще всего получали меньше, чем разработчики на одинаковой позиции. Сейчас DevOps, SRE получают или так же, как разработчики, или больше, потому что и скилла нужно больше. Так что посмотрите на Хедхантере, сколько в среднем получают разработчики, и делайте выводы. Мне кажется, от 120–150 тысяч. Разумная верхняя граница, думаю, 250–300. Но границ, в принципе, нет.

Вакансии SRE на Headhunter

МИ: SRE — это про практику. И как раз об этом мы будем говорить на нашем интенсиве, который пройдет 21–23 мая. Будет много кейсов, с которыми сталкивается SRE-инженер.Там же мы рассмотрим на практике построение метрик, проблемы с доступностью и прочее, прямо своими руками, реальными инструментами. Павел уже упомянул экспортеры, Prometheus, графики. Будем всё это щупать, со всем этим разбираться.

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

Мы дадим вам систему и будем её ломать и заставлять вас её чинить в коде, в инфраструктуре, смотреть на метрики, на логи, объясняться с пользователями и так далее. Мы показываем то, что написано в книгах Google об SRE через призму реальной работы.

МИ: Именно так. Там будут и Павел, и Артём. Еще к нам присоединится Иван Круглов. И мы все вместе будем во всем этом разбираться.

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

АА: Если ты зависишь от другого сервиса, ты не можешь написать сервис надежнее того, от которого зависишь. Но тут есть нюансы, потому что ты можешь ретраить некоторые запросы в рамках таймаута. Посылать сразу несколько запросов. То есть, если у тебя есть сервис, от которого ты зависишь, можно в него послать одновременно три запроса. И, возможно, один из них с большей вероятностью выполнится, чем просто один отправленный запрос. Либо ты можешь договориться с бизнесом и своими пользователями, 500-я ошибка — это точно ошибка. А 403–405 могут считаться не полноценной ошибкой, а в рамках предоставления сервиса. И когда недоступен сервис, от которого ты зависишь, ты своему клиенту отдаешь код ошибки, чтобы он знал, что нужно зайти позже. И это может считаться в рамках SLO, если договориться об этом.

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

Когда сервисы общаются между собой, они же все клиенты друг друга. Поэтому все эти вещи про SLO и Error budget распространяются не только на конечного пользователя. По сути, мы для каждого сервиса компании можем объявить свои SLO и Error budget, и каждый сервис обязуется для всех своих клиентов предоставлять этот определенный уровень доступности. Причем, можно говорить не только про сами приложения и про их метрики. Мы можем говорить и про другие системы компании с теми же уровнями. Если есть команда, которая занимается сопровождением баз данных, то она может объявить свои уровни и поддерживать их. Мы внутри компании постоянно этим всем пользуемся.

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

АА: Всё-таки это сделано в Google, и тут больше вопрос про надежность, а не про релизы как таковые. С редкими релизами имеет смысл собирать статистику, знать, насколько ты надежен, где что ломается и как это чинить. Можно просто два года подставлять костыли, чтобы через три года зарелизиться. Вопрос — зачем это надо, если мы все равно не можем починить быстро? Ну, можно чинить не быстро — тоже вариант, какие-то прослоечки делать.

МИ: Отличный вопрос. Крайне желательно иметь бэкграунд разработки. У нас приложение будет на Python и, если вы админ и кодили, и делали скрипты, наверное, вы тоже разберётесь. Но, как мы уже выяснили, все-таки SRE-инженеру нужен бэкграунд разработчика. Наши приложения будут работать в Kubernetes и крайне желательно с ним тоже уметь работать. Будем использовать Grafana, Prometheus.