Slo

Site Reliability Engineering (SRE) это одна из форм реализации DevOps. SRE-подход возник в Google и стал популярен в среде продуктовых IT-компаний после выхода одноимённой книги в 2016 году.

В статье опишем, как SRE-подход соотносится с DevOps, какие задачи решает инженер по SRE и о каких показателях заботится.

От DevOps к SRE

Во многих IT-компаниях разработкой и эксплуатацией занимаются разные команды с разными целями. Цель команды разработки выкатывать новые фичи. Цель команды эксплуатации обеспечить работу старых и новых фич в продакшене. Разработчики стремятся поставить как можно больше кода, системные администраторы сохранить надёжность системы.

Цели команд противоречат друг другу. Чтобы разрешить эти противоречия, была создана методология DevOps. Она предполагает уменьшение разрозненности, принятие ошибок, опору на автоматизацию и другие принципы.

Проблема в том, что долгое время не было чёткого понимания, как воплощать принципы DevOps на практике. Редкая конференция по этой методологии обходилась без доклада Что такое DevOps?. Все соглашались с заложенными идеями, но мало кто понимал, как их реализовать.

Ситуация изменилась в 2016 году, когда Google выпустила книгу Site Reliability Engineering. В этой книге описывалась конкретная реализация DevOps. С неё и началось распространение SRE-подхода, который сейчас применяется во многих международных IT-компаниях.

DevOps это философия. SRE реализация этой философии. Если DevOps это интерфейс в языке программирования, то SRE конкретный класс, который реализует DevOps.

Цели и задачи SRE-инженера

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

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

Цель инженера по SRE обеспечить надёжную работу системы. Он занимается тем же, что раньше входило в задачи системного администратора, решает инфраструктурные проблемы.

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

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

В задачи инженера по SRE входит ревью кода. Нужно, чтобы на каждый деплой SRE сказал: OK, это не повлияет на надёжность, а если повлияет, то в допустимых пределах. Он следит, чтобы сложность, которая влияет на надёжность работы системы, была необходимой.

• Необходимая сложность системы повышается в том объёме, которого требуют новые продуктовые фичи.
• Случайная сложность системы повышается, но продуктовая фича и требования бизнеса напрямую на это не влияют. Тут либо разработчик ошибся, либо алгоритм не оптимален.

Хороший SRE блокирует любой коммит, деплой или пул-реквест, который повышает сложность системы без необходимости. В крайнем случае SRE может наложить вето на изменение кода (и тут неизбежны конфликты, если действовать неправильно).

Во время ревью SRE взаимодействует с оунерами изменений, от продакт-менеджеров до специалистов по безопасности.

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

Целевые показатели: SLA, SLI, SLO

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

SRE подход предполагает, что все в компании приходят к общему пониманию. Для этого определяют, что такое надёжность (стабильность, доступность и т. д.) системы, договариваются о показателях и вырабатывают стандарты действий в случае проблем.

Показатели доступности вырабатываются вместе с продакт-оунером и закрепляются в соглашении о целевом уровне обслуживания Service-Level Objective (SLO). Оно становится гарантом, что в будущем разногласий не возникнет.

Специалисты по SRE рекомендуют указывать настолько низкий показатель доступности, насколько это возможно. Чем надёжнее система, тем дороже она стоит. Поэтому определите самый низкий уровень надёжности, который может сойти вам с рук, и укажите его в качестве SLO, сказано в рекомендациях Google. Сойти с рук значит, что пользователи не заметят разницы или заметят, но это не повлияет на их удовлетворенность сервисом.

Чтобы понимание было ясным, соглашение должно содержать конкретные числовые показатели Service Level Indicator (SLI). Это может быть время ответа, количество ошибок в процентном соотношении, пропускная способность, корректность ответа что угодно в зависимости от продукта.

SLO и SLI это внутренние документы, нужные для взаимодействия команды. Обязанности компании перед клиентами закрепляются в в Service Level Agreement (SLA). Это соглашение описывает работоспособность всего сервиса и штрафы за превышение времени простоя или другие нарушения.

Примеры SLA: сервис доступен 99,95% времени в течение года; 99 критических тикетов техподдержки будет закрыто в течение трёх часов за квартал; 85% запросов получат ответы в течение 1,5 секунд каждый месяц.

Почему никто не стремится к 100% доступности

SRE исходит из предположения, что ошибки и сбои неизбежны. Более того, на них рассчитывают.

Оценивая доступность, говорят о девятках:

• две девятки 99%,
• три девятки 99,9%,
• четыре девятки 99,99%,
• пять девяток 99,999%.

Пять девяток это чуть больше 5 минут даунтайма в год, две девятки это 3,5 дня даунтайма.

