Зачем SRE, когда есть DevOps? Метрики SLA, SLI, SLO. | Блог slurm.io
2026-02-19 18:15 Diff
https://slurm.io/blog/tpost/h6ijdoo7c1-rebyata-iz-google-ne-znali-o-devops-i-pr

«Ребята из Google не знали о DevOps и просто придумали то же колесо сами» — конспект митапа по SRE

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

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

Участники митапа:


  • Павел Селиванов — DevOps Engineer в Mail.ru Cloud Solutions. Строит DevOps, CI/CD-процессы.
  • Артём Артемьев — Lead SRE в компании Inspectorio. Помогает девопсам жить хорошо.
  • Марсель Ибраев — CTO «Слёрм».

Заметка на полях: 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.

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

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

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

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

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

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

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

Кто такой SRE-инженер? Почему это больше разработчик, чем админ


МИ: 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 и так далее. Просто с этой точки зрения любой разработчик тоже занимается автоматизацией, но почему-то его работу мы автоматизацией не называем.

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

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

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

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

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

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

Что такое SLO, SLA и Error Budget



МИ: А можешь расшифровать, что значат 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-инженер — это клей, а SRE — это хайп?



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

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

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

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

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

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

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

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

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

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

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

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

АА: Думаю, даже бывают 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. Или в то же время задуматься о введении каких-нибудь KPI, кнутов на входе, и начать разработчиков бить за баги. Тоже как вариант, наверное, тоже может работать. SRE точно не будет серебряной пулей, которая спасёт от всего. Но вот проблему стабильности, проблемы в организации IT-команды, когда есть классический конфликт между администрированием и разработкой, решить поможет.

Что должен знать 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?


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

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

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

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

Блиц по вопросам из чата


SRE должен быть свой у каждой команды?


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

Что, если сервис зависит от другого сервиса? Например, авторизации. Сервис авторизации падает сильно и надолго, это приводит к исчерпанию Error budget.


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

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

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

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

Имеет ли место SRE в компании с редкими релизами (раз в пару лет, например)?


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

Какие знания нужны, чтобы принять участие в интенсиве с пользой? Для начинающих или опытных?


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