Обсудим ваши цели и текущие знания. Обучение платное
Консультация с менеджером
Об интенсиве
Мы проводим этот практикум для инженеров в пятый раз. Программа сформирована с участием SRE-инженеров из зарубежных и российских компаний, таких как: Google, Booking, Databricks, TangoMe, Яндекс, Ecommpay, Leroy Merlin, Финам.
На время обучения вы станете SRE для сервиса покупки билетов в кинотеатр. Решая предложенные кейсы, вы получите представление, чем занимается SRE в реальности.
На интенсиве вы:
узнаете, как снизить ущерб от отказов в будущем.
внедрите правки прямо в прод;
узнаете, как решать конкретные проблемы, связанные с надежностью сервиса;
поймете, какие метрики собирать и как это делать правильно;
научитесь быстро поднимать продакшн силами команды;
SRE-инженером может стать как инженер эксплуатации, так и разработчик.
На интенсиве вы будете много практиковаться, а полученные навыки и знания можно адаптировать и внедрить в любую сферу.
БИЗНЕСУ
SRE решает те же проблемы, что и DevOps: увеличивает скорость выхода новых фич и налаживает процессы в команде. Но основная задача SRE – обеспечить стабильность и надежность работы сервисов, исключая ситуации, когда пользователи жалуются на сбои, а у инженеров «графики зеленые».
На интенсиве сотрудники получат представление о задачах специалиста по SRE в компании, изучат практики повышения надежности. Новая культура производства приведет к следующим изменениям:
Результаты внедрения SRE-подхода
Снижение процента отказов сервиса
Повышение скорости реагирования на отказы
Снижение рисков при выкате новых фич
Увеличение скорости разработки
Как внедрить
SRE подход — это методология работы с цифровыми продуктами. Её задача — через улучшение процессов и автоматизацию уменьшить время простоя и количество ошибок сервиса, делая бизнес, основанный на информационных системах, более предсказуемым и устойчивым.
Чтобы внедрить SRE предстоит:
определить команды разработки, где будет внедряться SRE. Экономический эффект будет максимальным, если эти команды отвечают за решения, генерирующие основную выручку;
обучить лидеров и сотрудников этих команд подходу и инструментам SRE;
сформировать процессы улучшения этих метрик.
выработать политику улучшения этих метрик (подход к мониторингу, бюджет ошибок, соответствующую автоматизацию);
определить метрики, которые будет улучшать SRE, и научиться их замерять;
В результате интенсива
Могу настроить:
мониторинг SRE-метрик (SLO, SLI, error budget) для своего сервиса. Понимаю как эти метрики выбрать;
мониторинг SRE-инфраструктурных сервисов. Умею опознавать и решать проблемы с инфраструктурой;
alerting и healthcheck;
разные методы деплоймента, знаю какие инструменты для этого существуют.
пожарную команду в случае инцидента, раздать роли коллегам и выступить лидером. Знаю, какие инцидент сервисы существуют;
надежные коммуникации между сервисами retry, timeout, circuit breaker.
Могу организовать:
Вы сможете составить план действий по внедрению SRE подхода в своей компании. Поймете, как коммуницировать с бизнесом, с коллегами в случае аварии, как принимать сервисы на поддержку.
Как проходит интенсив
ИЗУЧАЕМ ТЕОРИЮ
ЗНАКОМИМСЯ ВНУТРИ КОМАНДЫ И НАЛАЖИВАЕМ ВЗАИМОДЕЙСТВИЕ
РЕШАЕМ ПРАКТИЧЕСКИЕ КЕЙСЫ
ПОДВОДИМ ИТОГИ, РЕФЛЕКСИРУЕМ
ОБСУЖДАЕМ ОНБОРДИНГ SRE-ПОДХОДА В ВАШЕЙ КОМПАНИИ
Строим:
Наш учебный сайт состоит из нескольких микросервисов. Он агрегирует данные о сеансах, ценах и свободных местах со всех кинотеатров, показывает анонсы фильмов, дает выбрать кинотеатр, сеанс, зал и место, забронировать и оплатить билеты.
Мы сформулируем показатели SLO, SLI, SLA для этого сайта, разработаем архитектуру и инфраструктуру, которая их обеспечит, настроим мониторинг и алертинг.
Внутренние и внешние факторы начинают «портить» SLO
Ошибки разработчиков, отказы инфраструктуры, наплыв посетителей, DoS-атаки приводят к тому, что SLO ухудшаются.
Разбираем устойчивость, error budget, практику тестирования, управление прерываниями и операционной нагрузкой.
Ломаем:
Чиним:
incident response
Произошла авария. Сервис обработки платежей лег. Как действовать, чтобы восстановить работоспособность в минимальные сроки?
Организуем работу группы по ликвидации аварии: подключение коллег, оповещение интересантов (stakeholders), выстраивание приоритетов. Тренируемся работать под давлением в условиях предельно ограниченного времени.
Cмотрим на сайт и инциденты с точки зрения SRE
Разбираем подход к сайту с точки зрения SRE. Анализируем инциденты (причины возникновения, ход устранения). Принимаем решение по их дальнейшему предотвращению: улучшаем мониторинг, меняем архитектуру, подход к разработке и эксплуатации, регламенты. Автоматизируем процессы.
Изучаем:
Программа
17.06 ДЕНЬ 1: знакомство с теорией SRE, настройка мониторинга и алёртинга
В первый день вы познакомитесь с теорией SRE, научитесь настраивать мониторинг и алёртинг, а также объединитесь в команду с другими участниками интенсива.
Расскажем про метрики SLO, SLI, SLA и как они соотносятся с требованиями бизнеса. Поделимся Best Practices по настройке мониторинга. Дадим первые практические кейсы.
Введение
Обсудим цели и задачи курса, а также расскажем что такое SRE.
Тема 1: Мониторинг
Зачем нужен мониторинг
Перцентили
Alerting
Observability
Тема 2: Теория SRE
SLO, SLI, SLA
Durability
Error budget
Практика: Делаем базовый дашборд и настраиваем необходимые алерты
Практика: Добавляем на дашборд SLO/SLI + алерты
Практика: Первая нагрузка системы
Решение 1 кейса: зависимость downstream.
В большой системе существует много взаимозависимых сервисов, и не всегда они работают одинаково хорошо. Особенно обидно, когда с вашим сервисом порядок, а соседний, от которого вы зависите, периодически уходит в down.
Учебный проект окажется именно в таких условиях, а вы сделаете так, чтобы он все равно выдавал качество на максимально возможном уровне.
18.06 ДЕНЬ 2: решение проблем с окружением и архитектурой
Второй день построен вокруг решения двух кейсов: зависимость upstream и проблемы с архитектурой. Спикеры расскажут про управление инцидентами, правила для пожарной команды и работу с постмортерами (post mortem) и дадут шаблоны, которые вы сможете использовать в своей команде.
Одно дело, когда вы зависите от сервиса с низким SLO. Другое дело, когда ваш сервис является таковым для других частей системы. Так бывает, если критерии оценки не согласованы: например, вы отвечаете на запрос в течение секунды и считаете это успехом, а зависимый сервис ждёт всего 500 мск и уходит с ошибкой.
В кейсе обсудим важность согласования метрик и научимся смотреть на качество глазами клиента.
Тема 4:Инструменты варрума и алерт менеджмента.
Вest practiсe других компаний в организации инцидент-менеджмента.
Решение 3 кейса: проблемы с базой данных.
База данных тоже может быть источником проблем. Например, если не следить за replication relay, то реплика устареет и приложение будет отдавать старые данные. Причём дебажить такие случаи особенно сложно: сейчас данные рассогласованы, а через несколько секунд уже нет, и в чём причина проблемы — непонятно.
Через кейс вы прочувствуете всю боль дебага и узнаете, как предотвращать подобные проблемы.
Тема 5: Практика работы с постмортемами
Практика: Пишем постмортем по предыдущему кейсу и разбираем его со спикерами.
19.06 ДЕНЬ 3: traffic shielding и канареечные релизы
В третий день мы разберем кейс, посвященный проблеме с окружением (здесь будет подробный разбор Health Checking), а также поэтапно разберем, как внедрять SRE в компании и узнаем опыт компаний, в которых работают спикеры интенсива.
Тема 6: Health Checking
Health Check в Kubernetes
Жив ли наш сервис?
Exec probes
InitialDelaySeconds
Secondary Health Port
Sidecar Health Server
Headless Probe
Hardware Probe
Решение 4 кейса: проблема с окружением, билеты купить невозможно.
Задача Healthcheck — обнаружить неработающий сервис и заблокировать трафик к нему. И если вы думаете, что для этого достаточно сделать рутом запрос к сервису и получить ответ, то вы ошибаетесь: даже если сервис ответит, это не гарантирует его работоспособность — проблемы могут быть в окружении.
Через этот кейс вы научитесь настраивать корректный Healthcheck и не пускать трафик туда, где он не может быть обработан.
Тема 7: Способы деплоймента
Тема 8: SRE онбординг проекта
В крупных компаниях нередко формируют отдельную команду SRE, которая берёт на поддержку сервисы других отделов. Но не каждый сервис готов к тому, чтобы его можно было взять на поддержку. Расскажем, каким требованиям он должен отвечать. А также спикеры поделяться опытом, как у них проходило внедрение SRE и на какие грабли они наступали.
Подготовка
В процессе решения кейсов вам необходимо будет писать код на Python, если вы кодить не умеете, мы определим вас в команду, где эта экспертиза будет.
Также необходимо знать Linux и иметь навыки работы в кластере Kubernetes.
Спикеры интенсива
Интенсив основан на реальном опыте специалистов из крупных российских и зарубежных компаний. Программа дорабатывалась с каждым последующим интенсивом. Над данным интенсивом работали:
— Спикер Highload++ 2022 — Десятки успешных проектов по подъему нагрузки в США, Европе и России — Серьезный опыт кризис-менеджмента и ведения инцидентов — Регулярный докладчик на конференциях и митах
— На счету десятки выстроенных инфраструктур и сотни написанных пайплайнов CI/CD — Certified Kubernetes Administrator — Автор нескольких курсов по Kubernetes и DevOps — Регулярный докладчик на российских и международных IT-конференциях
Процесс оформления: 1. Оставляете заявку и получаете на почту анкету для оформления рассрочки. 2. Банк принимает решение в течение нескольких минут. 3. Заключаете сделку с банком онлайн. 4. Мы отправляем кассовый чек на эл. почту и предоставляем доступ к курсу.
Условия рассрочки: Срок: 4 месяца Первый платеж: от 0 руб. Переплата: 0 руб. Вы оплачиваете только стоимость курса, без процентов. Предоставляется только физическим лицам.