Стремиться к повышению доступности нормально, однако чем ближе она к 100%, тем выше стоимость и техническая сложность сервиса. В какой-то момент происходит уменьшение ROI отдача инвестиций снижается.

Например, переход от двух девяток к трём уменьшает даунтайм на три с лишним дня в год. Заметный прогресс! А вот переход с четырёх девяток до пяти уменьшает даунтайм всего на 47 минут. Для бизнеса это может быть не критично. При этом затраты на повышение доступности могут превышать рост выручки.

При постановке целей учитывают также надёжность окружающих компонентов. Пользователь не заметит переход стабильности приложения от 99,99% к 99,999%, если стабильность его смартфона 99%. Грубо говоря, из 10 сбоев приложения 8 приходится на ОС. Пользователь к этому привык, поэтому на один лишний раз в год не обратит внимания.

Среднее время между сбоями и среднее время восстановления MTBF и MTTR

Для работы с надёжностью, ошибками и ожиданиями в SRE применяют ещё два показателя: MTBF и MTTR.

MTBF (Mean Time Between Failures) среднее время между сбоями.

Показатель MTBF зависит от качества кода. Инженер по SRE влияет на него через ревью и возможность сказать Нет!. Здесь важно понимание команды, что когда SRE блокирует какой-то коммит, он делает это не из вредности, а потому что иначе страдать будут все.

MTTR (Mean Time To Recovery) среднее время восстановления (сколько прошло от появления ошибки до отката к нормальной работе).

Показатель MTTR рассчитывается на основе SLO. Инженер по SRE влияет на него за счёт автоматизации. Например, в SLO прописан аптайм 99,99% на квартал, значит, у команды есть 13 минут даунтайма на 3 месяца. В таком случае время восстановления никак не может быть больше 13 минут, иначе за один инцидент весь бюджет на квартал будет исчерпан, SLO нарушено.

13 минут на реакцию это очень мало для человека, поэтому здесь нужна автоматизация. Что человек сделает за 7-8 минут, скрипт за несколько секунд. При автоматизации процессов MTTR очень часто достигает секунд, иногда миллисекунд.

В идеале инженер по SRE должен полностью автоматизировать свою работу, потому что это напрямую влияет на MTTR, на SLO всего сервиса и, как следствие, на прибыль бизнеса.

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

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

Бюджет на ошибки

Как мы выяснили, пытаться достичь 100% стабильности не самая лучшая идея, потому что это дорого, технически сложно, а часто и бесполезно скорее всего, пользователь не оценит старания из-за проблем в соседних системах.

Поэтому команды всегда принимают некоторую степень риска и прописывают её в SLO. На основе SLO рассчитывается бюджет на ошибки (Error budget).

Бюджет на ошибки помогает разработчикам договариваться с SRE.

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

Если бюджет на ошибки не исчерпан, то у команды остаётся пространство для экспериментов. В рамках SRE подхода Error budget можно тратить буквально на всё:

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

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

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

Эксперименты в продакшене это важная часть SRE в больших командах. С подачи команды Netflix её называют Chaos Engineering.

В Netflix выпустили несколько утилит для Chaos Engineering: Chaos Monkey подключается к CI/CD пайплайну и роняет случайный сервер в продакшене; Chaos Gorilla полностью выключает одну из зон доступности в AWS. Звучит дико, но в рамках SRE считается, что упавший сервер это само по себе не плохо, это ожидаемо. И если это входит в бюджет на ошибки, то не вредит бизнесу.

Chaos Engineering помогает:

1. Выявить скрытые зависимости, когда не совсем понятно, что на что влияет и от чего зависит (актуально при работе с микросервисами).
2. Выловить ошибки в коде, которые нельзя поймать на стейджинге. Любой стейджинг это не точная симуляция: другой масштаб и паттерн нагрузок, другое оборудование.
3. Отловить ошибки в инфраструктуре, которые стейджинг, автотесты, CI/CD-пайплайн никогда не выловят.

Post mortem вместо поиска виноватых

В SRE придерживаются культуры blameless postmortem, когда при возникновении ошибок не ищут виноватых, а разбирают причины и улучшают процессы.

Предположим, даунтайм в квартал был не 13 минут, а 15. Кто может быть виноват? SRE, потому что допустил плохой коммит или деплой; администратор дата-центра, потому что провел внеплановое обслуживание; технический директор, который подписал договор с ДЦ и не обратил внимания, что его SLA не поддерживает нужный даунтайм. Все понемногу виноваты, значит, нет смысла возлагать вину на кого-то одного. В таком случае организуют постмортемы и правят процессы.

