SRE: data-driven подход к управлению надёжностью систем [Slurm] [Слёрм] [2022] [Селиванов П. Федорков В. Лакосников П. Гусев М. Бухаров С.]
Проектирование надежности сайта - Site Reliability Engineering: data-driven подход к управлению надёжностью систем [Slurm] [Слёрм] Обновленный онлайн-интенсив по SRE!!!
Кому полезно
ЛЮДЯМ
SRE-инженером может стать как инженер эксплуатации, так и разработчик.
Во время обучения вы будете много практиковаться, а полученные навыки и знания можно адаптировать и внедрить в любую сферу.
БИЗНЕСУ
SRE решает те же проблемы, что и DevOps: увеличивает скорость выхода новых фич и налаживает процессы в команде. Но основная задача SRE – обеспечить стабильность и надежность работы сервисов, исключая ситуации, когда пользователи жалуются на сбои, а у инженеров «графики зеленые».
SRE подход — это методология работы с цифровыми продуктами. Её задача — через улучшение процессов и автоматизацию уменьшить время простоя и количество ошибок сервиса, делая бизнес, основанный на информационных системах, более предсказуемым и устойчивым.
На интенсиве мы:
Строим:
Наш учебный сайт состоит из нескольких микросервисов. Он агрегирует данные о сеансах, ценах и свободных местах со всех кинотеатров, показывает анонсы фильмов, дает выбрать кинотеатр, сеанс, зал и место, забронировать и оплатить билеты.
Мы сформулируем показатели SLO, SLI, SLA для этого сайта, разработаем архитектуру и инфраструктуру, которая их обеспечит, настроим мониторинг и алертинг.
Ломаем:
Внутренние и внешние факторы начинают «портить» SLO
Ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки приводят к тому, что SLO ухудшаются.
Разбираем устойчивость, error budget, практику тестирования, управление прерываниями и операционной нагрузкой.
Чиним:
incident response
Произошла авария. Сервис обработки платежей лег. Как действовать, чтобы восстановить работоспособность в минимальные сроки?
Организуем работу группы по ликвидации аварии: подключение коллег, оповещение интересантов (stakeholders), выстраивание приоритетов. Тренируемся работать под давлением в условиях предельно ограниченного времени.
Изучаем:
Cмотрим на сайт и инциденты с точки зрения SRE
Разбираем подход к сайту с точки зрения SRE. Анализируем инциденты (причины возникновения, ход устранения). Принимаем решение по их дальнейшему предотвращению: улучшаем мониторинг, меняем архитектуру, подход к разработке и эксплуатации, регламенты. Автоматизируем процессы.
Требования к участникам:
В процессе решения кейсов вам необходимо будет писать код на Python, если вы кодить не умеете, мы определим вас в команду, где эта экспертиза будет.
Также необходимо знать Linux и иметь навыки работы в кластере Kubernetes.
Спикеры курса:
Павел Селиванов
Владислав Федорков
Павел Лакосников
Максим Гусев
Сергей Бухаров
Мы проводим этот практикум для инженеров в шестой раз. Программа сформирована с участием SRE-инженеров из зарубежных и российских компаний, таких как: Google, Booking, Databricks, TangoMe, Яндекс, Ecommpay, Финам.
На время обучения вы станете SRE для сервиса покупки билетов в кинотеатр. Решая предложенные кейсы, вы получите представление, чем занимается SRE в реальности.
На интенсиве вы:
Продажник: https://slurm.io/sre
Проектирование надежности сайта - Site Reliability Engineering: data-driven подход к управлению надёжностью систем [Slurm] [Слёрм] Обновленный онлайн-интенсив по SRE!!!
Кому полезно
ЛЮДЯМ
SRE-инженером может стать как инженер эксплуатации, так и разработчик.
Во время обучения вы будете много практиковаться, а полученные навыки и знания можно адаптировать и внедрить в любую сферу.
БИЗНЕСУ
SRE решает те же проблемы, что и DevOps: увеличивает скорость выхода новых фич и налаживает процессы в команде. Но основная задача SRE – обеспечить стабильность и надежность работы сервисов, исключая ситуации, когда пользователи жалуются на сбои, а у инженеров «графики зеленые».
SRE подход — это методология работы с цифровыми продуктами. Её задача — через улучшение процессов и автоматизацию уменьшить время простоя и количество ошибок сервиса, делая бизнес, основанный на информационных системах, более предсказуемым и устойчивым.
На интенсиве мы:
Строим:
Наш учебный сайт состоит из нескольких микросервисов. Он агрегирует данные о сеансах, ценах и свободных местах со всех кинотеатров, показывает анонсы фильмов, дает выбрать кинотеатр, сеанс, зал и место, забронировать и оплатить билеты.
Мы сформулируем показатели SLO, SLI, SLA для этого сайта, разработаем архитектуру и инфраструктуру, которая их обеспечит, настроим мониторинг и алертинг.
Ломаем:
Внутренние и внешние факторы начинают «портить» SLO
Ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки приводят к тому, что SLO ухудшаются.
Разбираем устойчивость, error budget, практику тестирования, управление прерываниями и операционной нагрузкой.
Чиним:
incident response
Произошла авария. Сервис обработки платежей лег. Как действовать, чтобы восстановить работоспособность в минимальные сроки?
Организуем работу группы по ликвидации аварии: подключение коллег, оповещение интересантов (stakeholders), выстраивание приоритетов. Тренируемся работать под давлением в условиях предельно ограниченного времени.
Изучаем:
Cмотрим на сайт и инциденты с точки зрения SRE
Разбираем подход к сайту с точки зрения SRE. Анализируем инциденты (причины возникновения, ход устранения). Принимаем решение по их дальнейшему предотвращению: улучшаем мониторинг, меняем архитектуру, подход к разработке и эксплуатации, регламенты. Автоматизируем процессы.
Требования к участникам:
В процессе решения кейсов вам необходимо будет писать код на Python, если вы кодить не умеете, мы определим вас в команду, где эта экспертиза будет.
Также необходимо знать Linux и иметь навыки работы в кластере Kubernetes.
6 декабря в 19.00, установочная AMA-сессия
Обсудим цели и задачи курса, а также расскажем что такое SRE, распределим на команды.
Открытие 2 теоретических тем:
Тема 1: Мониторинг
Практика: Делаем базовый дашборд и настраиваем необходимые алерты
Практика: Добавляем на дашборд SLO/SLI + алерты
Практика: Первая нагрузка системы
Решение 1 кейса: зависимость downstream.
В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down.
Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.
13 декабря в 19.00, AMA-сессия, ответы на вопросы
AMA-сессия и ответы на вопросы
Открывается доступ к 2-му теоретическому модулю:
Решение проблем с окружением и архитектурой
Второй модуль построен вокруг решения двух кейсов: зависимость upstream и проблемы с архитектурой. Спикеры расскажут про управление инцидентами, правила для пожарной команды и работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.
Тема 3: Управление инцидентами
Тема 4: Инструменты варрума и алерт менеджмента.
Вest practiсe других компаний в организации инцидент-менеджмента.
17 декабря 15.00 - 19.00, разбор практик и кейсов
Решение 2 кейса: зависимость upstream.
Одно дело, когда вы зависите от сервиса с низким SLO. Другое дело, когда ваш сервис является таковым для других частей системы. Так бывает, если критерии оценки не согласованы: например, вы отвечаете на запрос в течение секунды и считаете это успехом, а зависимый сервис ждёт всего 500 мск и уходит с ошибкой.
В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.
Решение 3 кейса: проблемы с базой данных.
База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы — непонятно.
Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы.
Практика работы с постмортемами
Практика: Пишем постмортем по предыдущему кейсу и разбираем его со спикерами.
20 декабря в 19.00, AMA-сессия, ответы на вопросы
AMA-сессия и ответы на вопросы по предыдущим темам.
Открывается доступ к 3-му теоретическому модулю:
Traffic shielding и канареечные релизы
В третьем модуле мы разберем кейс, посвященный проблеме с окружением, а также поэтапно разберем, как внедрять SRE в компании и узнаем опыт компаний, в которых работают спикеры курса.
Тема 5: Health Checking
Тема 7: SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать. А также спикеры поделяться опытом, как у них проходило внедрение SRE и на какие грабли они наступали.
24 декабря 15.00 - 19.00, разбор практик и кейсов
Решение 4 кейса: проблема с окружением, билеты купить невозможно.
Задача Healthcheck — обнаружить неработающий сервис и заблокировать трафик к нему. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность — проблемы могут быть в окружении.
Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.
27 декабря в 19.00, AMA-сессия, подведение итогов
SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать. А также спикеры поделяться опытом, как у них проходило внедрение SRE и на какие грабли они наступали.
Обсудим цели и задачи курса, а также расскажем что такое SRE, распределим на команды.
Открытие 2 теоретических тем:
Тема 1: Мониторинг
- Зачем нужен мониторинг
- Перцентили
- Alerting
- Observability
- SLO, SLI, SLA
- Durability
- Error budget
Практика: Делаем базовый дашборд и настраиваем необходимые алерты
Практика: Добавляем на дашборд SLO/SLI + алерты
Практика: Первая нагрузка системы
Решение 1 кейса: зависимость downstream.
В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down.
Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.
13 декабря в 19.00, AMA-сессия, ответы на вопросы
AMA-сессия и ответы на вопросы
Открывается доступ к 2-му теоретическому модулю:
Решение проблем с окружением и архитектурой
Второй модуль построен вокруг решения двух кейсов: зависимость upstream и проблемы с архитектурой. Спикеры расскажут про управление инцидентами, правила для пожарной команды и работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.
Тема 3: Управление инцидентами
- Resiliencе Engineering
- Как выстраивается пожарная бригада
- Насколько ваша команда эффективна в инциденте
- 7 правил для лидера инцидента
- 5 правил для пожарного
- HiPPO — highest paid person's opinion. Communications Leader
Тема 4: Инструменты варрума и алерт менеджмента.
Вest practiсe других компаний в организации инцидент-менеджмента.
17 декабря 15.00 - 19.00, разбор практик и кейсов
Решение 2 кейса: зависимость upstream.
Одно дело, когда вы зависите от сервиса с низким SLO. Другое дело, когда ваш сервис является таковым для других частей системы. Так бывает, если критерии оценки не согласованы: например, вы отвечаете на запрос в течение секунды и считаете это успехом, а зависимый сервис ждёт всего 500 мск и уходит с ошибкой.
В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.
Решение 3 кейса: проблемы с базой данных.
База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы — непонятно.
Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы.
Практика работы с постмортемами
Практика: Пишем постмортем по предыдущему кейсу и разбираем его со спикерами.
20 декабря в 19.00, AMA-сессия, ответы на вопросы
AMA-сессия и ответы на вопросы по предыдущим темам.
Открывается доступ к 3-му теоретическому модулю:
Traffic shielding и канареечные релизы
В третьем модуле мы разберем кейс, посвященный проблеме с окружением, а также поэтапно разберем, как внедрять SRE в компании и узнаем опыт компаний, в которых работают спикеры курса.
Тема 5: Health Checking
- Health Check в Kubernetes
- Жив ли наш сервис?
- Exec probes
- InitialDelaySeconds
- Secondary Health Port
- Sidecar Health Server
- Headless Probe
- Hardware Probe
Тема 7: SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать. А также спикеры поделяться опытом, как у них проходило внедрение SRE и на какие грабли они наступали.
24 декабря 15.00 - 19.00, разбор практик и кейсов
Решение 4 кейса: проблема с окружением, билеты купить невозможно.
Задача Healthcheck — обнаружить неработающий сервис и заблокировать трафик к нему. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность — проблемы могут быть в окружении.
Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.
27 декабря в 19.00, AMA-сессия, подведение итогов
SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать. А также спикеры поделяться опытом, как у них проходило внедрение SRE и на какие грабли они наступали.
Павел Селиванов
Владислав Федорков
Павел Лакосников
Максим Гусев
Сергей Бухаров
Мы проводим этот практикум для инженеров в шестой раз. Программа сформирована с участием SRE-инженеров из зарубежных и российских компаний, таких как: Google, Booking, Databricks, TangoMe, Яндекс, Ecommpay, Финам.
На время обучения вы станете SRE для сервиса покупки билетов в кинотеатр. Решая предложенные кейсы, вы получите представление, чем занимается SRE в реальности.
На интенсиве вы:
- узнаете, как снизить ущерб от отказов в будущем.
- внедрите правки прямо в прод;
- узнаете, как решать конкретные проблемы, связанные с надежностью сервиса;
- поймете, какие метрики собирать и как это делать правильно;
- научитесь быстро поднимать продакшн силами команды;
Продажник: https://slurm.io/sre