Rivalry2

HTML Diff

1 added 1 removed

Original 2026-01-01

Modified 2026-02-19

1 <h2>"Ребята из Google не знали о DevOps и просто придумали то же колесо сами" - конспект митапа по SRE</h2>

2 Зачем нужно SRE, когда есть DevOps, что такое SLO и бюджет на ошибки, каким компаниям точно не надо внедрять новую методологию, существуют ли джуниор-инженеры по SRE и сколько платят опытным. Об этом и не только говорили на митапе Слёрма "Профессия SRE: практика и мифы".На YouTube можно посмотреть <a>видеозапись встречи</a>, а здесь мы приводим текстовую версию разговора с некоторыми сокращениями.

3 <h2>Участники митапа:</h2>

4 <ul><li>Павел Селиванов - DevOps Engineer в Mail.ru Cloud Solutions. Строит DevOps, CI/CD-процессы.</li>

5 <li>Артём Артемьев - Lead SRE в компании Inspectorio. Помогает девопсам жить хорошо.</li>

6 <li>Марсель Ибраев - CTO "Слёрм".</li>

7 </ul>Заметка на полях: Site Reliability Engineering (SRE) произносится на русском как "эс-эр-и".Марсель Ибраев (МИ): Что такое SRE: это технология, методология или профессия? Что такое SRE простыми словами?Поисковик мне выдал прекрасные статьи, где объясняется, что это набор методов, показателей и предписывающих способов обеспечения надёжности систем. На вики-словаре есть не менее интересное определение: это обеспечение надежной работы систем, обеспечение бесперебойной доступности сервисов. После такого объяснения я, разумеется, всё понял и проникся, но всё-таки, что такое SRE простыми словами?

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

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

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

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

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

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

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

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

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

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

18 ПС: Да.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

48 <h2>Что такое SLO, SLA и Error Budget</h2>

49 МИ: А можешь расшифровать, что значат SLO, SLA, SLI?АА: Думаю, все слышали про SLA (Service Level Agreement) - это договор с любой компанией об уровне предоставления услуг, где компания обязуется, что 99% времени некий сервис будет работать.

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

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

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

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

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

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

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

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

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

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

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

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

62 <h2>SRE-инженер - это клей, а SRE - это хайп?</h2>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

77 <h2>Как внедрить SRE в компании</h2>

78 МИ: Внедрение SRE, как и DevOps, - это революция или эволюция? Стоит ли пушить решение о том, что нам нужен SRE или DevOps в компании?ПC: SRE - это всё-таки конкретная, понятная методология, и в ней должна быть потребность. Поэтому путь внедрения SRE эволюционный. Cделать SRE из состояния "мы классическая компания, у нас половина на железных серверах, половина на ноутбуке под столом" я боюсь, что не выйдет. Потому что будут люди, которые скажут, что это абсолютная фигня от смузи-админов, разработчиков в узких джинсах и т. д.

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

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

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

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

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

84 SRE - это же одно из возможных решений. Если есть проблема с доступностью сервиса, стабильностью, можно задуматься об SRE. Или в то же время задуматься о введении каких-нибудь KPI, кнутов на входе, и начать разработчиков бить за баги. Тоже как вариант, наверное, тоже может работать. SRE точно не будет серебряной пулей, которая спасёт от всего. Но вот проблему стабильности, проблемы в организации IT-команды, когда есть классический конфликт между администрированием и разработкой, решить поможет.

85 <h2>Что должен знать SRE-инженер и сколько может зарабатывать</h2>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

100 <a>Вакансии SRE на Headhunter</a>

101 <h2>Что будет на интенсиве по SRE?</h2>

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

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

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

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

106 <h2>Блиц по вопросам из чата</h2>

107 <h3>SRE должен быть свой у каждой команды?</h3>

108 АА: Зависит от размера команды и важности сервиса, с которым она работает. Как правило, SRE обеспечивает платформу, инструменты и сервисы для того, чтобы команды могли скидывать свои метрики и видеть, как работает их сервис. В этом случае SRE просто обеспечивает некоторую прослойку между инфраструктурой и вашим сервисом, и в каждую команду свой SRE не нужен. Но допускаю, что может быть очень важный, либо достаточно большой сервис, куда неплохо бы выделить отдельного SRE.<h3>Что, если сервис зависит от другого сервиса? Например, авторизации. Сервис авторизации падает сильно и надолго, это приводит к исчерпанию Error budget.</h3>

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

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

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

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

113 А: Всё-таки это сделано в Google, и тут больше вопрос про надежность, а не про релизы как таковые. С редкими релизами имеет смысл собирать статистику, знать, насколько ты надежен, где что ломается и как это чинить. Можно просто два года подставлять костыли, чтобы через три года зарелизиться. Вопрос - зачем это надо, если мы все равно не можем починить быстро? Ну, можно чинить не быстро - тоже вариант, какие-то прослоечки делать.<h3>Какие знания нужны, чтобы принять участие в интенсиве с пользой? Для начинающих или опытных?</h3>

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