Мониторинг и прозрачность

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

В стандартном случае есть три уровня событий:

• алёрты требуют немедленного действия (чини прямо сейчас!);
• тикеты требуют отложенного действия (нужно что-то делать, делать вручную, но не обязательно в течение следующих нескольких минут);
• логи не требуют действия, и при хорошем развитии событий никто их не читает (о, на прошлой неделе у нас микросервис отвалился, пойди посмотри в логах, что случилось).

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

С мониторингом связан критерий прозрачности (Observability). Это метрика, которая оценивает, как быстро вы можете определить, что именно пошло не так и каким было состояние системы в этот момент.

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

Observability напрямую связана с MTTR. Чем выше Observability сервиса, тем проще определить ошибку, исправить и автоматизировать, и тем ниже MTTR.

SRE для небольших компаний и компаний без разработки

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

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

Внедрять принципы SRE можно с малого: определить SLO, SLI, SLA и настроить мониторинг. Если компания не занимается ПО, то это будут внутренние SLA и внутренние SLO. Обсуждение этих соглашений приводит к интересным открытиям. Нередко выясняется, что компания тратит на инфраструктуру или организацию идеальных процессов гораздо больше времени и сил, чем надо.

Кроме того, для любой компании полезно принять, что ошибки это нормально, и начать работать с ними. Определить Error budget, стараться тратить его на развитие, а возникающие проблемы разбирать и по результатам разбора внедрять автоматизацию.

Что почитать

В одной статье невозможно рассказать всё об SRE. Вот подборка материалов для тех, кому нужны детали.

Книги об SRE от Google:
Site Reliability Engineering
The Site Reliability Workbook
Building Secure & Reliable Systems

Статьи и списки статей:
SRE как жизненный выбор
SLA, SLI, SLO
Принципы Chaos Engineering от Chaos Community и от Netflix
Список из более чем 200 статей по SRE

Доклады по SRE в разных компаниях (видео):
Keys to SRE
SRE в Дропбоксе
SRE в Гугл
SRE в Нетфликсе

Где поучиться

Одно дело читать о новых практиках, а другое дело внедрять их. Если вы хотите глубоко погрузиться в тему, приходите на онлайн-интенсив по SRE от Слёрма. Он пройдет 1113 декабря 2020.

Научим формулировать показатели SLO, SLI, SLA, разрабатывать архитектуру и инфраструктуру, которая их обеспечит, настраивать мониторинг и алёртинг.

На практическом примере рассмотрим внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки. Разберёмся в устойчивости, Error budget, практике тестирования, управлении прерываниями и операционной нагрузкой.

Узнать больше и зарегистрироваться

Слёрм приглашает на митап Профессия SRE: практика и мифы. Поговорим про SRE с экспертами, обсудим вопросы участников.
Повестка дня:

• Что такое SRE и зачем все это нужно IT и бизнесу?
• SRE хайп или проверенный подход?
• Как с этим работать?
• Практики SRE.
• Как внедрить у себя?
• Что нужно, чтобы стать SRE-инженером?

Начало митапа: 3 ноября, вторник, 19.00 МСК.

Эксперты

Артём Артемьев. Lead SRE в Inspectorio. Знает, как помочь команде встретиться с SLI и жить дружно. Имеет успешный опыт в инцидент-менеджменте и мониторинге сложных решений, perfomance-тестировании и борьбе за каждый RPS.

Павел Селиванов. Senior DevOps Engineer в Mail.ru Cloud Solutions. На счету десятки выстроенных инфраструктур и сотни написанных пайплайнов CI/CD. Сертифицированный администратор Kubernetes. Автор нескольких курсов по Kubernetes и DevOps. Регулярный докладчик на Российских и международных IT конференциях.

Ведущий митапа: Марсель Ибраев, СТО Слёрм.

Регистрация

Приходите, будем рады встрече и вашим вопросам!

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

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

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

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

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

Что такое SRE и чем отличается от DevOps

Марсель Ибраев (МИ): Что такое 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.

А давайте-ка что-нибудь сломаем? А то всё строим и строим, чиним и чиним. Скука смертная.

Давайте сломаем так, чтобы нам за это ничего не было мало того, чтобы нас за это безобразие ещё и похвалили. А потом заново всё построим да так, что будет на порядок лучше, отказоустойчивей и быстрее.

И снова сломаем.

Думаете, это конкурс по применению самого секретного инструмента всей нашей космонавтики Big Russian Space Hammer?

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

В декабре мы проведём очередной интенсив по SRE.



Устроим небольшую ретроспективу. Вспомните, как всего лишь несколько лет назад HR устраивали забеги наперегонки, кто ухватит в свою компанию побольше DevOps-инженеров. Приз поменялся. Теперь они, как следящая система Панцирь-С1, осматривают окружающее пространство, выискивают SRE-инженеров. Я рассказывал в статье Евгений Варавва, разработчик в Google. Как описать Google в 5 словах, как живётся SRE-инженеру в Google, и как даже такая корпорация испытывает дефицит в SRE-специалистах.

На онлайн интенсиве Слёрм SRE в декабре за три дня, с 10:00 и до 19:00, вы научитесь обеспечивать быстродействие, отказоустойчивость и доступность сайтов в условиях ограниченных ресурсов, ликвидировать IT-инциденты и проводить разбор полётов так, чтобы проблемы не повторялись.

Спикеры курса:

Иван Круглов. Staff Software Engineer в Databricks. Имеет опыт в enterprise компаниях по распределенной доставке и обработке сообщений, BigData и web-stack, поиску, построению внутреннего облака, service mesh.

Павел Селиванов. Senior DevOps Engineer в Mail.ru Cloud Solutions. На счету десятки выстроенных инфраструктур и сотни написанных пайплайнов CI/CD. Сертифицированный администратор Kubernetes. Автор нескольких курсов по Kubernetes и DevOps. Регулярный докладчик на Российских и международных IT конференциях.

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

Строить: Вам предстоит сформулировать показатели SLO, SLI, SLA для сайта, состоящего из нескольких микросервисов; разработать архитектуру и инфраструктуру, которая их обеспечит; собрать, протестировать и задеплоить сайт; настроить мониторинг и алёртинг.

Ломать: Вы рассмотрите внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки. Научитесь разбираться в устойчивости, error budget, практике тестирования, управлении прерываниями и с операционной нагрузкой.

Чинить: Вас натренируют быстро и эффективно организовать работу группы по ликвидации аварии в минимальные сроки: подключить коллег, оповестить интересантов (stakeholders), выстроить приоритеты.

Изучать: Вы сможете разобрать подход к сайту с точки зрения SRE. Проанализировать инциденты. Определить, как избежать их в будущем: улучшить мониторинг, изменить архитектуру, подходы к разработке и эксплуатации, регламенты. Автоматизировать процессы.

Онлайн-интенсив SRE имитирует реальные условия время на восстановление работоспособности сервиса будет предельно ограничено. Как в настоящей жизни, как в реальной рабочей ситуации.

Узнать условия курса SRE, а также изучить полную программу можно по ссылке.

Онлайн-интенсив запланирован на декабрь 2020 года. Для тех, кто оплатит участие заранее, мы подготовили скидку.

Готовы к напряжённому обучению, нестандартным задачам и внезапным авариям?

Просто не будет. Будет профессиональный рост.

Как совсем недавно была мода и высокий спрос на DevOps-инженеров, так сейчас рекрутеры крупнейших компаний ищут Site Reliability Engineer. Достаточно зайти на сайты крупнейших компаний, лидеров IT-рынка, чтобы в этом убедиться. Apple, Google, Booking, Amazon.

Site Reliability Engineering это билет в открытый мир IT. Любая страна, любая IT-компания.

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

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

Что будет на курсе:

Строить

Сформулируете показатели SLO, SLI, SLA для сайта, состоящего из нескольких
микросервисов, разработаете архитектуру и инфраструктуру, которая их обеспечит,
соберете, протестируете и задеплоите сайт, настроите мониторинг и алертинг.

Ломать

Рассмотрите внутренние и внешние факторы ухудшения SLO: ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки. Разберетесь в устойчивости, error budget, практике тестирования, управлении прерываниями и операционной
нагрузкой.

Чинить

Организуете работу группы по ликвидации аварии в минимальные сроки: подключение коллег, оповещение интересантов (stakeholders), выстраивание приоритетов. Имитация реальных условий: восстановление работоспособности сервиса в условиях предельно ограниченного времени.

Изучать

Разберете подход к сайту с точки зрения SRE. Проанализируете инциденты (причины возникновения, ход устранения). Примете решение по их дальнейшему предотвращению: улучшить мониторинг, изменить архитектуру, подход к разработке и эксплуатации, регламенты. Автоматизируете процессы.

Преподавать вам будут спикеры-практики:

Интенсив пройдёт в декабре 2020, а именно 1113 декабря. Каждый день начинаем в 10:00, проверка связи в 9:45. По расписанию занятия идут до 19:00 с перерывом на обед.

Детальную программу курса и условия вы можете увидеть на сайте курса по SRE.

Пока ещё действует акционное предложение. Осталось 28 мест из 30.

Никогда не поздно всё поменять!